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 [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
