December 2008 - Boost - lists.preview.boost.org

[python] Python 3.0
by Robert Dailey 06 Dec '08

06 Dec '08

Will Boost.Python 1.37 work with the Python 3.0 library?

4 6

Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd
by Vladimir Batov 06 Dec '08

06 Dec '08

> ... > All in all my impression of the *current* situation with the proposal is > that at *present* we have many useful and promising bits and pieces lying > around. I see good ideas. I see good suggestions. I fail to see the > product. It surely is a good start but to me we have not reached the > destination yet. I'd be more comfortable after I see those bits and pieces > taking shape. For me that shape primarily would be the interface and the > documentation -- the initial pieces of the contract between the user and > the implementor. Once both parties are happy with the contract, you'll > beaver away providing the content/implementation. Now that I looked at the code once again, I think I'd like to take back the "bits and pieces lying around" bit (as it feels plain wrong and I think I need better glasses to see things the first time around :-)). In fact, I feel that all the pieces are more/less in place and I'll be very much in content if I see something along the following lines: namespace boost { class uuid { struct time_generator; struct random_generator; struct best_generator; template<class Generator> uuid(Generator const&) {...} or template<class Generator> uuid(Generator const& =best_generator()) {...} static uuid null() { ... } typedef void (base::*bool_type)(); void internal_bool() {}; operator bool_type() const { return *this == null() ? 0 : &base::internal_bool; } ... }; struct uuid::time_generator { ... }; struct uuid::random_generator { ... }; struct uuid::best_generator { ... }; } // boost Replacing is_null() with the implicit "bool" converter is not a syntactic sugar. It's very much idiomatic along the same lines as "a + b" is better than "a.add(b)". I'd probably look at deploying Boost.Range functionality as I see many constructors working with ranges. With that caveat I think I am all willing to abandon my original (a very lonely BTW) position and run over to the happy 'yes' campers. Thanks, Vladimir.

2 1

Re: [boost] [UUID] Code for UUIDs as PODs and other changes
by Scott McMurray 06 Dec '08

06 Dec '08

On Sat, Dec 6, 2008 at 14:07, Roman Yakovenko <roman.yakovenko(a)gmail.com> wrote: > On Sat, Dec 6, 2008 at 11:10 AM, Scott McMurray <me22.ca+boost(a)gmail.com> wrote: >> I remarked the other day that a UUID has a well-defined, portable >> binary format, so I took a bit of time to rearrange things to make the >> UUID class a POD and make more use of the generators idea. Along the >> way I made a few other changes. >> >> I've uploaded the result (with updated docs) to the vault as >> uuid_alt_v13_pod.zip : >> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=uuid_a… >> >> Some elaboration follows below. Comments appreciated. > > Hi. Very nice implementation. I have few question: > Thanks, though most of the implementation credit still goes to Andy. > 1. Why variant() and version() are member function of class uuid? I > think they should be free functions. > Either way would work, obviously. I thought of them as properties of the UUID, rather than some computed thing, but that's an iffy difference, so for normal encapsulation justifications it may better to make them non-member. > 2. May be it is better to introduce "native_generator" which is cross platform? > There is actually a typedef for that. I figured that it would be better to keep the implementations separate and conditionally compile the typedef, rather than try to mix the 2 (or more, if other platforms) implementations into one. That said, strategies would also work nicely for that, and would allow cross-platform specification of which UUID version you'd like, too...

2 2

[shared_ptr] Two suggestions for the aliasing constructor
by Clive Jones 06 Dec '08

06 Dec '08

1) An aliasing constructor that takes an rvalue reference Motivating example: in my code I have a utility function... template <typename T, typename Y> boost::shared_ptr<T> shared_ptr_to_member(const boost::shared_ptr<Y> &ptr, T Y::*ptr_to_member) { return boost::shared_ptr<T>(ptr, &(ptr.get()->*ptr_to_member)); } ...which seems to me a prime candidate for having an overload that takes an rvalue reference. The implementation would be very simple, by direct analogy with the existing aliasing constructor and rvalue constructor. template< class Y > shared_ptr( shared_ptr<Y> && r, T * p ): px( p ), pn() // never throws { pn.swap( r.pn ); r.px = 0; } 2) Refactor the pointer_cast functions to use the aliasing constructor The pointer casting functions were implemented before the aliasing constructor was available; using it, simpler implementation is possible. For example, rewriting static_pointer_cast as: template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const & r) { return shared_ptr<T>(r, static_cast<T *>(r.get())); } ...allows the removal of boost::detail::static_cast_tag and the shared_ptr constructor that accepts it. Regards, --Clive.

1 0

[UUID] Code for UUIDs as PODs and other changes
by Scott McMurray 06 Dec '08

06 Dec '08

I remarked the other day that a UUID has a well-defined, portable binary format, so I took a bit of time to rearrange things to make the UUID class a POD and make more use of the generators idea. Along the way I made a few other changes. I've uploaded the result (with updated docs) to the vault as uuid_alt_v13_pod.zip : http://www.boostpro.com/vault/index.php?action=downloadfile&filename=uuid_a… Some elaboration follows below. Comments appreciated. ~ Scott PODness: As a POD, all the constructors are of course gone. This doesn't bother me, but I have no idea what others will think. In fact, I like it better, since I don't think that serialization to and from strings belongs in the type, and it seems like using a lexical_cast is perfectly reasonable: uuid u = lexical_cast<uuid>("21f7f8de-8051-5b89-8680-0195ef798b6a"); This cuts out a large chunk of code, too. I don't know if it's useful, but aggregate syntax also opens possibilities: uuid u = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */ 0x6b, 0xa7, 0xb8, 0x14, 0x9d, 0xad, 0x11, 0xd1, 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 }; In a possibly controversial move, I changed everything that could throw exceptions. That's not that much, though. The std::string parsing code I had already removed, which was the only source of one exception. The other came from the byte input iterator range constructor, which I kept as an assign member function (though I made mutable iterators available, so it's unnecessary). In there I switched the throw to an assert, assuming that it's reasonable for people to arrange for there to always be 16 elements as a precondition, since it's raw construction (which is used into the generators, for example) rather than something likely to come from user input. Include cost: I took the opportunity to move the stream I/O code out to its own header, like the serialization code is. This means that the uuids/uuid.hpp header is fairly light, as the <locale> and <string> includes are gone. In fact, all that's left are these: #include <boost/array.hpp> #include <boost/assert.hpp> #include <boost/config.hpp> #include <boost/cstdint.hpp> #include <boost/numeric/conversion/cast.hpp> #include <boost/static_assert.hpp> Generators: I liked the idea of using a generator object for the random UUIDs, so I wanted to extend that idea. I renamed it to random_generator, on the theory that random_generator<> isn't strenuous if a user wants the default PRNG. boost::uuids::random_generator<> gen1; boost::uuids::uuid u1 = gen1(); boost::lagged_fibonacci44497 rng; boost::uuids::random_generator<boost::lagged_fibonacci44497&> gen2(rng); boost::uuids::uuid u2 = gen2(); For name-based, I introduced a sha1_generator class. This is seeded with a namespace UUID (those from the RFC are provided in boost::uuids::namespaces), and then has an operator() that takes a byte input iterator range. It may be interesting to add a boost.range overload, allowing the generator to be used as a transform functor for strings. boost::uuids::sha1_generator gen(boost::uuids::namespaces::dns()); std::string name = "www.widgets.com"; boost::uuid u = gen(name.begin(), name.end()); Native UUIDs: I recall that someone in the review wanted an interface to the OS functionality, and I had been looking at Linux's earlier, so I wrote up 2 additional generators. e2fsprogs_generator uses the <uuid/uuid.h> header and libuuid on Linux, and passes all the tests that random_generator does. windows_generator uses UuidCreate, and is completely untested. Variants and Versions: I thought being able to find out these might be a good idea, so they're there too. enum variant_type {variant_ncs = 0, variant_dce = 1, variant_rfc_4122 = variant_dce, variant_microsoft = 2, variant_other = 3}; variant_type variant() const; enum version_type {version_wrong_variant = -1, version_unknown = 0, version_1 = 1, version_time_based = version_1, version_2 = 2, version_dce_security = version_2, version_3 = 3, version_name_based_md5 = version_3, version_4 = 4, version_random = version_4, version_5 = 5, version_name_based_sha1 = version_5}; version_type version() const; Implementation Details: I switched sha1.hpp over to using int32_t to remove the 4-byte-int requirement. I also let it handle 512 MiB+ messages (if size_t can), though that's not a serious concern. I replaced the *reinterpret_cast<unsigned long*> in random_generator with the kind of code used in sha1 that doesn't have the endianness dependence or what I think is an aliasing violation.

1 0

lexical_cast optimization
by David Abrahams 06 Dec '08

06 Dec '08

Someone was asking me today about the inefficiency of lexical_cast for its common itoa/atoi-like usage, and it occurred to me that it could *easily* be optimized to handle the common cases by dispatching to itoa/atoi ftoa/atof where available, and even sprintf. Seems like a great idea to me. Thoughts? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

9 9

[interprocess] default constructors
by Jan Stetka 06 Dec '08

06 Dec '08

Hi, Is there any reason why named_mutex and managed_shared_memory don't have a default constructor?

6 24

Running Boost Regression Tests
by frederic.bron＠alcan.com 05 Dec '08

05 Dec '08

I have tried to run the regression tests but I seem unsuccessful. My machine is a linux RHE4 x86_64 (Linux vorace0 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:32:02 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux). I wanted to test compiler intel 10.0 and g++ 3.4.6 (have also 4.1.0 but the name is g++4 and I do not know how to make boost understand it exists). Here is what I did: 1. downlowd run.py 2. python run.py --runner=bronf --platform=linux_x86_64 --tag=trunk --toolsets=gcc-3.4.6,intel-linux-10.0 I obtained the attached output (run.log) which ends with: # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 60, in ? runner(root) File "/soft/bal/usr/builds/boost_test/tools_regression_src/regression.py", line 189, in __init__ self.main() File "/soft/bal/usr/builds/boost_test/tools_regression_src/regression.py", line 542, in main getattr(self,action_m)() File "/soft/bal/usr/builds/boost_test/tools_regression_src/regression.py", line 507, in command_regression self.command_test() File "/soft/bal/usr/builds/boost_test/tools_regression_src/regression.py", line 313, in command_test self.command_test_boost_build() File "/soft/bal/usr/builds/boost_test/tools_regression_src/regression.py", line 350, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/soft/bal/usr/builds/boost_test/results/boost/bin.v2/libs/any/test/any_test.test' Any clue? F. Bron (See attached file: run.log) Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

5 36

n2427 atomic implementation?
by vicente.botet 05 Dec '08

05 Dec '08

Hi, Can the N2427 - C++ Atomic Types and Operations be implemented without the help of the compiler? Do some one have a partial implementation? Vicente

5 10

[config] BOOST_ALL_DYN_LINK comment in user.hpp
by Michael Marcin 05 Dec '08

05 Dec '08

The comment in boost/config/user.hpp gives 2 examples, both of which appear to be invalid. ------------------------------ // BOOST_ALL_DYN_LINK: Forces all libraries that have separate source, // to be linked as dll's rather than static libraries on Microsoft Windows // (this macro is used to turn on __declspec(dllimport) modifiers, so that // the compiler knows which symbols to look for in a dll rather than in a // static library). Note that there may be some libraries that can only // be statically linked (Boost.Test for example) and others which may only // be dynamically linked (Boost.Threads for example), in these cases this // macro has no effect. // #define BOOST_ALL_DYN_LINK ------------------------------ I believe Boost.Test can now be linked dynamically and Boost.Threads can now be linked statically. -- Michael Marcin

1 0