- Boost-users - lists.boost.org

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

v_array survival
by Chaman Singh Verma 19 Nov '08

19 Nov '08

Hello, I have one old software which is using v_array, but I don't see v_array in the latest Boost distribution ? Is this class defunct now and should I replace it by vector or something else ? csv

2 3

[Regex]: Warnings for unicode regex includes
by Roland Bock 19 Nov '08

19 Nov '08

Hi, when compiling the following code <snip> #include <boost/regex.hpp> #include <boost/regex/icu.hpp> int main() { return 0; } </snip> with g++ -Wall -Wextra, a bunch of warnings are produced, see below. The first two seem trivial to solve, but I don't know about the third. Is there a workaround to get rid of the warnings (other than to turn of the -Wall and -Wextra) and/or should I file a bug report? System information: Ubuntu 8.04, 64bit gcc 4.2.4 boost 1.36 Regards, Roland PS: Here are the warnings I get: g++ -Wall -Wextra test.cpp -c -I ~/include/ In file included from /home/rbock/include/boost/regex/icu.hpp:1015, from test.cpp:2: /home/rbock/include/boost/regex/v4/u32regex_token_iterator.hpp:286: warning: unused parameter ‘submatch’ /home/rbock/include/boost/regex/v4/u32regex_token_iterator.hpp:348: warning: unused parameter ‘submatch’ /home/rbock/include/boost/regex/v4/perl_matcher.hpp: In function ‘bool boost::re_detail::can_start(charT, const unsigned char*, unsigned char) [with charT = unsigned int]’: /home/rbock/include/boost/regex/v4/perl_matcher_common.hpp:787: instantiated from ‘bool boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::find_restart_any() [with BidiIterator = boost::u16_to_u32_iterator<const UChar*, unsigned int>, Allocator = std::allocator<boost::sub_match<boost::u16_to_u32_iterator<const UChar*, unsigned int> > >, traits = boost::icu_regex_traits]’ /home/rbock/include/boost/regex/v4/perl_matcher_common.hpp:245: instantiated from ‘bool boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::find_imp() [with BidiIterator = boost::u16_to_u32_iterator<const UChar*, unsigned int>, Allocator = std::allocator<boost::sub_match<boost::u16_to_u32_iterator<const UChar*, unsigned int> > >, traits = boost::icu_regex_traits]’ /home/rbock/include/boost/regex/v4/perl_matcher_common.hpp:229: instantiated from ‘bool boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::find() [with BidiIterator = boost::u16_to_u32_iterator<const UChar*, unsigned int>, Allocator = std::allocator<boost::sub_match<boost::u16_to_u32_iterator<const UChar*, unsigned int> > >, traits = boost::icu_regex_traits]’ /home/rbock/include/boost/regex/v4/regex_search.hpp:56: instantiated from ‘bool boost::regex_search(BidiIterator, BidiIterator, boost::match_results<BidiIterator, Allocator>&, const boost::basic_regex<charT, traits>&, boost::regex_constants::match_flag_type, BidiIterator) [with BidiIterator = boost::u16_to_u32_iterator<const UChar*, unsigned int>, Allocator = std::allocator<boost::sub_match<boost::u16_to_u32_iterator<const UChar*, unsigned int> > >, charT = int, traits = boost::icu_regex_traits]’ /home/rbock/include/boost/regex/v4/regex_iterator.hpp:75: instantiated from ‘bool boost::regex_iterator_implementation<BidirectionalIterator, charT, traits>::next() [with BidirectionalIterator = boost::u16_to_u32_iterator<const UChar*, unsigned int>, charT = int, traits = boost::icu_regex_traits]’ /home/rbock/include/boost/regex/v4/regex_iterator.hpp:142: instantiated from ‘boost::regex_iterator<BidirectionalIterator, charT, traits>& boost::regex_iterator<BidirectionalIterator, charT, traits>::operator++() [with BidirectionalIterator = boost::u16_to_u32_iterator<const UChar*, unsigned int>, charT = int, traits = boost::icu_regex_traits]’ /home/rbock/include/boost/regex/icu.hpp:847: instantiated from ‘OutputIterator boost::re_detail::do_regex_replace(OutputIterator, const std::pair<I1, I1>&, const boost::u32regex&, const std::pair<I2, I2>&, boost::regex_constants::match_flag_type) [with OutputIterator = boost::utf16_output_iterator<boost::re_detail::unicode_string_out_iterator>, I1 = boost::u16_to_u32_iterator<const UChar*, unsigned int>, I2 = boost::u16_to_u32_iterator<const UChar*, unsigned int>]’ /home/rbock/include/boost/regex/icu.hpp:1008: instantiated from here /home/rbock/include/boost/regex/v4/perl_matcher.hpp:46: warning: comparison of unsigned expression < 0 is always false

2 3

Remind me
by Dominik Steenken 19 Nov '08

19 Nov '08

Hi, i am currently trying to implement something very simple: i have some network code (using boost/asio) which waits for data on a tcp connection (tcp::socket). Now i want this waiting operation to have a timeout. I did not find timeout capability in boost/asio so i tried to implement a timer class using boost/thread. Now there are two problems: a) the boost::thread object representing the thread that should be interrupted after a given time is not necessarily available. i looked at the namespace this_thread but found no possibility to gain access to a reference to the current thread. b) the interrupt() method only works when the interrupted thread is at one of the predefined interruption points. In my example however, that thread is held up in a boost/asio method. I suppose i could resolve b) by using asynchronous receives but that would take some serious restructuring and problem a) would still remain. What i really want is just a timeout version of the synchronous receive in boost/asio. Any ideas? Dominik

3 4

Re: [Boost-users] timeconv.inl
by Dan Smithers 19 Nov '08

19 Nov '08

> Date: Mon, 17 Nov 2008 09:10:46 +0100 > From: Daniel Kr?gler <dsp(a)bdal.de> > Subject: Re: [Boost-users] timeconv.inl > To: boost-users(a)lists.boost.org > Message-ID: <gfr8u6$vgg$1(a)ger.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Dan Smithers wrote: >> > I am porting some inherited code to MSVS 2008 >> > This is also bringing along an upgrade from boost 1.32 to a newer >> > version (probably 1.37). >> > >> > I have found a thread wrapper class in the code that uses time_to >> > directly. This is defined in lib/thread/src/timeconv.inl and doesn't >> > look like its meant to be used directly. > > I agree with the last assertion. I'm not sure that I correctly > understand with "I have found a thread wrapper class in the code that > uses time_to directly"?! In which code or in which wrapper class? In the inherited code. > >> > The original code base has timeconv.inl in the boost include directory. >> > >> > Was timeconv.inl moved at some point in the past? >> > >> > Is this as bad as I think it is? > > I don't see the (bad) point - timeconv.inl was already part of > the implementation of boost 1.32, so it's existence or it's precise > location shouldn't influence your code [Note that the helper functions > are simply wrapped into an unnamed namespace w/o further surrounding > namespace]. > > It's now located in duplicated form in lib/thread/src/win32 > and lib/thread/src/pthread. Whether this is intended, I don't know, > but it also shouldn't harm. Thanks, I looked around a bit more, and found that the example code used the same code as in timeconv and that I was making exactly the same set of calls to achieve the same result. It just doesn't seem right to be including directly from the src directory. In the code base I have inherited, timeconv.inl is in the include directory and appears to be for public use.

1 0

Re: [Boost-users] rint, the interval library and Visual Studio 2008
by Stephan Puchegger 19 Nov '08

19 Nov '08

> #if BOOST_MSVC < 1400 > extern "C" { double rint(double); } > #else > inline double rint(double x) > { > _asm FLD [x] ; > _asm FRNDINT ; > //_asm RET ; > } > #endif > > In msvc_rounding_control.hpp. > > HTH, John. Thanks John, that helped a lot and is by far more elegant than my solution (simply add a rint implementation to my project). Perhaps your solution should be included in the next boost version. Best regards & thanks Stephan

1 0

[threads] contention for MSCRT's_pRawDllMain hook in static library
by Evan Burkitt 19 Nov '08

19 Nov '08

I'm using VS2005 to compile a DLL that links with the MFC DLL and also the static Boost threads library. I've upgraded from Boost v1.34.1 to v1.37 and now the threads library's use of MSCRT's _pRawDllMain hook interferes with MFC's use of the hook to point to its _RawDllMain export. I've come up with a workaround of a library that exports _pRawDllMain and links to _RawDllMain in the MFC DLL and an export I've added to the threads library that calls its dll_callback() function. I just can't get the MS linker to cooperate. If I put my library ahead of the threads library in the command line the linker complains of a multiply-defined symbol. If I put the threads library ahead of my library the linker uses the threads library _pRawDllMain export and ignores mine. Only if I remove the _pRawDllMain export from the threads library entirely does the linker use mine. I would like to leave the _pRawDllMain export in the threads library so that it will still work in my library's absence but I can't figure out what makes it so attractive to the linker. I realize this isn't, strictly speaking, a Boost issue, but the problem arose because of a change to Boost and I know there are a lot of smart people here. :)> -evan

2 2