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

Re: [Boost-users] [serialization] Deserialize by pointer withoutcalling new/constructor
by averigin 14 Oct '10

14 Oct '10

> It's not the most common scenario. It can be addressed, but requires > some more complete understanding of the library. The library "just works" > for the common cases. > > Think about why you have a base class pointer in your class which will > "never change". That is, if you recover it with out re-creating it, > you're > assuming that in the meantime the following statement has not been > executed. > > my_base_ptr = some_derived_ptr; > > That is, you're writing code on an assumption which you can't enforce. > If someday, in some other code module, far, far, away .. someone > executes the above, you'll have some unrecoverable mess to deal with > with no clear idea of what the source of the problem is. > > Sooo - my suggestion is to replace > > struct my_thing { > Base *m_ptr > ... > }; > > with > > struct my_thing > Base &m_b > ... > }; > > This will "just work" as far as serialization is concerned. > > Now if making the above change in your program is hard to do, you should > think about it a little bit more before you insert a booby trap into your > program. > Usually, this will entail some refactoring to get things back together > again. > But the result will be something more robust, less likely to contain bugs, > easier to test and aintain. Here's an attempt to further explain and (hopefully) clarify what's happening and why. 4 pieces of background to start, then I'll try to tie it all together. 1. In OMNeT, there are two main components to a simulation: Simple Modules, which have associated functionality (i.e., code), and Compound Modules, which are containers for simple modules and have no associated code. Note, for reference, the module types are termed cSimpleModule and cCompoundModule, both derived from cModule. All simple modules are derived from cSimpleModule and all compound modules are derived from cCompoundModule. 2. In a simulation it's possible to lookup another module (M_i) from the active module (M_a) and invoke methods on M_i. The lookup functions return a cModule pointer to M_i, which then must be dynamically cast to M_i's most-derived type to invoke its methods. However, that cast requires including M_i's header file in the code for M_a, which can result in ugly dependency trees. Thus, serializing by a looked-up cModule (base-class) pointer keeps things 'nice'. 3. When dynamically generating modules, they are created using a module factory which configures some internal state information which is not publicly accessible. Also, note that the factory method returns a cModule pointer. 4. When I run simulations, serialization and deserialization never occur during the same simulation; either the simulation starts fully configured and eventually serializes its state immediately before terminating, or it starts with a minimal skeleton and constructs the rest of the modules based upon a previously stored state. Now to put all the pieces together. When saving a simulation state, it's necessary to serialize a number of compound modules. So far, I've done this by adding a simple "archiver" module to them. I lookup the "archiver" module using the lookup functions and try to serialize the resulting cModule pointer. This causes the "archiver" module to save what information is publicly accessible (i.e., there is some internal state information it cannot access). When loading a saved state, the minimal skeleton includes one of the above mentioned "archiver" modules. It creates the input archive and then tries to create the other modules in the simulation. This is where I run into problems. What I wanted to do was have the "archiver" module create the other modules using their associated factories and then deserialize the rest of their state via the cModule pointers returned by the factories. This way the factory configures the module's private internal state information and the everything else is loaded from the archive, and this minimizes file dependencies (i.e., including header files for derived types). (I realize this isn't true (de)serialization, so I refer to it as partial-serialization.) However, this conflicts with the normal method for pointer deserialization, which would allocate memory for a new module, initialize it and then deserialize the information from the archive into that new object, which (in my case) is then promptly deleted or leaked. The only alternative I can see would be to dynamically cast the cModule pointers and directly call their serialize() or save()/load() methods directly. However, this seems like an ugly hack since that requires making the serialization methods public and including derived-class headers all over the place. Thus, I would like to stick with my partial-serialization method. I'm just not sure if it's possible to "easily" implement what I need for the loading portion. > > Of course if you're working in an environment whose controlling principle > is "just make it work right now", you're out of luck. You'll just have to > bury the bomb in your program and hope you're not in the immediate > vicinity when it blows up. > While I don't quite see it as a bomb, I know that probably just indicates short-sightedness on my part. Regardless, I am in the "just make it work right now" boat, so any help you can offer would be much appreciated. Regards, Adam Verigin P.S.: I did manage a temporary hack of archive/detail/iserializer.hpp pointer_iserializer::load_object_ptr() that (badly) assumed that if the passed pointer is not NULL, then it is a pointer to an allocated object so there's no need to create a new object. Coupled with a do-nothing load_construct_data() method this worked great for partial-deserialization, but causes memory corruption for normal deserialization since the assumption is not always true (nor is it a good assumption to try an force on other users).

1 1

[Smart Ptr] Why is weak_ptr a _ptr?
by Szymon Gatner 13 Oct '10

13 Oct '10

Hi, Is it just me or is it really the worse naming in whole boost library? It is nothing like any other smart pointer. No initialization / construction from raw pointer. No operator * or -> (the very least one would expect from _ptr class). No get(). And many more which I now forgot. My point is that is is not a pointer at all, not even a bit. It only happens to have a member variable returning one and that is hardly a reason to call type pointer-like. It should rather be called shared_tracker or shared_listener or something in that taste ;) Regards, Szymon

6 6

Proto domains shenanigans
by joel falcou 13 Oct '10

13 Oct '10

OK, I have a situation in which proto domain/subdomain could help me but i can't wrap my head around a proper solution. Here is the deal, i have various sub EDSL that goes like: - constants EDSL provides named consatnts (like zero_, one_, pi_ etc) that are meant to be terminal usable in any other EDSL en provide a type based way to know which constant is beging used and provide optimization in came it helps (e.g detecting x < zero_ in SIMD EDSL to replace with the SSSE3 corresponding fused operation) - a SIMD vector EDSL - various container based EDSL : table (multidim array), vector, matrix and tensor, polynom and rigid_transform. The rules I want to have is : - constant can mix with any other EDSL - SIMD don't mix with anybody - table mix with every other container and make them evaluates as table (e.g matrix * table == elementwise product and not matrix product) - vector, matrix, tensor can mix - polynom can mix with table but not with vector, matrix, tensor - rigid_transform van mix with table and matrix However i can't find any combination of domain definition that satisfy all. Is there some systematic methodologies to not fail at that ?

2 3

[asio] DNS query
by for-gmane 13 Oct '10

13 Oct '10

Hi, is it possible to do DNS queries with asio? (for example getting the MX record(s) of a domain)

4 3

[units] quantities with system abstraction "any<length>"
by alfC 13 Oct '10

13 Oct '10

Hi, In order to avoid reinventing the wheel I was wondering if there is any effort or there was any attempt to further abstract boost::units::quantities from its unit system but with a given dimension. That is, an object that can hold any boost::units::quantity<unit<Dimension, System> > with a given Dimension fir any System. For example (names are not ideal) any<length_dimension> a1 = 2.*si::meter; // RHS is type quantity<si::length> any<length_dimension> a2 = 2.*cgs::centimeter; //RHS is type quantity<cgs::length> any<length_dimension> b1 = 2.3 * si::second; // ERROR. or can hold any other quantity with length dimension (from any system). A sort of boost::variant<quantity<Dimension, system1> , quantity<Dimension, system2>, ... >, (but since the list is of type is not well defined maybe variant is not an options.) I know that there are some unresolved issues, for example, what is the result of a1 + a2, for which I have some solutions in mind. Anyway I just was wondering if this was tried before. And if not, what would be the best way to achieve it (boost::any? boost::variant?). (Note that all quantity<Unit> types has always the sizeof a double.) Alfredo

2 1

Boost serialization through base class
by Joe Drumm 13 Oct '10

13 Oct '10

Hi, I've tried using the most basic example I can find in the documentation to serialize a class using a pointer to a polymorphic base. However, it only serializes the base class. I'm currently on 1.34.1. Am I missing something obvious? Sample code below: class base { public: friend class boost::serialization::access; template<class Archive> void serialize(Archive& ar, const unsigned int) { } }; class derived : public base { public: derived() : foo(5) { } friend class boost::serialization::access; template<class Archive> void serialize(Archive& ar, const unsigned int) { boost::serialization::base_object<base>(*this); ar & BOOST_SERIALIZATION_NVP(foo); } int foo; }; BOOST_CLASS_EXPORT_GUID(base, "base") BOOST_CLASS_EXPORT_GUID(derived, "derived") TEST(OMSTestSuite, BasicDeserializeTest) { std::ofstream ofs("test.out"); boost::archive::xml_oarchive toa(ofs); base *b = new derived; toa & BOOST_SERIALIZATION_NVP(b); }

2 1

[String algo] Breaking change between 1.41 and 1.44 in split
by Christophe Henry 13 Oct '10

13 Oct '10

Hi, I noticed a breaking change in the split function when the input string is empty. Consider the following example: #include <string> #include <vector> #include <iostream> #include <boost/algorithm/string/split.hpp> #include <boost/algorithm/string/classification.hpp> int main() { std::vector<std::string> result; std::string empty_string; boost::algorithm::split( result, empty_string,boost::algorithm::is_any_of( "\t" ),boost::algorithm::token_compress_off); std::cout << "result size: " << result.size() << std::endl; return 0; } With boost 1.41 I get: result_size: 1 With 1.44 I get: result_size: 0 Meaning that splitting an empty string now has a new meaning. All I found to this subject was that 1 seems to be the correct answer (http://lists.boost.org/Archives/boost/2005/07/90266.php) Furthermore, there has been, according to the release notes, no change to string algo since the 1.41. This brings me to the question, before I start updating my code, is this change a design decision or an accident? Thanks, Christophe

1 0

[Accumulators] How to define the initial value ?
by Adrien Todeschini 13 Oct '10

13 Oct '10

Hi everyone, As the code of weighted_sum_impl constructor is [ in header <boost/accumulators/statistics/weighted_sum.hpp> ] template<typename Args> weighted_sum_impl(Args const &args) : weighted_sum_( args[parameter::keyword<Tag>::get() | Sample()] * numeric::one<Weight>::value ) { } and the template parameter Tag is defined as tag::sample namespace tag { struct weighted_sum : depends_on<> { typedef accumulators::impl::weighted_sum_impl<mpl::_1, mpl::_2, tag::sample> impl; }; } How can I define this tagged argument when initializing the accumulator_set ? ( Indeed, weighted_sum_impl constructor is called at this point ) Thanks in advance for your help. Adrien

2 6

[serialization] Deserialization of a float whose value is infinite throws an archive_exception ("stream error")
by Luca 12 Oct '10

12 Oct '10

Hello, using the Boost.Serialization library version 1.43, I saved to an XML archive a float number which has a value of infinite; then loading that XML file leads to a boost::archive::archive_exception, exception.what() return "stream error". The source code to reproduce the problem is the following: #include <boost/serialization/serialization.hpp> #include <sstream> #include <boost/archive/xml_woarchive.hpp> #include <boost/archive/xml_wiarchive.hpp> #include <iostream> struct XXX { friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP(mValue); } float mValue; };//struct int main() { std::wstringstream lSS; boost::archive::xml_woarchive oa(lSS); XXX xxx; float zero = 0.f; xxx.mValue = 1 / zero; oa << BOOST_SERIALIZATION_NVP(xxx); std::wcout<<"saved:"<<lSS.str() << std::endl; boost::archive::xml_wiarchive ia(lSS); ia >> BOOST_SERIALIZATION_NVP(xxx); std::wcout<<"loaded:"<<lSS.str() << std::endl; return 0; } Using gcc 4.4.4 on Linux/Debian the mValue member is saved as: <mValue>inf</mValue> while on Visual Studio 2005 on Windows XP sp2 the mValue member is saved as: <mValue>1.#INF</mValue> I see that the value of infinite has a different representation, (and this could be the main motivation behind the choice to not support them), but this lead to a situation in which a properly saved archive is not loadable by the library itself. As far I can see, the issue is at this line 209 of \libs\serialization\src\basic_xml_grammar.ipp parse_info<BOOST_DEDUCED_TYPENAME std::basic_string<CharType>::iterator> result = boost::spirit::parse(arg.begin(), arg.end(), rule_); return result.hit; where the parse function fails since result.hit is equal to false. I resolved the issue by checking all the data preventing accurately any infinite value before it is saved to an xml archive, but I wonder if this problem belongs to the library itself or not. Greetings, Luca

2 1

[asio]How to insure async handles not be called after calling deadline_timer::cancel()?
by 鑫炜廖 12 Oct '10

12 Oct '10

The document says, If the timer has already expired when cancel() is called, then the handlers for asynchronous wait operations will: have already been invoked; or have been queued for invocation in the near future. These handlers can no longer be cancelled, and therefore are passed an error code that indicates the successful completion of the wait operation. Does this mean that async handlers may be called after calling deadline_timer::cancel() (say, the second curcumstance) ? If yes, it seems make things unintuitive, eg. delete the resources that associate with handlers after cancel(). Is there any way to suppress or identify these handlers? thx.

3 2