- Remove From My Forums
-
Question
-
Hi,
I was wondering if anyone could help me with a problem i have come across. I’m using the
exit() function in my program to close it when an error occurs. This worked fine when i created
the program at university on a linux machine but now i am attempting to set it up on a windows
machine i get the following error:error C2381: ‘exit’ : redefinition; __declspec(noreturn) differs C:\Program Files\Microsoft Visual Studio 8\VC\include\GL/glut.h(146) : see declaration of ‘exit’
I understand that there are two definitions of exit and its unsure of which to use, but what is the best way of solving the problem?
Thanks in advance,
Craig
Answers
-
I managed to solve this problem.
For those who come across this in the future i simply rearranged
#include <GL/glut.h>
#include <stdlib.h>so that they were the other way round
#include <stdlib.h>
#include <GL/glut.h>and everything was fine.
Search code, repositories, users, issues, pull requests…
Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Sign up
I get to help a lot of people learn C# programming every year. As I watch new developers grow and get used to working in C# and Visual Studio, it has become fairly clear to me that reading C# compiler errors and even their documentation is an acquired skill. I’ve made a request for Microsoft to improve the error message feedback in Visual Studio, but until that’s resolved developers still have a tough time working through early obstacles.
Because of this, I’m creating this unusual post to serve as beginner-friendly documentation to what I personally view as the most likely compiler errors a new developer is likely to encounter. Microsoft has wonderful documentation on compiler errors, and this is something that will help you out significantly as you grow, but early on a paragraph or two aimed at a beginner can be exactly what you need.
I also snuck in a few of the more interesting compiler errors I noticed about the maximum limits of the C# compiler, so even if you’re very familiar with C# at this point you’ll likely still learn a few things skimming this list.
Take a look at my list and my recommendations on these issues and let me know if you find this helpful or encounter something I missed.
CS0003 – Out of Memory
This occurs when a computer runs out of memory compiling your code. Close any unnecessary programs and reboot the machine if the problem persists.
CS0004 – Warning Treated as Error
Developers may configure projects to treat certain warnings as errors. These warnings may be specified in the build section of the project’s properties. Typically it is best to resolve the specific warning listed in the build errors since someone wanted that to be treated severely.
CS0015 – Type Name too Long
.NET requires the names of types and namespaces to be less than 1024 characters. If you find yourself getting this error, you may want to reconsider your team’s naming choices.
CS0017 – More than one entry point defined
This occurs when your program has more than one class defined with a static void main method. Remove one of them or manually set the project’s startup object in the project properties.
CS0019 – Operator ‘operator’ cannot be applied to operands of type ‘type’ and ‘type’
This occurs when you try to compare two different types in ways that cannot be compared. For example, checking to see if integer values are equal to Boolean values, subtracting a string from a number, etc. This error often occurs when developers forget what type of data is stored by a particular variable.
CS0020 – Division by Constant Zero
This occurs if you try to force a division by zero in your code. You cannot force a division by zero through a numeric literal or by using a constant for the denominator, but you can declare a variable holding 0 and use that as a denominator.
CS0021 – Cannot apply indexing to type
This occurs when you try to use an array or list-style indexer on a type that doesn’t support it. This often occurs when developers assume they’re working with an array, string, or list and are not.
CS0023 – Operator ‘operator’ cannot be applied to operand of type ‘type’
This occurs when you try to use a mathematical operator with a type that doesn’t support it. For example, trying to generate a negative value of a string. Double check that your variables are of the type you think they are and re-evaluate what you are trying to do.
CS0026 – Keyword this cannot be used in a static method
This error occurs when you are working inside of a static method and try to use the this keyword. Static methods are methods associated with the class itself and not with an instance of the class. As a result, static methods do not have access to any properties, methods, or fields on the class that are not static.
CS0029 – Cannot implicitly convert type ‘type’ to ‘type’
This occurs when you have a variable of one type and are trying to store it into a variable of another type. Some types allow you to automatically convert from one type to another (an implicit conversion), but the types you are using do not support that. You may need to use an explicit cast using (type) syntax.
CS0030 – Cannot convert type ‘type’ to ‘type’
This occurs when there is no implicit or explicit conversion between two different types. If you’re sure you need to do what you’re doing, you could create a method to convert from one type to the other.
CS0031 – Constant value ‘value’ cannot be converted to a ‘type’.
This occurs when you try to store a value into a variable type that cannot store that particular value. For example, if you try to store 5 billion into an integer (which can store values up to around 2.1 billion) you will get this compiler error. You can resolve this error by storing the value into a type that can hold larger values, such as a long.
CS0050 – Inconsistent accessibility: return type ‘type’ is less accessible than method ‘method’
This occurs when a method returns a type that has a visibility or access modifier that is more restrictive than the method and class the method is currently in. For example this error will occur if a public method in a public class returns a type that is defined as internal.
This error usually occurs when developers forget to mark a class as public. Remember that classes have a default access modifier of internal when no access modifier is specified. Typically the fix for this is to explicitly declare that class as public.
CS0051 – Inconsistent accessibility: parameter type ‘type’ is less accessible than method ‘method’
This occurs when a method takes in a parameter that is of a type that has a visibility or access modifier that is more restrictive than the method and class the method is currently in. For example this error will occur if a public method in a public class requires a parameter of a type that is defined as internal.
This error usually occurs when developers forget to mark a class as public. Remember that classes have a default access modifier of internal when no access modifier is specified. Typically the fix for this is to explicitly declare that class as public.
CS0052 – Inconsistent accessibility: field type ‘type’ is less accessible than field ‘field’
This occurs when a class has a public field that is of a type that has a visibility or access modifier that is more restrictive than the class the method is currently in. For example this error will occur if a class has a public field of a type that is defined as internal.
This error usually occurs when developers forget to mark a class as public. Remember that classes have a default access modifier of internal when no access modifier is specified. Typically the fix for this is to explicitly declare that class as public.
CS0053 – Inconsistent accessibility: property type ‘type’ is less accessible than property ‘property’
This occurs when a class has a property of a type that has a visibility or access modifier that is more restrictive than the property’s visibility. For example this error will occur if a public property is of a type that is defined as internal.
This error usually occurs when developers forget to mark a class as public. Remember that classes have a default access modifier of internal when no access modifier is specified. Typically the fix for this is to explicitly declare that class as public.
CS0060 – Inconsistent accessibility: base class ‘class1’ is less accessible than class ‘class2’
This occurs when a class inherits from another class but the subclass’s access modifier is less restrictive than the base class’s access modifier. For example this error will occur if a public class inherits from an internal class.
This error usually occurs when developers forget to mark a class as public. Remember that classes have a default access modifier of internal when no access modifier is specified. Typically the fix for this is to explicitly declare that class as public.
CS0061 – Inconsistent accessibility: base interface ‘interface 1’ is less accessible than interface ‘interface 2’
This occurs when an interface inherits from another interface but the child interface’s access modifier is less restrictive than the base interface’s access modifier. For example this error will occur if a public interface inherits from an internal interface.
This error usually occurs when developers forget to mark an interface as public. Remember that interfaces have a default access modifier of internal when no access modifier is specified, although every member of an interface is public. Typically the fix for this is to explicitly declare that interface as public.
CS0100 – The parameter name ‘parameter name’ is a duplicate
This occurs when a developer declares a method but uses the same parameter name twice in the method’s parameter list. The fix for this is generally to remove an unneeded parameter or to rename parameters so that all parameters have a different name.
CS0101 – The namespace ‘namespace’ already contains a definition for ‘type’
This occurs when a class is defined twice in the same namespace. This can occur when a class is renamed but the old file still exists, when a developer forgot to mark a class as part of a different namespace, or when a developer intended to use the partial keyword but forgot to specify it. The fix for this will vary based on which files you want and what namespaces they should live in.
CS0102 – The type ‘type name’ already contains a definition for ‘identifier’
This occurs when you declare a member such as a field twice in the same class. Often this is a symptom of using an existing variable name instead of choosing a new name.
CS0103 – The name ‘identifier’ does not exist in the current context
This error often occurs when trying to use a variable defined in another scope. This commonly occurs when you try to define a variable inside of a try block and refer to it in a catch block, when there was no guarantee that the runtime was able to create that variable and therefore the variable is not available.
The fix for this is typically to declare the variable before the try / catch block and update its value from the try block. In this way the catch block will get either the initial value of the variable or its updated value and will be able to reference it.
CS0111 – Type ‘class’ already defines a member called ‘member’ with the same parameter types
This occurs when a developer creates a duplicate method or property with an identical signature consisting of a return type and parameter types. The compiler detects that there will not be a way for code outside of the class to distinguish between one member and the other and so this error is raised. Typically when this occurs you need to either rename one of the two members, change the parameters of one of the methods, or merge the two methods together into one method.
CS0117 – ‘type’ does not contain a definition for ‘identifier’
This occurs when you are trying to call a method or use a property on an instance of an object, but there is no method or property with that name. This can be an issue with capitalization, spelling, or forgetting the name of the member you’re referring to. Code completion can help you find the correct name to use.
CS0120 – An object reference is required for the non-static field, method, or property ‘member’
This often occurs in static methods when you attempt to work with non-static members of the same class. Remember that static methods are associated with the class itself and not with a specific instance of that class. As a result, static methods cannot access properties, fields, and methods that are not marked as static.
The fix for this is often to remove the static keyword from the method that needs to access instance variables. This is counter-intuitive since the compiler pushes you towards adding static in other places, but if you follow that path to its logical conclusion all of your data becomes static eventually, so you’re better off removing the static keyword when confronted by this.
CS0122 – ‘member’ is inaccessible due to its protection level
This occurs when you are trying to call a method or use a property on an instance of an object, but that member is defined as private or protected and you are outside of the class or something that inherits from it. You may not be intended to work with the method or property you are using and you should probably look for public members that might meet your needs without compromising the class’s encapsulation.
CS0127 – Since ‘function’ returns void, a return keyword must not be followed by an object expression
This is a rarer error that occurs when you are in a method defined as void but are trying to return a specific object. Remember that void methods do not return any value so a return statement should just be listed as return;. If you find that you do need to return a value, you should change the return type of the method from void to some specific type.
CS0128 – A local variable named ‘variable’ is already defined in this scope
This occurs when you re-declare a variable that already exists. The solution for this is to either use a different variable name or to remove the type name from your statement and change it from a variable declaration to an assignment statement and re-use the existing variable.
This error often comes from copying and pasting code that declares a new variable.
CS0133 – The expression being assigned to ‘variable’ must be constant
This occurs when you are declaring a const and declaring it to another variable. Constants are evaluated at the time your code is compiled and the compiler will not know the value of your variables. As a result, constants must be set to a literal number or string value.
CS0134 – ‘variable’ is of type ‘type’. A const field of a reference type other than string can only be initialized with null.
This occurs when you are trying to declare a const of a type other than a numeric or string value. Typically, if you have a const that needs to store a reference type you should instead use readonly which is less optimized than a const but works with reference types and ensures that the value will never change.
CS0136 – A local variable named ‘var’ cannot be declared in this scope because it would give a different meaning to ‘var’, which is already used in a ‘parent or current/child’ scope
This occurs when you declare a new variable with the same name as another variable in a visible scope. The solution for this is to either use a different variable name or to remove the type name from your statement and change it from a variable declaration to an assignment statement and re-use the existing variable.
CS0145 – A const field requires a value to be provided
This occurs when you declare a const but do not provide a value. You should set a const equal to some string or numeric variable when declaring it.
CS0150 – A constant value is expected
This occurs when the compiler requires a constant value such as a numeric or string literal but a variable is defined. This can occur when you use a variable in a switch statement or when you are using an array initializer for an array with a variable size.
Switch statements cannot use cases for specific variables, though switch expressions are more flexible.
When working with arrays of varying size, you may want to avoid the use of array initializers and instead manually set the elements of the array after creation.
CS0152 – The label ‘label’ already occurs in this switch statement
This occurs when you duplicate a case statement inside of a switch statement. Typically this occurs when you didn’t notice the case already existed and you can delete your repeated case statement.
CS0160 – A previous catch clause already catches all exceptions of this or of a super type (‘type’)
The ordering of catch statements in a try / catch matters since the runtime will try to match the first catch that applies to the exception it encountered. Because of this, the compiler generates this error if it sees a more specific exception type after a less specific exception type since this results in a case where the more specific catch statement could never be reached.
Move your more specific catch statement above the less specific one to fix this error.
CS0161 – Not all code paths return a value
This occurs because the C# compiler believes that it is possible to get to the end of your method without encountering a return statement. Keep in mind that the C# compiler does very little inferences based on your if statements and even if it may not actually be possible to reach the end of the method without returning, the compiler still thinks it is.
The fix for this is almost always to add a final return statement.
CS0165 – Use of unassigned local variable
This occurs when the compiler sees a variable that is defined but not set to an initial value and determines that the value of that variable needs to be read from later on in the method before the variable is guaranteed to have its value set.
The fix for this is generally to set the variable to be equal to an initial value.
CS0176 – Static member ‘member’ cannot be accessed with an instance reference; qualify it with a type name instead
This occurs when you have a static property or field on a class but are trying to refer to it on a specific instance of that class.
Use the class name instead of the instance variable to access the static member.
CS0201 – Only assignment, call, increment, decrement, and new object expressions can be used as a statement
This typically occurs when you are performing some sort of mathematical operation but not storing the result into a variable. The compiler understands the operation but sees it has no value, so it raises the error.
The fix for this is to store the result of the mathematical operation into a variable or to remove the unnecessary line.
CS0204 – Only 65534 locals are allowed
Apparently you have a method that has over 65 thousand local variables inside of it. The compiler doesn’t like this very much and, frankly, I’m a little concerned why you’d need that many.
Reconsider your life choices.
CS0230 – Type and identifier are both required in a foreach statement
This occurs when you are writing a foreach statement without specifying all parts of the statement.
foreach statements require a variable type, a variable name, the word in, and some variable that can be enumerated over. For example: foreach (string person in people)
CS0234 – The type or namespace name ‘name’ does not exist in the namespace ‘namespace’ (are you missing an assembly reference?)
This occurs when you are trying to refer to a type via its fully-qualified name, including the namespace, but no known type exists with that namespace and type name. This can be a spelling error, a mistake as to which namespace the type lives in, or a correct namespace and type, but your project does not yet have a reference to the project the type is defined in.
If your spelling and namespaces are correct you may need to add a project reference to your project or install a package via nuget.
CS0236 – A field initializer cannot reference the non-static field, method, or property ‘name’.
This occurs when you try to define a field by referencing another field. This error exists to prevent unpredictable behavior based on which field initializers run first.
The fix for this is to set the value of the field in the constructor instead of in a field initializer.
CS0246 – The type or namespace name ‘type/namespace’ could not be found (are you missing a using directive or an assembly reference?)
This occurs when you are trying to refer to a type no known type exists with that type name in the using statements currently in your file.
This is usually a spelling error or a missing using statement at the top of your file.
If your spelling and using statements are correct you may need to add a project reference to your project or install a package via nuget.
CS0266 – Cannot implicitly convert type ‘type1’ to ‘type2’. An explicit conversion exists (are you missing a cast?)
This occurs when you are trying to store a variable of one type into a variable of another type without casting. For example, if you are trying to set a double value into an int variable you will see this error.
The statement “an explicit conversion exists (are you missing a cast)” is telling you that these types are compatible, but the compiler wants to make sure you intend to convert from one to another so it requires you to cast your variable from one type to another.
You cast variables in C# by using parentheses around a type name like this: int num = (int)myDouble;
CS0500 – ‘class member’ cannot declare a body because it is marked abstract
This occurs when you declare an abstract member inside of an abstract class, but you tried to give it a method body (using {}). Abstract members do not have method bodies.
Remove the {}’s from your abstract method. Alternatively, if you want to provide a default implementation and allow inheriting classes to optionally override yours, use virtual instead of abstract.
CS0501 – ‘member function’ must declare a body because it is not marked abstract, extern, or partial
This occurs when you try to declare a method but forget to give it a method body with {}’s.
This can also occur when you mean to define an abstract method but forgot to use the abstract keyword.
CS0506 – ‘function1’ : cannot override inherited member ‘function2’ because it is not marked “virtual”, “abstract”, or “override”
In C# you have to mark a method as virtual or abstract to be able to override it.
The fix for this is usually to add the virtual keyword to the method in the base class.
CS0507 – ‘function1’ : cannot change access modifiers when overriding ‘access’ inherited member ‘function2’
When overriding a method you must keep the same access modifier as the base method. If the access modifier needs to change, change it in all classes that have the method.
CS0508 – ‘Type 1’: return type must be ‘Type 2’ to match overridden member ‘Member Name’
When overriding a method you cannot change the return type of the method. If you think you need to return something radically different, you may need to introduce a new method instead of overriding an existing one. Alternatively, creative uses of interfaces or inheritance can allow you to return a more specific version of something from a method through polymorphism.
CS0513 – ‘function’ is abstract but it is contained in nonabstract class ‘class’
When you need a method to be abstract, the entire class needs to be abstract as well.
CS0525 – Interfaces cannot contain fields
This one is self-explanatory. An interface is a contract that defines what members need to be present. Fields in classes should be private and are implementation details that do not belong in an interface.
CS0526 – Interfaces cannot contain constructors
This one is self-explanatory. An interface is a contract that defines what members need to be present on an already-constructed class. Interfaces do not care about how an instance is created and cannot denote constructors required for a given class.
CS0531 – ‘member’ : interface members cannot have a definition
This occurs when you try to give an interface member a method body. Interfaces denote capabilities that must be in place, not how those capabilities should work.
If you think you really need a default implementation of a method, you might want to use an abstract class instead of an interface.
CS0534 – ‘function1’ does not implement inherited abstract member ‘function2’
This occurs when you inherit from an abstract class that has abstract members but do not override those members. Because of this, the compiler has no implementation for those abstract members and does not know how to handle them if they are called.
Override the inherited member or mark the inheriting class as abstract as well.
CS0535 – ‘class’ does not implement interface member ‘member’
This occurs when you implement an interface but have not provided members that match those defined in the interface. Members must match the exact type signatures of those defined in the interface and should have names that match those in the interface as well.
CS0645 – Identifier too long
This occurs when you try to name a variable or other identifier something longer than 512 letters long.
What exactly are you trying to do over there that has you naming variables this long?
CS0844 – Cannot use local variable ‘name’ before it is declared.
This occurs when you try to use a variable in a method above when that variable is declared. C# does not have hoisting like some other languages do and variables are only available after they are declared.
Reorder your statements to match your needs.
CS1001 – Identifier expected
This usually occurs when you forget the name of a variable, class, or parameter but have defined other aspects of that line of code. Check some reference materials for what you are trying to do because you’re missing something important.
CS1002 – Semicolon expected
C# requires you to end most statements with a semicolon, including this one. Add a semicolon to the end of the line and all should be well.
CS1026 – ) expected
You have too many opening parentheses and not enough closing parentheses. Check to make sure that all open-parentheses have a matching closing parentheses.
Clicking on a parentheses in Visual Studio will highlight the matching parentheses making it easier to spot the one you’re missing.
CS1033 – Source file has exceeded the limit of 16,707,565 lines representable in the PDB; debug information will be incorrect
What on earth are you even doing over there? Why would you have a source file that requires more than 16 million lines?
Don’t do that. Just no. It’s time to hire a consultant.
CS1034 – Compiler limit exceeded: Line cannot exceed ‘number’ characters
Some people like tabs. Some people like spaces. You, apparently solve this debate by removing line breaks entirely.
You should never need to have a line of code longer than 16 million characters.
CS1035 – End-of-file found, ‘*/’ expected
Your code has a block comment start (/*) but no matching end comment. Add an end comment (*/) and the compiler will be happier.
CS1039 – Unterminated string literal
It looks like you started a string somewhere but forgot to put the other quotation mark. Add it in where it needs to be.
CS1501 – No overload for method ‘method’ takes ‘number’ arguments
This occurs when you are trying to call a method with an incorrect number of arguments or parameters to that method. Check the code or documentation for the method you’re trying to call and ensure you have the correct number of arguments specified.
CS1513 – } expected (missing closing scope)
You have too many opening curly braces and not enough closing curly braces. Check to make sure that all open curly braces have a matching closing curly brace.
Clicking on a { in Visual Studio will highlight the matching } making it easier to spot the one you’re missing.
CS1514 – { expected
Your code requires a { but you didn’t provide one. This often happens after declaring a namespace or class. Check your syntax and add curly braces where they need to go.
CS1525 – Invalid expression term ‘character’
This error seems ambiguous, but most of the time when I see this error it comes from someone trying to use == to assign a value to a variable instead of using the = operator. If this is not your error, you may need to consult some documentation or reference material for valid syntax for what you’re trying to do.
CS1552 – Array type specifier, [], must appear before parameter name
This error occurs when you put [] syntax around the variable name and not around the type name when declaring an array.
Write your arrays as int[] myArray; instead of int myArray[];.
CS1604 – Cannot assign to ‘variable’ because it is read-only
This occurs when you’ve declared a readonly or const variable and are trying to set its value. You can’t do that. If you need to change its value, it can’t be readonly or const.
CS7036 – No argument given that corresponds to the required formal parameter (incorrect method call)
This error occurs when trying to call a base constructor but not specifying a parameter that is required by that constructor.
Double check your base() call and make sure the number and types of parameters lines up with a specific constructor present on your base class.
Published August 30, 2019
As explained in item 53 of Effective C++, you should “Pay attention to compiler warnings”. In the vast majority of cases, the compiler has a good reason to emit them, and in the vast majority of cases, they point out to an oversight in your code.
But in a minority of cases, you may want to deliberately write code that triggers a warning.
In such occasions, letting the warning in the compiler’s output has several drawbacks. First, you will no longer have a clean build with no errors and no warnings. This warning will always remain here, and you’ll have to check that it’s the one you decided to leave in every time you compile the code.
This doesn’t scale if there are several warnings you decide to leave, because at each build you’ll have to check them all to see if a new warning hasn’t popped up and needs to be checked.
Second, if you’re following the best practice of transforming warnings into errors, by activating the -Werror flag in gcc and clang for example, leaving a warning in is simply not an option.
Fortunately, C++ lets you block the emission of a specific warning for a portion of code. Let’s see how to do that and keep code expressive.
Different code for different compilers
Let’s take the example of the warning that warns you that you didn’t use one of the parameters of a function:
void f(int a, int b)
{
std::cout << a << '\n';
// we are not using b!
}
The compiler is able to emit a warning for this. But all compilers don’t emit the same warning.
Here is gcc’s warning, which is the same as clang’s:
warning: unused parameter 'b' [-Wunused-parameter]
And here is Visual Studio’s warning:
warning C4100: 'b': unreferenced formal parameter
You can observe that they don’t have the same text and–more importantly for our purpose–the warning is not identified the same way.
Visual Studio identifies warnings with a number (here, 4100), whereas gcc and clang use a string (here, -Wunused-parameter).
As you can imagine, that will lead to different code to disable the same warning between the compilers.
We’re going to see how to disable a warning on gcc, clang, and on Visual Studio, and in case your application has to compile on all three, how to write code that disable a warning on all compilers.
The disabling sequence
Before we get into the code for each compiler, there is something in common in the sequence of disabling a warning between all three compilers.
To disable a set of warnings for a given piece of code, you have to start with a “push” pre-processor instruction, then with a disabling instruction for each of the warning you want to suppress, and finish with a “pop” pre-processor instruction.
For example, in our case, the sequence would look like that:
// up until this line, the warning is active
// PUSH disable warning (instruction specific to the compiler, see below)
// DISABLE the warning that a parameter is not used
void f(int a, int b)
{
std::cout << a << '\n';
// we are not using b, but the compiler won't emit a warning
}
// POP disable warning, the warning is now active again
Now let’s dive into the code for each compiler.
Disabling a warning on gcc and clang
A good thing is that gcc and clang require the exact same code for disabling a warning, as far as I’m aware.
The push instruction is this:
#pragma GCC diagnostic push
Note that even though it says “GCC”, it also works for clang.
The pop instruction is this:
#pragma GCC diagnostic pop
And to disable a warning, you indicate it this way:
#pragma GCC diagnostic ignored "-Wunused-parameter"
Putting this together, to suppress the warning in our example code we write:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-parameter"
void f(int a, int b)
{
std::cout << a << '\n';
// we are not using b!
}
#pragma GCC diagnostic pop
That’s is for gcc and clang.
Disabling a warning on Visual Studio
With Visual Studio, the push instruction is this:
#pragma warning( push )
The pop instruction is this:
#pragma warning( pop )
And to disable a specific warning, we need to write code like this:
#pragma warning( disable : 4100 )
Remember, in Visual Studio warnings are identified with numbers, not names.
If we have to suppress the warning in our example code on Visual Studio, we would write this:
#pragma warning( push )
#pragma warning( disable : 4100 )
void f(int a, int b)
{
std::cout << a << '\n';
// we are not using b!
}
#pragma warning( pop )
All in all, this is not so complicated.
But what if you write code that needs to compile on gcc, clang AND Visual Studio?
That can happen if your application is deployed on multiple OSes, or if you write a library for the general population of C++ programmers.
This is where the fun begins.
Disabling a warning on gcc, clang and Visual Studio at the same time
Since disabling warnings is done at the level of the pre-processor, we’re going to need a macro. We need to write a macro that resolves to either one of the above pieces of code, depending on the compiler used.
The disabling sequence is similar between all three compilers, so we’ll write a macro for each of the three steps: push, disable and pop:
DISABLE_WARNING_PUSH
DISABLE_WARNING_UNREFERENCED_FORMAL_PARAMETER
void f(int a, int b)
{
std::cout << a << '\n';
// we are not using b!
}
DISABLE_WARNING_POP
Let’s see how to write each macro on the various compilers, and then how to write code to combine all this into a cross-compiler code. We’re going to have some macro fun.
Implementing the macros on gcc and clang
As we saw above, the push in gcc and clang is this:
#pragma GCC diagnostic push
Our first instinct could be to define the DISABLE_WARNING_PUSH like this:
#define PIPES_DISABLE_WARNING_PUSH #pragma(GCC diagnostic push)
But using DISABLE_WARNING_PUSH then fails to compile:
error: expected unqualified-id DISABLE_WARNING_PUSH ^ note: expanded from macro 'DISABLE_WARNING_PUSH' #define DISABLE_WARNING_PUSH #pragma(GCC diagnostic push)
It’s because we’re not allowed to use #pragma in a #define instruction.
To circumvent this problem, compilers commonly offers a “pragma operator”, that is not standard and differs across compilers.
In gcc and clang, it is called _Pragma, and can be used this way:
#define DISABLE_WARNING_PUSH _Pragma("GCC diagnostic push")
Note that _Pragma expects a string with quotes, hence the "GCC diagnostic push".
Similarly, the pop instruction is this:
#define DISABLE_WARNING_POP _Pragma("GCC diagnostic pop")
Now to disable the warning, we have to write this:
#define DISABLE_WARNING_UNREFERENCED_FORMAL_PARAMETER _Pragma("GCC diagnostic ignored \"-Wunused-parameter\"")
Note the \" around the name of the warning. Remember that gcc and clang identify warning with strings, and that _Pragma expects a string. This results in a string within a string, so quotes inside of quotes, which then need to be escaped.
This is not pretty. To mitigate this, we could use C++11’s raw strings literals:
#define DISABLE_WARNING_UNREFERENCED_FORMAL_PARAMETER _Pragma(R"(GCC diagnostic ignored "-Wunused-parameter")")
But this is still far from ideal. Especially if we want to disable several types of warnings, because we’d need to repeat this code over and over.
What would be nice would be to write this:
#define DISABLE_WARNING_UNREFERENCED_FORMAL_PARAMETER DISABLE_WARNING(-Wunused-parameter)
With no quotes, just the name of the warning.
Let’s see how to do that. This where the macro fun begins.
Generic macro code
To get rid of all the issues with quotes, we’re going to use the “Stringizing opeator”, which is #. As Microsoft Docs puts it, “If [the stringizing opeator] precedes a formal parameter in the macro definition, the actual argument passed by the macro invocation is enclosed in quotation marks and treated as a string literal.”
Put another way, the # operator puts quotes around a macro parameter.
The stringizing operator helps support the DO_PRAGMA trick, that consists in defining the following macro:
#define DO_PRAGMA(X) _Pragma(#X)
In short, DO_PRAGMA puts quotes around a string and passes it to the _Pragma operator.
We’re going to use it this way (we’ll see how that works step by step afterwards):
#define DISABLE_WARNING(warningName) \
DO_PRAGMA(GCC diagnostic ignored #warningName)
DISABLE_WARNING is a macro function that takes a parameter, which we can invoke like this:
DISABLE_WARNING(-Wunused-parameter)
In this case, warningName is -Wunused-parameter. So #warningName, with the stringizing operator, is "-Wunused-parameter".
Thus,
GCC diagnostic ignored #warningName
is equivalent to
GCC diagnostic ignored "-Wunused-parameter"
Finally, DO_PRAGMA(GCC diagnostic ignored #warningName) puts quotes around all that and sends it to _Pragma. Which leads to the desired result.
As a result, this macro function allows to disable several warnings with expressive code:
#define DISABLE_WARNING_UNREFERENCED_FORMAL_PARAMETER DISABLE_WARNING(-Wunused-parameter) #define DISABLE_WARNING_UNREFERENCED_FUNCTION DISABLE_WARNING(-Wunused-function) // and so on
Implementing the macro in Visual Studio
If you came out of the preceding section in one piece, the rest should glide.
Visual Studio follows the same principles as gcc and clang: you can’t put a #pragma inside of a #define directive, but there is a pragma operator to help us achieve this. But contrary to gcc, it is not called _Pragma but __pragma, with two underscores.
What’s easier in Visual Studio than in gcc and clang is that the warnings are not identified by strings but by numbers (e.g. 4100), and the __pragma operator doesn’t expect strings in quotes.
So here is how to write DISABLE_WARNING for Visual Studio:
#define DISABLE_WARNING(warningNumber) __pragma(warning( disable : warningNumber ))
The push and the pop are also straightforward:
#define DISABLE_WARNING_PUSH __pragma(warning( push )) #define DISABLE_WARNING_POP __pragma(warning( pop ))
Putting it all together
Now that we know how to disable a warning for gcc, clang and Visual Studio, let’s put this altogether in the same code, so that your application or library can run on all three compilers with the same code.
Essentially, the code is going to follow this structure:
if Visual Studio
code for Visual Studio
else if gcc or clang
code for gcc and clang
else
macros that are defined but don't do anything
To identity the compiler, we can rely on the specific macro that each of them defines:
_MSC_VERfor Visual Studio (which incidentally also gives the version of the compiler, but we won’t use this information),__GNUC__for gcc,__clang__for clang.
You’ll note that they use the naming convention that C++ programmers are not allowed to use: two consecutive underscores, and a name starting with an underscore followed by a capital letter. The very reason why we can’t use them is because they are reserved to the compiler. Like here.
Note the else part in the above code. I think it is necessary to define the same macros as in the if and else if branches. Even if you don’t use another compiler than Visual Studio, gcc or clang today, it would be a shame to halt the compilation on another compiler just because you didn’t define the macros for it.
Or perhaps you don’t want your code to run on a compiler you don’t officially support. In any case, if this is what you want then a better option is to write somewhere else some specific macro-code to prevent the code from compile on non-supported compilers.
In summary, here is all the code put together:
#if defined(_MSC_VER)
#define DISABLE_WARNING_PUSH __pragma(warning( push ))
#define DISABLE_WARNING_POP __pragma(warning( pop ))
#define DISABLE_WARNING(warningNumber) __pragma(warning( disable : warningNumber ))
#define DISABLE_WARNING_UNREFERENCED_FORMAL_PARAMETER DISABLE_WARNING(4100)
#define DISABLE_WARNING_UNREFERENCED_FUNCTION DISABLE_WARNING(4505)
// other warnings you want to deactivate...
#elif defined(__GNUC__) || defined(__clang__)
#define DO_PRAGMA(X) _Pragma(#X)
#define DISABLE_WARNING_PUSH DO_PRAGMA(GCC diagnostic push)
#define DISABLE_WARNING_POP DO_PRAGMA(GCC diagnostic pop)
#define DISABLE_WARNING(warningName) DO_PRAGMA(GCC diagnostic ignored #warningName)
#define DISABLE_WARNING_UNREFERENCED_FORMAL_PARAMETER DISABLE_WARNING(-Wunused-parameter)
#define DISABLE_WARNING_UNREFERENCED_FUNCTION DISABLE_WARNING(-Wunused-function)
// other warnings you want to deactivate...
#else
#define DISABLE_WARNING_PUSH
#define DISABLE_WARNING_POP
#define DISABLE_WARNING_UNREFERENCED_FORMAL_PARAMETER
#define DISABLE_WARNING_UNREFERENCED_FUNCTION
// other warnings you want to deactivate...
#endif
You can then use the macros this way:
DISABLE_WARNING_PUSH DISABLE_WARNING_UNREFERENCED_FORMAL_PARAMETER DISABLE_WARNING_UNREFERENCED_FUNCTION /* code where you want to disable the warnings */ DISABLE_WARNING_POP
A great responsibility
This leads to code that is both concise and portable across compilers. Indeed, if you need to support a new compiler, you can just add a new branch to the #if defined statement.
But before you get into all this, heed the advice of Effective C++ and “Pay attention to compiler warnings.” Only once you did that, and if you know what you’re doing, use the above code to silence a warning in a portion of your code.
You will also like
- What Books to Read to Get Better In C++
- How to split a string in C++
- Better Macros, Better Flags
- 3 Types of Macros That Improve C++ Code
- TODO_BEFORE(): A Cleaner Codebase for 2019
Don’t want to miss out ? Follow:
Share this post!
Это ваша первая программа на C (или C++) — она не такая уж большая, и вы собираетесь скомпилировать ее. Вы нажимаете на compile (или вводите команду компиляции) и ждете. Ваш компилятор выдает пятьдесят строк текста. Вы выбираете слова warning и error. Задумываетесь, значит ли это, что все в порядке. Вы ищите полученный исполняемый файл. Ничего. Черт возьми, думаете вы, я должен выяснить, что все это значит …
Типы ошибок компиляции
Во-первых, давайте различать типы ошибок. Большинство компиляторов покажет три типа предупреждений во время компиляции:
- предупреждения компилятора;
- ошибки компилятора;
- ошибки компоновщика.
Хоть вы и не хотите игнорировать их, предупреждения компилятора не являются чем-то достаточно серьезным, чтобы не скомпилировать вашу программу. Прочитайте следующую статью, которая расскажет вам, почему стоит дружить с компилятором и его предупреждениями. Как правило, предупреждения компилятора — это признак того, что что-то может пойти не так во время выполнения. Как компилятор узнает об этом? Вы, должно быть делали типичные ошибки, о которых компилятор знает. Типичный пример — использование оператора присваивания = вместо оператора равенства == внутри выражения. Ваш компилятор также может предупредить вас об использовании переменных, которые не были инициализированы и других подобных ошибках. Как правило, вы можете установить уровень предупреждений вашего компилятора — я устанавливаю его на самый высокий уровень, так что предупреждения компилятора не превращаются в ошибки в выполняемой программе (“ошибки выполнения”).
Тем не менее, предупреждения компилятора не должны останавливать работу вашей программы (если только вы не укажете компилятору рассматривать предупреждения как ошибки), так что они, вероятно, не так серьезны как ошибки.
Ошибки — это условия, которые препятствуют завершению компиляции ваших файлов.
Ошибки компилятора ограничены отдельными файлами исходного кода и являются результатом “синтаксических ошибок”. На самом деле, это означает, что вы сделали что-то, что компилятор не может понять. Например, выражение for(;) синтаксически не правильно, потому что цикл всегда должен иметь три части. Хотя компилятор ожидал точку с запятой, он мог также ожидать условное выражение, поэтому сообщение об ошибке, которое вы получите может быть что-то вроде:
line 13, unexpected parenthesis ‘)’
Заметьте, что ошибки компилятора всегда будут включать номер строки, в которой была обнаружена ошибка.
Даже если вы прошли процесс компиляции успешно, вы можете столкнуться с ошибками компоновщика. Ошибки компоновщика, в отличие от ошибок компилятора, не имеют ничего общего с неправильным синтаксисом. Вместо этого, ошибки компоновщика — это, как правило, проблемы с поиском определения функций, структур, классов или глобальных переменных, которые были объявлены, но не определены, в файле исходного кода. Как правило, эти ошибки будут иметь вид:
could not find definition for X
Как правило, процесс компиляции начинается с серии ошибок компиляции и предупреждений и, исправив их, вы столкнетесь с ошибками компоновщика. В свою очередь, я бы сначала исправлял ошибки компиляции, а затем ошибки компоновщика.
Ошибки компилятора — с чего начать?
Если вы столкнулись с перечнем пятидесяти или шестидесяти ошибок и предупреждений, то будет сложно определить с чего начать. Самое лучшее место, тем не менее, в начале списка. В самом деле, вы почти никогда не начинаете исправлять ошибки от конца файла до его начала по одной простой причине: вы не знаете ошибки ли они на самом деле!
Одна ошибка в верхней части вашей программы может вызвать целый ряд других ошибок компилятора, потому что эти строки могут рассчитывать на что-то в начале программы, что компилятор не смог понять. Например, если вы объявляете переменную с неправильным синтаксисом, компилятор сообщит о синтаксических ошибках, и что он не может найти объявление для переменной. Точка с запятой, поставленные не в том месте, могут привести к огромному количеству ошибок. Это происходит, потому что синтаксис C и C++ синтаксис позволяет объявить тип сразу же после его определения:
struct
{
int x;
int y;
} myStruct;
код создаст переменную, MyStruct, с местом для хранения структуры, содержащей два целых числа. К сожалению, это означает, что если вы опустите точку с запятой, компилятор будет интерпретировать это так, как будто следующая вещь в программе будет структурой (или возвращает структуру).
Что-то вроде этого:
struct MyStructType
{
int x;
int y;
}
int foo()
{}
может привести к огромному количеству ошибок, возможно, включая сообщения:
extraneous ‘int’ ignored
Все это из-за одного символа! Лучше всего начать с самого верха.
Анализ сообщения об ошибке
Большинство сообщений от компилятора будет состоять как минимум из четырех вещей:
- тип сообщения — предупреждение или ошибка;
- исходный файл, в котором появилась ошибка;
- строка ошибки;
- краткое описание того, что работает неправильно.
Вывод g++ для указанной выше программы может выглядеть следующим образом (ваши результаты могут отличаться, если вы используете другой компилятор):
foo.cc:7: error: semicolon missing after struct declaration
foo.cc это имя файла. 7 — номер строки, и ясно, что это ошибка. Короткое сообщение здесь весьма полезно, поскольку оно показывает именно то, что не правильно. Заметим, однако, что сообщение имеет смысл только в контексте программы. Оно не сообщает, в какой структуре не хватает запятой.
Более непонятным является другое сообщение об ошибке из той же попытки компиляции:
extraneous ‘int’ ignored
Программист должен выяснить, почему это произошло. Обратите внимание еще раз, что эта ошибка была вызвана проблемой в начале программы, не в строке 8, а раньше, когда в структуре не хватает точки с запятой. К счастью, понятно, что определение функции для foo было в порядке, это говорит нам о том, что ошибка должна быть где-то в другом месте программы. На самом деле, она должна быть в программе раньше — вы не будете получать сообщение об ошибке, которое указывает на синтаксическую ошибку до строки, на которой ошибка на самом деле произошла.
Это руководящий принцип вычисления ошибок компилятора: если сомневаетесь, посмотрите в программе раньше. Так как синтаксические ошибки могут позже иметь серьезные последствия, вполне возможно, что компилятор указывал номер строки, в которой на самом деле не было синтаксической ошибки!
Будет гораздо хуже, если компилятор не будет сообщать вам, что произошло ранее в программе. Даже первая ошибка компилятора, которую вы получите, может быть связана с несколькими строками до указанного предупреждения.
Обработка непонятных или странных сообщений
Есть несколько особенно сложных типов ошибок компилятора. Первый — это необъявленная переменная, которую, как вам кажется, вы объявили. Часто, вы можете указать, где именно переменная была объявлена! Проблема в том, что часто переменная просто написана с ошибкой. К сожалению, это довольно трудно увидеть, так как обычно мы читаем то, что ожидаем, а не то, что есть на самом деле. Кроме того, есть и другие причины, почему это может быть проблемой — например, проблемы с видимостью!
Чтобы разобраться в возможных проблемах, я делаю так: в строке, где находится якобы необъявленная переменная, надо выполнить поиск текстовым редактором слова под курсором (в качестве альтернативы можно скопировать имя переменной и выполнить поиск), и если я записал его неправильно, оно не найдется. Также не надо вводить имя переменной вручную, так как вы случайно можете ввести его правильно.
Второе непонятное сообщение:
unexpected end of file
Что происходит? Почему конец файла будет «неожиданным» ? Ну, здесь главное думать как компилятор; если конец файла является неожиданным, то он, должно быть, чего-то ждет. Что бы это могло быть? Ответ, как правило, «завершение». Например, закрывающие фигурные скобки или закрывающие кавычки. Хороший текстовый редактор, который выполняет подсветку синтаксиса и автоматический отступ, должен помочь исправить некоторые из этих ошибок, что позволяет легче обнаружить проблемы при написании кода.
В конечном счете, если сообщение непонятное, то подходите к проблеме, думая, как компилятор пытается интерпретировать файл. Это может быть трудно, когда вы только начинаете, но если вы обращаете внимание на сообщения и попробуете понять, что они могли бы означать, вы быстро привыкнете к общим закономерностям.
Наконец, если ничего не работает, вы всегда можете просто переписать несколько строк кода, чтобы убрать любые скрытые синтаксические ошибки, которые вы могли не увидеть. Это может быть опасно, так как вы можете переписать не ту секцию, но это может помочь.
Ошибки компоновщика
После того как вы окончательно исправили все ошибки синтаксиса, вздремнули, перекусили пару раз и морально подготовили себя к правильной компиляции программы, вы все равно можете столкнуться с ошибками компоновщика. Их часто довольно сложно исправить, потому что они не обязательно являются результатом того, что написано в вашей программе. Я вкратце опишу типичные видов ошибок компоновщика, которые можно ожидать, и некоторые пути их решения.
У вас могут возникнуть проблемы с тем, как вы настроили свой компилятор. Например, даже если включить нужные заголовочные файлы для всех ваших функций, вы все равно должны предоставить вашему компоновщику правильный путь в библиотеку, которая имеет фактическую реализацию. В противном случае, вы получите сообщение об ошибке:
undefined function
Обратите внимание на поддержку этих функций компилятором (это может произойти, если вы включите собственное объявление функции, чтобы обойти ошибку во время компиляции). Если ваш компилятор поддерживает эту функцию, то для решения проблемы обычно требуются конкретные настройки компилятора. Вам следует сообщить компилятору, где искать библиотеки и убедиться, что библиотеки были установлены правильно.
Ошибки компоновщика могут произойти в функциях, которые вы объявили и определили, если вы не включили все необходимые объектные файлы в процесс связывания. Например, если вы пишете определение класса в myClass.cpp, а ваша основная функция в myMain.cpp, компилятор создаст два объектных файла, myClass.o и myMain.o, а компоновщику будут нужны оба из них для завершения создания новой программы. Если оставить myClass.o, то у него не будет определения класса, даже если вы правильно включите myClass.h!
Иногда появляются незначительные ошибки, когда компоновщик сообщает о более чем одном определении для класса, функции или переменной. Эта проблема может появиться по нескольким причинам: во-первых, у объекта может быть два определения — например, две глобальные переменные объявлены как внешние переменные, чтобы быть доступными за пределами файла исходного кода. Это относится как к функциям, так и к переменным, и это, на самом деле, нередко случается. С другой стороны, иногда это проблема с директивами компоновщика; несколько раз я видел, как люди включают несколько копий одного и того же объектного файла в процесс связывания. И бинго, у вас есть несколько определений. Типичным проявлением этой проблемы является то, что у целого ряда функций есть несколько определений.
Последний странный тип ошибки компоновщика — сообщение
undefined reference to main
Данная ошибка компоновщика отличается от других тем, что она может не иметь ничего общего с объектом, включая файлы или правильные пути к вашей библиотеке. Напротив, это означает, что компоновщик пытался создать исполняемый файл и не смог понять, где расположена функция main(). Это может случиться, если вы забыли включить основную функцию, или, если вы попытаетесь скомпилировать код, который никогда не был отдельным исполняемым файлом (например, если вы попытались скомпилировать библиотеку).