- Boost - lists.boost.org

serialization: buffers
by Darren Cook 28 Sep '04

28 Sep '04

I've a class like this: class Example{ int str[BSize]; int *p; }; Where p points to next available element (p==str+BSize is possible when it is full). I.e. str is like begin() and p is like end(). I want to add a serialize() function, something like this: template<class Archive> void serialize(Archive &ar,const unsigned int){ ar & BOOST_SERIALIZATION_NVP(buf,p); } but there seems to be no support for buffers like this? For the moment I've implemented using separate load/save functions, where save writes the buffer size and load starts by reading it. While much simpler than the load/save code I'm replacing, the above 1-liner is even more appealing. Darren

1 0

RE: [boost] lexical_cast.hpp:102: error: `wstring' is not a member of `std' ?
by DY, JERRY U (SBCSI) 28 Sep '04

28 Sep '04

Could be related to the following g++ problem. Scheduled to be fixed in gcc 3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005 -Jerry -----Original Message----- From: Rob [mailto:spamrefuse@yahoo.com] Sent: Sunday, September 26, 2004 9:17 PM To: boost(a)lists.boost.org Subject: [boost] lexical_cast.hpp:102: error: `wstring' is not a member of `std' ? Hello, I'm not a boost expert, but I'm using LyX, which has boost (version 1.31.0) included in its source code. I have FreeBSD (4.10) and use gcc 3.4.2. When I compile LyX, I get an error from boost: [...] ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std' ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std' ../../boost/boost/lexical_cast.hpp:103: error: template argument 1 is invalid ../../boost/boost/lexical_cast.hpp:103: error: explicit specialization of non-template `<type error>' ../../boost/boost/lexical_cast.hpp:162: error: declaration of `operator>>' as non-function ../../boost/boost/lexical_cast.hpp:162: error: expected `;' before '(' token ../../boost/boost/lexical_cast.hpp:168: error: expected `;' before "private" When I reported this to the LyX list, I was told to forward the problem to the boost list. There may be a problem here with FreeBSD, gcc 3.4.2 and boost. Any idea what is going on here? Thanks, Rob. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

regression results? (where's the beef??)
by Victor A. Wagner Jr. 28 Sep '04

28 Sep '04

Is it just me, or have the regression results not been picked up by metacomm in the past 24 hours? Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 2

Re: immutable string
by Igor Kholodov 28 Sep '04

28 Sep '04

>> Agree, but which name should we used - >> "reverse_const_iterator" >> or "const_reverse_iterator"? >> I thought it was the latter. > >Now I see :) Will fix it. Great, after the fix I will run the same tests with VC 7.1. It is amazing how many strings are const_string-compatible objects! Thanks, Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/

2 1

[boostbook] link to an enum
by Angus Leeming 27 Sep '04

27 Sep '04

I can define a link to a class with: <classname alt="boost::glob_predicate">glob_predicate</classname> How do I define a link to an enum? It seems that a shorthand notation is missing. Is there a longhand way? Regards, Angus

3 3

[boostbook] mangling of names of generated docs
by Angus Leeming 27 Sep '04

27 Sep '04

I find that if I have a header file "foo_bar.hpp" containing the declaration of a function "foo_bar" (there may be other functions in there too of course), then the generated html docs are: Writing foo_bar.html for refentry(foo_bar) Writing id2767798.html for section(id2767798) foo_bar.html contains the docs for the function whilst id2767798.html contains Header <foo_bar.hpp> namespace boost { namespace child { void foo_bar(std::string const &); } } I can see why this is done, but why not modify the mangling so that id2767798 becomes foo_bar_hpp and id2767798.html becomes foo_bar_hpp.html? Especially since each regeneration of the docs results in a different ID. Regards, Angus

1 0

Re:Re: [boost] Re: FORMAL review of "Output Formatters" - votes needed
by Robert Ramey 27 Sep '04

27 Sep '04

Reece wrote: >Roland Richter wrote: > John Torjo wrote: > >> The dilemma I see is that the outfmt library is somewhere between >> serialization (boost::serialization) and pretty-printing >> (boost::format). IMO, outfmt provides *both* at a basic level in that >> it simply adds streaming operators << and >> to STL containers, >> which, for some reason, are currently missing. What advantages does using the output formatters for output/input have over using the serialization library to do the same thing? Robert Ramey

1 0

[thread] test_read_write_mutex* failures
by Stefan Slapeta 27 Sep '04

27 Sep '04

Hi all, there are some failures at runtime for this testcase which look like this: [...] timed test, sp=0 ../../../libs/thread/test/test_read_write_mutex.cpp(293): error in "test_read_write_mutex": test w1.m_value == 10 failed ../../../libs/thread/test/test_read_write_mutex.cpp(294): error in "test_read_write_mutex": test r1.m_value == -1 failed ../../../libs/thread/test/test_read_write_mutex.cpp(295): error in "test_read_write_mutex": test r2.m_value == 10 failed I didn't investigate too much so far, but something is very strange with this: (1) If I compile this test with bjam using the Intel toolset, it fails (exactly like in the regression results). (2) If I compile this test with bjam using the vc 7.1 toolset, it passes (exactly like in the regression results). Now here comes the interesting part: (3) If I compile this test in the VS IDE using Intel Compiler, it fails, but has a slightly different output from bjam. (4) If I compile this test in the VS IDE using VC, it fails, too (!!), with the same output as above. I've already checked the compiler and linker options that are passed by bjam, there is nothing suspicious. I'll continue my investigations tomorrow, in between any ideas about where these differences could come from are _very_ appreciated! Stefan

3 3

[shared_ptr] Interlocked* - possible bug?
by John Torjo 27 Sep '04

27 Sep '04

Hi Peter, I think there is a bug in your Interlocked* implementation of shared_ptr (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) In atomic_read you have: inline long atomic_read(long volatile const & value) { return value; } I don't believe this is thread-safe. In order to make sure you're receiving the latest value, I assume you could do something like: inline long atomic_read(long volatile & value) { const int IMPOSSIBLE_VALUE = -100; return InterlockedCompareExchange(&value, IMPOSSIBLE_VALUE, IMPOSSIBLE_VALUE); } Am I missing something? Best, John -- John Torjo -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

4 13

RE: [boost] Python/GCC 3.4.1/Linux failures
by Stefan Seefeld 27 Sep '04

27 Sep '04

> From: Jonathan Brandmeyer [mailto:jbrandmeyer@earthlink.net] > Sent: September 27, 2004 15:55 > > > Just an observation, g++ 3.4.2 (Debian 3.4.2-2) passes > all of the tests. > > > > The tests fail for gcc 3.4.2 here. > > > > Which Python version do you use? > > 2.3.4 (Debian package 2.3.4-12) unfortunately debian has the bad habit to assign its own version numbers, so it could well be that what it refers to as 'gcc 3.4.2' is actually only a prerelease or something. I'v always found this very confusing... FWIW, Stefan

1 0