December 2008 - Boost - lists.boost.org

Re: [boost] [uuid] Interface
by Vladimir.Batov＠wrsa.com.au 19 Dec '08

19 Dec '08

>> Great in theory, but I think it'll break >> lexical_cast<uuid>("21f7f8de-8051-5b89-8680-0195ef798b6a"), since the >> lexical_cast wants to default-construct the target type into which it >> will read. Yes, the default lexical_cast behavior requires the default constructor. Having said that I've been routinely specializing lexical_cast to optimize away the overhead. Something like namespace boost { template<> inline std::string lexical_cast<std::string> (std::string const& v) { return v; } template<> inline std::string lexical_cast<std::string> (char const* const& v) { return v; } template<> inline std::string lexical_cast<std::string> (bool const& v) { return v ? "yes" : "no"; } } If we do that for boost::uuid, then the user gets the familair interface and we have our class clean and minimal. Having said that I am honestly unsure about uuid id = lexical_cast<uuid>(str); as it seems already covered by template<typename InputIterator> uuid(InputIterator, InputIterator); I certainly want the explicitness of "string str = lexical_cast<string>(id);" though. Still, keeping the bidirectional nature of lexical_cast is probably important for the user. Therefore, I'd *probably* have namespace boost { template<> inline boost::uuid lexical_cast<std::string> (std::string const& v) { return boost::uuid(v.begin(), str.end()); } } >> template <typename ByteInputIterator> >> uuid(ByteInputIterator begin, ByteInputIterator end); Can we take it one step further and replace it with a more generic: template<class ForwardReadableRange> uuid(ForwardReadableRange const& range) { typedef typename boost::range_iterator< ForwardReadableRange >::type Iterator; Iterator begin = boost::begin(range); Iterator end = boost::begin(end); ... the rest is the same. } That way uuid id(string) is supported without the need for an explicit "uuid::uuid(string const&)" constructor as other containers as well. >> > // valid expression >> > // generator() - result type must be convertible to a uuid >> > template <typename Generator> >> > explicit uuid(Generator & generator); I feel that the "generator() - result type must be convertible to a uuid" requirement is somewhat excessive. Given the rest of the code it results in a generator having to know and even be able to create boost::uuid. That seems like an unnecessary coupling. I think generators should know *nothing* about uuid and certainly *not* create those. Instead, the generators should provide the necessary *ingredients* but it'd be uuid (well, its uuid(generator) constructor) actually creating an uuid instance. That might be as straghtforward as template<class Generator> uuid(Generator const& gen) { std::pair<Iterator, Iterator> range = gen(); ... something that uuid(begin, end) or uuid(range) does. } That way, the requirements for a generator are looser as all it needs is to provide a range. More so, the design maintains the locality of uuid creation and destruction -- those are created and destructed in the conventional way, i.e. by the uuid constructor and destructor (rather than created by a generator but destroyed by the uuid::~uuid()). As Scott noted template<class Generator> uuid(Generator const& gen) constructor is somewhat redundant. However, I'd personally like to keep it as it communicates to the user one of the main ways of creating a uuid. >> bool is_nil() const; >> operator unspecified_bool_type() const; // return !is_nil(); It's a minor point but I'd ask whay we need both? The reason I greatly favor "bool" converter is that it is idiomatic and does *not* introduce a new vocabulary. That is important from the usability point of view as any new vocabulary is obviously only usable *after* one learnt it. Why ask the user to learn something (like "is_nil") if he can get by without? Thanks, Vladimir.

2 1

[swap] How to fix ADL barrier for XL, Intel, GCC, Sun and Como?
by Niels Dekker - mail address until 2008-12-31 19 Dec '08

19 Dec '08

The boost::swap utility from Joseph Gauterin has an ADL barrier against infinite recursion or ambiguity, as recommended by Steven Watanabe and David Abrahams, last year at the mailing list: "Re: [boost] Koenig lookup swap." http://lists.boost.org/Archives/boost/2007/08/125938.php Last Friday I added "test_adl_barrier" to test this ADL barrier. Unfortunately it fails on many compilers, including XL (AIX), Intel (version 9 and 10), GCC, Sun and Como: http://www.boost.org/development/tests/trunk/developer/utility-swap_.html While I usually use MSVC, and for that specific compiler, the ADL barrier appears successful! Do you know how to fix the ADL barrier for the other compilers? I'm afraid we'll need to have #if BOOST_WORKAROUND statements in there... FYI, the boost::swap utility is at: http://svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp The ADL barrier test is at: http://svn.boost.org/svn/boost/trunk/libs/utility/swap/test/test_adl_barrie… Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

5 26

Single letter template type causes errors in compile of program_options and filesystem boost libraries
by Mike Collier 19 Dec '08

19 Dec '08

Hi, Problem lIbraries: program_options and filesystems Version: Release 1.37.0 System: Mac OS X 10.5.6, Red Hat Linux Enterprise 4, Red Hat Linux Enterprise 3 Compiler : gcc 4.0 and gcc 3.3 I have just started trying to use the boost libraries. I tried starting with program options and filesystem. Unfortunately both of these do not compile in my environment because of the use of single letter variable and template types. For example in alignment_of.hpp the template: template <unsigned A, unsigned S> struct alignment_logic { BOOST_STATIC_CONSTANT(std::size_t, value = A < S ? A : S); }; causes error and in operators.hpp the template: // Import a 3-type-argument operator template into boost (if necessary) and // provide a specialization of 'is_chained_base<>' for it. # define BOOST_OPERATOR_TEMPLATE3(template_name3) \ BOOST_IMPORT_TEMPLATE3(template_name3) \ template<class T, class U, class V, class B> \ struct is_chained_base< ::boost::template_name3<T, U, V, B> > { \ typedef ::boost::detail::true_t value; \ }; causes errors. The errors are the result of using single letters for variables or template types. The reason for the errors is in my compile environment ( electrical engineering related ) defines are used for the convenience of writing units in code. These defines exist in a vendor supplied header in my project: #define A #define V #define W #define s #define S #define J among many others to denote units ( in these defines the units are Amps, Volts, Watts, Seconds, and Joules ). These defines come from the vendor of the software I am using and can't be easily changed. I believe the correct change is to use longer names for variables and template types in the boost library headers, which means changing the boost library headers. I can do this locally in my copy of the headers, but it seems to me a better design is to use longer names in the boost libraries in first place. I don't see any benefit to using the single letter names in the boost library headers. Does anyone have other solutions to this problem or know of reasons why single letter variable and template type names are used in the boost libraries? Thanks, Mike

6 9

[test][doc] non-working link
by Rutger ter Borg 19 Dec '08

19 Dec '08

Dear Gennadiy, the link in http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/utf/intro.html to "collection of examples", pointing to http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/example-toc.html, seems to be broken. Kind regards, Rutger

3 2

Unit Test Framework - strange behaviour of test_unit::depends_on
by Me here 19 Dec '08

19 Dec '08

Hi there, Why the code below does not run test case TC_TestCase and reports that the whole test suite is skipped? Nothing is executed from my code. If the line /*1*/ is commented out, then behaviour is as expected. I use MSVC 2008 SP1 Win32, boost 1.36.0 or boost 1.37.0. I have to admit that test_unit::depends_on is not documented. Unit test framework is changed in 1.37.0 but changes are not documented anywhere. Regards, Alexander ----------- code in question ------ #include <boost/test/included/unit_test.hpp> using boost::unit_test::test_suite; void Dependency() { BOOST_MESSAGE( "Dependency!" ); BOOST_CHECK( 1 ); } void TC_TestCase() { BOOST_MESSAGE( "A test case!" ); BOOST_CHECK( 1 ); } test_suite* init_unit_test_suite( int argc, char* argv[] ) { test_suite* ts = BOOST_TEST_SUITE( "Test_Test" ); ts->add( BOOST_TEST_CASE( &TC_TestCase ) ); /*1*/ ts->depends_on( BOOST_TEST_CASE( &Dependency ) ); return ts; } -------- end code in question ------ ------------ output ----------- Running 1 test case... Entering test suite "Master Test Suite" Test suite "Test_Test"is skipped Leaving test suite "Master Test Suite" *** No errors detected ---------- end output -----------

2 1

[release][website] updating info
by JOAQUIN M. LOPEZ MUÑOZ 18 Dec '08

18 Dec '08

I've just added a new library (flyweight) to the release branch and I have a couple of questions regarding the associated update of website material: Where can I find the Version 1.38.0 news entry to add the blurb for the new lib? Is it my responsability (as the author of the new lib) to update public_html/beta/doc/libraries.xml, or public_html/live/doc/libraries.xml, both or none? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

building boost (regex) in mingw
by Lorenzo Bettini 18 Dec '08

18 Dec '08

Hi I'm trying to install boost regex library under mingw but I can't seem to succeed... the simple configure way does not work I've also tried bjam --build-dir=./tmp --toolset=gcc stage --with-regex but this does not create .a .so files, but only .lib files that I cannot use with mingw compiler... any help please? thanks in advance Lorenzo

3 17

[interprocess] Suspicious code in detail/segment_manager_helper.hpp
by Markus Schöpflin 18 Dec '08

18 Dec '08

Hello, this file contains at line 384 the following method of index_data: void *value() const { return static_cast<void>(detail::get_pointer(m_ptr)); } Either the declaration of the return value or the cast seems to be wrong. Markus

1 1

Re: [boost] [utility/swap] Internal compiler error Siliconmanborland-6.10.0 (CodeGear?)
by Niels Dekker - mail address until 2010-10-10 18 Dec '08

18 Dec '08

David (siliconman) wrote: > It had already been logged when I got to looking: > <http://qc.codegear.com/wc/qcmain.aspx?d=68959> Thanks, David. I've been searching through qc.codegear.com before, but I hadn't found it. I guess I just chose the wrong keyword to search for, e.g., "template", and "Fatal F1004". BTW, I decided to submit the report myself, because I don't have access to borland-6.10.0. As far as I know, it isn't available for free. (I do have the free Turbo C++ 2006 Explorer installed, though.) If I had access to borland-6.10.0, I would have tried to make a smaller test program to reproduce the internal compiler error. Because I wonder if it is specific to the current implementation of the boost::swap utility... Please let me know if you have any suggestion for boost::swap (or its specialized_in_std.cpp test) to work around the compiler error. Kind regards, Niels PS Your replies don't appear on the mail archives: http://lists.boost.org/Archives/boost/2008/11/index.php http://thread.gmane.org/gmane.comp.lib.boost.devel/182214 Is that intentional?

2 6

[detail/lightweight_mutex] Win32 threading selection in boost/detail/lightweight_mutex.hpp
by joaquin＠tid.es 18 Dec '08

18 Dec '08

Hello, This is a followup of a discussion we had some time ago: http://lists.boost.org/Archives/boost/2007/09/127115.php Lines 31-40 of boost/detail/lightweight_mutex.hpp read like this: #if !defined(BOOST_HAS_THREADS) # include <boost/detail/lwm_nop.hpp> #elif defined(BOOST_HAS_PTHREADS) # include <boost/detail/lwm_pthreads.hpp> #elif defined(WIN32) || defined(_WIN32) || defined(__WIN32__) # include <boost/detail/lwm_win32_cs.hpp> #else // Use #define BOOST_DISABLE_THREADS to avoid the error # error Unrecognized threading platform #endif I think the conditions for selecting boost/detail/lwm_win32_cs.hpp are suboptimal because they're ruling out the case where the user's disabled Pthreads in cygwin/mingw by explicitly defining BOOST_HAS_WINTHREADS, a case covered by boost/config/platform/cygwin.hpp: in such a situation, Win32 threading is available but none of WIN32 and similar are defined by default (unless <windows.h> has been previously included, which makes boost/detail/lightweight_mutex.hpp context dependent). Wouldn't it be better to change the selection code to the following? #elif defined(BOOST_HAS_WINTHREADS) # include <boost/detail/lwm_win32_cs.hpp> #else Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2