Are there official rules/guidelines for including boost headers? I'm wondering as up until recently I almost always used the format #include <boost/library.hpp>. Then I came across Boost.Timer, whose documentation states that there are 2 versions of the library, a deprecated and a new one.
The deprecated version resides in <boost/timer.hpp> whereas the new one resides in <boost/timer/timer.hpp>. The two version seemingly exist without any interaction...
So I thought: "well obviously one should prefer the 'internal' headers". So I looked at some of my more regularly used headers and noticed that for example <boost/format.hpp> simply includes the headers of boost/format plus several external dependencies. So including the specific headers doesn't seem like the best idea.
So I thought: "well maybe that's a transitional artifact and they're working towards the boost/library/header'scheme".
The I noticed the new Boost.Atomics library - only just recently added - and was stunned: there's a header boost/atomics.hpp and a folder with headers of the same name.
Now I'm somewhat confused: Is there an official guideline on which headers are to be considered public (similar to the standard headers) and where the internal aspects of the api starts? Or is it completely up to the library to decide the structure of it's headers?
As far as I know, the Boost Library Requirements and Guidelines does not define the scoping and separation of header files. The Boost Header Policy defines guidelines to allow headers to co-exist with other headers. Nevertheless, many of the libraries provide a distinction by:
Providing separate files for logical divisions of types/functionality users may want.
Placing header files internal to the library within a detail directory.
Declaring internal types, functions, etc. in a detail namespace.
Some even make another level of distinction by separating a function declaration from its definition within header files by placing the definition in an impl directory.
It is suppose to be safe to include the highest-level header file. Additionally, it should generally be safe to include more specific files. For example:
If I want boost::thread, boost::mutex, and boost::lock, or do not mind the additional includes, then I may include boost/thread.hpp.
If I only want boost::thread, then I would include boost/thread/thread_only.hpp. I would not directly include boost/thread/detail/thread.hpp.
Related
I am struggling to figure out a strange AFX-related bug in a C++/MFC module, my working theory is that there is some discrepancy between the way different modules are being built in relation to Windows libraries.
We have various preprocessor settings in project files and header files and I would like to find a standard list of such definitions, so I easily search for all references and check for inconsistencies. For instance I've just spotted that in a single project we have /D "_WIN32_WINNT=0x0501" and /D "WINVER=0x0601
We commonly use variations on:
WIN32
_WINDOWS
_WIN32_WINNT=0x0501
_VC80_UPGRADE=0x0600
WINVER=0x0601
VC_EXTRALEAN
_AFXEXT
Are there a list of all those that are commonly used? Are there names for standard values instead of using e.g. 0x0601 Do some of these infer/control others so we can simplify to fewer options in our project files (why do we have WINVER & _WIN32_WINNT)?
I'm concerned I'll try to tidy this all up but miss one definition somewhere I didn't know about!
VPP provides the I/S for developing custom plugins that can be hooked into a graph of nodes. I've only seen examples for such plugins written in the C language, and was wondering whether other language, Go for instance, can also be used to write such plugins.
I have no idea what "VPP" is but nonetheless the answer is: "maybe"; here's why:
Go code is able to interface with C libraries via its facility known as cgo.
cgo is a multiple-faceted thing: it allows you to "export" certain Go functions in a certain way so that they can be called from the C side, and it allows you to call functions from the C side. It also allows you to write bits of inline C code to provide glue for the C side, when necessary.
Since some time Go building toolset (at least its "reference" implementation) provides for compiling Go code into a static or dynamic library with C-compatible API.
See this.
With these things in mind, in theory, it should be possible to do what you're after.
Note some possible obstacles:
Most of the time, if a "platform" allows you to write a "plugin" in C, it presupposes your plugin will make extensive use of the platform's own API.
This usually means your plugin is supposed to include certain header files provided by the platform.
The platform might also require your plugin to link against some platform-provided library (usually shared), or libraries.
cgo can do all of the above, but you will need to scrutinize the API provided by the platform and maybe write Go helpers to make its usage more natural for the Go code.
Building/linking issues (usually the locations of the header files and the libs) may also be a thing to solve.
I am trying to port a project from Google Protocol Buffers 3.0.0-beta-2 to 3.1.0. After recompiling my .proto file I noticed that I had a number of compilation errors with the project due to protoc enforcing a coding standard that I did not choose and renaming fields accordingly. I do not want to rename e.g. MDData to Mddata or XYServer to Xyserver inside the project since the intended meanings of the abbreviations are now lost and possibly subject to change in further Protocol Buffer releases to come.
I have seen this behaviour on the C# part so far and am not sure if this is also the case for generated code for C++.
TL;DR:
Is there a way to disable automatic code style changes inside Google Protocol Buffer's Proto Compiler (and keep my own formatting) of fields?
There is no way to enforce this short of writing your own code generator. Only the public API of the stubs is considered stable.
Under the hood, the protoc compiler regenerates the code from scratch each time, so there is no way for it to know the original style of the file. It would need to be passed in the original generated file along with the proto in order to do this.
That said, if you want to modify the code generator, it is certainly possible.
Recently, I compiled Eigen3 and use it to do some linear algebra task at Windows.
But I wonder why Eigen3 doesn't need to link additional lib or DLL (I just need to include its header)
Does Eigen do all calculating at compile time? Or do I miss understanding something?
If so, what is the category name of this kind library
Like all C++ template libraries, Eigen is completely contained in the header file and inserted in the source file everytime. So it does not contain on any cpp files, which would be compiled to a dll.
The distinction between dll/lib and header occurs when the classes are declared in the header and implemented in a cpp file. Then the implementation part is always the same and can be loaded from a dll.
However, in a template library, the classes are not finished, since they depend on the template parameters you pass to them. e.g. if you write Matrix<float, 17, 19>, you create a new complete class with a completely new implementation, which could not be loaded from a dll.
This also makes c++ programs that uses a lot of templates (like many different fixed size matrices), very big.
we're building a cross-platform utility which must have a small footprint. We've been pulling header files from boost as and when we need them but now we must link against some boost C++ thread code. The easiest immediate solution was to create our own custom library using CMake's "add_library" command to create a static library composed of some boost thread source files. These compile without any problems.
The difficulty arises when I try to link to this library from an executable. Visual Studio 2008 returns an error saying that it cannot link to "libboost_thread-vc90-mt-sgd-1_40.lib". What really puzzles me is that I've grepped through all the source code and CMake config files and I can't find any reference to this libboost library, leading me to think that this has been autogenerated in some way.
This works OK in Linux, can anyone point out why I'm experiencing these issues in Windows?
#Gearoid
You found the correct reason for your problem, but not the correct solution. The BOOST_AUTO_LINK_NOMANGLE is an internal, i.e. for library authors, definition to control the auto-linking. The user level definition is BOOST_ALL_NO_LIB which when defined disables the auto-linking feature for all Boost Libraries code you use. This is described in the user.hpp configuration header (see user.hpp near the bottom and the Boost Config documentation). You can also control this on a per library level as describe in that header.
Ok, well, it turns out that Boost uses this auto-link feature for Visual Studio which embeds references to a mangled (ie, platform-compiler-mult-threaded, etc) boost library name.
The header file which controls this is called "auto_link.hpp" which lives in the config directory of the boost include tree. There's a special preprocessor definition called "BOOST_AUTO_LINK_NOMANGLE" which toggles this behaviour.
Another triumph of mediocrity for Microsoft.