GoLand IDE by JetBrains offers automatic deletion of redundant type conversion. But there is a message:
Delete conversion (changes semantics)
I cannot figure out what is meant by changes semantics. What does it actually change?
Extra info:
GoLand indeed shows Possibly redundant type conversion when an expression is of a floating type. In all other cases, the message is Redundant type conversion. The uncertainty in the former statement is connected to the fact that conversion from float to float is sometimes used to prevent the compiler's Fused Multiply Add (FMA) instruction selection to avoid rounding errors. Please refer to this issue for more details. I would agree, though, that changes semantic is perhaps too strict as a conversion result depends on many factors. So, I've changed the wording to may change semantics. I've also updated the inspection's description, so it contains this information. These changes will appear in GoLand 2020.3.
Related
I am learning about compilers, specifically looking at 2-phase compilers, and am confused on the certain phases where errors are detected. Let's say we have something like:
int x, y;
x = x + y + z;
Where we are trying to reference a variable that has not been declared. I think this is an error that would be detected in the front-end of the compiler. But I don't know which sub-area of the front-end would detect this error.
The three parts to the front-end are: the scanner, the parser, and the context-free analyzer. The scanner reads every single character in a statement and splits the statement up into tokens. So, I could be wrong, but I don't think the error would be detected here. The parser checks to see if the statement is syntactically correct. Here is where I start to get confused. Even though z is undeclared, the syntax of the statement is technically correct, so would the error not be detected here either? The context-free analyzer uses the symbol table and syntax tree to check the program to see if it is semantically consistent with the language definition. Here it also does type checking. Would it be here that the error would be detected? Because at this point the compiler would look in the symbol table and notice that z doesn't have a type (or that it's not in there at all?). Or is this something that would be detected by the back-end of the compiler? If it is the back-end, I don't understand why that is the case. Any clarification would be highly appreciated. Thanks.
This is ultimately compiler-dependent, but typically this would come up at the semantic analysis level, which is still in the compiler front-end.
With a traditional compiler, this couldn't be done in the scanning phase because scanners use finite automata and the language of "strings that represent proper variable scoping" isn't regular. This also typically wouldn't be done as part of parsing, since parsing usually is about building up an AST and, if it were done bottom-up, the scoping information wouldn't be available at the time that the parser determined the structure of the code.
However, the semantic analyzer has all the information necessary to find this error - it has the AST and can use that to build a symbol table, walk through all the expressions in the code, and notice that z isn't anywhere in that symbol table.
How can I disable removing leading zero for decimal, when it convert to char?
For example:
select to_char(0.1) from dual;
return .1, not 0.1.
I know than i can use format parameter, but i want that it work correct for implicit conversion.
I have a lot of plsql code for get data from database.
In some case there are conversions from float to varchar2.
For example use dbms_sql.define_array with varchar2 table when column type of request is number.
I can try find all such things and correct them (and I do it), but IMHO it is better way to set up rule for such conversions.
Thanks in advance.
Afaik you cannot alter the default format for implicit conversion.
In case you limit yourself to using the conversion in the context of inserts/updates to a given table, you might mimic the intended behaviour using database triggers. I do not see any advantage compared to an express format model in your queries for that use case.
There are some official oracle docs claiming that you can override built-in functions by re-implementing them in java. I have never done that, I do not know whether this is a generally viable method, and I would strongly discourage any attempt at tinkering with the database API (therefore, nolink is included) !
Assuming that what you aim at is feasible somehow, reconsider why you do not want to expressly indicate the conversion format. The few additional keystrokes are hardly a nuisance for the developer while the idiom contributes to a self-documenting code base.
Spend your development resources more wisely than performing micro-optimizations !
It seems that GO language does not have warnings in it. I've observed
few instances.
1. "declared and not used"(if variable is declared and not used
anywhere it gives an error and does not compile the program)
2. "imported and not used"(similarly if package is imported and not
used anywhere it gives an error and does not compile the program)
Can somebody help. If they have any pointers.
Go is trying to prevent this situation:
The boy is smoking and leaving smoke rings into the air. The girl gets
irritated with the smoke and says to her lover: "Can't you see the
warning written on the cigarettes packet, smoking is injurious to
health!"
The boy replies back: "Darling, I am a programmer. We don't worry
about warnings, we only worry about errors."
Basically, Go just wont let you get away with unused variables and unused imports and other stuff that is normally a warning on other languages. It helps put you in a good habit.
The Go Programming Language
FAQ
Can I stop these complaints about my unused variable/import?
The presence of an unused variable may indicate a bug, while unused
imports just slow down compilation. Accumulate enough unused imports
in your code tree and things can get very slow. For these reasons, Go
allows neither.
When developing code, it's common to create these situations
temporarily and it can be annoying to have to edit them out before the
program will compile.
Some have asked for a compiler option to turn those checks off or at
least reduce them to warnings. Such an option has not been added,
though, because compiler options should not affect the semantics of
the language and because the Go compiler does not report warnings,
only errors that prevent compilation.
There are two reasons for having no warnings. First, if it's worth
complaining about, it's worth fixing in the code. (And if it's not
worth fixing, it's not worth mentioning.) Second, having the compiler
generate warnings encourages the implementation to warn about weak
cases that can make compilation noisy, masking real errors that should
be fixed.
It's easy to address the situation, though. Use the blank identifier
to let unused things persist while you're developing.
import "unused"
// This declaration marks the import as used by referencing an
// item from the package.
var _ = unused.Item // TODO: Delete before committing!
func main() {
debugData := debug.Profile()
_ = debugData // Used only during debugging.
....
}
One solution for unused imports is to use goimports, which is a fork of gofmt. It automatically adds missing imports and removes unused ones (in addition to formatting your code).
http://godoc.org/code.google.com/p/go.tools/cmd/goimports
I've configured my editor to automatically run goimports whenever I save my code. I can't imagine writing go code without it now.
From what I just read, (wikipedia)
"Go's syntax includes changes from C aimed at keeping code concise and readable."
The word "concise" is very important to the compiler. I have found out
that the syntax enforced by the compiler is no longer "\n" or whitespace
agnostic. And there are no "warning" type errors.
There are good things about Go. There are some not so good things. The
attitude of no warnings is a bit extreme, especially when developing or testing
a new package. It seems that partial development is not acceptable. Warnings are not acceptable. It is either the production version or the highway. This is a very dualistic point of view. I wonder if evolution would have resulted in "life", if that had been the constraints on nature.
I can only hope that things will change. Death seems to be very beneficial at times.
I have tried Go, and I am disappointed. At my age I don't think I will return.
Why didn't C++0x deprecate implicit conversions for user defined types a.k.a. objects? Is there any project which actually uses this (mis)feature? Whenever I see a single argument constructor in a code I get to review or modify I treat it as bug and make it explicit. So far it worked well and nobody complained.
Thank you.
EDIT: Let me quote Alex Stepanov, the creator of STL:
Open your C++ book and read about the
explicit keyword! Also petition your
neighborhood C++ standard committee
member to finally abolish implicit
conversions. There is a common
misconception, often propagated by
people who should know better, that
STL depends on implicit conversions.
Not so!
Reference: A. Stepanov. C++ notes
EDIT AGAIN: No, no debate plz. I am just curious whether anyone uses implicit conversions in their work. I never seen any project which would allow implicit conversion for objects. I thought hard and couldn't come with any hypothetical scenario where implicit conversion wouldn't become a minefield. I mean C++ single argument conversions, not float->double or similar conversions inherited from C.
The obvious answer is that code written and working in C++03 is supposed to continue working with C++0x compilers.
For one thing, it would be a hugely breaking change to remove implicit conversion from the language - even if it were made optional and off-by-default with an implicit keyword.
I've done a search of comp.std.c++ and it doesn't seem to have been discussed at all in that group - though there have been some questions on the subject, no-one seems to have suggested going so far as removing it. I would certainly not go so far either: it's a feature I happily use on occasion and I do not subscribe to making all possibly-converting constructors explicit either - unless it causes real bugs.
This is my attempt to start a collection of GCC special features which usually do not encounter. this comes after #jlebedev in the another question mentioned "Effective C++" option for g++,
-Weffc++
This option warns about C++ code which breaks some of the programming guidelines given in the books "Effective C++" and "More Effective C++" by Scott Meyers. For example, a warning will be given if a class which uses dynamically allocated memory does not define a copy constructor and an assignment operator. Note that the standard library header files do not follow these guidelines, so you may wish to use this option as an occasional test for possible problems in your own code rather than compiling with it all the time.
What other cool features are there?
From time to time I go through the current GCC/G++ command line parameter documentation and update my compiler script to be even more paranoid about any kind of coding error. Here it is if you are interested.
Unfortunately I didn't document them so I forgot most, but -pedantic, -Wall, -Wextra, -Weffc++, -Wshadow, -Wnon-virtual-dtor, -Wold-style-cast, -Woverloaded-virtual, and a few others are always useful, warning me of potentially dangerous situations. I like this aspect of customizability, it forces me to write clean, correct code. It served me well.
However they are not without headaches, especially -Weffc++. Just a few examples:
It requires me to provide a custom copy constructor and assignment operator if there are pointer members in my class, which are useless since I use garbage collection. So I need to declare empty private versions of them.
My NonInstantiable class (which prevents instantiation of any subclass) had to implement a dummy private friend class so G++ didn't whine about "only private constructors and no friends"
My Final<T> class (which prevents subclassing of T if T derived from it virtually) had to wrap T in a private wrapper class to declare it as friend, since the standard flat out forbids befriending a template parameter.
G++ recognizes functions that never return a return value, and throw an exception instead, and whines about them not being declared with the noreturn attribute. Hiding behind always true instructions didn't work, G++ was too clever and recognized them. Took me a while to come up with declaring a variable volatile and comparing it against its value to be able to throw that exception unmolested.
Floating point comparison warnings. Oh god. I have to work around them by writing x <= y and x >= y instead of x == y where it is acceptable.
Shadowing virtuals. Okay, this is clearly useful to prevent stupid shadowing/overloading problems in subclasses but still annoying.
No previous declaration for functions. Kinda lost its importance as soon as I started copypasting the function declaration right above it.
It might sound a bit masochist, but as a whole, these are very cool features that increased my understanding of C++ and general programming.
What other cool features G++ has? Well, it's free, open, it's one of the most widely used and modern compilers, consistently outperforms its competitors, can eat almost anything people throw at it, available on virtually every platform, customizable to hell, continuously improved, has a wide community - what's not to like?
A function that returns a value (for example an int) will return a random value if a code path is followed that ends the function without a 'return value' statement. Not paying attention to this can result in exceptions and out of range memory writes or reads.
For example if a function is used to obtain the index into an array, and the faulty code path is used (the one that doesn't end with a return 'value' statement) then a random value will be returned which might be too big as an index into the array, resulting in all sorts of headaches as you wrongly mess up the stack or heap.