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

[array] with variable size
by Hicham Mouline 20 Nov '08

20 Nov '08

Hello, I have a third-party library that gives me a number N of doubles, then expects from me a double* to an array where it will set N elements This would have happen many times and N is variable, so I wish not to reallocate the array each time. I know however N is maxed at some value Nmax like 50. I thought of using a array<double, Nmax> that would be allocated once, then perhaps have a wrapper around it so that only N elements of it can be accessed. This seems to be a usual idiom, are there ready implementations? Regards,

5 7

Re: [Boost-users] Boost range changes [1.37.0]
by Tomas Puverle 20 Nov '08

20 Nov '08

> template<class T> > bool is_singular_or_empty(const T& t) { return(t.empty()); } > template<class T> > bool is_singular_or_empty(const iterator_range<T>& t) { > return(t.is_singular() || t._empty()); } Hey Steven, That was my initial approach, too. >From a library designer point of view, the reason why I was reluctant about the above is that it breaks the range contract (begin, end, empty,...) and forces my users to be aware of the idiosyncrasies of a particular range implementation. >From an implementation point of view, unfortunately, you seem to have got caught out by the same problem as me - is_singular() is only useful in debug builds. It always returns false in release builds and hence the above won't work. Worse, it will break silently, as t.empty() will end up comparing invalid iterators in release. I am sure you can see how this would be very hard to find and debug. This also illustrates my other big issue with having functions which work differently in different builds. Kind regards, Tom

1 0

boost build
by df.trash 20 Nov '08

20 Nov '08

I want to build the Filesystem Library on Windows so that it statically links to my code at runtime. I use the following statement on the command line to invoke bjam: bjam release --with-filesystem --toolset=msvc-7.1 link=static This builds only 1 library: libboost_filesystem-vc80-mt-1_36.lib It does not build the System Library which Filesystem depends on. I'm very much new to the Boost paradigm. Why can I not build the System Library statically? Do I really need the System Library and its error handling features? Will the Filesystem Library need the System Library or is the System Library just an option to handle errors and not essential at runtime?

2 1

Big ints library?
by Lang Stefan 20 Nov '08

20 Nov '08

Hello, I was wondering whether there is a library for algorithms working on very big natural numbers, i. e. bigger than any available standard int type. Does the boost library have one? I did check the documentation, but if there is one I haven't looked in the right places. Thanks in advance, even if the answer is no! Stefan

2 1

multiply dynamic_bitset
by Markus Raab 20 Nov '08

20 Nov '08

How can I multiply two dynamic_bitset? Thank you Markus Raab

2 2

Too many (11053) warnings- lead to extremely slow compile times
by Raj Prasan 20 Nov '08

20 Nov '08

I get 11053 warnings after I have included boost serialization in my Mixed project - Native + Managed .NET code.. and the compile time has become 9.5 minutes after this. Previously it was I think 8-10 times faster... Warning level is set to 2 only. Default was 3 or 4.. I use VS 2008.. on WinXPsp2 *some example Warnings.* ===================== Warning 1 warning C4099: 'boost::static_warning_impl<false>::STATIC_WARNING' : type name first seen using 'struct' now seen using 'class' f:\GoodWorking\Boost\boost\serialization\export.hpp 135 Warning 3 warning C4835: 'boost::serialization::extended_type_info_typeid<BaseItem> `private: static boost::serialization::extended_type_info_typeid<BaseItem> & __cdecl boost::serialization::singleton<boost::serialization::extended_type_info_typeid<BaseItem> >::get_instance(void)'::`2'::t' : the initializer for exported data will not be run until managed code is first executed in the host assembly f:\GoodWorking\Boost\boost\serialization\singleton.hpp 104 *----------------------- > Warning 3 is shown for many other classes which extend BaseItem* <------------------- Warning 33 warning C4835: 'instance' : the initializer for exported data will not be run until managed code is first executed in the host assembly f:\Rajavanya\GoodWorking\Boost\boost\serialization\singleton.hpp 121 Warning 47 warning C4835: 'boost::archive::detail::pointer_oserializer<boost::archive::text_oarchive,BaseItem> `private: static boost::archive::detail::pointer_oserializer<boost::archive::text_oarchive,BaseItem> & __cdecl boost::serialization::singleton<boost::archive::detail::pointer_oserializer<boost::archive::text_oarchive,BaseItem> >::get_instance(void)'::`2'::t' : the initializer for exported data will not be run until managed code is first executed in the host assembly f:\GoodWorking\Boost\boost\serialization\singleton.hpp 104 Warning 9033 warning C4835: 'boost::serialization::extended_type_info_typeid<std::map<int,BaseItem *,std::less<int>,std::allocator<std::pair<int const ,BaseItem *> > > > `private: static boost::serialization::extended_type_info_typeid<std::map<int,BaseItem *,std::less<int>,std::allocator<std::pair<int const ,BaseItem *> > > > & __cdecl boost::serialization::singleton<boost::serialization::extended_type_info_typeid<std::map<int,BaseItem *,std::less<int>,std::allocator<std::pair<int const ,BaseItem *> > > > >::get_instance(void)'::`2'::t' : the initializer for exported data will not be run until managed code is first executed in the host assembly f:\GoodWorking\Boost\boost\serialization\singleton.hpp 104 Warning 9136 warning C4835: 'boost::archive::detail::pointer_iserializer<boost::archive::text_iarchive,RCadApp> `private: static boost::archive::detail::pointer_iserializer<boost::archive::text_iarchive,RCadApp> & __cdecl boost::serialization::singleton<boost::archive::detail::pointer_iserializer<boost::archive::text_iarchive,RCadApp> >::get_instance(void)'::`2'::t' : the initializer for exported data will not be run until managed code is first executed in the host assembly f:\GoodWorking\Boost\boost\serialization\singleton.hpp 104 Warning 11038 warning C4835: 'boost::archive::detail::oserializer<boost::archive::text_oarchive,std::pair<int const ,BaseItem *> > `private: static boost::archive::detail::oserializer<boost::archive::text_oarchive,std::pair<int const ,BaseItem *> > & __cdecl boost::serialization::singleton<boost::archive::detail::oserializer<boost::archive::text_oarchive,std::pair<int const ,BaseItem *> > >::get_instance(void)'::`2'::t' : the initializer for exported data will not be run until managed code is first executed in the host assembly f:\GoodWorking\Boost\boost\serialization\singleton.hpp 104 Warning 11052 warning C4835: 'boost::archive::detail::pointer_iserializer<boost::archive::text_iarchive,Vector> `private: static boost::archive::detail::pointer_iserializer<boost::archive::text_iarchive,Vector> & __cdecl boost::serialization::singleton<boost::archive::detail::pointer_iserializer<boost::archive::text_iarchive,Vector> >::get_instance(void)'::`2'::t' : the initializer for exported data will not be run until managed code is first executed in the host assembly f:\GoodWorking\Boost\boost\serialization\singleton.hpp 104 Please give me some suggestions please... -- With best Regards Rajavanya S Twitter me @ https://twitter.com/quakeboy I Blog @ http://www.techtola.com Call me @ 9916-90-93-92 ---------------------------------------------------------------------------------------------- "True love is knowing a person's faults, And loving them even more for them."

1 0

Re: [Boost-users] Boost range changes [1.37.0]
by Dave Handley 20 Nov '08

20 Nov '08

Please see comments inline: "Tomas Puverle" <Tomas.Puverle(a)morganstanley.com> wrote in message news:loom.20081120T001601-724@post.gmane.org... > Thorsten, > > Thanks for the reply. See comments inline. > >> The change has happened long ago. It was a design mistake to try to make >> a range of singular iterators valid since it adds overhead also for >> those that don't need it. > > When you say "overhead", are you speaking of size or speed? > Was this overhead demonstrated by some particular use case? > Does this mean you may be also removing the "singular" flag at some point? > Is there a supported way of constructing valid empty ranges? I can't see that > there's a way to do it. I'm also not sure about the overhead issue here. Checking a single bool inside size and/or empty strikes me as a trivial matter - no more complex than many things in the standard library or elsewhere in boost. <snip> > > IMHO, this is obfuscated. There is a difference between an empty range and a > range which is optional. In line with the std containers, I would argue that a > default constructed range should be empty. I have to agree with this premise. In line with a lot of proxy or container type objects I would expect a default constructed object to do something sensible. I wouldn't expect, for example, a boost.shared_ptr to default construct to an object that asserts when you check it for NULL. This change appears to be quite a severe change in functionality. <snip> > In any case, I've enjoyed using your library. I found it so useful I've built > four other libraries, which are mostly based on passing data around through > Boost.Ranges. I just wish that all of my code wasn't broken now that > I've upgraded. > This is a point on which I feel I have to amplify. I've been using Boost for quite a long time now, and been through numerous upgrades, many of which I've managed the upgrade at work. Breaking changes are always the thing that hurts the most during an upgrade. Especially now that boost has gone to an accelerated release cycle where we see such regular new releases. I'm sure that many users of Boost like myself don't get to upgrade to every release, so moving to a new release involves jumping through 2 or 3 releases. Breaking changes in this context are very painful. As a library writer myself, where I am forced to do a breaking change, I always try and make it something that will break on compile - otherwise my users cannot be confident in doing a library upgrade without a very extensive testing schedule - quite often this results in users simply not upgrading. With this particular change, I feel even more strongly. Assertions in library code can often be a bad thing. If the users of the library are not explicitly aware of a change that takes out a check and replaces it with an assertion, then you get applications which can either abort unexpectedly (if not built with NDEBUG) or worse still just do something different in a silent fail. This is just downright dangerous. Personally, I would strongly support backing out of a change like this. However, if Thorsten strongly disagrees, I would at least recommend as a compromise position to introduce a define along the lines of BOOST_NO_ASSERT (or maybe BOOST_RANGE_NO_ASSERT) that gets rid of the assertion and does something sensible instead. The only times I like to see assertions in libraries are: firstly, states which should be impossible to get into and are therefore testing for either corruption or a problem in the library; or secondly, occasions where you are going to crash anyway if you continue - for example if after the assertion you are about to dereference a NULL or uninitialised pointer. Things which are common states that systems using the library could get into should do something sensible - at worst throw an exception, and at best return a sensible answer. Please reconsider this change - I have yet to upgrade to 1.33.7 yet, and knowing this type of change is present there makes me highly reluctant to go ahead with an upgrade. I'm not sure (just covering the post from Steven) that going through an entire codebase and changing calls to empty with calls to a new template function "is_empty_or_singular" is really a palatable solution. Boost provides a fantastically useful set of libraries - they have certainly significantly changed the way I code in C++; but breaking changes should always be very carefully thought about, they have a nasty habit of leaving people isolated in old versions of boost, and also have a habit of driving people away from using boost. Regards Dave

1 0

non nullable smart pointers
by Brendan Miller 19 Nov '08

19 Nov '08

I've been interested in non nullable smart pointers for a while. I noticed a thread I wanted to check if anyone was still interested in doing it: http://lists.boost.org/Archives/boost/2008/04/135616.php This seems like a worthwhile activity. Null is a legacy element from C that essentially breaks type safety. C++ added references as a way of moving people away from null, but T& obj style references have a number of problems: 1. They have value semantics, which is just plain annoying considering they are *called* references. 2. They use obj.member notation instead of obj->member. 1 is just not usually desireable, and 2 means that there's no way to write a "smart reference" that uses ref.member notation. With that in mind what would a nonnullable pointer be named? I've seen one implemented as a "checked_ptr", but that's a mouthful and doesn't account for the fact that several variations on memory management scheme are needed. I'm thinking: ref<T> myObject; // for a non-nullable pointer with no special memeory management scoped_ref<T> myObject; // for scoped_ptr style memory mangement shared_ref<T> myObject; // you get the idea. I'm also aware of a number of problems with the shared_ptr implementation, specifically that it creates a second allocation for the counter (the counted body problem), and that it always does synchronization, which might have performance overhead for single threaded code (someone else might know more about that than me). It migth be nice to start fresh on these designs now that some perspective has been gained. For the counted body problem I was thinking of creating a make_shared_ref that would create an object and counter adjacent to each other (just put them in the same struct). I put together some proof of concept tempaltes a whie ago and having make_shared_ref<T> behave exactly like new T was somewhat problematic due to overloading issues. Also, you'd need to keep around an extra function pointer in the counter object to delete the struct all together or delete the object seperate object and counter (if they are non-adjacent) and I"m not sure about how that would stack up performance wise. Brendan

3 8

[serialization] dynamically allocated objects and reset_object_address
by Joaquin M Lopez Munoz 19 Nov '08

19 Nov '08

Hello, Consider a tracked type T which is only serialized through T pointers: under these circumnstances, when loading a T* Boost.Serialization automatically allocates a T object for the pointer to refer to. I've found out that these dynamically allocated objects cannot be moved by using reset_object_address: this member function simply ignores them. Would it be possible that reset_object_address also took care of these objects or is there any limitation I'm not aware of? FWIW, this is not an academic question but has raised in connection with some serialization code I'm writing. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

date_time: offset warning
by Hicham Mouline 19 Nov '08

19 Nov '08

https://svn.boost.org/trac/boost/changeset/47957 I see that this was fixed 4months ago. It isn't fixed in 1.37 though... meaning offset is not commented out... Regards,

1 0