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

[john skaller]

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