- Boost - lists.boost.org

Re: [boost] [serialization] Can one deserialize a derived classes viapointers to the base class using polymorphic archives in aDLL context?
by Bogdan 13 Feb '10

13 Feb '10

Robert Ramey <ramey <at> rrsd.com> writes: > >> > >> Please note BOOST_CLASS_EXPORT_IMPLEMENT is used only once per class > >> (inside polymorphic_derived2.cpp), yet the serializers are inserted > >> in the same map both from the Dll and from the executable. > >> > >> Am I doing something wrong? Has anyone been able to create a similar > >> working example? I really appreciate any feedback I could get. > > It looks like polymorphic_derived2.cpp is being included in both the > mainline as well as the DLL. > > It's not clear that polymorphic_base needs to be n the DLL and probably > shouldn't be. > > Make sure that your header includes BOOST_CLASS_EXPORT_KEY and not > BOOST_CLASS_EXPORT. > > finally, make sure that the test for this facility works. > > Robert Ramey > Thank you Robert for your quick response: I appreciate a lot the generous work you put in the library. I double checked the project I previously uploaded: I downloaded it via gmane.org, changed the name back from bin to zip and verified the following: - polymorphic_derived2.cpp file is included only in dll_polymorphic_derived2.vcproj. - there are only three projects dll_polymorphic_derived2, Library and test_dll_exported plus an explicit reference to the bjam files (I removed the latter after downloading); - there is no usage BOOST_CLASS_EXPORT; - there are exactly three declarations of BOOST_CLASS_EXPORT_KEY: one in polymorphic_base.hpp, and two in polymorphic_derved2.hpp one for polymorphic_derived1 and another for polymorphic_derived2. Similarly, there are only three usages of BOOST_CLASS_EXPORT_IMPLEMENT. There was only one question mark: test_dll_exported.vcproj depended on dll_polymorphic_derived2 both via Project Dependencies option and explicitly as an input library: to be on the safe side, I removed the explicit dependency of test_dll_exported on dll_polymorphic_derived2 from the solution. I rebuild the solution from scratch. Unfortunately I got the same exception. So I am still cornered and looking for some help. Thank you again, Bogdan

1 0

[serialization] Can one deserialize a derived classes via pointers to the base class using polymorphic archives in a DLL context?
by Bogdan 13 Feb '10

13 Feb '10

Hi all, I am trying to upgrade to boost 1.42 using Visual Studio 2008 and I have difficulties using serialization with polymorphic archives in a DLL setup. I would like to encapsulate in one DLL the class serialization functionality based on a polymorphic base archive. In another place, I would like to perform the actual serialization/deserialization using a specific archive (e.g., polymorphic_text_[io]archive). The section "Special Considerations" of the documentation indicates in two paragraphs ("DLLS - Serialization and Runtime Linking" and " Plugins") that this scenario is supported by the library. However I couldn't find any example that shows how to do that. Therefore, I changed slightly the boost test that includes test_dll_exported.cpp and polymorphic_derived2.cpp as follows: 1. I moved the classes polymorphic_base and polymorphic_derived1 to the project polymorphic_derived2 This way, we have one place where those classes serialize their members (i.e., polymorphic_derived2.dll) and a separate binary where we serialize them via a derived archive (i.e., test_main() inside test_dll_exported.exe); 2. I replaced the template version of the serialization functions with the equivalent version based on boost::archive::polymorphic_[io]archives. I also removed the text-based instantiation inside the Dll. As indicated in the boost documentation, the class serialization will only have to be compiled once for all archive implementations (present or future). Therefore, the DLL should contain only the serialization functions to the base polymorphic archives. While everything builds correctly, at run time I get a C++ exception BEFORE main() in basic_serializer_map.cpp around the line 48: // if this fails, it's because it's been instantiated // in multiple modules - DLLS - a recipe for problems. // So trap this here if(!result.second){ boost::serialization::throw_exception( archive_exception( archive_exception::multiple_code_instantiation, bs->get_debug_info() ) ); } Please note BOOST_CLASS_EXPORT_IMPLEMENT is used only once per class (inside polymorphic_derived2.cpp), yet the serializers are inserted in the same map both from the Dll and from the executable. Am I doing something wrong? Has anyone been able to create a similar working example? I really appreciate any feedback I could get. Thank you, Bogdan PS For more info I attached the files describing my problem plus the .sln file (I used the configuration "Debug runtime-dynamic threading-multi")

2 1

Re: [boost] [contract] Contract Programming Library
by Andrzej Krzemienski 13 Feb '10

13 Feb '10

> I am thinking to submit a library for Contract Programming (a.k.a. > Design By Contract (TM) ) for C++. > I have drafted some of the library documentation in Boost-like format: > http://dbcpp.sourceforge.net/boost/libs/contract/doc/html/ > Comments? Hi, I would be very interested in trying such a library. I have one suggestion, which may be impossible to implement, but I think it would be worth at least looking at. The macros for defining assertions spoil function declarations. I know it is inevitable, etc., but.. read on. I know at least one library in Boost that also spoils function declarations in order to provide additional functionality: Concept Check library; they may be others too (MPL?). My suggestion is that if there are (or will be) libraries that require spoiling function declarations, they should all provide the same "spoiled" syntax. Otherwise I will be always asking "how do I declare a function in this library?". It would be very convenient if Boost provided one alternative function definition syntax that when used would enable all its libraries to work. Regards, &rzej

2 1

Interest in Remote Procedure Call Library?
by Daniel Larimer 13 Feb '10

13 Feb '10

I have been playing with some code and recently developed a very efficient, extensible, and easy to use API for performing remote procedure calls (with multiple protocols). I am writing to gauge interest and get feedback on the user API. The native "protocol" is a custom combined tcp/udp protocol using multi-cast for discovery, but it would be very easy to add a shared memory solution, a dbus, XML/RPC, CORBA, etc back end to the user api. Example: class SomeClass { public: int add( int a, int b ) { return a + b ); void sub( int a, int b, int* result ) { if(result) *result = a -b; }; void inout( int& a ) { a += 5; } }; META_INTERFACE( SomeClass, METHOD(add) METHOD(sub) METHOD(inout) ) // server SomeClass myclass; Server myserver( &myclass, "my.named.service" ); // client RemoteInterface<SomeClass> ri( "my.named.service" ); int result = ri.add(1,4); assert( result == 5 ) ri.sub( 5, 1, &result ); assert( result == 4 ); ri.inout(result); assert( result == 9 ); API can support any type that is serializable. It also supports the signal/slot paradigm. SomeClass could have any number of base-classes both virtual and non-virtual. With respect to performance, it can perform 15,000+ synchronous (invoke, wait for return) operations per-second on localhost/linux. Asynchronous operations are capable of 500,000+ invokes/sec. The library doubles as a built-in reflection system allowing run time inspection member functions, parameter types, inheritance, etc. I am working to convince my employer (small company of 25) that contributing this library would bring more benefits than "costs" to the company. The reasons I think it is a good idea include: 1) Expose the company to more people (marketing) 2) We can give our customers an "open" API for communicating with our products 2) Offload some of the development / maintenance / support to the open source community 3) I like open source and have personal reasons for wanting it free and open. So I need to get some more support to convince my employer that this will be a good move. Active interest would be a good sign. Other ideas on the positive aspects of contributing vs keeping it internal would also help me make my case. Thanks, Dan

7 33

WARNING: BoostBook build change..
by Rene Rivera 13 Feb '10

13 Feb '10

In response to the whole, using Boost logo outside of real Boost Libraries, I changed the BoostBook XSL slightly to: * Default to not including a navbar. * Default to not including the Boost logo in the navbar, when one expressly asks to include the navbar. I changed the Boost Jamroot to include the two options one needs to get back the standard Boost navbar+logo: <xsl:param>nav.layout=horizontal <xsl:param>boost.image=Boost The "boost.image" param is new and lets one specify: none (for no logo image), Boost (for the boost.png image), or anything else (for your own custom image. So.. WARNING: You may have to change your doc builds if you previously assumed that the navbar or logo would show up outside of Boost to include the above options (or some version thereof). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

bcp utility documentation
by Jeroen Habraken 13 Feb '10

13 Feb '10

Hi, I just noticed that http://www.boost.org/doc/libs/1_42_0/tools/bcp/bcp.html which is linked to from the main boost.org page under documentation leads to a 404. The page used to exist as http://www.boost.org/doc/libs/1_41_0/tools/bcp/bcp.html. Regards, Jeroen Habraken

2 2

[property_tree] Proposal for Boost.Property_Tree put function
by Andrew Hundt 12 Feb '10

12 Feb '10

I have been using the boost::property_tree in one of our products, and have become frustrated by an inconsistency between two of the convenience functions. The basic_ptree get function allows the specification of a separate delimiter when specifying the path, such as: pt.get<float>('/', "p.a.t.h/t.o/v.a.l.u.e"); However, there is no similar way to call put to place the same value as follows: pt.put('/', "p.a.t.h/t.o/v.a.l.u.e", 3.14f); I would like propose the addition of functions to allow consistency between the use of get and put functions. The basic use of these functions is described in http://www.boost.org/doc/libs/1_42_0/doc/html/boost_propertytree/accessing.… Are there any thoughts or comments? Regards, Andrew Hundt

1 0

[1.3.9][hpux]:pthread_create syambol does not exist in boost.1.3.9 library
by gopal haldar 12 Feb '10

12 Feb '10

Hi I built both boost.1.3.2 and boost 1.3.9 in the hpux 11.23 system. I can see the pthread_create symbol in boost 1.3.2 library but not in boost1.3.9 thread library. Due to this issue, my application crashing hpux 11.11 with boost 1.3.9 system and showing message "pthead_create symbol not found" in the boost thread library but working fine with 1.3.2. Please let me know the solution. Regards Gopal

2 1

[transact] code in sandbox
by strasser＠uni-bremen.de 11 Feb '10

11 Feb '10

Hi, I haven't had much time lately, and that's not going to change to next couple of weeks, so I've uploaded what I have so far to the sandbox: https://svn.boost.org/svn/boost/sandbox/transaction/boost/transact/ what's new: *** basic_transaction_manager: - now supports all kinds of combinations of commits, like we've discussed, including one-phase/transient two-phase, persistent two-phase. no logging/recovery yet. - lazy and non-lazy transaction construction, user-configurable *** simple_transaction_manager: a transaction manager supporting only one resource. basic_tranaction_manager includes a lot of MPL/fusion and the logging infrastrucure, none of which is needed for only one resource. this is intended to be the default transaction manager when one of our libraries is used on its own. *** logging infrastructure: to be used by basic_transaction_manager for its distributed transaction log, and optionally by resource managers that need logging (so it is part of the public interface!) - olog_files: maintaining log files without knowing its contents, manual log rolling - otransaction_log_files: same as olog_files, but automatic log rolling based on transactions - olog: writes to olog_files, aware of log entries - olog_buffer: same interface as olog, but buffers log entries locally and only accesses the log when the internal buffer overflows. - TODO: ilog_files/ilog to read/recover from logs. code is there, but not migrated to "transact". - TODO: interleaved_ologs/..., providing multiple olog interfaces so different resource managers can share a log, as we've discussed. *** new syntax for transaction scopes: syntax changed from: atomic{ ... }retry; to do atomic{ }commit(); I prefer that syntax because it resembles the do{}while(...) syntax. downside is that it conflicts with transaction::commit() if the user chooses to define BOOST_TRANSACT_COMMIT to "commit" (as is done above). *** TODO object_access not migrated to "transact" yet. utility functions for resource managers to serialize/clone/compare/... objects. regards, Stefan

2 4

Re: [boost] Iterator facade example could use some changes/documentation adjustments
by Jacob McIntosh 11 Feb '10

11 Feb '10

> From: Jeffrey Hellrung <jhellrung(a)ucla.edu> > To: boost(a)lists.boost.org > Subject: Re: [boost] Iterator facade example could use some > changes/documentation adjustments > > I think this is a valid concern, though I'm guessing this would cause > problems at most infrequently. I'm having difficulty coming up with a > use case where this would be a problem. Did you stumble upon this while > writing "real" code? It just came to mind while I was writing some of my own iterators. I wasn't even using iterator facade to do it, as I ended up using raw pointers for iterators in my use case, but I started looking at the documentation for is_convertible to figure out why they chose that conversion, and noticed the other behavior. And, though I personally haven't used that in real code, I could imagine a developer having the bright idea of converting a derived iterator into a base one thinking it will _only_ remove his need to explicitly cast the value provided by the derived iterator for whatever purpose. But, even disregarding that, on a more basic level... using is_convertible to allow conversion from non-const to const iterators is really doing more than just that. It's letting you do a host of other things as well... and though my example involved derived classes, The same would happen in cases like converting an integer iterator into a double iterator, as is_convertible returns true in that case as well. Any time the size of the types is different, it could cause problems. This is arguably a very stupid usage of iterators, but if we can enforce proper usage via compile time errors rather than runtime errors... why not? > > Would this motivate the existence of an is_iterator_convertible > metafunction, which is identical to is_convertible except for pointers? > > - Jeff > I'm not sure what there is to gain from this, would have to see what functionality is_iterator_convertible would provide. IMO, it doesn't make a whole lot of sense to convert an iterator<A> to iterator<B> unless A == const B. Converting a const iterator to non-const iterator wouldn't enforce the access of the const iterator, and doing so in a copy constructor removes the need to const_cast for clarity. And converting an iterator<derived> to iterator<base>... or iterator<int> to iterator<double> doesn't seem to make much sense, to me. - Jacob

1 0