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

[serialization] serialization of pointers to primitive types?
by Joaquín Mª López Muñoz 17 Sep '06

17 Sep '06

The following test program: #include <boost/archive/text_oarchive.hpp> #include <sstream> int main() { int x=0; int* const px=&x; std::ostringstream oss; boost::archive::text_oarchive oa(oss); oa<<px; return 0; } produces this error in MSVC++ 6.0: ...boost/serialization/access.hpp(109) : error C2228: left of '.serialize' must have class/struct/union type ...boost/serialization/serialization.hpp(81) : see reference to function template instantiation 'void __cdecl boost::serialization::access::serialize( class boost::archive::text_oarchive &,int &,const unsigned int)' being compiled and the following error in GCC 3.2: ...boost/serialization/access.hpp: In static member function `static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive, T = int]': ... ...boost/serialization/access.hpp:109: request for member `serialize' in `t', which is of non-aggregate type `int' I've checked the same snippet against Boost 1.33.1, CVS HEAD and RC_1_34_0, using other primitive types like std::string, same problem always. Same problem also for the loading counterpart. When the pointed-to type is not primitive, though, everything works fine, regardless of whether the type has intrusive or non intrusive serialization support. I am sure I'm doing something really stupid here, but I've been banging my head against this several hours. Some clue greatly appreciated. Thank you, Joaquín Mª López Muñoz Telefónica, Investigación y Desarrollo

3 4

[timer] Comments do not match the implementation?
by KSpam 17 Sep '06

17 Sep '06

I would like to use boost::timer to replace a timing object from another library. In looking into the header file, I noticed the following comments: // It is recommended that implementations measure wall clock rather than CPU // time since the intended use is performance measurement on systems where // total elapsed time is more important than just process or CPU time. All is well and good I thought to myself ... wall clock is exactly what I want! But alas, the implementation just wraps std::clock(). The man page for clock states the following: "The clock() function returns an approximation of processor time used by the program." In summary, the header states that the timer implementation should use wall clock time, but it ignores its own advice and uses processor time. I'm confused. Do I need to create my own timer implementation in order to use wall clock time? Thanks, Justin

2 2

Re: [Boost-users] Boost serialization : concurrency (was Possibleto append...)
by Robert Ramey 17 Sep '06

17 Sep '06

So now you know my intention - and I believe that the code reflects that. I'm guessing that the key might be that the DLL gets unloaded "too soon" so that we get a seg fault by invoking code that is no longer in memory. But as you have discovered - this is very problematic to track down and could be a subtle error of my own, an error in the language support system (loading/unloading DLLS). Overzealous optimization on the compiler's part or something else entirely. Sorry I can't be of more help. Good Luck Robert Ramey

1 0

[asio] Strange compilation error
by Christian Henning 17 Sep '06

17 Sep '06

Hi there I'm experiencing a strange compilation error that I cannot resolve myself. The following non-functionating triggers the error. I'm using VC2003 SP1. The error is due to the write() call. template <class T > void sent( const T& object ) { std::ostringstream archive_stream; boost::archive::binary_oarchive archive( archive_stream ); archive & object; std::string outbound_data = archive_stream.str(); // Format the header. std::ostringstream header_stream; header_stream << std::setw( 8 ) << std::hex << outbound_data.size(); std::string outbound_header = header_stream.str(); // Write the serialized data to the socket. We use "gather-write" to send // both the header and the data in a single write operation. std::vector<boost::asio::const_buffer> buffers; buffers.push_back(boost::asio::buffer(outbound_header)); buffers.push_back(boost::asio::buffer(outbound_data)); boost::asio::write( socket, buffers ); } This is the verbose error message: ..\..\..\External\Includes\Boost\asio\impl\write.ipp(40) : error C2825: 'Sync_Write_Stream::error_type': cannot form a qualified name ..\..\..\External\Includes\Boost\asio\impl\write.ipp(58) : see reference to function template instantiation 'size_t boost::asio::write<Sync_Write_Stream,Const_Buffers,boost::asio::detail::transfer_all_t,boost::asio::detail::throw_error_t>(Sync_Write_Stream (__stdcall &),const Const_Buffers &,Completion_Condition,Error_Handler)' being compiled with [ Sync_Write_Stream=SOCKET (int,int,int), Const_Buffers=std::vector<boost::asio::const_buffer>, Completion_Condition=boost::asio::detail::transfer_all_t, Error_Handler=boost::asio::detail::throw_error_t ] SendImages.cpp(75) : see reference to function template instantiation 'size_t boost::asio::write<SOCKET(int,int,int),std::vector<_Ty>>(Sync_Write_Stream (__stdcall &),const Const_Buffers &)' being compiled with [ _Ty=boost::asio::const_buffer, Sync_Write_Stream=SOCKET (int,int,int), Const_Buffers=std::vector<boost::asio::const_buffer> ] ..\..\..\External\Includes\Boost\asio\impl\write.ipp(40) : error C2039: 'error_type' : is not a member of 'operator``global namespace''' ..\..\..\External\Includes\Boost\asio\impl\write.ipp(40) : error C2146: syntax error : missing ';' before identifier 'e' ..\..\..\External\Includes\Boost\asio\impl\write.ipp(40) : error C2065: 'e' : undeclared identifier ..\..\..\External\Includes\Boost\asio\impl\write.ipp(41) : error C2228: left of '.write_some' must have class/struct/union type type is '__w64 unsigned int (__stdcall &)(int,int,int)' ..\..\..\External\Includes\Boost\asio\impl\write.ipp(41) : error C3861: 'e': identifier not found, even with argument-dependent lookup ..\..\..\External\Includes\Boost\asio\impl\write.ipp(44) : error C3861: 'e': identifier not found, even with argument-dependent lookup ..\..\..\External\Includes\Boost\asio\impl\write.ipp(46) : error C3861: 'e': identifier not found, even with argument-dependent lookup ..\..\..\External\Includes\Boost\asio\impl\write.ipp(50) : error C2825: 'Sync_Write_Stream::error_type': cannot form a qualified name ..\..\..\External\Includes\Boost\asio\impl\write.ipp(50) : error C2039: 'error_type' : is not a member of 'operator``global namespace''' ..\..\..\External\Includes\Boost\asio\impl\write.ipp(50) : error C2146: syntax error : missing ';' before identifier 'e' ..\..\..\External\Includes\Boost\asio\impl\write.ipp(50) : error C3861: 'e': identifier not found, even with argument-dependent lookup ..\..\..\External\Includes\Boost\asio\impl\write.ipp(51) : error C3861: 'e': identifier not found, even with argument-dependent lookup Thanks ahead, Christian

2 2

Need help with boost and dev-c++
by Craig Ritzdorf 17 Sep '06

17 Sep '06

I'm having a problem using any part of boost in dev-c++. The compiler itself seems to handle the code fine but when it trys to link i get the error: [Linker error] undefined reference to 'boost::filesystem::path::path(char const*)' I looked through the archive and found someone else (Chun Ping Wang) with this same problem but it was never answered. Thanks Craig

2 1

[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