Hi Ákos, I like your style of critics. Always put a reference to your opinion so it gets more weight. However I do not agree with everything you write. Ákos Maróy on Sunday, August 24, 2008 10:42 AM:
Christian,
And gcc-4, which also supports the #pragma once. The use of this
But the #pragma keyword is not for this. Even the MSDN page for #pragma says:
"Each implementation of C and C++ supports some features unique to its host machine or operating system ... The #pragma directives offer a way for each compiler to offer machine- and operating system-specific features"
see http://msdn.microsoft.com/en-us/library/d9x1s805(VS.80).aspx
having to guard a header file from inclusion is in no way a machine or OS dependent 'feature', thus it's not something you'd want to solve with #pragma.
I think in this point you're mistaken, since the pragma is simply a communication channel directly to your compiler. GCC offers not only machine or architecture pragmas but also e.g. diagnostic pragmas, the #pragma message or means to change optimization level per compilation unit.
also see chapter 24 from C++ Coding Standards by Herb Sutter and Andrei Alexandrescu, titled "Always write internal #include guards. Never write external #include guards.", http://www.gotw.ca/publications/c++cs.htm
I agree! Buut that's out of question.
basically using #pragma once is bad style.
I strongly disagree :) It's shorter, thus more elegant, does not induce myriads of names like the preprocessor guards and is even faster. GCC also saw that and de-deprecated it in versions 4.x.
I include enough boost headers which implicitly include version.hpp and the like so I need not bother making this explicit.
see chapter 23 from C++ Coding Standards by Herb Sutter and Andrei Alexandrescu, titled "Make header files self-sufficient.". the fact that you include version.hpp frequently doesn't mean it shouldn't be explicit in this header file. if a header uses a feature, it should include the header for that feature.
You got a point here. It probably doesn't hurt and makes the whereabouts of the BOOST_VERSION macro evident in my case.
if you're interested I can send you a version of your implementation I changed, along the following:
- added #ifdef guards / removed #pragma once - made the files self-sufficient - removed signed / unsigned comparision / conversion warnings from the save() functions of both iarchive and oarchive - solved portability issue with right-shifting signed values in the save() function of portable_binary_oarchive (right-shifting signed values is implementation dependent)
I'd be glad to send it the changed code over, if interested.
Sure! I'm curious how you changed my code, send it right over please! :) Especially the right-shifting issue caught my interest! Do you have examples where right shifting does not repeat the sign bit? Let me see how you solved it. Regards, -- Christian Pfligersdorffer Software Engineering http://www.eos.info