I'm working on a project which requires converting a massive codebase from c running on embedded target to a visual c++ software, all of the structures in the c code are defined with __attribute__ ((pack)) which visual c++ does not support,
I cannot alter the c code.
I am looking for a workaround which will enable me to make vc++ refer to __attribute__ ((packed)) the same way as it refers pragma pack,pop macros
the simple method of a define substituting the two is not possible because the __attribute__ ((packed)) macro has a space between its words and the second word starts with a '('
is there any other creative way that won't make me alter the code?
First of all, I would ask yourself whether in the VC compiled version of the code the structures need to be packed? Is there a functional reason for this, or just the whim of the original coder?
Secondly does the code use any other __attribute__ directives? If not then you can safely "remove" all the gcc __attribute__ directives by defining an empty macro, either:
#define __attribute__(...)
in a "forced-include" header file (command line option /FI <filename>), or simply:
/D __attribute__(...)
on the command line. The forced-include may be simpler if you need to add other directives to adapt the code.
So if the only use of __attribute__ is for packing, and you don't really need packed structures, then you are done. If however the packing is essential, and as you say:
all of the structures in the c code are [packed]
Then you can globally apply packing via the command line using /Zp for the project, or in the forced-include file add:
#pragma pack(1)
If the solution is not truly suitable - for example not all the structures should be packed or __attribute__ is used (and needed) for other purposes - then the path of least resistance may be to use gcc rather then VC for your Windows build. The easiest way to do that is to use MinGW (minimal GNU for Windows).
Related
AFAIK, symbols are useful to prevent multiple parsing. If both a.h and b.h include c.h, a
#ifndef C_H
#define C_H
...
// c.h definition would go here
...
#endif
will prevent c.h from being "parsed" (I believe it's not the right word) more than once.
However, I have seen something like
#ifdef WIN32
...
in other people's code. That symbol must have been defined somewhere else because a search for
#define WIN32
in the whole project returns empty. My question is: where are these symbols actually defined? Does the OS keep something similar to a pool of symbols that different programs can use to query for OS or other processes properties?
There are two options where those which are not in the code itself can originate from:
The compiler suite itself sets it as a default when you start compiling your code.
You give the compiler (or preprocessor, to be exact) a list of those definitions when you compile the code (or your IDE project preferences do, when you are using an IDE. For example, in Visual Studio 2013 you will find those when you open Project > Properties > Configuration Properties > C/C++ > Preprocessor > Preprocessor Definitions).
In general, those definitions are not only used for the reason you describe (as include guards), but also to enable or disable code based on the platform you develop for - for example, you can have code branches only compiled for windows, or only if you are using a 64 bit compiler.
You might want to take a look at some predefined compiler macros
Microsoft
AFAIK this is part of the compiler you use.
The Microsoft C++ compiler internally defines some macros such as WIN32, that's why it's not defined in any particular header. So when you build a source file with VC++ the stuff in inside #ifdef WIN32 gets compiled, but not on say Linux gcc.
Also your nomenclature is a bit off -- these are called preprocessor macros, not symbols. The names of the variables, functions, etc in your code are symbols.
Each compiler has a list of defined macros. MSVC defines WIN32 when compilation target is 32-bit Windows.
We're using protocol buffers (2.4.1) in a medium size embedded system w/ c# an c++ code. We use protobufs to isolate our managed and native layers w/ an easy to maintain serialization layer (For the curious, we would have just used Pinvoke, but we also have to run native code in a separate process on test/simulators).
Our system has a number of DLL's, and I have the generated native protobuf code in it's own DLL so that the other parts of the system can don't have to link in the generated code directly.
The problem i'm having is that all the generated accessors are inline, eg:
inline const ::MyProtoClassName::MyField& MyProtoClassName::myfield() const
{
return myfield_ != NULL ? *myfield_ : *default_instance_->myfield_;
}
use the generated API in size (the 'default_instance_' is dereferenced and accessed if this particular field not set). This means that I can't link (lnk2001) any clients using the accessors because there is not symbol default_instance_
I think the typical use case for ProtoBufs would be to have each component link in the generated protobuf code itself (after all, this is primarily a serialization layer for distributed systems), but
I'm wondering if there is a compile switch to change the inlining behavior that I missed. (Have all accessors defined in the CC file, not H)
Thanks!
Thanks #g-makulik! Looks like the answer was about 30 lines up in the ProtoC code, i just didn't see it :)
< see his answer below for the bulk of the solution > This should also help you, though.
As noted in some of Kenton's changelogs, adding this causes several warnings (C4251, c4275) relating to base classes that are not also DLLEXPORT'd
with the way ProtoBufs is implemented, and the protobuf classes being all templates, these warnings are benign. To cleanly ignore them (eg WITHOUT having to disable the warnings for all clients) I used this somewhat hacky approach:
-wrapper for the protobuf.h file that eveyone includes. (no one include the real generated H file)
#pragma once
#pragma warning(push)
#pragma warning(disable:4251)
#pragma warning(disable:4275)
// include the protobuf generated code; but exclude the warn c4251, c4275
// these relate to the dll exported
#include "yourProtoFile.h"
#pragma warning(pop)
and a wrapper C file (the real protobuf CC file is not in my project -> not built directly)
#include "MyProtoFile_WRAPPER.h"
#include "MyProtoFile.cc"
I think this link could answer your question: Protobuf with MSVC: how to export generated Message
Quote from Kenon Varga (Project leader of google protobuf):
If you invoke protoc like:
protoc --cpp_out=dllexport_decl=MY_EXPORT_MACRO:path/to/output/dir myproto.proto
then it will generate code with MY_EXPORT_MACRO in all the right places. However, this option is incomplete -- currently there is no way to force the generated .pb.h to #include a header which defines MY_EXPORT_MACRO. I'm open to patches to fix this. Or, you could use a hack to work around it, such as adding the #include via some sort of text processing after protoc finishes, or perhaps moving the .pb.h to .pb2.h and replacing the .pb.h file with one that first includes your header then includes the .pb2.h...
And additonally to cover the mentioned incompleteness (Quote from Aron Bierbaum):
We currently get around this limitation by forcing the the header to
be included using compiler command line flags:
Windows: /FIproject/Config.h
Linux: -include project/Config.h
NOTE:
Using the inline keyword shouldn't be relevant in this case (that an additional __declspec dllexport/__declspec dllimport attribute is put on the accessor method). Per definition it's up to the compiler to inline functions or not. Of course seeing a __declspec dllexport or __declspec dllimportattribute is contradictionary for inlining.
I can see
#ifdef <token>
code;
#endif
to be included, but I can't find it defined in any of the headers it includes. Is there any other mechanism with which the token could be defined?
Firstly, there are macros that are implicitly defined by the compiler (for example, __cplusplus). Some of these are standard, and some are compiler-specific extensions. See your compiler manual for the full list.
Additionally, most compilers allow defining macros on the command line. The exact mechanism is compiler-dependent, but often takes the form of a -D or /D command-line option. For example, see the gcc manual:
-D name
Predefine name as a macro, with definition 1.
-D name=definition
The contents of definition are tokenized and processed as if they appeared during translation phase three in a `#define' directive. In particular, the definition will be truncated by embedded newline characters.
If you are invoking the preprocessor from a shell or shell-like program you may need to use the shell's quoting syntax to protect characters such as spaces that have a meaning in the shell syntax.
If you wish to define a function-like macro on the command line, write its argument list with surrounding parentheses before the equals sign (if any). Parentheses are meaningful to most shells, so you will need to quote the option. With sh and csh, -D'name(args...)=definition' works.
For Microsoft Visual C++, see http://msdn.microsoft.com/en-us/library/hhzbb5c8(v=vs.80).aspx
Some compilers provide convenient tools for figuring out where a particular preprocessor macro is defined. See, for example, How to know (in GCC) when given macro/preprocessor symbol gets declared?
Most (all?) compilers allow defining values with flags (-D in gcc), also some may be set by the compiler itself.
Yes, of course, preprocessor directives can be set with the compiler. For example, gcc lets you add directives in the command line, you can specify directives in the project settings in Visual Studio. Also think about __cplusplus, or _LINE_ of _FILE_. Those aren't defined anywhere, yet they exist. Also _DEBUG or UNICODE which are set up by the MSVS environment.
I have the following option defined in CMake:
option(OURAPP-DEV-USE_EXTREME_DEBUGGING "Use extreme debugging features" OFF)
and I would like to check in a C++ file that this option was checked (in the CMake-GUI) or not.
I.e. writing C++ code like:
#if OURAPP-DEV-USE_EXTREME_DEBUGGING
print_extra_debugging();
#endif
Please note, that our project setup requires that there is a - between the options regarding the components (such as OURAPP and DEV and the rest ...)
Any idea how to make it happen?
Transfer the CMake option to the C++ world using a preprocessor define.
IF(OURAPP-DEV-USE_EXTREME_DEBUGGING)
ADD_DEFINITIONS(-DUSE_EXTREME_DEBUGGING)
ENDIF()
Under the hood, this adds the define to the compiler command line, and is then available to the preprocessor:
#ifdef USE_EXTREME_DEBUGGING
print_extra_debugging();
#endif
Note that a hyphen is not a valid character in a C preprocessor token, so you'll have to change the name in the define.
You can also use cmake CONFIGURE_FILE, cf. http://www.cmake.org/cmake/help/cmake2.6docs.html#command%3Aconfigure_file
I'm compiling code using gcc that comes from Visual C++ 2008. The code is using errno_t, but in some versions of gcc headers including <errno.h> doesn't define the type. How do I detect if the type is defined? Is there a define that signals that the type was defined? In the case it isn't defined I'd like to provide the typedef to let the code compile correctly on all platforms.
Microsoft's errno_t is redundant. errno is defined by the ISO C standard to be a modifiable lvalue of type int. If your code needs to store errno values, then you should put them into an int.
Do a global search and replace s/errno_t/int/ and you're done.
Edit: Also, you shouldn't be providing a typedef int errno_t in your code, because all names that end with _t are reserved.
You can't check for a typedef the way you can for a macro, so this is a bit on the tricky side. If you're using autoconf, this patch shows the minimum changes that you need to have autoconf check for the presence of errno_t and define it if it's missing (the typedef would be placed in a file that includes your generated config.h and is included by all files that need errno_t). If you're not using autoconf you need to come up with some way to do the same thing within your build system, or a very clever set of tests against compiler version macros.
This is typically the case where GNU autoconf comes to the rescue. Basically autoconf will generate a configure script that can detect various system-dependent features such as whether this type exists and how it is defined. You then include the generated C header file within your application.
If you know which versions of GCC are giving you trouble, you can test for them. You can check for versions of GCC using something like:
#if __GNUC__ == 3
...
#else
...
#endif