December 2007 - Boost - lists.boost.org

Reporting bugs at Trac?
by Olaf van der Spek 01 Feb '08

01 Feb '08

Hi, http://boost.org/more/bugs.htm > Submit a bug report to either boost-users list, boost mailing list, or our bug tracking facility; IIRC Trac accounts are only for developers. Maybe it's a good idea to include a Register link anyway and explain this? > submitting it to either of the mailing lists is a preferred way - because many of the Boost developers read the lists on a daily basis, this way you are likely to get a quicker response, and the discussions that often arise there from (possible) bug reports are quite interesting and educational as well; Why aren't reports from Trac forwarded to the mailing lists then? Greetings, Olaf

2 5

Re: [boost] Boost pool allocator slower than STL allocator
by Robin 01 Feb '08

01 Feb '08

Hi I've been testing out boost pool allocator, and my results shows it's slower than the STL allocator. I'm using VSNet 2005 SP1. See test code below. Also, on a separate issue, I notice the pool_allocator uses a singleton with static member in a function (Meyer's singleton). While this avoid the static construction issue, it does not free the memory until the application quits. This would work fine only POD data, if the dtor depends on a system in the application, it won't work. Shouldn't there be a pool allocator which can be used like the object_pool? Robin Test code -------- With boost pool, timing on average is (0.03) vs STL (0.02) seconds in release mode. In debug mode, its boost (0.99) vs STL (0.8) #include <boost/pool/pool_alloc.hpp> #include <iostream> #include <vector> using namespace std; class A { int x, y; public: A () : x (0), y (0) {} }; #include <windows.h> class Timer { public: Timer() { reset(); } /// reset() makes the timer start over counting from 0.0 seconds. void reset() { unsigned __int64 pf; QueryPerformanceFrequency( (LARGE_INTEGER *)&pf ); freq_ = 1.0 / (double)pf; QueryPerformanceCounter( (LARGE_INTEGER *)&baseTime_ ); } /// seconds() returns the number of seconds (to very high resolution) /// elapsed since the timer was last created or reset(). double seconds() { unsigned __int64 val; QueryPerformanceCounter( (LARGE_INTEGER *)&val ); return (val - baseTime_) * freq_; } /// seconds() returns the number of milliseconds (to very high resolution) /// elapsed since the timer was last created or reset(). double milliseconds() { return seconds() * 1000.0; } private: double freq_; unsigned __int64 baseTime_; }; int main () { Timer timer; for (int i = 0; i < 10; ++i) { // Switch allocators // typedef vector <A> VectorA; typedef vector <A, boost::pool_allocator <A> > VectorA; VectorA vectorA; double startTime = timer.seconds (); for (int jj = 0; jj < 1000000; ++jj) { vectorA.push_back (A()); } double endTime = timer.seconds (); cout << "Time taken is " << i << " - " << endTime - startTime << endl; } return 0; } > On 30/12/2007, Robin <al(a)cyberversion.com> wrote: > >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > > It seems your message got sent without any body text.

4 4

Boost.Tests: Unit test defines own main() function, why?
by Jens Seidel 17 Jan '08

17 Jan '08

Hi, I would like to know why Boost's unit test framework requires that the user defines init_unit_test_suite(int, char**) (or with char *[] argument???) instead of main(). I recently had again some trouble because of it: * It broke the general autoconf test in boost.m4 as the existance of a Boost library can normally easily be tested by using boost code in main() and not init_unit_test_suite(). (Will probably be fixed soon in boost.m4.) * According to http://lists.boost.org/Archives/boost/2007/05/121601.php linkers don't look into libraries (either static or dynamic) to find main so that unit tests cannot be cimpiled as shared library. * I noticed that Debian's Boost library doesn't work for me as main() is not found in the shared library (but in the static one). I found now beside my bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456863 also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432921 which mainly refers to the link above. I'm not sure whether my problem is an error in Debian's packages or not but I ask why is main handled differently in Boost.test? Wouldn't it be sufficient to ask the user simple to start init_unit_test_suite() from a user specified main() to make most problems go away? Maybe it would be even OK to just start init_unit_test_suite() in the constructor of a static variable (yes, I know that the initialisation order may cause trouble with other static data). http://www.boost.org/libs/test/doc/faq.html doesn't explain it! I will now use ifdef's to easily allow using boost/test/included/unit_test.hpp as alternative to the library. Jens

10 52

[Interval] Bug when constructing from an unsigned integer type
by John Maddock 15 Jan '08

15 Jan '08

This compiles: boost::interval<double> in(1u); but creates a nonsense interval. IMO this should work? Likewise the same problem manifests itself when constructing from an unsigned long long (and in this case you really do want a true interval to be created). John.

2 6

Strings tagged with their character set
by Phil Endecott 10 Jan '08

10 Jan '08

Dear All, Something that I have been thinking about for a while is storing strings tagged with their character set. Since I now have a practical need for this I plan to try to implement something. Your feedback would be appreciated. The starting point is the idea that the character set of a string may be known at compile time or at run time, and so two types of tagging are possible. First compile-time tagging: template <character_set> class tagged_string { ... }; tagged_string<utf8> s1; tagged_string<latin1> s2; Some typedefs would be appropriate: typedef tagged_string<utf8> utf8string; Now run-time tagging: class rt_tagged_string { private: character_set cs; public: rt_tagged_string(character_set cs_): cs(cs_) ... ... }; rt_tagged_string(utf8) s3; (Consise-yet-clear names for any of these classes would be great.) I propose to implement conversion between the strings using icode and/or GNU recode. It would be easy to allow this conversion to happen invisibly, but it might be wiser to make conversion explicit. I'm not sure what the 'character_set' that I've used above should be. It needs to be some sort of user-extensible enum or type-tag. We need character types of 8, 16 and 32 bits. wchar is not useful here because it's not defined whether it's 16 or 32 bits. So I propose the following, modelled after cstdint: typedef char char8_t; typedef <implementation-defined> char16_t; typedef <implementation-defined> char32_t; I then propose a character_set_traits class: template <character_set> class character_set_traits; template <> class character_set_traits<utf8> { typdef char8_t char_t; const bool variable_width = true; ... }; For the fixed-width, compile-time-tagged strings I think it makes sense to inherit from std::basic_string< character_set_traits<charset>::char_t >. The only problem I can see with this is that latin1string s1 = "hello world"; s1.substr(1,5) <--- this returns a std::string, not a latin1string If latin1string has a constructor from std::string (which is its own base type) that's fine, i.e. we can still write: latin1string s2 = s1.substr(1,5); but unfortunately we can also write latin2string s3 = s1.substr(1,5); which is not so good. So a different approach is to define a set of character-set-specific character types, and build string types from them: typedef char8_t latin1char; typedef char8_t latin2char; For variable-width character sets, the methods of std::string are less useful (though far from useless). I understand that there's already a utf8 iterator somewhere in Boost, can it help? For run-time character sets, is there any way to provide e.g. run-time iterators? I imagine these strings being used as follows: - Input to the program is either run-time or compile-time tagged with any character set. - Data that is not manipulated in any way it just passed through. - Data that will be processed will first be converted to a suitable, compile-time-tagged, character set, and if appropriate converted back afterwards. So the absence of (useful) string operations on run-time-tagged or variable-width character set data is not a problem. For conversions, there is the question of partial characters in variable-width character sets. If a program is processing data in chunks it may be legitimate for a chunk boundary to fall in the middle of a UTF8 character. IIRC, icode has a method to deal with this which we could expose in a stateful converter: charset_converter utf8_to_ucs4(utf8,ucs4); while (!eof) { utf8string s = get_chunk(); ucs4string t = utf8_to_ucs4(s); send_chunk(t); } utf8_to_ucs4.flush(); - but many applications may only need a stateless converter. I will be working on this over the next couple of weeks, so any feedback would be much appreciated. Regards, Phil.

16 55

seek issue with boost::iostreams::stream
by Steve Nutt 08 Jan '08

08 Jan '08

I've created a device with the boost::iostreams::dual_seekable category to use with the boost::iostreams::stream class, but I'm having trouble implementing seek. When I call seekp on the stream, seek on my device is called with a which (openmode) of both BOOST_IOS::in and BOOST_IOS::out. I would have expected for a call to seekp the which parameter in the seek call on my device would be BOOST_IOS::out, and calling seekg would set which to BOOST_IOS::in. The following code in boost\iostream\detail\streambuf\indirect_streambuf.hpp ignores the which argument passed and passes on through both in and out. template<typename T, typename Tr, typename Alloc, typename Mode> inline typename indirect_streambuf<T, Tr, Alloc, Mode>::pos_type indirect_streambuf<T, Tr, Alloc, Mode>::seekpos (pos_type sp, BOOST_IOS::openmode) { return seek_impl( position_to_offset(sp), BOOST_IOS::beg, BOOST_IOS::in | BOOST_IOS::out ); } Is this correct, and if so how do I implement seeking when using a dual head device? Many thanks, Steve Nutt

2 2

[IOStreams] Opinion on test case needed
by Frank Birbacher 07 Jan '08

07 Jan '08

Hi! I had problems using iostreams::stream<file_descriptor> with Windows and MSVC 8 Express. The file_descriptor had a bug and failed seeking. But the error had gone unnoticed. Because of this I wrote a test case for this in hope to discover an error in IOStreams (source: see below). I did not discover one. Instead the test runs fine on linux/gcc 4.1.2 but fails on Windows/MSVC8Express (test run: see below). I based the test on "Standard C++ IOStreams and Locales" (Langer&Kreft), Section 1.3 "The Stream State". And I found the IOStreams library is just using std::iostream for handling the errors. So is MSVC buggy in this regard? Or am I missing something? Source of test case in Trac SVN Browser: http://svn.boost.org/trac/boost/browser/sandbox-branches/birbacher/fix_iost… Result of test case on platform Windows/MSVC 8 Express: > ...using <p..\..\..\bin.v2\libs\iostreams\test\error_test.test\msvc-8.0express\debug>error_test.exe... > testing.capture-output ..\..\..\bin.v2\libs\iostreams\test\error_test.test\msvc-8.0express\debug\error_test.run > ====== BEGIN OUTPUT ====== > Running 12 test cases... > error_test.cpp(81): error in "wrap_nothrow <&test_seekg>": exception thrown by function(stream) > error_test.cpp(66): error in "wrap_nothrow <&test_seekg>": stream still good > error_test.cpp(68): error in "wrap_nothrow <&test_seekg>": stream did not set badbit > error_test.cpp(69): error in "wrap_nothrow <&test_seekg>": stream did not fail > error_test.cpp(71): error in "wrap_nothrow <&test_seekg>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_nothrow <&test_seekg>": stream does not report failure by operator void* > error_test.cpp(66): error in "wrap_throw <&test_seekg>": stream still good > error_test.cpp(68): error in "wrap_throw <&test_seekg>": stream did not set badbit > error_test.cpp(69): error in "wrap_throw <&test_seekg>": stream did not fail > error_test.cpp(71): error in "wrap_throw <&test_seekg>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_throw <&test_seekg>": stream does not report failure by operator void* > unknown location(0): fatal error in "wrap_throw_delayed<&test_seekg>": std::runtime_error: bad seek > error_test.cpp(73): last checkpoint > error_test.cpp(81): error in "wrap_nothrow <&test_seekp>": exception thrown by function(stream) > error_test.cpp(66): error in "wrap_nothrow <&test_seekp>": stream still good > error_test.cpp(68): error in "wrap_nothrow <&test_seekp>": stream did not set badbit > error_test.cpp(69): error in "wrap_nothrow <&test_seekp>": stream did not fail > error_test.cpp(71): error in "wrap_nothrow <&test_seekp>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_nothrow <&test_seekp>": stream does not report failure by operator void* > error_test.cpp(66): error in "wrap_throw <&test_seekp>": stream still good > error_test.cpp(68): error in "wrap_throw <&test_seekp>": stream did not set badbit > error_test.cpp(69): error in "wrap_throw <&test_seekp>": stream did not fail > error_test.cpp(71): error in "wrap_throw <&test_seekp>": stream does not report failure by operator ! > error_test.cpp(73): error in "wrap_throw <&test_seekp>": stream does not report failure by operator void* > unknown location(0): fatal error in "wrap_throw_delayed<&test_seekp>": std::runtime_error: bad seek > error_test.cpp(73): last checkpoint > > *** 24 failures detected in test suite "Master Test Suite" > > EXIT STATUS: 201 > ====== END OUTPUT ====== Any opinions on this? Any suggestions on what to do about it? Frank

4 16

[iostreams] understanding the models
by Benjamin Collins 06 Jan '08

06 Jan '08

I'm trying to write a device for iostreams, but I'm having a hard time understanding how the current sources and the models explained in the documentation are in agreement. Maybe I'm shooting myself in the foot by never being able to work on this for more than 30 minutes at a time and having that 30 minutes be late at night, but... Anyway, it seems odd to me - for example, the boost::iostreams::mapped_file_source class has the following category of source_tag + direct_tag + closable_tag, and has member functions open(), size(), data(), begin(), and end(). None of these are particularly surprising. After all - a mapped_file has to be open()ed at some point. But under what model as defined in the docs? In other words, how and when is that function called, and how does a stream_buffer know he can call open() on a particular device? Also, the documentation indicates that a source device needs to support the read() function - but mapped_file_source has no read() (maybe because it is convertible to 'direct'?). -- Benjamin A. Collins <ben.collins(a)acm.org> http://bloggoergosum.us

2 1

[iostreams] Patch for latest CodeGear (Borland) compiler
by Nicola Musatti 06 Jan '08

06 Jan '08

Hallo, The patch in http://svn.boost.org/trac/boost/ticket/1294 improves support for the latest version of bcc32, 5.9.2 . If I don't receive objections in two or three days I'll apply it. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

2 1

[Interval] Conversion from integer types?
by John Maddock 04 Jan '08

04 Jan '08

Can someone explain what the issue is in converting an integer type to a boost::interval, and in performing mixed integer/floating point arithmetic and comparisons? Is it simply that the integer types may have more bits in their representation than floating point ones, and we may therefore loose precision? If so, can we not convert integers to intervals implicitly, complete with calculation of the error? That would auto-magically make mixed integer/floating point arithmetic work as well. And yes, I'm prepared to invest some time to make this work and do the right thing, if time is the only stumbling block :-) Thanks, John.

3 6