- Boost - lists.boost.org

Re: [boost] [uuid] Interface
by Vladimir Batov 19 Dec '08

19 Dec '08

>> ... > No. The input iterator constructs from the raw octets, expecting them > as in 4.1.2. Layout and Byte Order Well, I obviously confused the construction from a string and the construction from the raw octets. Quite embarassing. My mind is obviously already chasing that Christmas goose. > I'm still not convinced that that providing the default constructor is > such a bad thing, so I would still like Andy's #define to allow it. I'd like the default constructor as well. Very much in fact. The problem is that our expectations of what that constructor needs to do are quite different. The behavior of the default constructor that you'd like to see (apologies if I got it wrong) is to create an invalid uuid. I feel that is not the canonical use of the default constructor. Indeed, that usage of the default constructor *not* to actually create an object has become quite popular. It does not make it right though. I find it unfortunate and hackish. I feel that the default constructor should indeed construct... with all the default "parameters"... as the language prescribes... as other constructors do. In uuid context it'd be to let the OS/infrastructure decide what is best. That way we'd achieve the best portability without sactificing the quality and I am sure for that reason it'll be the most popular deployment. That's why I'd like that behavior assigned to the simplest available (default) constructor. I do not want to be forced to choose a certain generator just to discover it is not supported on another platform. Having said that I do not see my view getting far. In that case, I'd prefer not to have the default cnstr at all as IMHO it sends the wrong message and enforces the wrong programming practice. Just my view, of course. OK, I guess, it is indeed time for me to tune out and get into that Christmas spirit. Happy Christmas and Happy New Year everyone (pick whichever appropriate). Best, Vladimir.

3 2

accumulators + complex
by Neal Becker 19 Dec '08

19 Dec '08

I'm interested in 2nd order stats for complex numbers. typedef std::complex<double> complex_t; typedef accumulator_set<complex_t, stats<tag::mean, tag::moment<2> > > acc_t; 2 issues: 1) Need template<typename flt_t> inline std::complex<flt_t> operator/ (std::complex<flt_t> const& a, unsigned long int b) { return std::complex<flt_t> (real (a)/b, imag (a)/b); } 2) What do I get for moment<2> in the case of complex (and does this match the usual mathematical definition?)

2 3

[accumulators] misprint in accumulators users guide
by Neal Becker 19 Dec '08

19 Dec '08

The example under 'Defining a New Feature' says: typedef impl::mean_accumulator< mpl::_1 > impl; I think it needs to say: typedef accumulators::impl::mean_accumulator< mpl::_1 > impl;

2 1

interest in properties library
by Daniel Oberhoff 19 Dec '08

19 Dec '08

Hi, I am thinking about submitting a library proposal and would like to query wether there is any interest in such a library and chance of success of such a proposal. The basic idea is to implement the possibility to decorate a class with named properties, such that given a pointer to an instance properties can be accessed by name rather than using set/get methods. Also the type of the instance should not need to be known at compile time, other than that it derives from a suitable base class describing the property mechanisms. There is a rough implementation existing and used in a product environment. Setting and getting is done using appropriate boost functions. Type resolution is done using RTTI (especially dynamic cast). Complex inheritance hierarchies are supported through virtual inheritance from the base class, such that several classes along the hierarchy can contribute property slots. CRTP and static initialization is used to register properties. Convenient setter/ getter function generators are provided as is a mechanism to access nested properties using dot notation. I would very much like to put this work into the community as I think it will only make it better, plus I want to give back to boost since it has been a lot of help to me and still is. Best Daniel Oberhoff Fraunhofer FIT Schloss Birlinghoven St. Augustin Germany

2 1

[Msm] New version available
by Christophe Henry 19 Dec '08

19 Dec '08

Hi, Santa was a bit early this year and he just brought into the vault (http://www.boostpro.com/vault/index.php?direction=&order=&directory=Msm&) the new version of Msm, 1.10. You will find inside support for: - explicit entries - fork - entry pseudo states - exit pseudo states - conflicting transitions And a few bugfixes. It lasted a while, but I hope you will have fun with it. I will be thankful for any comment I will get. Cheers, Christophe

1 0

Asking for feedback for book (in German) about the Boost C++ libraries
by Boris 19 Dec '08

19 Dec '08

I've written a book in German about the Boost C++ libraries and uploaded it to http://www.highscore.de/cpp/boost/. As this is the very first version it's currently only available in HTML. I would appreciate any feedback about the content, presentation, examples, typos :) etc. Thanks, Boris

3 4

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