compiler-warnings

I am working on a calculation module using C#, and I bumped on this : double v = 4 / 100; I know this is a wrong initialization that returns v = 0.0 instead of v = 0.04 The c# rules says I must ensure at least one of the member is a double , like this : double v = (double) 4 / 100; double v = 4.0 / 100; However, I have many many initializations of that kind that involves integer variables operations, and I feel lazy to browse my code line by line to detect such mistakes. Instead, is it possible to get warned by the compiler about this ? Alright, after some playing around and what not, I have a

Just learned here that -Wsequence-point comiplation flag will pop a warning when the code can invoke UB. I tried it on a statement like int x = 1; int y = x+ ++x; and it worked very nicely. Until now I have compiled with gcc or g++ only using -ansi -pedantic -Wall . Do you have any other helpful flags to make the code more safe and robust? gsamaras As alk summed up, use these flags: -pedantic -Wall -Wextra -Wconversion First, I think you don't want to use the -ansi flag, as suggested in Should I use "-ansi" or explicit "-std=..." as compiler flags? Secondly, -Wextra seems to be quite useful

I'm getting a strange warning: The predefined type 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll' There is no line number given, so it's hard to figure out what it's on about. The compiler error code is CS1685 Are you using someone's dll (or your own) which had implemented this attribute (with exactly the same name) itself as a means of using some c# 3.0 features on pre .Net 3.5 runtimes? (A common trick) This is the probable cause.

I am using fully qualified name of the enum inside a method in one of my class. But I am getting compiler warning which says "warning C4482: nonstandard extension used: enum 'Foo' used in qualified name" . In C++, do we need to use enums without the qualified name? But IMO, that looks ugly. Any thoughts? Yes, enums don't create a new "namespace", the values in the enum are directly available in the surrounding scope. So you get: enum sample { SAMPLE_ONE = 1, SAMPLE_TWO = 2 }; int main() { std::cout << "one = " << SAMPLE_ONE << std::endl; return 0; } Poy To make it clean, replace: enum Fruit {

I've an application which includes an external library I developed, and I'm getting the following warning message every time I compile using the device as target: mylib-release-iphonesimulator.a, file was built for unsupported file format which is not the architecture being linked (armv7). I've 2 versions of the library, both added into the project. One built for the iphonesimulator and the other for iphoneos. Even though it works well on any target (seems the compiler takes the correct version of the library depending of the target) that sort of warning becomes anoying. Is any way to get rid

This question already has an answer here: Could not load file or assembly or one of its dependencies 35 answers Writing a routine WinForms app that references a few custom libraries written by myself. I am building one particular library which depends on another library and, when I do, I get the following warning message: "Could not load file or assembly 'RHLib' Version 1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified" The application functions, there are no error messages, but I am one of those that likes a completely clean

First 10 minutes learning rust, I'm given 58 lint options and I'm thinking: gcc has a solution to this. To be clear: I want to enabled all warnings/lints ( -Wall ) and treat all warnings as hard errors ( -Werror ). Something that would go in the .toml file? A workaround? gcc’s -Werror becomes rustc --deny warnings or the crate attribute #![deny(warnings)] . You can also pass the flag through an environment variable: RUSTFLAGS="--deny warnings" . -Wall or -Weverything aren’t really necessary in Rust; most of the sorts of things that would be covered by it are already compilation errors or lints