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

trouble getting older version of boost to build
by David Toth (dtoth) 03 Jun '14

03 Jun '14

Hi. I am trying to build boost 1.41 (I need some of the libraries from it to compile some 3rd party software) and I am having issues. On CentOS 6.5 with the "Software Developer Workstation" installation (which comes with gcc 4.4.7 and g++ 4.4.7), I can build boost simply by running bootstrap.sh followed by running bjam. That creates all the libraries and then I can compile the other software that requires those libraries. Unfortunately, I can't use CentOS on the systems I am using. I reverted to trying it on CentOS just to see if I could get it to work on one version of Linux, thinking that it would be easy to then get it to work on another version. On Ubuntu, Fedora, and Debian (these are the versions of Linux I can use on the systems), I am unable to build the full set of libraries. After running bootstrap.sh and bjam, I am missing these files that were created on CentOS: libboost_thread.a‎ libboost_thread.so‎ libboost_thread.so.1.41.0‎ Without those files, the 3rd party software won't compile. Ubuntu, Fedora, and Debian come with more updated compilers and I read some place online that gcc 4.8 and g++ 4.8 have some issues with the old versions of boost, so I tried installing gcc 4.4.7 and g++ 4.4.7 and changing the symbolic links for gcc and g++ in /usr/bin/ to point to gcc 4.4.7 and g++ 4.4.7. Unfortunately, I am still unable to get the thread library to get created. I know boost 1.41 is old and I *might* be able to get away with using a version as recent as 1.49, but I have the same problems building that (and every version in between 1.41 and 1.49). Any help would be greatly appreciated. Thanks in advance. Dave

3 4

Convert library review manager result
by Edward Diener 01 Jun '14

01 Jun '14

This is my analysis of the 'convert' library review and the result of whether the convert library should be accepted into Boost. Please read the entire analysis to understand my reasoning before reading the result. I would like to thank all of those who took part in the review and made comments. This includes Julian Gonggrip, Rob Stewart, Andrzej Krzemienski, Matus Chochlik, Jeroen Habraken, Erik Nelson, Hartmut Kaiser, Joel De Guzman, Thijs (M.A.) van den Berg, Roland Bock, Gavin Lambert, feverzsj, Paul Bristow, and alex. If I have missed anybody I do apologize. All comments were taken into account and all comments were intelligent and to the point. Naturally I would also like to than Vladimir Batov for patiently answering all comments and explaining and defending his library and his design decisions. For the most part I am going to focus on general issues rather than on the individuals who made them. Documentation issues: The documentation was too focused on explaining the library as it differed from lexical_cast. Vladimir Batov explained why this is so but I also agree that the documentation can be better by simply focusing on what the library provides in terms of functionality. Comments also mentioned that the current converters are not documented as well as the could be, and some commenters reflected that knowledge of how a particular converter works, including possible failures using that converter, is also needed despite the common library interface. The documentation did not provide enough information about the use of locales in the library. The reference section was very limited with not enough explanation. A reference built from doxygen comments in the source files would be better. A better explanation or example in the documentation for writing one's own converter was suggested. Although the Performance section in the documentation was fairly lengthy some commenters wanted to know why some things could not be tested. Others wanted more information about how convert performance compared to other convert-like implementations. In general I think most reviewers found the documentation adequate for understanding how to use the library but lacking in completeness. Vladimir Batov reflected that if the library were accepted into Boost he would then create more complete documentation and the above issues could be addressed. Implementation issues: As in most reviews most commenters did not look very deeply into the actual code but were happy to know how to use the library, and this is understandable for a review. There were a few pertinent comments however and I am just going to enumerate them. All macros should be prefix with BOOST_. My own addition to that is that all macros should be prefixed with BOOST_CONVERT_ to avoid any conflicts with other libraries. There should be a jamfile for running the tests. Also some full-blown examples of using the library in a simple program, along with the appropriate jamfile, would be helpful. Source code should contain spaces, not tabs. This is an easily fixed minor issue. As mentioned before doxygen comments in the public source are the usual Boost way of doing things. The main header file should be convert.hpp instead of api.h. Some includes were missing from the printf converter. Design issues: In the design of the library is where we have the most varying views. The major issue in discussing the design of the library for those who felt it was inadequate were the comments that using the library was too complicated, that the central function for invoking a conversion should be simpler to use. While all suggestions were well-argued I felt that a number of these differences were merely syntactical issues rather than issues that made the functionality easier to use. The main interface for using the library is: convert<output_type>::from(input_value, converter) Vladimir Batov had asserted during the review that this could be simplified further by removing the need for the 'from::' part of the signature which would make the syntax simpler. Some reviewers did not like the name 'convert' and offered substitutions, others wanted the default value, currently specified as '.value_or(default)', to be specified as a direct input parameter, others wanted the converter itself which is an input parameter to be specified via another syntax. All of these are too me syntactical issues and no resolution could possibly please everybody but it is understandable that different reviewers have different syntactical preferences. More to the point were some changes in actual functionality. The three most important involved the return value, type requirements for the output type, and the use of a default converter. Considering each in its turn: 1) The return value is some form of 'optional', with the idea of using boost::optional if it meets all the requirements needed by the 'convert' library. A number of people wanted the actual value returned without having to append .value() to the convert signature to get it. They were also concerned with the performance overhead of having to create an optional value as the immediate return value. It was also suggested that while the current convert syntax might be fine, some alternatives directly returning the value, for those who like maximum simplicity, might be possible. 2) The type requirements for the output type are default constructible and copy constructible. A number of reviewers felt that if a non-const reference were passed to the convert function as an output instance then the type requirements would not have to be met. However the type requirements of some of the underlying converters might be affected by this and the documentation does explain how to work around the default constructible requirement, but I still do understand the reasoning behind this possibility. 3) A number of reviewers wanted a default converter to be used but there was hardly an agreement on what this default converter should be, some favoring lexical_cast, others favoring stringstream, and no doubt others might want something else. Nevertheless providing a default constructor interface, possible with a macro defined a compile time, seems like it might be doable. There was further discussion about the actual callable signature for a plug-in converter. Here there was less contention about the interface, which is currently a callable with a signature of: template<typename TypeOut, typename TypeIn> bool operator()(TypeIn const& value_in, TypeOut& result_out) const; Vladimir Batov did suggest some possible alternatives and there was a discussion with a number of reviewers about alternatives that seem implementable. This also ties into the concern of some reviewers that it should be straightforward to create one's own converters with minimum restrictions on the input and output types, as well as minimum performance overhead. Votes: A number of reviewers made comments but offered no final vote on whether or not the conversion library should be accepted into Boost. Some reviewers offered a Yes vote, but heavily based on changes they want to see. I will attempt to tabulate them here: YES votes: Christopher Kormanyos Paul Bristow Julian Gonggrip ( with some reservations which Vladimir Batove has met or may easily meet ) Andrzej Krzemienski Matus Chochlik YES, conditionally but otherwise NO if conditions are not met, which the current version does not meet] Jeroen Habraken Roland Bock alex NO Rob Stewart Final Decision: Among those who voted YES conditionally but otherwise NO there was a general consensus including Vladimir Batov, the 'convert' library creator, and some of the others that an attempt could be made to satisfy some of the conditions for simplification and/or functionality they desired. My decision, based on the votes as I interpret them, is that the convert library is ACCEPTED into Boost. While a perfect design is impossible I believe that the design of the library is an adequate starting point for a general-purpose conversion framework and that the design could change incrementally enough to satisfy some of the qualms of those who might not find it as initially useful as they have hoped, while still maintaining the central framework which Vladimir Batov has created. Furthermore I believe that others have reflected that a general-purpose conversion library would be very useful if it were flexible enough to support plug-in converters created by programmers, as the 'convert' library does. I realize that what is essentially a 5 to 4 vote in favor of the library is not an overwhelming consensus by any means but I feel that 3 of those 4 NO votes are predicated on wishes for possible changes to the 'convert' library which may yet be met before the library gets officially added to an upcoming Boost release. Since I have accepted the library based on the votes and my interpretation of the issues I would like to encourage those who feel that some alternate designs could be implemented as part of the 'convert' library to work with Vladimir Batov, if he is agreeable, to add those alternatives to the library. Nonetheless it is his library and he would be the final arbiter of any decisions reached. I would like to encourage the view, however, that the current design is what has been voted in by others as the 'convert' library so that any changes made to it as it is added to Boost should be incremental additions which minimally change what others see as an acceptable library.

1 0

Re: [Boost-users] [serialization] deserialized instance empty even though proper serialize methods called
by Hickman, Steve (AdvTech) 31 May '14

31 May '14

From: Robert Ramey [mailto:robertmacleranramey@gmail.com] Sent: Friday, May 30, 2014 3:43 PM To: boostusers(a)googlegroups.com Cc: robertmacleranramey(a)gmail.com; boost-users(a)lists.boost.org; boost-users(a)lists.boost.org; Hickman, Steve (AdvTech) Subject: Re: [Boost-users] [serialization] deserialized instance empty even though proper serialize methods called On Friday, May 30, 2014 2:37:00 PM UTC-7, Hickman, Steve (AdvTech) wrote: I corrected the problem with the DLL import. That had no discernible effect. lol - you didn't tell me there was a problem with DLL import. The issue here was link warnings due to the fact that I was importing back into the DLL exported interfaces. I fixed this by changing how my DLL import macros in my header files expand for the library being built. When used in the library, they expand to nothing, otherwise they expand to “__declspec(dllimport)”. The actual function definitions in the .cpp files always expand to “__declspec(dllexport)” when the library is built as a DLL. It does not throw an unregistered_cast() exception (which it seems like it should). Consider filing a trac item for this. Done this strongly suggests a problem with EXPORT ing the derived class. Note that that each DLL contains it's own casting table. Of hand I don't remember which EXPORT s get added to which table. Certainly the EXPORT IMPLEMENT should be the *cpp file which is part of the DLL. It is One way to test this would be to verify that the static library build/test works. This always has only one table so such problem wouldn't come up. Building/linking my library statically does solve the problem. And it works for the application I need to use it for, so I’m going with that approach for now. . But it still leaves open the question of why we're getting to this point. There are two approaches to a problem like this: a) Just "make it work" by adding stuff until it seems to work. This is the approach favored by management. Given my current time constraints, using a static library works and will be my approach until I see it break. b) Get to the bottom of it and fix it once it once an for all - and add notes/comments and/or tests to make sure the bugger stays dead. This is the approach favored by (unemployed) programmers. And since I’m trying to avoid unemployment, I’ll have to delay this for now. The former seems to work - but the problem keeps sucking up time in the future. The latter is tedious and frustrating - but this keeps one from getting stuck in a dead end job constantly fixing the same problems. Robert Ramey --- Steve H.

1 0

[boost.msm] BOOST_MSM_EUML_DECLARE_STATE_MACHINE with state base class
by Stefan Näwe 31 May '14

31 May '14

Hi there, I use MSM from boost 1.49 with VC9 on Windows XP. I want to use the eUML front end. My states shall use a polymorphic base class and are defined like this: // State base class struct Worker { virtual void work() = 0; }; // a state struct Running_ : msmf::state<Worker>, euml_state<Running_> { void work() { ... } } const Running; My transition table is defined with BOOST_MSM_EUML_TRANSITION_TABLE() My state machine is defined like this: BOOST_MSM_EUML_DECLARE_STATE_MACHINE(( trans_table, init_ << AnyState, no_action, // fsm_entry no_action, // fsm_exit attributes_ << one_attr << another_attr, configure_ << no_configure_, Log_No_Transition, Log_Exception), MyFSM_fe) struct FSM : msmb::state_machine<MyFSM_fe> {}; All OK until here. But now I want to add the state base class to the above invocation of BOOST_MSM_EUML_DECLARE_STATE_MACHINE to be able to say : fsm.get_state_by_id(fsm.current_state()[0])->work() at any given time. BOOST_MSM_EUML_DECLARE_STATE_MACHINE(( trans_table, init_ << Running, no_action, // fsm_entry no_action, // fsm_exit attributes_ << one_attr << another_attr, configure_ << no_configure_, Log_No_Transition, Log_Exception, Worker), MyFSM_fe) But this gives me a compile error: C2275: 'Worker' : illegal use of this type as an expression. Is there any way to achieve what I need ? Can I somehow _NOT_ use the macro and create the same state machine (i.e. with attributes!) ? Thanks for any help! Stefan -- ---------------------------------------------------------------- /dev/random says: A Bugless Program is an Abstract Theoretical Concept. python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')" GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF

2 4

Directed graph, incoming edges
by Jeremy Murphy 31 May '14

31 May '14

Just wondering what people generally do when they want to model a directed graph but they also want efficient access to the incoming edges of a vertex? Make a bidirectional graph and store directionality as a property of an edge? Thanks, cheers. Jeremy

2 2

Re: [Boost-users] [serialization] deserialized instance empty even though proper serialize methods called
by Hickman, Steve (AdvTech) 30 May '14

30 May '14

I corrected the problem with the DLL import. That had no discernible effect. FWIW, I also note at this point that I have set all serializable classes to BOOST_CLASS_IMPLEMENTATION(fully_qualified_classname,boost::serialization::object_serializable); because I don’t save any of the archives. Since I’m only using this for immediate “over the wire” communication, I don’t need backwards compatibility. On the tracking bug: It would also be interesting to run your own test with the default tracking behavior to see if the symptom disappears. I set up to run with default tracking behavior. This had no discernible effect on stopping pointer_tweak (line 527 in iserializer.hpp) from nullifying the pointer to the deserialized instance. I didn’t look to see if it had an impact on the tracking flag (not certain how I would know since now tracking *should* be on) In the .cpp files of all serialized classes. This shouldn’t matter because I never read references to prior instances As far as we know. I never reference prior instances because, at least for the tests I’m running, the data structures don’t contain pointers. They do contain members that are also defined in the library. These members are never, at least in the tests I’m running, handled via pointers. In addition, I using this facility to serialize data that I send “over the wire” one data structure at a time. In each case I open a new archive to serialize one data structure instance, then extract the buffer created and close the archive. Similarly, on the receiving side, I open an archive for each structure I deserialize, do the deserialization, then close the archive (in both cases the archive stack variables go out of scope). It may be that on the receive side that there is some static data in the serialization library that thinks it needs to turn serialization on – I don’t know. I haven’t dug into that. Using/not using tracking is subservient to actually getting the deserialized data, so I’ll leave it with the default behavior for now. There remains the core problem that the call to pointer_tweak on line 527 of iserailzer.hpp causes the t pointer (the one containing the deserialized data) to be nullified. Digging into pointer_tweak, it appears that the problem lies in void_upcast(lines 314-334) in void_cast.cpp. While it receives the appropriate type information for both the base and derived class, it cannot find any info in the void_caster_register (which has size zero) to tell it how to convert one to the other, so it returns null. (line 333). It does not throw an unregistered_cast() exception (which it seems like it should). Could the problem lie in that because this is a DLL, its singletons (like void_caster_registry) are singletons across all EXEs that use that DLL ? Microsoft doc seems to indicate that isn’t the case (see http://msdn.microsoft.com/en-us/library/h90dkhs0(v=vs.90).aspx ) by default at least. If there is a problem here, I could envision the following scenario: In my case, both the serializing and deserializing EXEs are running in parallel, so they could be affecting any static data in the DLL. In particular, they both could be updating and clearing the void_caster_registry. If void_caster::recursive_unregister() has been called by the serializing EXE, it may not contain anything that is now needed by the deserializing EXE. Does that make sense? Is that possible? Regardless of what is causing the problem, should this be solvable by adding the explicit // method 2 : explicitly register base/derived relationship boost::serialization::void_cast_register<derived, base>( static_cast<derived *>=NULL), static_cast<base *>(NULL) to all my serialize methods? It doesn’t fix it for me(I added the appropriate calls as the first statement after a logging statement in all the serialize methods). Furthermore, the void_cast_registry still has size 0. --- Steve H.

1 0

date_time: nth friday of month
by MM 30 May '14

30 May '14

Hello, Is there an object that encodes "second friday of month", rather than "second friday of april"? Then you would pass to it month + year to get a date? If not, how would I implement such a type? Extend nth_day_of_the_week_in_month? Thanks,

2 3

how to correctly compile and use math module (for gmp) (b1.55 win32)
by eaj68 30 May '14

30 May '14

When compiling only regex module all works ok, but when I substitute 'math' for regex in command i get this: b2 -a --debug-configuration --prefix=C:\boost --address-model=32 --with math --layout=tagged toolset=gcc variant=release link=static threading=single runtime-link=static optimization=off notice: found boost-build.jam at C:/boost/boost-build.jam notice: loading Boost.Build from C:/boost/tools/build/v2 notice: Searching 'C:\WINDOWS' 'C:\Documents and Settings\Administrator' 'C:\Documents and Settings\Administrator' 'C:\boost\tools/build/v2' 'C:/boost/tools/build/v2/kernel' 'C:/boost/tools/build/v2/util' 'C:/boost/tools/build/v2/build' 'C:/boost/tools/build/v2/tools' 'C:/boost/tools/build/v2/contrib' 'C:/boost/tools/build/v2/.' for site-config configuration file 'site-config.jam'. notice: Loading site-config configuration file 'site-config.jam' from 'C:/boost/tools/build/v2'. notice: Searching 'C:\Documents and Settings\Administrator' 'C:\Documents and Settings\Administrator' 'C:\boost\tools/build/v2' 'C:/boost/tools/build/v2/kernel' 'C:/boost/tools/build/v2/util' 'C:/boost/tools/build/v2/build' 'C:/boost/tools/build/v2/tools' 'C:/boost/tools/build/v2/contrib' 'C:/boost/tools/build/v2/.' for user-config configuration file 'user-config.jam'. notice: Loading user-config configuration file 'user-config.jam' from 'C:/boost/tools/build/v2'. notice: Searching '.' for project-config configuration file 'project-config.jam'. notice: Loading project-config configuration file 'project-config.jam' from '.'. warning: toolset msvc initialization: can not find tool cl.exe warning: initialized from project-config.jam:3 notice: will use 'cl.exe' for msvc, condition <toolset>msvc notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>/<address-model>', setup: '' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>/<address-model>32', setup: '' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>x86/<address-model>', setup: '' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>x86/<address-model>32', setup: '' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>/<address-model>64', setup: '' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>x86/<address-model>64', setup: '' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>ia64/<address-model>', setup: '' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>ia64/<address-model>64', setup: '' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>arm/<address-model>32', setup: '' notice: [cmdline-cfg] toolset gcc not previously configured; attempting to auto-configure now notice: will use 'g++' for gcc, condition <toolset>gcc-4.10.0-mingw notice: using gcc libraries :: <toolset>gcc-4.10.0-mingw :: C:\gcc/bin C:\gcc/lib C:\gcc/lib32 C:\gcc/lib64 warning: toolset gcc initialization: can not find tool C:/gcc/i686-pc-mingw32/bin/ar.exe warning: initialized from notice: using gcc archiver :: <toolset>gcc-4.10.0-mingw :: C:/gcc/i686-pc-mingw32/bin/ar.exe warning: toolset gcc initialization: can not find tool C:/gcc/i686-pc-mingw32/bin/ranlib.exe warning: initialized from notice: using gcc ranlib :: <toolset>gcc-4.10.0-mingw :: C:/gcc/i686-pc-mingw32/bin/ranlib.exe notice: using rc compiler :: <toolset>gcc-4.10.0-mingw :: C:\gcc\bin\windres.exe link.jam: No such file or directory notice: [zlib] Using pre-installed library notice: [zlib] Condition notice: iostreams: not using bzip2 compression notice: iostreams: not using bzip2 compression notice: [python-cfg] Configuring python... notice: [python-cfg] Registry indicates Python 2.6 installed at "C:\Python26\" notice: [python-cfg] Checking interpreter command "python"... notice: [python-cfg] running command 'python -c "from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))" 2>&1' notice: [python-cfg] ...does not invoke a working interpreter notice: [python-cfg] Checking interpreter command "C:\Python26\python"... notice: [python-cfg] running command 'C:\Python26\python -c "from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))" 2>&1' notice: [python-cfg] ...does not invoke a working interpreter notice: [python-cfg] No working Python interpreter found. notice: [python-cfg] falling back to "python" notice: [python-cfg] Details of this Python configuration: notice: [python-cfg] interpreter commanC: "python" notice: [python-cfg] include path: "Include" notice: [python-cfg] library path: "\libs" notice: [python-cfg] DLL search path: "<empty>" error: Unable to find file or target named error: 'libs/math/build//boost_math' error: referred to from project at error: '.' compiling all the modules without `--where` switch seems to work ok and produce these modules: libboost_atomic-mt-s.a libboost_chrono-mt-s.a libboost_chrono-s.a libboost_coroutine-s.a libboost_date_time-s.a libboost_exception-s.a libboost_filesystem-s.a libboost_graph-s.a libboost_iostreams-s.a libboost_locale-mt-s.a libboost_log_setup-s.a libboost_log-s.a libboost_math_c99f-s.a libboost_math_c99l-s.a libboost_math_c99-s.a libboost_math_tr1f-s.a libboost_math_tr1l-s.a libboost_math_tr1-s.a libboost_prg_exec_monitor-s.a libboost_program_options-s.a libboost_random-s.a libboost_regex-s.a libboost_serialization-s.a libboost_signals-s.a libboost_system-mt-s.a libboost_system-s.a libboost_test_exec_monitor-s.a libboost_thread-mt-s.a libboost_timer-s.a libboost_unit_test_framework-s.a libboost_wave-s.a libboost_wserialization-s.a but when I try to make an appication that uses gmp: (from : http://www.boost.org/doc/libs/1_53_0/libs/multiprecision/doc/html/boost_mul… ) that is only the include part to see it works: #include <iostream> #include <boost/multiprecision/gmp.hpp> int main() { return 0; } I get: In file included from C:\boost_gmp_test.cpp:2:0: c:\boost/boost/multiprecision/gmp.hpp:19:17: fatal error: gmp.h: No such file or directory #include <gmp.h> ^ compilation terminated. But I am sure that I have correctly installed boost ang GCC because regex module compiles and works without any issue. -- View this message in context: http://boost.2283326.n4.nabble.com/how-to-correctly-compile-and-use-math-mo… Sent from the Boost - Users mailing list archive at Nabble.com.

5 5

Re: [Boost-users] [serialization] deserialized instance empty even though proper serialize methods called [Honeywell Internal]
by Hickman, Steve (AdvTech) 30 May '14

30 May '14

Classification: Honeywell Internal I should have been more explicit in my original post. All serialization/deserialization is being done with base class pointers. I have a set of tests where I discovered the problems of serializing/deserializing with different pointer types that you identify below - so I've avoided that. What you suggest for the test program is essentially what I've done in my tests. One thing I did find in review is that somehow the serialize methods were marked protected rather than private. Fixing that partially corrected the problem. Now the deserialization "sticks" for all of the base class objects deserialized through the base class pointer (the data is in the fields after exiting the serialize process). For derived class objects deserialized through a base class pointer, I'm using xml_archive and stepping through the code. Here's what I see: First, one thing I notice: It appears that the system thinks tracking is on (line 476 of basic_iarchive.cpp: tracking is true) even though I've consistently said BOOST_CLASS_TRACKING(fully_qualified_classname,boost::serialization::track_never); In the .cpp files of all serialized classes. This shouldn't matter because I never read references to prior instances, but it may indicate a problem. The correct constructors are called in load_construct_data and the correct serialize methods are called. Further, at the end of the derived class serializer, all the fields contain the correct data - so it is loading correctly from the archive. The deserialize works up through the return from line 516 of iserializer.hpp (call to ar.load_pointer()) (at the topmost level - I have no embedded pointers in the objects I'm using to test with). T continues to have the values loaded. The call on line 527 of iserializer.hpp to pointer_tweak() appears to be causing the problem. It returns a null pointer. This means that the second portion of the nvp at the top level is now a null pointer, and I've lost what was loaded. I should also note at this point that all of the relevant classes have virtual destructors. This is the only virtual method they have. Note that all of the methods on these classes are declared with the appropriate DLL import/export (since this is built as a DLL). I should also note that I was wrong from my final reply on my previous post that the warnings on locally defined symbol 'symbol' imported in function 'function' had disappeared. They only disappeared because I was inadvertently doing incremental links. My initial attempts to resolve this issue have not apparently been successful. While the Microsoft documentation indicates that the code will still work (but just run slower) in the presence of these warnings, is it possible that the downcast in pointer_tweak() is failing because of this? I am endeavoring to correct this, but I'm a bit surprised at how the Microsoft compiler appears to be unable to chain macro definitions. --- Steve H. From: Robert Ramey [mailto:robertmacleranramey@gmail.com] Sent: Thursday, May 29, 2014 2:03 PM To: boostusers(a)googlegroups.com Cc: robertmacleranramey(a)gmail.com; boost-users(a)lists.boost.org; boost-users(a)lists.boost.org; Hickman, Steve (AdvTech) Subject: Re: [Boost-users] [serialization] deserialized instance empty even though proper serialize methods called [Honeywell Internal] OK - this should work. But in a few rare cases it won't. Usually this due to a very unusual corner case. That case is were something isn's de-serialized exactly as it was serialized. a) serializing through a derived pointer de-serialization through a base class pointer fix - even though one knows the derived class when serializing, serialize through a pointer to the base class - effectively using an implicit cast b) some other bizarre cases I don't remember. make a pair of test program which tests your serialization. a) use xml_archives b) program A should invoke both e main(){ ... X xp1 = new X; oar << xp1; ... X xp2; iar >> xp2; assert(*xp1 == *xp2); } c) split b above into two programs Robert Ramey ============================================================================================================================================================================================================ This message classified as Honeywell Internal by Hickman, Steve (AdvTech) on Friday, May 30, 2014 at 7:33:06 AM. The above classification labels are in accordance with the Honeywell Corporate Classification Policy. The information contained in this electronic message is confidential and intended only for the use of the individual/entity named above, and the information may be privileged. If you, the reader of this message, are not the intended recipient or an employee or agent responsible to deliver this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and delete the original message. ============================================================================================================================================================================================================

1 0

Fix for annoying bug / library maintenance
by Filip Konvička 30 May '14

30 May '14

Hi, https://svn.boost.org/trac/boost/ticket/4964 This is out there for years. To me this seems to be clearly explained and a fix is provided, but apparently all bugs assigned to 'bgubenko' aren't monitored (for years there has been no reaction). So is there a way of getting the fix ever applied? Or are such unmaintained libraries just doomed to eventually die, despite the efforts of the people reporting bugs and posting patches? Thanks, Filip

4 5