- Boost - lists.boost.org

Serializing using RTTI
by tcmichals 12 Apr '05

12 Apr '05

I'm creating a simple file that is serializing several classes to a file. The problem is the order and the number of the of the objects saved in the file, depending on the options the user selects, 1 or 3 classes can be stored, I'm confused on how to call deserializer process for this case? Maybe use the rtti type and then call the correct deserializer? For example: class baseObj { // Code // serialize code }; class optionObj : public baseObj { //Code // Serial // BOOST_SERIALIZATION_BASE_OBJECT_NVP(baseObj); // etc }; class configObj : public baseObj { //Code // Serial // BOOST_SERIALIZATION_BASE_OBJECT_NVP(baseObj); // etc }; saveData( std::string fileInfo) { // code if (userSaveConfig ) os << saveConfig; if (optionSave) os < saveOptions; } getData(std::string fileInfo) { // clueless.. 1. how to determine the order the class has been saved? }

3 3

[Filesystem] Feature Request: One more implementation using .NET
by Pavel Chikulaev 12 Apr '05

12 Apr '05

Dear all, IMO in C++ .NET it's not good idea to use "windows.h"'s plain C functions because someday Microsoft will call them all deprecated or current implementation will not allow make client's code purely managed. .NET implementation of boost::filesystem will make usage of library more safe. Plus, .NET implementaion will possibly work on other platforms than Windows where such classes are available. Actually I don't know any, but I believe Microsoft or somebody else will find a way to do it. So, may be add one more implementation? Sooner or later it should be done. Any thoughts? -- Pavel Chikulaev

6 16

Archive * This() and the most derived class.
by George M. Garner Jr. 12 Apr '05

12 Apr '05

Robert, A comment in interface_oarchive.hpp states that interface_oarchive<Archive>::This() is supposed to return the a pointer to the most derived class. Actually, it gives you a pointer to the "Archive" template parameter which may or may not be the most derived class, depending on how your internal "invoke" plumbing resolves the type. In the following case I was able to get the most derived class only by overriding both operator<<(const T & t) and save_override()(using VC2k3): class fau_xml_woarchive : public boost::archive::xml_woarchive { public: [...] template<class T> void save_override(const ::boost::serialization::nvp<T> & t, int i) { save_start(t.name()); boost::archive::save(*this, t.value()); save_end(t.name()); } template<class T> _Mytype& operator<<(const T & t) { save_override(t, 0); return *this; } [...] }; Was that your intention? Regards, George.

1 1

[mpl] annoying warning for mpl::long_<LONG_MAX>
by Yariv Tal 12 Apr '05

12 Apr '05

On Visual Studio.NET / VC7.1 the following code: #include <boost/mpl/long.hpp> #include <climits> boost::mpl::long_<LONG_MAX> lll; Gives the following warning: ...\boost_1_32_0\boost\mpl\aux_\integral_wrapper.hpp(72) : warning C4307: '+' : integral constant overflow ...\main.cpp(39) : see reference to class template instantiation 'boost::mpl::long_<N>' being compiled with [ N=2147483647 ] . . . (warning goes on and on...) Is this a known issue? When would this lead to errornous program behaviour? (maybe never?) Are there plans to fix it? (i.e. by specializng long<LONG_MAX> to not use the '+') Yariv Tal.

2 1

Problem with xml_woarchive_impl<Archive>::save(const wchar_t * ws)
by George M. Garner Jr. 12 Apr '05

12 Apr '05

Robert, The implementation of xml_woarchive_impl<Archive>::save(const wchar_t * ws) may be found beginning on line 122 of xml_woarchive_impl.ipp. The code serializes the given wide character string twice into the stream, the first time without and the second time with escaping. Compare this with the implementation of save(const std::wstring & ws) a few lines above which correctly serializes the wide character string only once with escaping. Regards, George.

1 0

[ptr_container] post review comments
by Pavel Chikulaev 12 Apr '05

12 Apr '05

Thorsten, 1. Since we can iterate over elements in container using pair of begin end or pair of ptr_begin ptr_end it's not enough to provide member-functions which take only iterators as arguments, we also need overloads which take ptr_iterators. Motivation example: ptr_vector<int> v; //... ptr_vector<int>::iterator i = std::find(v.begin(), v.end(), 5); if (i != v.end()) v.erase(i); //works just fine, but int k = 5; int * pk = &k; ptr_vector<int>::ptr_iterator i = std::find(v.ptr_begin(), v.ptr_end(), pk); if (i != v.ptr_end()) //here we can just write simple erase, we need to write something like that: v.erase(v.begin() + std::distance(v.ptr_begin(), i)); //and it's really no good. I'd like to list all the functions that need to have a twin, but I'd better say shorter - at least every public function that have one or more parameters with type iterator. Differently, ptr_iterators seem to be sick, petty and harmed. We just can't use them anywhere. Another, more simple approach is to provide function that returns iterator of the corresponding ptr_iterator. The funny thing is that we already can get ptr_iterator from iterator, but it's not so needed as the backward transformation. But I do think this is not a good solution, because with this approach we can achive the required functionality, but the syntax will be very very bad. One more approach is to simply get rid of ptr_iterators, but provide user with adapters he will ever need. I like it, but sometimes (or more oftener) I (and you) still simply need ptr_iterators. IMO the best solution is the hardest solution - approach number 1. 2. The next drill is on templated functions and constructors. If we will decide to keep ptr_iterators, consider the following code: ptr_vector<int> v; ptr_vector<int> v2(v.ptr_begin(), v.ptr_end()); IMO user (that was I) expects this compiling. But it's not. Why can't I construct ptr_vector from ptr_iterators? It's good iterators, just any else, but I can, because they need special care to handle them. IMO it's nonsense not to enable such support. The same applies to templated insert, assign, and other functions. So, all of them need an overload for templated ptr_iterators. I think the library should either supply the user of ptr_iterators all he will every need or get rid of them completely. No some more remarks, but they are not so important as the above. 4. IMO header <boost/ptr_container/clone_allocator.hpp> deserves to be higher in folder hierarchy since its' contents can be widely used by other libraries/people. 5. IMO header <boost/ptr_container/exception.hpp> contents doesn't follow good naming scheme. What do other people think when they see boost::bad_index & ? Some class, maybe exception, since it has prefix bad, but how knows that this class comes with ptr_container library? No-one. BTW why don't you use std::out_of_range? At least please change its' name. The same for boost::bad_pointer in the same header file. 6. What a funny name!! boost::ptr_container_ptr_container_detail in <boost/ptr_container/nullable.hpp> Maybe this header also deserves more fame(I mean nullable<T>)? 7. Why don't you throw std::out_of_range exception like std containers when ptr_sequence_adapter::at is out of bounds? Instead, you throw unknown boost::bad_index. 8. It's seems you didn't put contents of detail headers in detail namespace so we have boost::map_config class in <boost/ptr_container/ptr_map_adapter.hpp>. Why don't you put all adapters and their config classes to ptr_container::detail namespace? I don't think anyone will use them. 9. <boost/ptr_container/ptr_predicate.hpp> contents derserve to be documented. And it's better to make ptr versions to all <functional> functions and add these classes: template<typename T, typename U, typename R> class boost::ptr_binary_function : std::binary_funtion<T *, U *, R> {}; template<typename T, typename R> class boost::ptr_unary_function : std::unary_funtion<T *, R> {}; It will simplify your code and IMO it will be useful for users who wants to make their own ptr functions/predicates. 10. indirected1, indirected2 are not good names, don't you think? 11. std::set doesn't have set::at, why does boost::ptr_set have one(even two)? Sorry to dig so deep. P.S. BTW, have you fixed that const_ptr_iterator bug yet? -- Pavel Chikulaev

2 15

Problem with string_algo/range
by Martin 12 Apr '05

12 Apr '05

The updated version of string_algo (using boost.range library) no longer works with VC70. trim_copy_if(std::string(" abc "), is_any_of(" ")); generates the following error: boost\range\detail\begin.hpp(114) : error C2027: use of undefined type 'boost::range_detail::range_begin<T>' with [ T=boost::range_detail::range<const char [2]>::type ] boost\algorithm\string\detail\classification.hpp(68) : see reference to function template instantiation 'boost::range_result_iterator<C>::type boost::begin(C (&))' being compiled with [ C=const char [2] ] boost\algorithm\string\classification.hpp(203) : see reference to function template instantiation 'boost::algorithm::detail::is_any_ofF<CharT>::is_any_ofF (SeqT (&))' being compiled with [ CharT=boost::range_value<C>::type, SeqT=const char [2] ]

2 1

[Boost-bugs] [ boost-Bugs-1181272 ] function.hpp breaks assign.hpp
by SourceForge.net 12 Apr '05

12 Apr '05

Bugs item #1181272, was opened at 2005-04-12 08:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1181272&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joakim Möller (jmoller) Assigned to: Nobody/Anonymous (nobody) Summary: function.hpp breaks assign.hpp Initial Comment: #include <boost/function.hpp> #include <boost/assign.hpp> The above includes break during compilation in Visual C++ 7.0 (2002). The error is; c:\VSS3\TDM\Boost\boost\assign\list_of.hpp(48) : error C2955: 'boost::is_array' : use of class template requires template argument list c:\VSS3\TDM\Boost\boost\type_traits\is_array.hpp (82) : see declaration of 'boost::is_array' If the order is modified to read; #include <boost/assign.hpp> #include <boost/function.hpp> .. it will work OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1181272&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[shmem] New snapshot uploaded to boost vault
by ION_G_M 12 Apr '05

12 Apr '05

Hi to all, Lately I've been very busy at work and doing some kde translations, so I didn't have time to work in the documentation. Pavel already have made some good suggestions but I didn't have the time to do them. Surely, Shmem documentation should have much more examples and should clarify confusing vocabulary. I'm still lazy about changing to QuickBook but since it can include source code examples directly, it should be the way to go. It is just that configuring BoostBook was not easy, so I'm just afraid of QuickBook ;-) Now, after excuses and tears, I've just finished the new classes I was coding and I've done some small fixes to do a new snapshot. I don't plan to work on Shmem for the next 20 days, so forgive me if you are waiting better documentation. Fixes and new features: -> Small bug fixes as always -> New shared memory containers: equivalents to STL set/multi/set/map/multimap adapted from SGI's STL. Now we have red- black trees in shared memory -> Full-powered strings in shared memory: basic_string class used with Shmem STL compatible allocators allows the same functionality as std::basic_string. If you have any suggestion, improvement or idea, please, let me know. Regards, Ion

1 0

Hash float functions - request for help
by Daniel James 11 Apr '05

11 Apr '05

Hello everyone, The hash functional tests have finally made it into the regression summary, but there are a few failures, mainly caused by the float functions. I've committed a couple of fixes that should improve matters, but I could use some help porting them to other compilers/platforms. I've attached a couple of test files, it would be great if you could run them on the compilers and platforms that you have access to and send me the results. It's quite likely that the second test will fail to compile, just let me know if it does. Send the results to me directly, to avoid noise. You'll need to add the boost include path when compiling the tests. The tests try to discover the versions of the float functions for the different float types - if you know of a differently named function for your platform that would be a great help. I guess the proper way to do this would be to add macros and tests to Boost.Config, but it's too near to the release to do that. thanks for any help, Daniel

3 4