- Boost - lists.boost.org

[unique_ptr] So how is it used differently?
by Sid Sacek 23 Dec '08

23 Dec '08

Thank you, I didn't realize it was already a part of the latest boost library. What I'm curious about is two things... 1) When would I choose unique_ptr<> over auto_ptr<> ? And 2) When would I choose unique_ptr<> over scoped_ptr<> ? Can somebody please provide some coding differences? If these coding examples are already documented someplace, can you please direct me to them? Thank you very much in advance. -Sid Sacek -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of OvermindDL1 Sent: Sunday, December 21, 2008 6:01 AM To: boost(a)lists.boost.org Subject: Re: [boost] unique_ptr, was: Composing non copyable and movable classes On Sat, Dec 20, 2008 at 3:10 PM, Sid Sacek <heavyreign(a)optonline.net> wrote: > > I tried to locate the mentioned unique_ptr<> classes for testing, but am > unable to locate them. > > Can somebody point me in the right direction please? This is the only unique_ptr I know of: http://www.boost.org/doc/libs/1_35_0/doc/html/interprocess/interprocess_smar t_ptr.html#interprocess.interprocess_smart_ptr.unique_ptr _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

5 6

Computer Properties
by Sid Sacek 23 Dec '08

23 Dec '08

Is there a boost library that provides information like: 1) Number of CPU cores ? 2) Total amount of system RAM ? 3) Other system and hardware basics ? Regards, -Sid Sacek

3 3

"thread's copy constructor is inaccessible" BUG in solaris.
by Maruvekere, Praveen (Contractor) 23 Dec '08

23 Dec '08

Hi , I have done the temporary fix to build the boost 1.37.0 as told in one of the solaris user forum thread http://forums.sun.com/thread.jspa?threadID=5326640 <http://forums.sun.com/thread.jspa?threadID=5326640> for the below said error sun.compile.c++ bin.v2/libs/thread/build/sun-5.9/release/link-static/threading-multi/thr ead.o "./boost/thread/detail/thread.hpp", line 344: Error, inaccessible: boost::thread::thread(boost::thread&) is not accessible from boost::move(boost::detail::thread_move_t<boost::thread>). 1 Error(s) detected. Do I need a patch to fix this? -PM-

2 1

[uuid] Interface
by Andy Tompkins 22 Dec '08

22 Dec '08

Here is what I see the interface looking like based on feedback from the review so far. It would, of course, be split into different header files. namespace boost { namespace uuids { class uuid : boost::totally_ordered<uuid> { // no default constructor private: uuid(); public: typedef ... value_type; // will only represent one octet typedef ... iterator; typedef ... const_iterator; typedef ... difference_type; typedef ... size_type; enum variant_type { variant_unknown, variant_ncs, variant_rfc_4122, variant_microsoft }; enum version_type { version_unknown, version_1 = 1, version_2 = 2, version_3 = 3, version_4 = 4, version_5 = 5, version_time_based = version_1, version_dce_security = version_2, version_name_based_md5 = version_3, version_random_number_based = version_4 version_name_based_sha1 = version_4 }; public: // valid expression // generator() - result type must be convertible to a uuid template <typename Generator> explicit uuid(Generator & generator); // assert(std::distance(begin, end) >= 16); template <typename ByteInputIterator> uuid(ByteInputIterator begin, ByteInputIterator end); iterator begin(); iterator end(); const_iterator begin() const; const_iterator end() const; bool is_nil() const; operator unspecified_bool_type() const; // return !is_nil(); static size_type size(); // always return 16 bool operator==(uuid const& rhs) const; bool operator<(uuid const& rhs) const; variant_type variant() const; version_type version() const; }; void swap(uuid & lhs, uuid & rhs); std::size_t hash_value(uuid const& u); // removed get/set_showbraces (does anybody want/use them?) template <typename ch, typename char_traits> std::basic_ostream<ch, char_traits>& operator<<(std::basic_ostream<ch, char_traits>& os, uuid const& u); template <typename ch, typename char_traits> std::basic_istream<ch, char_traits>& operator>>(std::basic_istream<ch, char_traits>& os, uuid& u); class nil_generator // always generates a nil uuid { public: typedef uuid result_type; uuid operator()(); }; uuid nil(); // easy to use function - should it be included? template <typename RandomGenerator = boost::mt19937> class random_generator { public: typedef uuid result_type; random_generator(); explicit random_generator(RandomGenerator & gen); explicit random_generator(RandomGenerator * gen); uuid operator()(); }; // I guess technically a transformer since it does not have a zero argument // operator() class name_based_generator // uses sha1 hash { public: typedef uuid result_type; explicit name_based_generator(uuid const& namespace_uuid); template <typename ch, typename char_traits, typename allocator> uuid operator()(std::basic_string<ch, char_traits, allocator> const& name); uuid operator()(const char* name); // use std::strlen uuid operator()(const wchar_t* name); // use std::wcslen template <typename ByteInputIterator> uuid operator()(ByteInputIterator begin, ByteInputIterator end); }; class windows_generator // uses UuidCreate { public: typedef uuid result_type; uuid operator()(); }; class linux_generator // used uuid_generate { public: typedef uuid result_type; uuid operator()(); }; // on windows - will typedef to windows_generator // on linux - will typedef to linix_generator typedef ... native_generator; } //namespace uuids using uuids::uuid; // so nobody has to type boost::uuids::uuid } //namespace boost BOOST_CLASS_IMPLEMENTATION(boost::uuids::uuid, boost::serialization::primitive_type) /* uuid Generator concept Notation: X - a type that is a model of uuid generator x - an object of type X Associated Types: Result Type - X::result_type - this must be convertable to boost::uuids::uuid Valid Expressions: x() - return a boost::uuids::uuid */ Regards, Andy Tompkins

4 5

[boost.build] should we not define _SECURE_SCL=0 by default for all msvc toolsets
by Thorsten Ottosen 22 Dec '08

22 Dec '08

Dear all, Is there are reason why we do not compile with this flag set by default? Are there any users of Boost out there which actually wants the securuty mode turned on? If not, then I suggest that we change the build settings. Thanks in advance -Thorsten

13 28

Processor traits
by Antoine de Maricourt 22 Dec '08

22 Dec '08

Hi, is there in boost a trait to describe current target capabilities, i.e. processor's available instruction set, size of registers (32, 64, ... bits) and any other usefull feature? To give an example, I'd like to write code like the following one, with different versions of the same function depending on target capabilities. Regards, Antoine. --- namespace detail { template <typename T, unsigned D, typename P = current_target_trait> struct _popcount; template <> struct _popcount<__m128i, 128, ssse3> { int operator()(const __m128i& x) { static const __m128i M = { 0x0f0f0f0f0f0f0f0fULL, 0x0f0f0f0f0f0f0f0fULL }; static const __m128i C = { 0x0302020102010100ULL, 0x0403030203020201ULL }; __m128i y = _mm_add_epi16 (_mm_shuffle_epi8 (C, _mm_and_si128 (x, M)), _mm_shuffle_epi8 (C, _mm_and_si128 (_mm_srai_epi16 (x, 4), M))); return _mm_cvtsi128_si32 (_mm_sad_epu8 (_mm_hadd_epi16 (y, y), _mm_setzero_si128())); } }; // Count bits in the low 64-bit quad word template <> struct _popcount<__m128i, 64, ssse3> { int operator()(const __m128i& x) { static const __m128i M = { 0x0f0f0f0f0f0f0f0fULL, 0x0f0f0f0f0f0f0f0fULL }; static const __m128i C = { 0x0302020102010100ULL, 0x0403030203020201ULL }; __m128i y = _mm_shuffle_epi8 (C, _mm_and_si128 (_mm_unpacklo_epi32 (x, _mm_srai_epi16 (x, 4)), M)); return _mm_cvtsi128_si32 (_mm_sad_epu8 (_mm_hadd_epi16 (y, y), _mm_setzero_si128())); } }; } template <typename T> int popcount (const T& data) { return detail::_popcount<T,sizeof(data)*8>()(data); }

2 1

Re: [boost] interest in properties library
by Daniel Oberhoff 22 Dec '08

22 Dec '08

> Hello, Daniel. > > Saturday, December 20, 2008 at 4:29:53 PM you wrote: > > DO> What I still want to do is enable simpler syntax and maybe signals > DO> triggered by property and other goodies, but that is actually > rather > DO> simple to do, using bind and/or lambda. > > Some time ago I showed another way to define properties for the class. > I think what this way quite simpler. Take a look: > > > Hi. I saw this in the list. I like the notational simplicity, but it does it allow run-time addressing of properties (i.e. scripting, setting properties from config files) and accessing properties without knowing the full type? The latter becomes important when you don't want to include headers for everything or load additional classes through plugins. I have also found some properties stuff in the sandbox, especially one that nice handles property graphs, but none fulfilled the above requirements. So maybe this is too specialized? I thought it would be a great way to allow scriptable access to properties of classes that are not known at compile time, and thereby allow easy runtime setup of a modular system. Thanks for the replies though, some interesting thoughts. Daniel

2 1

[config] gcc and <unordered_set> vs <ext/hash_set>
by John Maddock 22 Dec '08

22 Dec '08

Folks, Dave A. asked for a config macro to detect the presence of std conforming <unordered_set> and <unordered_map>. However, I've run into an unexpected issue: it appears that with gcc-4.3.x you cannot include both <unordered_set> and <ext/hash_set> as attempting to do so leads to endless errors inside the <ext/*> headers :-( Including either one of the headers is just fine though. So... how should we handled this? Not define BOOST_HAS_HASH when <unordered_set> *is* available? As far as I can tell the only library effected by this change would be Boost.Serialization which would lose has_set support in gcc's c++0x mode. How do folks feel about that? Regards, John.

5 6

[smart_ptr] shared_ptr::before(), owner_less, etc.
by Frank Mori Hess 22 Dec '08

22 Dec '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If I provide a patch that adds support for before() methods to boost::shared_ptr and weak_ptr, and a boost::owner_less (as described in n2637) would it be considered? I don't plan to change the semantics of boost::shared_ptr::operator<(), I just want to make it slightly easier to write code that will be portable across boost::shared_ptr and the upcoming std::shared_ptr. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJSv/f5vihyNWuA4URAuCbAKDQc5/ufv01thvyrLUScX2GpiXMZACgkzII +6c/b6ZJ9e5oee7O9DWxI6Q= =Ggbl -----END PGP SIGNATURE-----

2 3

Re: [boost] interest in properties library
by Daniel Oberhoff 21 Dec '08

21 Dec '08

> On Sat, Dec 20, 2008 at 5:29 AM, Daniel Oberhoff > <daniel.oberhoff_at_[hidden]> wrote: > > HasPropertiesBase<VariantTypes> * foo = new Foo; > > foo->set_property("a", 1); > > int a = get<int>( foo->get_property( "a" ) ); > > If this is your typical use case, I would implement properties > non-intrusively in a separate property_database: > > property_database pd; > boost::shared_ptr<Foo> foo(new Foo); > pd.set<int>(foo,"a"); > > The property_database class is essentially a > std::map<boost::weak_ptr<void>,std::map<std::string,boost::any>>, and > you'd dynamic_cast<void *> the pointers passed to set and get. > Interesting approach. If you need non-intrusiveness. Though if intrusiveness is not a problem I think my approach is better, because a) you bind the properties explicitly to the class and thus have much less setup work to do and b) it automatically manages many properties along the inheritance graph. > > Another thought, you can also use tag types to make the properties > compile-time type-safe. See the similar system used in > http://www.boost.org/doc/libs/1_37_0/libs/exception/doc/boost-exception.html > . > In that case the syntax could be: > > typedef property<struct tag_a,int> prop_a; > pd.set(prop_a(42),foo); > int p=pd.get<prop_a>(foo); > Well, I use boost::variant, the other option is boost::any. The variant makes it possible to inspect the type at runtime and automate conversions, while the boost:.any would give you type safety. I admit your approach would be more efficient, but I designed this with scriptability in mind, which is also why I use strings as keys. Also it looks like your approach does not allow addressing properties at run-time. Daniel

1 0