I'm an intern student and my boss told me to do porting from Linux c to Visual C++.
When I built the coding, I found this error "unexpected in macro formal parameter list", here is the code
#define cache_info(format, msg...)
do { \
;\
} while (0)
I don't know what is wrong and what the coding is for .
I can't also ask the Linux programmer since he is out. Can someone help me ???
Sounds like your version of Visual C++ doesn't support variadic macros.
you might need to try something like this to get it to work.
#define FUNC(foo) ThisFunc foo
void ThisFunc(int, ...);
int main()
{
FUNC((123, 456));
}
or you could just be missing a comma?....
#define cache_info(format, msg,...)
I think that the problem could be from one of two things.
First, your macro is defined as
cache_info(format, msg...)
But you probably meant to write
cache_info(format, msg, ...)
Though this could just be a typo in your original post.
More importantly, though, macros with variable numbers of arguments ("variadic macros") are not supported in C++; they exist only in C. If you're trying to compile this C code with a C++ compiler, the compiler should give you an error here because the code isn't legal C++.
if using Windows 64 bit OS, & visual studio, try after running this bat file : \Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat
It will register env settings. It worked for me..
Related
I have an issue with C++ macros. So I have this two Macros to help with OpenGL error handling. I have to basically wrap this Macro with any OpenGL function I attempt to call. The problem is that this GLCall macro prevents intellisense for anything I attempt to write below it. Anyone know what the issue might be? intellisense works perfectly above any GLCall() line by the way.
the code
#define ASSERT(x) if(!(x))__debugbreak();
#define GLCall(x) GLClearError(); x; ASSERT(GLLogCall(#x, __FILE__, __LINE__));
Visual Studios default intellisense is not the most intelligent. All I did was install Visual Assist and everything worked well.
Trying to build Tink library (https://github.com/google/tink) with Bazel. Bazel installed, gcc version 7.2.0, Windows 10 x64. Visual C++ 2017.
At first, there were errors like "C++ compilation of rule '#boringssl//:crypto' failed" - I commented these lines (with compilation flags I think) in boringssl/BUILD file (sections boringssl_copts, boringssl_copts_c11) and they disappeared.
But after that, bazel said, that error is in errors.h file (https://github.com/google/tink/blob/master/cc/util/errors.h)
// from #include "absl/base/port.h"
#define PRINTF_ATTRIBUTE(string_index, first_to_check) \
__attribute__((__format__ (__printf__, string_index, first_to_check)))
// Constructs a Status object given a printf-style va list.
crypto::tink::util::Status ToStatusF(
crypto::tink::util::error::Code code, const char* format, ...)
PRINTF_ATTRIBUTE(2, 3);
} // namespace tink
} // namespace crypto
enter code here
Error C3646: unknown override specifier on line 32 (line with "PRINTF_ATTRIBUTE(2, 3);"). The most frightening thing is that in another files the same code (defining same attribute) is working.
There are another errors in this file, but mentioned is the first (and another are about the same line, so they are consequences of the first I guess).
I'm nearly a total newbie in cpp, but only cpp should be used, not java-version of library.
Thank you for your help, and sorry for possible misformatting and broken english - this is my first question here.
Unfortunately, we don't support Windows for now. It's something that we plan to support next year, please see our feature roadmap.
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.
I have the following trivial file named Temp.cpp:
#include <string>
int main() { return 0; }
and I'm trying to compile it with the following command-line in the Windows XP Free Build Environment, using WDK 7.1:
cl.exe /Iinc\api\crt\stl70 /Iinc\crt C:\Temp.cpp
and I'm getting really random errors like:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.207 for 80x86
C:\WinDDK\7600.16385.1\inc\api\crt\stl70\iosfwd(202) :
error C2144: syntax error : 'int' should be preceded by ';'
The error goes away if I use stl60 instead of stl70, but that doesn't solve the problem.
What's the cause of the problem?
Update: I tried uninstalling and installing the WDK again, but nothing changed. :(
Update 2: Okay, apparently the error is screaming out at the header file itself: _SCL_INSECURE_DEPRECATE is the cause. Does anybody know how to turn it off correctly? (If I just comment out the lines, I get a ton more errors regarding a bunch of other macros.)
Found the answer myself, through modifying the headers and guess'n'checking:
I need to have _STL70_ defined.
Which cl.exe are you picking up? If your path happens to have an older (VC6) compiler before the WDK one, you'd expect these errors. VC6 can't compile the STL as shipped with VC7
apparently the error is screaming out at the header file itself: _SCL_INSECURE_DEPRECATE is the cause. Does anybody know how to turn it off correctly?
If you're having problems with _SCL_INSECURE_DEPRECATE, try setting:
/D_SCL_SECURE_NO_DEPRECATE
But given the error message you're seeing it sounds like you're the compiling headers with a a compiler that's older than the headers support (so this might not get you very far anyway).
I've started playing around with the WDK / DDK (I'm assuming they're the same thing) samples and in particular the printer port monitor example. I've got this compiling using their build tool and I can attach to the spooler process and debug through... good stuff!
.. Problem comes when I simply want to write some debug out. I really thought this would be simple (haven't doing c++ in a while!) but it appears not!
The current problem I'm having is simply trying to create an instance of std::wchar, as in below:
std::wstring test("Blah");
Problem is, when I compile with the wdk build tool I get these errors:
1>c:\winddk\7600.16385.1\src\print\monitors\localmon\localmon.c(361) :
error C2143: syntax error : missing ';' before ':'
1>c:\winddk\7600.16385.1\src\print\monitors\localmon\localmon.c(363) :
error C2143: syntax error : missing ';' before 'type'
I'm guessing that this is because the compiler doesn't understand the std:: bit maybe? The line number points to the wstring declaration above.
I've added include <string.h> but that didn't help and my sources file is below:
!IFNDEF MSC_WARNING_LEVEL
MSC_WARNING_LEVEL=/W3
!ENDIF
MSC_WARNING_LEVEL=$(MSC_WARNING_LEVEL) /WX
C_DEFINES=-DUNICODE -D_UNICODE -D_SPL_CLUST
TARGETNAME=ddklocalmon
TARGETTYPE=DYNLINK
DLLENTRY=_DllMainCRTStartup
DLLDEF=localmon.def
DLLORDER=localmon.prf
TARGETLIBS=$(SDK_LIB_PATH)\kernel32.lib \
$(SDK_LIB_PATH)\advapi32.lib \
$(SDK_LIB_PATH)\user32.lib \
$(SDK_LIB_PATH)\ws2_32.lib \
$(SDK_LIB_PATH)\spoolss.lib
INCLUDES=$(INCLUDES); \
$(DDK_INC_PATH); \
USE_MSVCRT=1
SOURCES=localmon.rc \
localmon.c \
winspool.c \
util.c \
config.c \
xcv.c \
irda.c \
mem.c \
PRECOMPILED_INCLUDE=precomp.h
Also, if I ever got wstring working I was going to use this with OutputDebugString() to process my debug to the visual studio output console, but I think I've read somewhere that this may not work as the port monitor runs in kernel mode?
If anyone could shed any light on this I'd really appreciate it! :)
Andy.
std::string and std::wstring are C++ classes (actually typedefs for C++ classes), and you are compiling .c files.
Using the C++ runtime libraries in drivers feels a bit strange, I don't know if it works.
If you where to compile as C++ the include is <string> and not <string.h>.
Almost all, if not all, of the DDK uses C, not C++.
std::string and std::wstring is a part of C++ standard library (included in header file - NOT that is part of C standard library as #dalle already posted).
And as #dalle already posted you compile C source code (samples are written in C) - the right format for C++ source file name is *.cpp
Full C++ support is available in user-mode. So since you have user-mode DLL using C++ is OK it you rename files to *.cpp (but looks ugly because you embed C++ chunks into pure-C code samples).
In kernel-mode code however the C++ support is very limited.
If you really need full C++ language support in kernel-mode you may use some tricks to enable it but it is very complicated thing to do by yourself that requires lots of knowledge and experience (though there are some incomplete solutions available to the public).