- Boost - lists.preview.boost.org

lexical_cast.hpp:102: error: `wstring' is not a member of `std' ?
by Rob 27 Sep '04

27 Sep '04

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.

2 1

dynamic_bitset taking a buffer...
by Boost Rookie 27 Sep '04

27 Sep '04

Hi, I've just started playing around with Boost. I have a specific need which I hope dynamic_bitset can fulfill. I'd like to have a dynamically sized bitbuffer which is initialized with a data stream of bits (this should be quite efficient). Then I'd like to extract the bits from that bitbuffer as specified in a protocol, e.g. bit 0-3 : version bit 4-5 : whatever bit 6 : ack bit 7-9 : whatever and so on... So something like this is what I think should be possible to do: // Note: Original code simplified to examplify... // Read DATALEN bytes from socket char buffer[DATALEN]; int read_bytes = read(socket,buffer,DATALEN); // Init a bit buffer (efficiently) boost::dynamic_bitset<unsigned char> bitbuf(buffer,read_bytes); // Extract different data, as specified by the communication protocol int version = bitbuf.get(0,4); // Extract 4 bits starting at position 0 int whatever = bitbuf.get(4,2); // Extract 2 bits starting at position 4 bool ack = bitbuf.get(6,1) // Extract 1 bit at the 6th position and so on... Reading docs at http://www.boost.org/libs/dynamic_bitset/dynamic_bitset.html shows that my shot at using dynamic_bitset is totally wrong! I cannot construct the bitbuf in that way. Instead, I should specify something called Block/BlockInputIterator as a template parameter? I do not know what that is. Looking at the examples at that page doesn't help either. Only different intergers are stored in the dynamic_bitset... It seems that a string of 1's and 0's can be stored but I really do not want to convert my original data buffer into a std::string and then convert that into a bitbuffer. After construction I do not see how to extract the bits!? Is it only possible to extract one bit at a time?!?!? Is dynamic_bitset designed to handle problems like this or am I trying to do something that is not possible? If dynamic_bitset can't help, is there something else in boost or elsewhere that is designed to solve problems like this? Thanks in advance!

1 1

true64 and Irix tests out of date?
by John Maddock 27 Sep '04

27 Sep '04

I committed a bunch of fixes for issues such as http://tinyurl.com/6s2go and http://tinyurl.com/3smk3 on Monday, but the latest regression test runs (dated Wednesday), are still showing the same errors - in fact they are showing errors for code that no longer exists, so I know that there's something up with the test runs :-) Anyone any idea what's going on, we haven't branched for release yet have we? Thanks, John.

3 3

[BGL] bfs and boost::ref
by Vladimir Prus 27 Sep '04

27 Sep '04

At the moment, it's not possible to pass the object returned by boost::ref as visitor to the breadth_first_search function. So, if visitor has state, I need to hold that state by pointer, which is inconvenient. Any opinions on the attached patch? Unless there are any objections, I'll commit it after we branch for release. - Volodya

2 2

Re:[boost] [serialization] scoped_ptr.hpp broken
by Robert Ramey 27 Sep '04

27 Sep '04

Vladimir wrote: > ......./boost/boost/serialization/scoped_ptr.hpp:36: error: `make_nvp' > undeclared (first use this function) >The attached patch fixes the problem. >BTW, Robert, this problem was introduce when you moved the content of the >header from boost::serialization to just boost::. What was the rationale? >The log only says: > fixes for cw/comeau implement ADL This was changed in order to function with compilers that implement two-phase lookup. This is described (somewhat) in them manual under the section:Reference/Class Serialization/Free Functions/Namespaces for Free Function Overrides Before this change, there is a problem with compilers which implement two-phase lookup. Overrides for templates have to be defined before their usage in another template. This conflicted with the implementation of BOOST_CLASS_EXPORT. To support these compilers, I had to either put non-intrusive serialization functions in the same namespace as the type being serialized or re-organize export. The latter is non-trivial and couldn't be guaranteed to be ready in time for release (at least at the time the issue came up). Perhaps, export may someday get re-organized so that BOOST_CLASS_EXPORT can appear before the archive classes which would resolve the problem in a simpler way. But for now - that's the way it is. Robert Ramey

2 1

Re: immutable string
by Igor Kholodov 27 Sep '04

27 Sep '04

>>> Igor Kholodov <C.JUMP(a)prodigy.net> wrote: >>> >>>> I am testing immutable string outside boost, using >> it >>>> as string type with common text transformation >> library >>>> (http://cttl.sourceforge.net/) It works quite well, >>>> about 18% speed is gained while parsing large XML >>>> documents (>1MB) when using const_string. >>> >>> Could you please specify the compiler and STL >> implementation you use? >>> >> >> Tested with GCC 3.4.1 (mingw) and GCC 3.2.3 on linux. > >Then, I think, the results are very good because GNU ISO >C++ implementation of std::basic_string<> uses representation sharing with >reference counting, which is the same thing that const_string<> does. The >only difference between the std::basic_string<> and const_string<> is that >the latter one uses small string optimization, and, I think, this is what >makes it look better. > Glad if this helps. Any plans in the future to add reverse iterator support to const_string? I wrote some code to work around the absence of const_reverse_iterator, rbegin(), and rend(), all of which would be nice to have available. Regards, Igor Kholodov http://cttl.sourceforge.net/

2 1

program_options - required (or min/max) number of occurences declaratively?
by Jonathan Graehl 27 Sep '04

27 Sep '04

I grepped through the program_options source and couldn't find anything about declaratively specifying required options (or even more specifically, min/max # of occurrences), except for positional options. I know it's possible to do variables_map::count("option-name") or if I have an impossible default value bound to an option, I could check for that (default would = option absence), but it might be nice to have "requiredness" be a declared option trait, that could show up in the option description. value<int>(&myoption)->required() or something like that - obviously min/max wouldn't make sense for scalars (I have no use for min/max personally). -Jonathan p.s. I know there is a concept in the command line parser of "value required or not" - I'm talking about an *option* being required.

4 4

Re: immutable string
by Igor Kholodov 26 Sep '04

26 Sep '04

>Igor Kholodov <C.JUMP(a)prodigy.net> wrote: > >> I am testing immutable string outside boost, using it >> as string type with common text transformation library >> (http://cttl.sourceforge.net/) It works quite well, >> about 18% speed is gained while parsing large XML >> documents (>1MB) when using const_string. > >Could you please specify the compiler and STL implementation you use? > Tested with GCC 3.4.1 (mingw) and GCC 3.2.3 on linux. Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/ Igor Kholodov http://cttl.sourceforge.net/

2 1

RSI/cw-8.3 results
by Aleksey Gurtovoy 26 Sep '04

26 Sep '04

Rene, Since you are testing with a quite different configuration than ours, could you please adjust the name of your toolset somehow so that we have the ability to mark up the failures specific to your setup? Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

CW 9.3 results (or lack thereof) - current state
by Stefan Slapeta 26 Sep '04

26 Sep '04

After one day and one night of investigation, I think (!) I've finally managed to make bjam report correct results for my regressions. As it seems, the solution is not calling cv_env.bat before running the test. This batch file is also called again before each test case and it seems that the environment gets somewhat confused then: during the execution of the cmd file the errorlevel is still set to 0 after the test case has been executed although the test case definitely reported something different. What I know for sure is that this problem occurs independent of the OS and the machine (see the temporary 'slapeta_experimental' results) and whether the test is started by regression.py or not. The results for CW-9.3 seem to be correct now and thus there should be some more failing test cases for this toolset now. As for my Intel 8.0 results, I hope there are no similar interferences because they don't run without calling iclvars.bat once. I must manually make a testcase fail to verify this (before I fixed the tss cleanup, Intel failed, too, but this wasn't reported, either). That's where I am at the moment. Cheers, Stefan

4 5