I build the boost (latest CVS) ) using MSVC6 SP5, STLport 5.0 beta, February 2003 SDK under Win XP SP2. I am using boost to check STLport as I am a contributor to this library. I setup STLport and boost (stlport.hpp) so that all C symbols are imported within std but boost do not enfore this injection (BOOST_NO_STDC_NAMESPACE is undefined). This way I know that STLport do import correctly all C symbols used by boost. In this case C symbols calls have to be fully qualified as VC6 has ambiguity trouble as soon as you have a using namespace std directive. I have remarked that the latest boost release do not force C symbols injection using STLport like it used to do with previous versions. It is perhaps the way I should build boost even if in this case boost is forced to define BOOST_NO_STDC_NAMESPACE which is a little bit disappointed on an STLport point of view as STLport _do_ import C symbols for any compilers except VC6. Maybe the stlport.hpp config file should check the _STLP_NO_USING_FOR_GLOBAL_FUNCTIONS STLport macro before defining its own macro. I have plan to send a patch for this config file in order to use STLport 5.0, I will think about it at that time. I hope this description will help you take your decision. Bests Francois Dumont ----- Original Message ----- From: "Vladimir Prus" <ghost@cs.msu.su> To: <boost@lists.boost.org> Cc: "François Dumont" <francois.cppdevs@free.fr> Sent: Wednesday, January 12, 2005 12:17 PM Subject: Re: [boost] program_options lib patch Hi François,
According some boost library sources I have checked it looks like there is an implicit coding standard rule which is to always use C functions from their C++ std namespace import equivalent. Thanks to this, compilers like MSVC6 but also Commeau according what I have read in comments, do not give compilation errors because of ambiguity. The program_options library do not apply this rule, here are the patch to fix it. It, of course, use the BOOST_NO_STDC_NAMESPACE to force std import when missing.
In cmdline.cpp, this modification made the Commeau workaround irrelevant, it has been removed.
I have a couple of general questions about this patch: 1. Why it's necessary. Did you have problems with some compiler? If yes, what it was? 2. What compilers did you test your modification with? I recall that std::tolower vs. tolower thing was hard to get working everywhere, so I'd rather no touch it unless it's broken somewhere. - Volodya