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

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

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

21 Dec '08

> Daniel Oberhoff wrote: > > > HasPropertiesBase<VariantTypes> * foo = new Foo; > > foo->set_property("a", 1); > > int a = get<int>( foo->get_property( "a" ) ); > > And I suppose if it's not an int, it throws? > For proprieties, it might be better to provide lexical conversion to > the > target type, so that it always succeeds (modulo allocation errors). > > Anyway, I'm not too sure this is very useful. > It's just a std::map<std::string, some_variant_type>. Does that really > deserve its own class? > well, this was the simpler case. by using variants and defining proper visitors conversions can be made automatically, like using lexical_cast, which is what I wanted to do soon (I alread do the simple conversions, just learned about lexical cast now). But the point of the lib is actually, that you don't need to know the type of the class, plus that you have arbitrary setter/getter methods. Also properties from classes along the inheritance graph get concatenated into a single interface. Daniel

1 0

[crypto] Bug in md5
by Konstantin Litvinenko 21 Dec '08

21 Dec '08

Hi All! I just tried crypto library from the vault and immediately hit a bug :) in message_digest.hpp template<class Context> std::string message_digest<Context>::to_string() const { // !!!BUG!!! Should be context_type::digest_length * 2 + 1 char buf[context_type::digest_length * 2]; for (int i = 0; i < context_type::digest_length; ++i) std::sprintf(buf + i * 2, "%02x", static_cast<const unsigned char*>(digest())[i]); return std::string(buf, context_type::digest_length * 2); }

2 1

Composing non copyable and movable classes
by vicente.botet 21 Dec '08

21 Dec '08

Hi, Imagine a class X which contains several noncopyable and movable members Ci mi;. class X : noncopyable { C1 m1; C2 m2; // ... Ck mk; // ... }; Very often a class is made movable by storing a pointer to some implementation data on a shared_ptr. Without allocator this means a heap new/delete. If the class accept allocators this means an allocate/deallocate on the allocator. class Mi : noncopyable { struct implementation_data; shared_ptr<implementation_data> data_; // ... }; The question is how to make X movable efficiently. The first way is to move each one of the movable objects one by one. This could be expensive if the number of members is high. In addition X can have also member that are not movable. The second approach is to use the same technique, store a pointer to the data on a shared_pointer, and move on one operation all the members via the pointer. class X : noncopyable { struct implementation_data { C1 m1; C1 m2; // ... C1 mk; }; shared_ptr<implementation_data> data_; public: // ... }; In this case the class X don't need any more that its members be movable. In order to avoid the allocation/deallocation of the respective classes Ci, it would be interesting to have a class which is not copyable and not movable and that owns the implementation class nonmovable_Ci : noncopyable { struct implementation_data; implementation_data data_; // ... }; Except the movable support, the nonmovable_Ci class share with Ci the same functionality. But is not related to Ci by inheritance. Both classes model a common concept. Of course this can not be applied if the implementation_data must be hidden in some .cpp file (pimpl idiom). The consequence is the classes and functions that should work with both implementations need to be templated. This allows the class X to allocate all the data at once. class X : noncopyable { struct implementation_data { nonmovable_C1 m1; nonmovable_C1 m2; // ... nonmovable_C1 mk; }; shared_ptr<implementation_data> data_; public: // ... }; I think that this separation is in line with the C++ principle "you don't pay for what you don't use". Any thoughts? Vicente

12 18

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

20 Dec '08

> On Fri, Dec 19, 2008 at 5:50 AM, Daniel Oberhoff < > daniel.oberhoff_at_[hidden]> wrote: > > 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'm not sure I follow exactly what you mean, could you give a small > example > of the interface and usage? It sounds like you are referring to > something > along the lines of C# properties though I don't immediately see what > you are > using dynamic casting for or what exactly this provides as a benefit > over > get/set methods. Thanks. sorry, forgot the examples. so, to enable properties for a class: class Foo : public HasProperties<VariantTypes, foo> { protected: typedef HasProperties<VariantTypes, foo> PBase; typedef Foo This; static void init_properties() { PBase::add_ivar_property_rw( "a", &This::a ); } private: int a; }; usage: HasPropertiesBase<VariantTypes> * foo = new Foo; foo->set_property("a", 1); int a = get<int>( foo->get_property( "a" ) ); Here VariantTyped is a mpl::sequence Furthermore it still works when a class has several such properties activated classes along its inheritance ancestors, and all properties can be acessed unless there is a name conflict, in which case classes further down override properties from its ancestors, though this could be handled differently. What I still want to do is enable simpler syntax and maybe signals triggered by property and other goodies, but that is actually rather simple to do, using bind and/or lambda. Best Daniel

4 3

Re: [boost] [boost.build] should we not define _SECURE_SCL=0bydefault for all msvc toolsets
by raindog＠macrohmasheen.com 20 Dec '08

20 Dec '08

I read about people running into them frequently enough on internal discussion aliases at microsoft (where I work) and recall just last week I believe someone who ran into a perf issue on this newgroup while writing a sorting algorithm ------Original Message------ From: Emil Dotchevski Sender: To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Dec 20, 2008 12:13 AM Subject: Re: [boost] [boost.build] should we not define _SECURE_SCL=0bydefault for all msvc toolsets On Fri, Dec 19, 2008 at 10:34 PM, <raindog(a)macrohmasheen.com> wrote: > The checks are however a huge performance hit that people tend to be caught by surprise with. Not my experience. The checks do affect performance, but rarely enough to get on my radar. I do like having them on by default. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

2 1

[Test] should we consider to turn off argument deduction for 2nd template parameter
by Thorsten Ottosen 20 Dec '08

20 Dec '08

Hi Genndiy, When I write code like BOOST_CHECK_CLOSE( a->conditionals().sum(), 2., 0.001f ); I tend to get a compilation error the first time, because I wrote BOOST_CHECK_CLOSE( a->conditionals().sum(), 2, 0.001f ); I think that many users are not helped very much by the resulting error messages deep inside the test library. Maybe we should consider to turn off deduction for the second argument with template< class T > bool operator()( T l, mpl::identity<T>::type r, ... ); ? Any thoughts. -Thorsten

5 6