Archive for the ‘Visual Studio’ Category

C++ Library Symbol Exports – The Good, the Bad and the Ugly

28. June 2011

The Good

Selectively exporting symbols for a library is a good thing. It keeps program startup times down and enforces the public API of a library. The Good is that it’s possible and even the default mode for Visual C++.

The Bad

For whatever reason, the Visual C++ (or DLL?) designers decided that you have to declare your public functions with __declspec( dllexport ) when building the library and __declspec( dllimport ) when using it. What’s wrong with gcc’s visibility(“default”)?

All kind of fun ensues when you want to export explicit template instantiations with MSVC’s dualiton construct. Even more fun appears when you use static libraries.

The MSVC approach does not really work for static libraries. As far as I can tell, there are no exports for static libraries. Say you have a piece of code which you’ld like to share between different shared libraries without actually shipping this as a shared library as well. The fabric foundation in Equalizer is such an example, and right now this is ‘shared’ by compiling the relevant object three times – once for the client, server and admin library. Obviously this is not optimal since it increases the build time unnecessarily. Building fabric as a static library and linking it to these three shared libraries works fine with the GNU toolchain, but not with MSVC since it would require to manually specify all the public symbols when linking the DLL.

The Ugly

The implementation chosen by gcc is utterly useless for C++. Setting the default visibility to hidden requires to manually export the vtable of each class and all STL intantiations used – including the internal classes instantiated by the STL itself! While I can see how this implementation came into being, it is clearly designed for C code and not for C++. The vtable and STL are internals of the C++ implementation, developers should not need to care about them.

For now I have given up on using selective visibility with gcc, and only use explicit exports on Windows for Equalizer and other projects I’m working on. This makes sure that checkins will regularly break the Windows build. Hurray!

My Wishlist

One can dream:

For the VC++ developers: Please provide a __declspec(dllvisible) which works also for re-exporting symbols from static libraries. Let the toolchain figure out the details.

For the GCC developers: Please make exporting symbols from C++ classes simpler. VC++ can do it, so it can’t be that hard!

Discaimer

The above is obviously a rant. I am fully aware that workarounds exist for all of the issues mentioned above. Implementing them in real build environments is more time consuming than it should be and than is feasible. If you know about simple fixes, please comment below.

Equalizer 1.0 released

20. May 2011

It’s been only 21 months since the last post, but both Equalizer and me are still alive. This month we finally released the version 1.0, which was looong overdue.

Most notably, this release defines the stable API for all Equalizer 1.x releases. This means that all the functions marked with version 1.0 will be source-code compatible until we’ll release an Equalizer 2.0. Parts of the API are still undefined and unstable, in particular for the also-new Collage network library. However, 99% all of the functions used by the examples are stable.

Since the last major version, 0.9, there have been plenty of improvements and new features, e.g., subpixel compounds, reliable multicast for data distribution, runtime mono/stereo switch and many more. A comprehensive list is in the Release Notes.

Since this month I’ve started working on a new project based on Equalizer, and hopefully I’ll update this blog more regularly. More about this in another post…

Subversion and Visual Studio Project files

2. October 2007

Somewhat off-topic, but does anybody know a proper solution to the problem that each Visual Studio instance seems to save project and solution files in a different way? (example)

My preferred solution would be a tool which loads the xml file(s) and saves them in a predefined order without changing the semantics of the files. This could be used as a pre-commit script to subversion, so that the source tree only ever sees a ‘unified’ version.

There has been some discussion on the QT list about this, but all the suggestions are workarounds which imo do not work in a distributed team.


Follow

Get every new post delivered to your Inbox.

Join 40 other followers