September 2006 - Boost-users - lists.preview.boost.org

[function_types][review schedule] new version released
by Tobias Schwinger 17 Sep '06

17 Sep '06

Dear Boost community, a new version of the FunctionTypes candidate library has been uploaded to the vault: http://tinyurl.com/qaf5f What's new (compared to the last "official" version, not the preview)? ====================================================================== - The interface, - the documentation, - the test-suite, - carefully picked and inline-documented source code examples, - the code generator for preprocessed files is entirely written on top of Wave, - the preprocessed files and the configuration (up to a certain extent) are compiler-agnostic, - the preprocessed files do not have to be regenerated for custom configurations, unless for optimization (and changing the library code, of course), and - the library is default calling convention-agnostic, OIW the default calling convention can be changed and detected without changing the library's configuration (unless for MSVC<8 due to the lack of a 'thiscall' keyword) Unless there are any objections from the review manager regarding the fitness of the submission, we can put the library back on the review schedule -- my apologies for it took so long, BTW. Regards, Tobias

1 0

Boost-Install on Mac OS X
by Chris M 17 Sep '06

17 Sep '06

Hi I'm trying to build boost on Mac OS X 10.4.7. I had some Python issues and jam complained about Boost.Python so I downloaded and installed Python 2.4. Still though, that didn't fix it. I tried a half-hearted attempt at creating some symbolic links but decided there must be a "right" way to install boost on the latest mac OS X and was wondering if anyone here can point me toward a writeup of the process. Thanks, Chris

2 1

Properties (newbie)
by Olivier Tournaire 17 Sep '06

17 Sep '06

I have already post this email, but I cannot see it on the list. So, I post it again ... Sorry ... Hi all, I am a new boost user (2 days old ...). I just want to know a few things. 1. I use an adjacency_list with my own properties to store my graph. I just want to know if it is possible to manipulate directly the properties' values. At the moment, I use get(...) to obtain the property, make my change, and use put(...) to set the new value. 2. My graph cannot contain parallel edges, so I use a setS. However, the documentation says that listS or vecS is more efficient in time and space complexity. Is it possible to use std::vector or std::list and to disallow parallele edges ? Thanks in advance Olivier --------------------------------- Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. Cliquez ici.

3 2

Re: [Boost-users] [serialization] Purpose of load_construct_data (was: Re: Library Interface Design)
by JOAQUIN LOPEZ MU?Z 16 Sep '06

16 Sep '06

Hello again, lots of talking to each other today :) ----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Sábado, Septiembre 16, 2006 8:03 pm Asunto: Re: [Boost-users] [serialization] Purpose of load_construct_data (was: Re: Library Interface Design) > JOAQUIN LOPEZ MU?Z wrote: [...] > > http://boost.org/libs/serialization/doc/ > > serialization.html#constructors > > where my_class serializes my_class::m *both* at > > my_class::serialize *and* my_class::(load|save)_construct_data. > > If the analysis I develop in my previous post is correct > > (is it?) this leads to my_class::m being serialized *twice* > > when a pointer to my_class is saved. Maybe it would sufice > > to rewrite this part of the documentation with a more > > sensible example like the one at test_non_default_ctor.cpp. > > What do you think? > > I agree. The fact that the example uses a member variable confuses > the issue. I'll amend the documentation accordingly. Thank you! > However, the current example does illustrate a case where it > seems impossible to avoid serializing a member twice. One > could leave it in the load_construct_data, and eliminate it from > the serialization code - but then this would work only if the > object was serialized via a pointer. If it were my program I would > say hmmmm - I'm really confusing the role of the variable m - If > its to be initialzed at construction - it shouldn't be messed with > by serialization or operator= etc. If its realy part of the objects > dynamic state - then it shouldn't be required at construction time. Well, I think the apparent puzzle stems from the incorrect assumption (IMHO) that a given member must be either part of the construction info or dynamic state --in many cases, it can be *both*, which is precisely what happens with my_class. I'd appreciate if you can consider this extension proposal that would allow for one-phase serialization while keeping the statu quo --maybe we can have our cake and eat it too :) Augment the serialization interface with a pair of new user-overridable function like this: template<typename Archive, class T> inline void construct_from_archive( Archive & ar, T * t, const unsigned int file_version) { // default implementation load_construct_data(ar,t,file_version); ar>>*t; } template<typename Archive, class T> inline void construct_to_archive( // OK, the name is ugly Archive & ar, const T * t, const unsigned int file_version) { // default implementation save_construct_data(ar,t,file_version); ar<<*t; } and use it when serializating T through a pointer. Now, if we return to the case of my_class, where my_class::m is both used at construction them and serialized as part of my_class::serialize, we can handle all situations as follows: // as in your example template<class Archive> inline void save_construct_data( Archive & ar, const my_class * t, const unsigned int) { ar << t->member; } // as in your example template<class Archive> inline void load_construct_data ( Archive & ar, my_class * t, const unsigned int) { int m; ar >> m; ::new(t)my_class(m); } // this is new template<class Archive> inline void construct_to_archive( Archive & ar, const my_class * t, const unsigned int fv) { save_construct_data(ar,t,fv); // avoid m being saved twice } // this is new template<class Archive> inline void construct_from_archive( Archive & ar, my_class * t, const unsigned int fv) { load_construct_data(ar,t,fv); // avoid m being loaded twice } My proposal basically amounts to adding a new customization point to the existing protocol for serialization of pointers. It has the following advantages: * You don't break anything (it's a pure extension). * It addresses a concern (one-phase serialization) that is conceptually different to the concerned addressed by (load|save)_construct_data (serializing non default- constructible objects), and does it so in an orthogonal manner. * It lets you solve the problem of members being both part of construction info and dynamic state, as I've (hopefully) just shown . How do you like this? > Anyway, I'll alter my example to make the variable in question > "const" and remove it from serialization which is a better > of example of the real cases where this can come up. > > Robert Ramey Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] [serialization] serialization of pointers toprimitive types?
by JOAQUIN LOPEZ MU?Z 16 Sep '06

16 Sep '06

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Sábado, Septiembre 16, 2006 7:50 pm Asunto: Re: [Boost-users] [serialization] serialization of pointers toprimitive types? > JOAQUIN LOPEZ MU?Z wrote: [...] > > Wouldn't it be an option that pointers to > > primitive types will be handled as non-tracked? What would be > > the overhead of that option? In case this is an option, please > > consider my vote for inclusion as a new feature in Boost 1.35. > > OK - that would work fine - but I also believe it would trip the > infamous "const trap" so that might have to be considered. Umm... Well, at first blush, seems like serializating a pointer to a primitive type is no different than serializing a pointer to a non-primitive type --the same const issues, controversial as they might be, are already present. Besides, this new feature would be a pure extension, in the sense that code that didn't compile before would do now, so, you're positively not breaking anything. [...] > So - although the problem never comes up for me I concede your > point. I have erroneously confused the identity of two concepts - > serialization and tracking. From that standpoint I'm inclined > to make the change you suggest. The only concern is that it would > breakone of the user traps that inhibits certain user behavior > because it will almost surely lead to intractible problems. Again, I don't see how ensuring that the const rule works also for primitive types is any harder than the current implementation, which only applies to non-primitive type --seems like all you've got to do is to extend the enforcement in a straightforward manner. But then again, you're the implementor and surely can see internal difficulties I'm not aware of. > Dealing with the trap is a pain - but its much less painful than > dealing with user's who have done something that is permitted and > seems natural to do end up having archives that cannot be read or > recovered. I believe that serializing someting like > std::set<int *> will eventually lead to such problems eventually > in most cases. > > To summarize, you're correct. But I'm concerned that just > "fixing" the code will create new set of problems. Thanks for addressing my concern! Well, if you're doing the change for Boost 1.35 we'll surely have plenty of time to detect any potential problems that might arise. > Robert Ramey Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] Comments / Advice on using Boost Test Library
by Sohail Somani 16 Sep '06

16 Sep '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Matt Schuckmann > > What I'd like to ask the Boost community about is this: how to go > > about unit testing private class methods. Hi, Rather than change the interface of my classes to use friend classes (I feel this unnecessarily clutters the interface), I do something simple and evil: #define private public #define protected public # include "MyClass.hpp" #undef private #undef protected Or something along those lines. This is permissable in unit tests, I would think. Sohail

4 4

Re: [Boost-users] [serialization] serialization of pointers to primitive types?
by JOAQUIN LOPEZ MU?Z 16 Sep '06

16 Sep '06

Hello Robert, ----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Sábado, Septiembre 16, 2006 8:01 am Asunto: Re: [Boost-users] [serialization] serialization of pointers to primitive types? > Serialization of pointers to primitive data types is prohibited. > I'm pretty sure this is mentioned in the documentation. ( don't > have the exact reference handy) I've persued the docs and in every place where this is referred to, the statement is that primitive types are not tracked, which is IMHO different than serialization of pointers to primitive types being forbidden. Examples: - Serializable concept: "A type T is Serializable if and only if one of the following is true: * it is a primitive type. [...] * it is a pointer to a Serializable type.[...]" from which it can be deduced that a pointer to a primitive type is serializable. - Object tracking: "Default tracking traits are: * For primitive, track_never.[...]" At the risk of repeating myself, I understand what serializing a pointer to a non-tracked type involves. This is not the same as not being able to serialize the pointer in the first place, which is what happens with primitive types, to my dismay. > - and it has been noted a couple of times. The reason is that > doing this would result in ALL usages of that type being tracked > - which is probably a heck of a lot more than the user had in mind. I'm not talking about primitive types being tracked, which I agree with you implies an unacceptable burden, but about the mere possibility of serialization of a pointer to a primitive type. Wouldn't it be an option that pointers to primitive types will be handled as non-tracked? What would be the overhead of that option? In case this is an option, please consider my vote for inclusion as a new feature in Boost 1.35. > > The way to serialize pointer to primitives > (serialization_level::prmitive) is to use BOOST_STRONG_TYPEDEF to > define a new type and specify serialization function for it. This > won't work for std::string so you'll have to make a trivial > derivation of std::string if you want to serialize a pointer to a > std::string. The problem with that is that it is an intrusive solution that complicates things when dealing with generic code. Sometimes, it can be just impossible to do that intrusive change or require the user to do it. From this restriction, for instance, we have that std::set<int*> is not serializable as is. Telling the user to change her definition to something like std::set<BOOST_STRONG_TYPEDEF(...)*> just for the sake of serializability could be unacceptable in some (many?) situations. > Robert Ramey Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Writing a more readable code
by Alexander Shyrokov 16 Sep '06

16 Sep '06

How can make the following code inside of for_each more readable? void f(char*); typedef std::map<int,char> TMap; TMap a; std::for_each(a.begin(),a.end(),boost::bind(f,boost::bind(&TMap::value_type::second,_1))); Is it possible to convert boost::bind(&TMap::value_type::second,_1) to a function object or a typedef name? -- Regards, Alexander. http://sjcomp.com

4 5

Re: [Boost-users] [boost::serialization] Convert enumeration tostringand back again
by Nat Goodspeed 16 Sep '06

16 Sep '06

> ________________________________________ > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey > Sent: Saturday, September 16, 2006 2:27 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [boost::serialization] Convert enumeration tostringand back again > > class param_choice { > enum > { > PARAM_CHOICE_UINT8, > PARAM_CHOICE_UINT16, > PARAM_CHOICE_UINT32, > PARAM_CHOICE_INT8, > PARAM_CHOICE_BOOL > } m_current_value; > template<class Archive> > save(Archive &ar, unsigned int version) { > std::string svalue; > switch(m_current_value){ [Nat] If I were going to do this "by hand," I'd at least want to construct a map. From that I'd populate another for the reverse lookup. But that's probably because I haven't yet read up on Boost.MultiIndex. > case PARAM_CHOICE_UINT8: > svalue = "PARAM_CHOICE_UINT8"; > ... > } > ar << BOOST_SERIALIZATION_NVP(svalue); > } > template<class Archive> > load(Archive &ar, unsigned int version){ > std::string svalue; > ar >> BOOST_SERIALIZATION_NVP(svalue); > if(svalue == std::string("PARAM_CHOICE_UINT8") > m_current_value = PARAM_CHOICE_UINT8; > else > if(... > ... > } > };

1 0

Re: [Boost-users] Library Interface Design
by Nat Goodspeed 16 Sep '06

16 Sep '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Scott Meyers > Sent: Tuesday, September 12, 2006 1:09 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] Library Interface Design > > I've always been a big fan of the "don't let users create objects they > can't really use" philosophy. So, in general, I don't like the idea of > "empty" objects or two-phase construction. It's too easy for people to > make mistakes. [Nat] I try to design for single-phase construction myself. The aberrant use case that I've bumped into is deserialization. Intrusive serialization can preserve single-phase construction -- but what if the class designer didn't anticipate the need to serialize? I haven't yet worked with a serialization framework smart enough to consider constructor arguments. (I haven't yet worked with the Boost Serialization library, either; forgive me if this is already a solved problem.)

8 16