I recently came across a piece of code which uses
the pragma directive
#error Error ! Define [_HOS_ | _HOS_OV_ | _HOV_].
This code is from the ADOC-C jacobian computation routine.
The problem is that in C++ visual studio 2010 there is a curly red line below the #error indicating there is some problem within that line.
The code also fails to compile giving error message at that line
Is there a syntax issue or are those [_HOS_ | _HOS_OV_ | _HOV_] not defined at that point, and intelliSense knows that resulting in curly red line indicating some problem?
The author of that code intended to have an error when not at least one of the tags named in the error message is defined. You should have a look at the documentation of the ADOC-C stuff if s.th. is mentioned there about these tags.
The intent of the #error directive is to create compile errors. It's usually a way for the programmer who wrote the code to tell the programmer that's trying to compile and use it "You did something wrong, this won't work!". The string following the directive is the message that should be shown to the programmer trying to compile the code.
You should check what directives are around this one, for example are there any #ifdefs that cause it to be executed. Then you should lookup the conditions in which they executed (e.g. not defining the things the error lists) and look for a way to make them go away.
The problem is that in C++ visual studio 2010 there is a curly red line below the #error indicating there is some problem within that line.
Visual Studio 2010 does not recognize #error preprocesor syntax anymore. It only recognize #pragma warning
Related
When I try to run the following header
https://github.com/marmalade/glib/blob/master/glibconfig.h
in Microsoft Visual Studio, I get the following error: 'G_CAN_INLINE': macro redefinition. What is the reason for this? Any help is appreciated. Thanks.
There's actually a trick for this which might work for you. What you can do is this:
Comment out the #define(s) for G_CAN_INLINE in glibconfig.h (make a copy first!).
After the relevant #include, add (temporarily) the following line to the source file that is generating the compiler error:
int any_old_variable_name = G_CAN_INLINE;
Give Intellisense a moment to catch up.
Right-click on G_CAN_INLINE and select 'Go To Definition'.
With a bit of luck, VS will then show you where that macro is (also) being defined and that should help you figure out what to do.
Having said which, G_CAN_INLINE doesn't look to be all that important. You will probably find that you can just #undef it before you include glibconfig.
According to cppreference [[deprecated("message string")]] we should be able to use the symbol but in VS results in error instead.
For example I wan't to issue a warning for ANSI methods in UNICODE builds and vice versa:
#ifdef UNICODE
[[deprecated("This method does not work well in UNICODE builds")]]
#endif // UNICODE
void f() {}
compiler doesn't let me compile, but standard says the attribute should allow usage but issue a warning message.
How to resolve this?, btw. my project is set to maximum conformance with the standard.
What ever the reason for VS going against the standard, is there a better way to issue a warning for above case?
Very much late to the party, but this cost me a couple of hours this morning.
By default, Visual Studio and the sdl (Security Development Lifecycle) compile flag treat
[[deprecated]] as an error. Whether or not you agree with this or not, that's how they do it.
To fix this go to Configuration Properties -> C/C++ -> Command Line and add /sdl /w34996
The /wX part represents the severity of the warning, and the rest is the error you want to report as a warning.
I hope this saves people some time.
I was able to get the compiler to treat [[deprecated]] as a warning by adding
/w34996
to the compiler options, as suggested in the responses in following link
https://developercommunity.visualstudio.com/content/problem/786502/cant-treat-deprecated-warning-as-warning-with-wx.html
is there a better way to issue a warning for above case?
There's no other way of warning about usage of a function than deprecation attribute in standard C++ at least that I know of.
Msvc has other alternatives such as #pragma deprecated(f), but those are not better.
How to resolve this?
Assuming you haven't configured your compiler to treat warnings as errors, you could proceed with writing a bug report to the maintainers.
I haven't tested it with Visual Studio, but in my case the following helped and probably is more generic:
On that error usually warnings are treated as errors with the compiler flag -Werror, that is automatically set in Visual Studio. That is the reason way a class or function marked with [[deprecated]] results in an error. To avoid explicitly that error and output it just as a warning, the compiler flag -Werror -Wno-error=deprecated-declarations can be set. In CMake it would look like:
add_compile_options(-Werror -Wno-error=deprecated-declarations)
When using the std::map with types that use trivial, non-throwing, copy constructors, a compiler warning/error is thrown (warning level 4, release mode) for unreachable code in xtree. This is because the std::map has a try-catch in it that helps maintain the state of the tree in the case of an exception, but the compiler figures out that the catch statement will never be called if the stored elements don't throw. These warnings can be easily suppressed with the following lines at the top of the .cpp file:
#pragma warning(push)
#pragma warning(disable:4702)
#include <xtree>
#pragma warning(pop)
Is there a way to bypass this warning/error without changing the warning level, building in debug, suppressing the warning, or using a different type in the map? Is there plans to change this in the standard library?
Update:
Maybe it is compiler specific. I am using vc7.
The error is below:
c:\program files\microsoft visual studio .net 2003\vc7\include\xtree(1116) : error C2220: warning treated as error - no 'object' file generated
c:\program files\microsoft visual studio .net 2003\vc7\include\xtree(1116) : warning C4702: unreachable code
Apparently the xtree is used by the std::map.
Unfortunately it looks like xtree is part of the underlying implementation of map in VC7, and as such there isn't much that can be done to mitigate it. It looks like it's a bug in the standard library.
Is it a possibility to use a newer compiler? I'm fairly sure there are free downloads of more recent versions of the compiler you could use, and perhaps they've fixed this issue.
If that's not an option, probably the best solution is to wrap the include of map into your own private header, complete with a comment and the #pragma+include <xtree> lines you already discovered (in addition to an include of map. This way you hide the workaround from normal use.
I am having a service written in C++ and i use VC++ 6.0.
When i build this service i get a strange message as shown (The letter 'T'coming during compilation). Though it does not cause any problem, i would like to know why this message occurs.
Compiling...
SerString.cpp
SerSwitcher.cpp
Smtp.cpp
SysConfigBlob.cpp
T
T
TransLateReportNames.cpp
Perhaps this explains it?
Try to look for #warning T or #pragma message ("T") inside your code / headers.
eMbedded Visual C++ 3 project, that is building for PocketPC 2000. On the ARM build, the linker throws the following error:
fatal error LNK1223: invalid or corrupt file: file contains invalid pdata contributions
On SH3, the project compiles, links, and works. The project also works when built for ARM on Visual C++ 2005, but I need to test builds specifically from eVC3.
Any ideas, please? What's a pdata contribution and how do I affect (or disable) those? It's something to do with exception handling; I've tried disabling SEH by specifying /EHsc, to no effect.
Very weird. I tried commenting out everything in the file. The error went away when I commented out a function that was extern "C" void __declspec(naked) with no body (body #ifdef'fed away). I have similar functions in the project, but they did not throw any errors like this. Maybe a compiler bug...
No idea from me, but the Google-mind dredged up this thread which might give you a clue how to fix/workaround the problem... maybe:
http://www.pocketpcjunkies.com/Uwe/Forum.aspx/wince-pb/7477/Link-error-during-DEBUG-build
After looking at the error more closely, I finally figured out that this is
a side-effect of my hijacking of SC_SetDaylightTime() in the kernel with my
own version. Apparently, something that I'm doing in my code there is
causing the compiler to generate pdata entries that are wrong in some way.
A strategically-placed #ifndef worked around it.