[zeromq-dev] Issues installing ZeroMQ and PyZMQ on RHEL 6

john skaller skaller at users.sourceforge.net
Wed Feb 22 06:39:14 CET 2012

On 22/02/2012, at 4:14 PM, Wolfgang Richter wrote:

> I agree with most things (pretty excellent 0MQ thread post!) except
> blanket compiling code as C++.  Unexpected things start to happen
> outside of your control like namespace mangling.  This can hurt when
> doing certain dynamic code loading.  That's just one example of a
> "hidden" change coming in with a C++ compile versus pure C.

Ah yes, you're right.  Very good point on dynamic loading C++ there.

You can of course work around that, by using stuff
like extern "C", however this then "announces" that your code is C++.

I do that myself, but there are people really trying to write C
that don't want to extern "C" stuff just in case someone tries
to include a C header from C++ compilation.

A better idea is probably: trial compile with C++ until it actually
compiles. Then re-compile with C to make sure it still compiles.
Finally link the C code with g++ if you know some of the 
stuff in the background (like zmq) is really C++.

It's a bit messy for a workflow. If you do it right your build
scripts would produce a "testing version" using C++ but
a production version using C.

> It would be nice to get to the bottom of this linking issue on RHEL
> systems though.

Indeed. Especially with C++20XX coming online, standard library
changes and upgrades will matter.

> If you want to write C code, and want to be safer, it's probably
> better to turn to static analysis tools like Splint
> <http://www.splint.org/> or the more recent Clang static analyzer
> <http://clang-analyzer.llvm.org/> rather than pretend it's C++ code
> and use a C++ compiler just for stronger type safety (still not
> great).

Well it isn't an exclusive or situation. Using C++ compiler by default
is pretty easy to do. Running a static analyser or lint like tool or
whatever is generally worthwhile on *production* ready code,
or code with bugs known to exist but not yet located,
but too much hassle to do during development.

john skaller
skaller at users.sourceforge.net

More information about the zeromq-dev mailing list