When browsing the source of the open source .NET Framework 4.7 I stumbled across the C++ header sal.h and found a line of code saying [source_annotation_attribute( SA( Method ) )] which seems to be similar to attributes and the AttributesUsage class in C#.
Now I know that generally, there are no user defined attributes in C++ as there are in C#, and my first guess was that [source_annotation_attribute( SA( Method ) )] is just a macro, but it is neither defined in sal.h nor in any other headers, since sal.h does not #include any.
My next guess is that [source_annotation_attribute] is actually built in the MSVC, just like for e.g. [[noreturn]] attribute.
I would be glad if somebody could shed some light on what it actually is and if I can declare my own attributes similar to that, if it is not built into the compiler.
If you want to see for your self, the particular file is \Source\externalapis\legacy\vctools\vc12\inc\vc\sal.h and the attribute occurs (among others) in line 1934.
Here is an example on the usage in sal.h:
[source_annotation_attribute( SA( Method ) )]
struct __M_
{
#ifdef __cplusplus // [
__M_();
#endif // ]
int __d_;
};
typedef struct __M_ __M_;
Many thanks in advance.
To conclude what #VTT has already said, it looks like the source_annotation_attribute is a compiler inbuilt construct, which is shipped as part of a Microsoft extension to C++
(even if it is not mentioned there because it is an implementation detail, meant for internal use only) that is valid only when compiled with the compiler switch /Ze
What adds to this is the fact that Microsofts SAL is built in deeply in Visual Studio
i.e.
Build -> Run Code Analysis on Solution
and since Visual Studio (obviously) uses their MSVC compiler, it is not too implausible that Microsoft would not build any internal constructs like this in their compilers.
Related
Compiling one of my projects that uses gRPC with the latest Visual Studio 2019 16.5 preview 2 compiler gives rise to this warning:
1>D:\...\grpcpp\impl\codegen\security\auth_context.h(38,19): warning C4996: 'std::iterator<std::input_iterator_tag,const grpc::AuthProperty,ptrdiff_t,const grpc::AuthProperty *,const grpc::AuthProperty &>': warning STL4015: The std::iterator class template (used as a base class to provide typedefs) is deprecated in C++17. (The <iterator> header is NOT deprecated.) The C++ Standard has never required user-defined iterators to derive from std::iterator. To fix this warning, stop deriving from std::iterator and start providing publicly accessible typedefs named iterator_category, value_type, difference_type, pointer, and reference. Note that value_type is required to be non-const, even for constant iterators. You can define _SILENCE_CXX17_ITERATOR_BASE_CLASS_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning.
Before submitting a bug report, I thought I've check here if the gRPC developers are already aware of this?
gRPC is currently dependant on Absel that is reliant on C++11. You should avoid using two different C++ standards in your applications to avoid template incompatibilities. There is a longer discussion on Absel C++11 vs C++17 versions here: https://github.com/abseil/abseil-cpp/issues/259.
You can check out the Absel pages for more details at https://github.com/abseil/abseil-cpp.
The position that gRPC doesn't support C++17 is a little surprising. I might be missing it, but I don't see any mention on the main grpc page that anything beyond C++11 isn't supported. The only support matrix I was able to find was: https://grpc.io/docs/#official-support
In general both protobuf and gRPC usage will cause a slew of warnings in Visual Studio, unrelated to this error. For generated cc files, suppressing warnings 4267, 4996, and 4244 is helpful.
For this C++17 warning/error, since the issue is in a header, you'll hit the issue on your own, non-generated cpp files. You don't want to disable such warnings/errors on every file that uses the header, because then you'll mask your own issues. I currently work around by creating grpcpp.suppress_errors.h:
#pragma once
#pragma warning ( push )
#pragma warning( disable : 4996)
#include <grpcpp/grpcpp.h>
#pragma warning ( pop )
Then instead of including <grpcpp/grpcpp.h>, include grpcc.suppress_errors.h . It's a bit silly, but it will keep your own code clean from suppressions.
aggieNick02's answer didn't fix it for me. But I could could manage to suppress the errors in Visual Studio like so:
I added _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS; to the preprocessor definitions.
Not as optimal as aggieNick02's answer, but at least this kept me going.
I got grpc from vcpkg, if that info helps somebody:
1.37.0 3
dc35791a568aacf855355bcfcdff978ec22e69d3
2021-07-27
abseil (2021-03-24), c-ares (1.17.1), grpc (1.37.0), openssl (1.1.1k), protobuf (3.15.8), protobuf (3.15.8), re2 (2020-10-01), upb
(2020-12-19), zlib (1.2.11)
gRPC does not currently support C++17. We're currently using C++11. You should probably use whatever flags are necessary to have your compiler enforce C++11 semantics.
The "not", "and", etc... are keywords in C++ (macros in C). Is there any way to "enable" them in Visual Studio 2013? I'm able to use the words as macroses with iso646.h included. But VS seems not be able to recognize them as keywords.
Using /Za seems to enable them without including iso646.h, see it live, the following program produces an error without using /Za but works fine otherwise:
int main()
{
int x = 1, y = 0 ;
if (x and y)
{
//...
}
return 0;
}
As ta.speot.is indicates /Za disables extensions, the following documentation indicates you must include ios646.h otherwise:
Under /Ze, you have to include iso646.h if you want to use text forms of the following operators:
and it lists the alternative tokens below.
Note, I knew I saw this before, I include a link to a bug report for this in my answer to a similar question. Although this does not include the workaround noted above.
Note 2: Cheers and hth. - Alf indicates that there may be many undesirable consequences to turning off extension and therefore you may be better off just including iso646.h.
Use a forced include (option /FI) of the iso646.h header.
For work in the command interpreter you can put this in your CL environment variable, or e.g. in a response file.
Turning off Visual C++ language extensions with /Za can also do the trick, at the cost of rendering the compiler pretty much useless – since Microsoft code such as the Windows API headers generally uses the extensions.
On a more recent version of VS (tested on Version 15.7.0 Preview 3.0); ensure that conformance mode is set for visual studio:
It then compiles with the alternative operator representations.
I am a beginner was trying to do some C++ programming on Xcode. It works fine, but when I try to compile the same c++ file on my windows pc using VS, there were some errors. After I look at my code closely, there are really some stupid mistakes that I have made which caused the errors, but Xcode seemed to have ignored them...
My question is that is there any setting that I need to change to prevent Xcode from being so smart?
For example, the following code can actually compile in xcode:
#include <iostream>
using namespace std;
int main() {
if (true or false){
cout << "How is this possible? \n";
}
return 0;
}
There are also other cases where the code is actually wrong, but it can compile just fine is Xcode which is the annoying part and I want to disable that.
As far as I can see there is nothing wrong with your code.
The ISO C++ standard does not specify which standard headers are included by other standard headers. So, it is entirely possible that the version of iostream used by Xcode directly or indirectly includes ciso646. Whereas Visual Studio's version of iostream does not include ciso646. There are many similar cases with other headers. You just need to read the error messages and realize that your error (when you move your file to a different platform) is due to a missing header file.
It would be nice if writing portable code meant writing code in accordance with the C++ standard specification, but unfortunately that's not the case. Although there are various compiler options on various implementations which can help bring different implementations closer together, in general you will just have to bring the code into the target environment and actually test it there.
So ultimately writing portable code means you'll have to learn some subset of C++ that is accepted by all the implementations you want to target.
or is an 'alternative token' in C++, and VS is incorrect to reject it. There's no option in Xcode to disable support for alternative tokens. However VS has non-standard support for or as a macro using the header <ciso646>, and Xcode does have a header <ciso646> which does nothing (as the standard specifies). So you can write code which uses or and which works in both Xcode and VS by including this header.
#include <iostream>
#include <ciso646> // does nothing in Xcode, allows `or` in VS
using namespace std;
int main() {
if (true or false){
cout << "How is this possible? \n";
}
return 0;
}
Unfortunately VS can't support all of the alternative tokens through macros and so Xcode will still support some that VS doesn't.
There are also other cases where the code is actually wrong, but it can compile just fine is Xcode which is the annoying part and I want to disable that.
If you give specific examples then I can provide additional advice on how to write portable code.
Rather than changing your Xcode settings, I suggest cross-checking your code using another development environment.
If you're looking for something cheap and full-proof. Download a VirtualBox Windows VM, and run download Dev C++ (bloodhshed)
VS does not support or: you need to use || instead.
You can include some special files but it doesn't inject or sufficiently well into the language for it to work in all instances.
If you want to suppress use of or (and your compiler supports no better way)
#define it to something that emits a compiler error, for example
#define or OR
This at least means that the nature of the compilation errors will be identical on Xcode and VC.
The "not", "and", etc... are keywords in C++ (macros in C). Is there any way to "enable" them in Visual Studio 2013? I'm able to use the words as macroses with iso646.h included. But VS seems not be able to recognize them as keywords.
Using /Za seems to enable them without including iso646.h, see it live, the following program produces an error without using /Za but works fine otherwise:
int main()
{
int x = 1, y = 0 ;
if (x and y)
{
//...
}
return 0;
}
As ta.speot.is indicates /Za disables extensions, the following documentation indicates you must include ios646.h otherwise:
Under /Ze, you have to include iso646.h if you want to use text forms of the following operators:
and it lists the alternative tokens below.
Note, I knew I saw this before, I include a link to a bug report for this in my answer to a similar question. Although this does not include the workaround noted above.
Note 2: Cheers and hth. - Alf indicates that there may be many undesirable consequences to turning off extension and therefore you may be better off just including iso646.h.
Use a forced include (option /FI) of the iso646.h header.
For work in the command interpreter you can put this in your CL environment variable, or e.g. in a response file.
Turning off Visual C++ language extensions with /Za can also do the trick, at the cost of rendering the compiler pretty much useless – since Microsoft code such as the Windows API headers generally uses the extensions.
On a more recent version of VS (tested on Version 15.7.0 Preview 3.0); ensure that conformance mode is set for visual studio:
It then compiles with the alternative operator representations.
I'm trying to compile some source code with Visual C++ 2010 Express. The code was written for GCC, and contains attributes like this:
struct something {
...
} __attribute__((packed));
Since this is not standard C++ syntax, Visual C++ doesn't recognize it. With this macro prior to the struct declaration, it works fine:
#define __attribute__(p)
But I don't want to alter the files. I created a new property sheet (GccCompat), and went to Preprocessor Definitions, and added the macro, like this:
__attribute__(p)
or like this:
__attribute__(p)=
But it doesn't work. It's simply not called. If I define just __attribute__ (without parameters) in the same location, the macro is correctly defined. Note that the command line that is generated looks fine (the macros with parameters are passed exactly the same as the ones without), but the compiler seems to ignore it. So, how can I globally define my macro with a parameter?
It might be impossible, at least that way. Notice that Microsoft's documentation of the /D option doesn't specify a syntax for macros that take arguments.
Defining macros in the IDE is generally focused on the nature of creating a /D:CPP_TOKEN flag for the compiler, i.e. #define CPP_TOKEN.
In the advanced compiler settings you may be able to define such a macro as /D:"attributes(p)=/nothing/" or something like that. Just open the VS command prompt and see what it says. GCC 4.2 will allow something like that (using it's -D switch), but I don't have MSVC10 handy.