April 2004 - Boost - lists.preview.boost.org

[serialization] all wide tests were failing because...
by Vladimir Prus 14 Apr '04

14 Apr '04

Robert, if you recall, all wide archive tests were failing for me. They still failed with #18, and now I finally (after quite some debugging) know why. The error I was getting was: Exception in "call_test_main": std::length_error: basic_string::reserve It occured even on test_vector, which is fairly simple. The generated data contained this: 22 boost::serialization .... note that this was for wide archive, where the data should have being in UCS-4 encoding, i.e. ('2' <zero> <zero> <zero> '2' ...) The reason, once found, is simple: { test_ostream os(testfile, TEST_STREAM_FLAGS); test_oarchive oa(os); } You change codecvt in archive constructors and the archive also has locale saver. The destructor for archive is called *before* destructor for 'os'. At this time, codecvt is switched back, right? So, when destructor of 'os' calls 'close' which flushes the data, you're using default codecvt. If I add explicit 'os.close()' after writing to archive, the written data is correct. What this means is that destructor of archive *really should* call 'flush' on the stream. After I've made basic_text_oprimitive's destructor to flush stream: template<class OStream> basic_text_oprimitive<OStream>::~basic_text_oprimitive(){ os.flush(); } The test_vector passed with wide stream. I'm rerunning other tests now. In fact, I'm getting suspicious about changing codecvt at all. I suppose that if somebody is using wide streams, he already deals with encoding somehow, so why serialization library should try to second-guess the user? - Volodya

1 0

Re: [boost] Serialization. Pointer to constant object.
by Robert Ramey 14 Apr '04

14 Apr '04

Alexey Nikitin wrote: ... >void f3(A const* a, text_oarchive& oa) >{ > oa << a; >} >Why compiled function f1 and f2 but not f3 ? Good point. I have a fix - but it won't work for compilers that don't support Partial Template Specialization. I haven't been able to find a more general fix. Robert Ramey

2 1

[program_options] Unicode support
by Vladimir Prus 14 Apr '04

14 Apr '04

Hello, it seems that Unicode support is the last issue that should be addressed before the library can be added to CVS. Since the issue is somewhat tricky, I'd appreciate some comments before I start coding. The initial description of the approach I plan is at http://zigzag.cs.msu.su:7813/program_options/html/program_options.design.ht… or http://zigzag.cs.msu.su/~ghost/program_options/html/program_options.design.… So summarize the document, user would be able to pass wchar_t** to the parse_command_line function. If specific option needs unicode, this can be specified like this: ("email", unicode::value<Email>(), "email address") I believe the change will be mostly transparent and won't affect ascii usage. All options are very welcome! TIA, Volodya

9 30

question regarding basic_stream::imbue
by Robert Ramey 14 Apr '04

14 Apr '04

I have a simple question regarding basic_stream::imbue(locale &) Can it be applied after a file is opened? The state saver libray seems to suggest that it can. Some information suggests that it can if the file is position at the start. Experience with dinkumware and STLport suggests that it can't. If it can't what's the best way to work around it? Robert Ramey

2 1

[serialization] utf8 test glitch
by Vladimir Prus 14 Apr '04

14 Apr '04

Robert, to make utf8 test pass, I had to apply the attached patch. Seems like there was a typo which manifected itself only on 4-bit wchar_t -- one of the trailing bytes did not have the high bit set, so the facet returned an error. - Volodya

1 0

Re:[boost] Serialization #18
by Robert Ramey 14 Apr '04

14 Apr '04

Alexey Nikitin wrote: >I think it is not good idea to use "using namespace ...;" in header files. I agree - I'll fix it. Robert Ramey

1 0

circular_buffer question
by Neal D. Becker 14 Apr '04

14 Apr '04

I'm looking at circular_buffer. It appears to me that operator[] uses "add", and that "add" only allows a positive value of offset? It is not difficult to allow arbitrary values, and this is very useful. if "position" is the current "m_first" and "allocated" is the allocated buffer size, the index could be calculated: int index (int offset) const { int x = (offset + position) % int(allocated); if (x >= 0) return x; else return x + allocated; }

4 6

Boost Regex Understanding Captures topic
by Edward Diener 13 Apr '04

13 Apr '04

While the documentation for this topic is excellent, the one thing missing, I believe, is that the term "Captures" is never defined. I believe a brief single line at the very top of the topic defining the term would be judicious.

3 3

mirroring boost cvs ?
by Toon Knapen 13 Apr '04

13 Apr '04

We would like to mirror the boost cvs for internal users (in our company). We could of course run a script every night that performs a 'cvs checkout' followed by a 'cvs import'. But this way for instance, the versions of all files in our mirror do not correspond to the version of all files on the official boost trunk. There are also tools out there to do this but this requires that specific daemons are run on the server side (i.e. by sourceforge). Any ideas ? Thanks, toon

2 1

[Patch] iterator/iterator_facade.hpp collides with macros on i386-pc-solaris2.8
by Brad Spencer 13 Apr '04

13 Apr '04

In iterator/iterator_facade.hpp, there are a lot of template arguments that have names like "R1" and "D2". Unfortunately, these "all caps" tokens are fodder for collisions with macros. On i386-pc-solaris2.8, for some reason, "R1" is defined to be "9" (it's some kind of register identification macro) and so instead of: template < . . . , class R1, . . . > we get template < . . . , class 9, . . . > which, of course, doesn't work :) I've attached a patch against 1.31.0 (the trunk for this file) to fix this one file by adding "_type" to the end of all such all-caps names. I have not tested it very well. Perhaps there should be a policy to avoid names that are likely to collide with system macros? Just using mixed case (or lower case) is probably enough. Thanks for the great software! -- ------------------------------------------------------------------ Brad Spencer - spencer(a)infointeractive.com - "It's quite nice..." Systems Architect | InfoInterActive Corp. | A Canadian AOL Company

2 3