Re: [boost] Re: C++ Standards Committee upcoming meeting

[Douglas Gregor]

On Tuesday 11 March 2003 09:20 pm, Beman Dawes wrote:
> Doug Gregor is tentatively planning to host a session on the Boost
> documentation system he has been working on. No date or time yet.c
>
> Doug, how are your plans shaping up?
>
> --Beman

I'm mainly working on usability issues now, most importantly moving the tools 
into their "final" places in the Boost CVS repository (unless there are any 
objections?), teaching BBv2 to handle BoostBook documents (need... help... 
from... experts...), and getting some good reference documentation together. 

As it stands, the system itself is in good shape, and the documentation for 
libraries I've redocumented in BoostBook is quite reasonably. I still think a 
BoostBook overview/tutorial at Oxford would be beneficial.

Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Jamfile patches for Borland

[Beman Dawes]

At 08:27 PM 3/11/2003, Alisdair Meredith wrote:

>Borland fails several tests due to missing exports from  in its
>dynamic runtime library.
One question: Is there any way to work around the missing exports by adding 
some Borland specific code to boost/limits.hpp? Or would that just cause 
problems if the user happened to link staticly?

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Jamfile patches for Borland

[Beman Dawes]

At 09:07 PM 3/11/2003, Edward Diener wrote:

>While I realize it may be the only answer to the problems you mention,
>making libraries link to the static RTL where they would normally link to
>the dynamic RTL is IMHO a bad general solution. My reason for thinking 
this
>is the problems which always seem to occur when modules mix static and
>dynamic RTL routines in their linkage to other libraries. I can't prove
>this always causes problems but I have seen where using either all
>dynamic RTL or
>all static RTL when creating an executable and accompanying libraries is
>always a safe run-time solution, at least as far as reusability of the 
RTL
>is concerned.

While I understand this argument against "making libraries link to the 
static RTL where they would normally link to the dynamic RTL", the patch 
Alisdair provided doesn't alter any object libraries. It affects regression 
tests only, or am I missing something?

We have a similar situation with some other compilers. Metrowerks only 
fully supports locales with static linking, for example.

As a workaround, I'm inclined to accept the patch if it improves the test 
results, although I'd like to hear from John Maddock or others who are 
familiar with Borland's idiosyncrasies.

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Spirit and regression tests

[Beman Dawes]

At 07:07 PM 3/11/2003, Alisdair Meredith wrote:

>Is there any reason the Spirit tests are not integrated into the
>regression suite at the moment?
Too much for 1.30.0. The same applies to Boost.Python.

As soon as 1.30.0 ships we need to review a bunch of operational issues, 
including regression tests, to see where to go from here.

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: C++ Standards Committee upcoming meeting

[Beman Dawes]

At 07:12 PM 3/11/2003, Dietmar Kuehl wrote:

>Beman Dawes wrote:
>> The C++ Standards Committee will be meeting in Oxford, UK, April 7th
>> through 11th. As always, Boosters are welcome to attend as "technical
>> experts" - See http://www.boost.org/more/cpp_committee_meetings.html.
>
>Is there going to be general Boost meeting on Sunday something like this?
>At the last meetings there always was some kind of Boost meeting, at 
least
>for meeting Boosters in person.

Doug Gregor is tentatively planning to host a session on the Boost 
documentation system he has been working on. No date or time yet.c

Doug, how are your plans shaping up?

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Jamfile patches for Borland

[Fernando Cacciola]

"Alisdair Meredith" <[EMAIL PROTECTED]> escribió en el
mensaje news:[EMAIL PROTECTED]
> Borland fails several tests due to missing exports from  in its
> dynamic runtime library.
>
> The following two patches will use static linking on the problem
> libraries (for borland only)
>
I'm not sure if this is correct because the problem is not with boost but
with STLPort numeric_limits<> as shipped with BCB6.
(I reported this before).
The problem I see is that the test will now pass but becasue of a particular
condition (the static RTL).
As a boost user, I wouldn't expect a 'Passed' to require something which is
not explicit in the regression results and which is not very common.
It wouldn't be so much of a problem, IMHO, if the status tables contained an
additional column showing particular uncommon constrians.

Fernando Cacciola




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] token_iterator: Feature request: return refernce totoken_function

[Joe Gottman]

   I would like to suggest a change to token_iterator.hpp.  I need my
token_iterator's token_function to be able to accumulate state.  Therefore,
I would like to add the following public method to  class
boost::detail::tokenizer_policy :

const TokenizerFunc &func() const {return func_;}

Note that since the TokenizerFunc is owned by the token_iterator, there is
no chance of losing information if the token_iterator is copied inside some
algorithm. Also,  because this function returns a const reference to the
TokenizerFunc, and both reset() and operator() are non-const member
functions of TokenizerFunc, the user will not be able to call either reset()
or operator() on the token_function using this method.   The only use for
func() will be to get public state information out of the token_function,
which is precisely what I need.

Joe Gottman



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Jamfile patches for Borland

[Edward Diener]

While I realize it may be the only answer to the problems you mention,
making libraries link to the static RTL where they would normally link to
the dynamic RTL is IMHO a bad general solution. My reason for thinking this
is the problems which always seem to occur when modules mix static and
dynamic RTL routines in their linkage to other libraries. I can't prove this
always causes problems but I have seen where using either all dynamic RTL or
all static RTL when creating an executable and accompanying libraries is
always a safe run-time solution, at least as far as reusability of the RTL
is concerned.

Alisdair Meredith wrote:
> Borland fails several tests due to missing exports from  in
> its
> dynamic runtime library.
>
> The following two patches will use static linking on the problem
> libraries (for borland only) snip...



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Jamfile patches for Borland

[Alisdair Meredith]

Borland fails several tests due to missing exports from  in its
dynamic runtime library.

The following two patches will use static linking on the problem
libraries (for borland only)


BOOST_ROOT/status jamfile for config/limits test

cvs diff Jamfile (in directory C:\Projects\3rdParty\boost\status)
Index: Jamfile
===
RCS file: /cvsroot/boost/boost/status/Jamfile,v
retrieving revision 1.106
diff -r1.106 Jamfile
30a31
> subinclude libs/spirit/test ;# test-suite spirit
48,49c49,56
<[ run libs/config/test/config_info.cpp : : :
always_show_run_output ]
<[ run libs/config/test/limits_test.cpp
../libs/test/build/boost_test_exec_monitor ]
---
>   
>   [ run libs/config/test/config_info.cpp : : : 
> always_show_run_output ]
>   [ run libs/config/test/limits_test.cpp 
> ../libs/test/build/boost_test_exec_monitor 
>   : #args
>   : #input-files
>   : <*>static # uses limits; borland toolset 
> doesn't have a complete limits in the dynamic library
>   ]


Also, numeric/interval/test/jamfile

cvs diff Jamfile (in directory
C:\Projects\3rdParty\boost\libs\numeric\interval\test\)
Index: Jamfile
===
RCS file: /cvsroot/boost/boost/libs/numeric/interval/test/Jamfile,v
retrieving revision 1.2
diff -r1.2 Jamfile
17,23c17,57
< [ run libs/numeric/interval/test/add.cpp  ]
< [ run libs/numeric/interval/test/det.cpp  ]
< [ run libs/numeric/interval/test/fmod.cpp ]
< [ run libs/numeric/interval/test/mul.cpp  ]
< [ run libs/numeric/interval/test/overflow.cpp ]
< [ run libs/numeric/interval/test/pi.cpp   ]
< [ run libs/numeric/interval/test/pow.cpp  ]
---
> [ run libs/numeric/interval/test/add.cpp
> : #args
> : #input-files
> : <*>static # uses limits; borland toolset doesn't 
> have a complete limits in the dynamic library
> ]
> 
> [ run libs/numeric/interval/test/det.cpp  
> : #args
> : #input-files
> : <*>static # uses limits; borland toolset doesn't 
> have a complete limits in the dynamic library
> ]
> 
> [ run libs/numeric/interval/test/fmod.cpp 
> : #args
> : #input-files
> : <*>static # uses limits; borland toolset doesn't 
> have a complete limits in the dynamic library
> ]
> 
> [ run libs/numeric/interval/test/mul.cpp  
> : #args
> : #input-files
> : <*>static # uses limits; borland toolset doesn't 
> have a complete limits in the dynamic library
> ]
> 
> [ run libs/numeric/interval/test/overflow.cpp 
> : #args
> : #input-files
> : <*>static # uses limits; borland toolset doesn't 
> have a complete limits in the dynamic library
> ]
> 
> [ run libs/numeric/interval/test/pi.cpp   
> : #args
> : #input-files
> : <*>static # uses limits; borland toolset doesn't 
> have a complete limits in the dynamic library
> ]
> 
> [ run libs/numeric/interval/test/pow.cpp  
> : #args
> : #input-files
> : <*>static # uses limits; borland toolset doesn't 
> have a complete limits in the dynamic library
> ]
26c60,65
< ../../../test/build/boost_test_exec_monitor ]
---
>   ../../../test/build/boost_test_exec_monitor 
> : #args
> : #input-files
> : <*>static # uses limits; borland toolset doesn't 
> have a complete limits in the dynamic library
> ]
> 
28c67,72
< ../../../test/build/boost_test_exec_monitor ]
---
>   ../../../test/build/boost_test_exec_monitor 
> : #args
> : #input-files
> : <*>static # uses limits; borland toolset doesn't 
> have a complete limits in the dynamic library
> ]
> 
30c74,79
< ../../../test/build/boost_test_exec_monitor ]
---
>   ../../../test/build/boost_test_exec_monitor 
> : #args
> : #input-files
> : <*>static # uses limits; borland toolset doesn't 
> have a complete limits in the dynamic library
> ]
> 
32c81,85
< ../../../test/build/boost_test_exec_monitor ]
---
>   ../../../test/build/boost_test_exec_monitor 
> : #args
> : #input-files
> : <*>static # uses limits; borland toolset doesn't 
> have a complete limits in the dynamic library
> ]


-- 
AlisdairM

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Re: possible addition to operators library

[Daniel Frey]

On Tue, 11 Mar 2003 12:22:19 +0100, Sam Partington wrote:

> As for the issue below, I also have no idea how to go about
> automatically selecting either method.  Plus I think this might
> introduce complexities which make the compiler's job that much harder to
> optimise.  Could well be wrong on that though.

Optimization won't bother me that much as it should all be compile-time
magic. It still has to be verified but before that, we need something
that we can verify. :)

> Essentially I think the options are to
> 
> - document its unusual behaviour in the presence of other conversion
> operators
> - use the private operator int method.
> 
> So if we take the plusses and minuses for each method:
> 
> safe-bool:
> + obvious error messages (see list of error messages at end)

This is from the "convenience" section IMHO. But it's important.

> - problems with classes that provide other user-defined conversions
> operators.

A "technical" thing. The question is, what do we prefer? I personally
prefer a technical advantage as it creates safer overall code. I am used
to work with several people in a large code-base and in my experience
it's always a very helpful thing if the interface of your code leads to
compile-errors when misused. Documentation will help you to reject the
responsibility - it won't help you to get the job done. If the compiler
rejects your code and the error message itself is anything but clear, you
are at least forced to work on it. That's not nice in the moment you are
faced with it, but in the long term it pays.

The alternative (keep the safe-bool and document it) leads to hidden bugs
that are IMHO hard to find. Remember that we have a very close view to a
tiny code fraction. Imagine it to be the part of a 100.000 lines project.
It compiles without a warning but calls operator int() instead of
operator!().

> So it comes down to two things,
> 
> 1) How important is it to have legible diagnostics? 2) How important is
> it to behave properly with other user-defined conversions?

The latter will probably be the result of a colleague adding operator
int() 6 month after you developed the class. What formerly worked
correctly turns into a bug silently and you will - depening on your
definition of operator int() not necessarily notice it in the beginning.
Maybe - and we all know Murphy - it provides the correct semantics in
99.9% of all cases. That's a nice bug to trace, isn't it?

But these are just my personal opinions, other opinions welcome.

> My gut feeling is that I'd rather have the safe-bool method, but I
> suspect my judgement is coloured by two things: - I never use user
> defined conversion operators - I use MSVC 6 as my main compiler, and not
> being able to do if (a && !a) would bother me.

The VC issue bothers me, as I don't think I fully understand what exactly
happens. Doesn't the compiler give any additional messages to explain
what exactly is ambiguous for operator&&? Does anyone know this problem
and has a work-around?

Regards, Daniel

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: C++ Standards Committee upcoming meeting

[Dietmar Kuehl]

Beman Dawes wrote:
> The C++ Standards Committee will be meeting in Oxford, UK, April 7th
> through 11th. As always, Boosters are welcome to attend as "technical
> experts" - See http://www.boost.org/more/cpp_committee_meetings.html.

Is there going to be general Boost meeting on Sunday something like this?
At the last meetings there always was some kind of Boost meeting, at least
for meeting Boosters in person.
-- 
 
Phaidros eaSE - Easy Software Engineering: 

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Bad links on regression log cs-win32-RC_1_30_0.html

[Beman Dawes]

At 06:31 PM 3/11/2003, Beman Dawes wrote:

>At 03:57 PM 3/11/2003, Alisdair Meredith wrote:
>
> >All the links to warnings/fails point to the d: drive and so are a
> >little inaccessible right now 
>
>Argh! I've been fooling around with the setup to allow running tests on
>both the main trunk and the release candidate, and that is clearly having 

>some unexpected fallout.
>
>No promises as to when it will be fixed, but we really do need to address 

>linking problems permanently. Perhaps by pointing the links at CVS.

Fixed. Turned out to be a much simpler problem than I expected. Should be 
OK now.

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Spirit and regression tests

[Alisdair Meredith]

Is there any reason the Spirit tests are not integrated into the
regression suite at the moment?

I just updated status\jamfile to test locally and the only problem I had
was an MT test running away for a VC7 build

diff below

===
RCS file: /cvsroot/boost/boost/status/Jamfile,v
retrieving revision 1.106
diff -r1.106 Jamfile
30a31
> subinclude libs/spirit/test ;# test-suite spirit

-- 
AlisdairM
Team Thai Kingdom

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] I/O library formal review

[Dietmar Kuehl]

Having implemented [most of] the IOStreams library I think I can comment
on the array streams stuff:

- Stream buffers normally cannot be copied and I don't see any reason
  why this should be different for array streams. The only good this
  copy constructor would is to allow returning this kind of stream
  buffer from a function and I cannot see any argument in favour of
  this... (if there are good arguments for this, they are lacking from
  the rationale).

- I could imagine that constructor taking a sequence as argument could
  be put to good use: Essentially, I cannot see any approach to
  preinitialize the internal array for some output and I would prefer
  this approach over the non-const iterators to initialize the get area.

- The class is definitely lacking access to the end of the put area:
  there is no way to tell how many characters were written to the put
  area, rendering the class pretty useless for certain applications I
  have in mind for it (like, eg. converting some object to a string).
  Similiarily, it is assumed that the get area is made up of the whole
  array which is also a serious restriction: it is more likely that eg.
  a character sequence representing an object only fills a portion of
  the array.

- As is, the class support both input and output at the same time. This
  seems to indicate that the last get position should be coupled with
  the last position it was written to. Alternatively, the object could
  be constructed taking an std::ios_base::openmode parameter as
  argument to setup only the corresponding buffers. I don't really like
  the idea of having a read/write array where there is no control which
  characters are initialized and which are not when reading.

- For the "basic_wrapping_ios<...>" the "base_from_member"
  base object should probably be virtual: the way it is, the basic_ios
  is still initialized prior to the stream buffer. The intention of
  factoring the stream buffer into a base class is, however, to
  initialize it prior the ios subobject which is a virtual base of the
  stream objects and thus initialized prior to all non-virtual bases.

I think it is reasonable to incorporate a stream buffer like this into
the Boost library. However, I have the feeling that the current proposal
actually has some serious flaws. That is, I would be in favour of the
library if the points I made above are addressed (where addressing
either means changing the details into the mentioned direction or
providing a sound rationale why it should stay the way it is).

I read the documentation of the and the sources of the arary_stream
classes but haven't tried to use or run the code.
-- 
 
Phaidros eaSE - Easy Software Engineering: 

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] date_time on gcc linux

[Jeff Garland]

M. Andre wrote:

>So I guess the config isn't included in all files? According to 
the docs
>#include  is an 
>available header file with definitions without io.

Looks like I introduced a bug here.  Will fix.  

Thx,

Jeff








___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Bad links on regression log cs-win32-RC_1_30_0.html

[Beman Dawes]

At 03:57 PM 3/11/2003, Alisdair Meredith wrote:

>All the links to warnings/fails point to the d: drive and so are a
>little inaccessible right now 
Argh! I've been fooling around with the setup to allow running tests on 
both the main trunk and the release candidate, and that is clearly having 
some unexpected fallout.

No promises as to when it will be fixed, but we really do need to address 
linking problems permanently. Perhaps by pointing the links at CVS.

>Also, is there any way to get the 'differences emphasised' view?  Often
>a single test starts passing/failing and it is very hard to locate which
>one has changed, especially without the previous test results for
>reference.
I know! That's my favorite too. But the procedure for generating it is a 
horrible hack done just to prove the concept. The permanent solution would 
be to keep the information in the .xml file. No idea when that might be 
implemented, however:-(

It would be particularly nice to be able to see history, but that may be a 
dream for the distant future.

Thanks,

--Beman 

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] date_time on gcc linux

[Michel André]

Hello!

When compiling the following program on gcc 3.2 on a Linux box aginst the
boost in the CVS repository it fails

#include 
int main(int argc, char** argv)  {}

with

[EMAIL PROTECTED] michel]$ g++ i.c -I"/home/michel/boost/work"
In file included from
/home/michel/boost/work/boost/date_time/posix_time/posix_time_types.hpp:9,
 from i.c:2:
/home/michel/boost/work/boost/date_time/microsec_time_clock.hpp: In static
   member function `static time_type
   boost::date_time::microsec_clock::create_time(timeval*)':
/home/michel/boost/work/boost/date_time/microsec_time_clock.hpp:44: parse
error
   before `;' token

adding

#include 
#include 
int main(int argc, char** argv)  {}

or including
#include 

works.

So I guess the config isn't included in all files? According to the docs
#include  is an available
header file with definitions without io.

Regards
/Michel



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: I/O library formal review

[Gennadiy Rozental]

> * The Rationale for Array-Based Streams concludes "it may have real-life
> applications." It would be a bit more satisfying if there was at least one
> example of a real-life application.

I second this. Could anybody show an example where array_stream would be
preferable to stringstream.
In other case I do not see a reason to include this component. Maybe only as
an example in .../lib/io/example

 > * newl needs a bit more rationale. How is cout << newl different from
cout
> << '\n'? How is it better?

Maybe newl does not reset the manipulators? If it true it should be spelled
out explicitly. In any case I also like to see an example where newl is
preferable to << '\n'.

Gennadiy.



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Bidirectionnal map

[David B. Held]

"Eric Martel" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [...]
> Nearly 5 months later, did anyone work on this bimap?

I didn't. ;)

> Will it be included anytime soon in an official distribution of boost?

Not unless someone ambitious like you decides to work on it some
more. ;)

Dave




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] 1.30.0-b1: filesystem::path::swap

[Beman Dawes]

At 03:23 AM 3/10/2003, Geurt Vos wrote:
>Hi,
>Is there any reason boost::filesystem::path doesn't
>provide a swap(path &) function? If there is, I think
>the docs should explain why, but if there isn't, well,
>can it still be implemented before 1.30.0 goes gold?
Let me turn the question around and ask what your expectations would be for 
a swap member beyond what is already offered by std::swap?

No throw guarantee?

More efficient?

Or are you asking that filesystem::path satisfy more container 
requirements?

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Bidirectionnal map

[David Abrahams]

"Eric Martel" <[EMAIL PROTECTED]> writes:

> Hi,
>
> After a quick Google search, I found out that Joaquín M López, the author of
> a bidirectionnal map hosted on codeproject sent a message (Mon, 21 Oct 2002
> 21:29:18) on the boost mailing list to promote his library.  David B. Held
> replied about using his work to include the bidirectionnal map to boost, to
> avoid library proliferation.
>
> So now, here's my question :
>
> Nearly 5 months later, did anyone work on this bimap?  Will it be included
> anytime soon in an official distribution of boost?

Not unless someone requests a formal review and takes it through the
formal review process.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Meta programming 'debug' mode.

[Dirk Gerrits]

Gennaro Prota wrote:
On Tue, 11 Mar 2003 17:46:17 +0100, Dirk Gerrits
<[EMAIL PROTECTED]> wrote:


Perhaps I missed a part of the discussion, but what is wrong with Jaap's 
suggestion:

#ifdef BOOST_STATIC_NDEBUG
   #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true )
#else
   #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( B )
#endif
?


Well, considering that what we want is just a no-op, which do you
prefer?
a)  typedef ::boost::static_assert_test<
  sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( true ) >)>
BOOST_JOIN(boost_static_assert_typedef_, __LINE__);
(I've just picked up one of the implementations in static_assert.hpp,
but the others don't differ too much.)
b)  typedef void boost_static_assert_typedef;
The effect is the same.

However, (a) or BOOST_STATIC_ASSERT_IMPL( true ) avoids all of the 
(potential?) problems you are worrying about. So why do you prefer (b)?

Regards,

Dirk Gerrits

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Bad links on regression log cs-win32-RC_1_30_0.html

[Alisdair Meredith]

All the links to warnings/fails point to the d: drive and so are a
little inaccessible right now 

Also, is there any way to get the 'differences emphasised' view?  Often
a single test starts passing/failing and it is very hard to locate which
one has changed, especially without the previous test results for
reference.

-- 
AlisdairM

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Re: Re: release procedure typo(?)

[Beman Dawes]

At 12:48 PM 3/11/2003, Gennadiy Rozental wrote:
>
>> It looks pretty explicit to me.  If you think it can be improved,
>> please propose a doc patch.
>
>May be like this. See the patch attached.
Applied. Thanks!

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Meta programming 'debug' mode.

[Gennaro Prota]

On Tue, 11 Mar 2003 17:46:17 +0100, Dirk Gerrits
<[EMAIL PROTECTED]> wrote:


>> In effect I would prefer the one without __LINE__. But if any compiler
>> warns about duplicate typedefs than it's better having a single
>> version, with __LINE__, than #ifs.
>> 
>> Also I have a slight preference for using void instead of char, as
>> suggested by Greg:
>> 
>> 
>>   typedef void boost_static_assert_typedef
>
>Perhaps I missed a part of the discussion, but what is wrong with Jaap's 
>suggestion:
>
>#ifdef BOOST_STATIC_NDEBUG
> #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true )
>#else
> #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( B )
>#endif
>
>?

Well, considering that what we want is just a no-op, which do you
prefer?

a)  typedef ::boost::static_assert_test<
  sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( true ) >)>
BOOST_JOIN(boost_static_assert_typedef_, __LINE__);

(I've just picked up one of the implementations in static_assert.hpp,
but the others don't differ too much.)


b)  typedef void boost_static_assert_typedef;


As I said however, there can be compilers that warn about duplicate
typedefs like

namespace xyz {
   typedef void boost_static_assert_typedef;
   typedef void boost_static_assert_typedef;

}

(To be honest, I'm afraid some compiler even gives an error, confusing
the C rule with the C++ one. But I don't know of any (fortunately
:-)). Anyhow, let's not put the cart before the horse. If such a
compiler shows up then we'll consider using __LINE__; before that,
let's just use

  typedef void boost_static_assert_typedef


Genny.

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] I/O library formal review

[Beman Dawes]

Comments, based on reading the docs (without much background in 
understanding the ins and outs of stream buffers):

* Needs a libs/io/test/Jamfile, using the subinclude approach from the main 
status/Jamfile.

* The Stream-buffer-wrapping Streams Rationale section (there is no 
Introduction section) doesn't really answer some very important questions 
like "Why are these facilities provided?", "What are their uses?", "What do 
they do better than the Standard Library's current classes?"

* The Rationale for Array-Based Streams concludes "it may have real-life 
applications." It would be a bit more satisfying if there was at least one 
example of a real-life application.

* newl needs a bit more rationale. How is cout << newl different from cout 
<< '\n'? How is it better?

It is hard to form an opinion about the library without better rationale.

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Bidirectionnal map

[Eric Martel]

Hi,

After a quick Google search, I found out that Joaquín M López, the author of
a bidirectionnal map hosted on codeproject sent a message (Mon, 21 Oct 2002
21:29:18) on the boost mailing list to promote his library.  David B. Held
replied about using his work to include the bidirectionnal map to boost, to
avoid library proliferation.

So now, here's my question :

Nearly 5 months later, did anyone work on this bimap?  Will it be included
anytime soon in an official distribution of boost?

Thanks a lot for your time

Cheers,

Eric



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Darwin regression tests

[Chris Little]

on 3/11/03 11:45 AM, Beman Dawes at [EMAIL PROTECTED] wrote:

> At 11:01 AM 3/11/2003, Markus Schöpflin wrote:
> 
>> The must be something wrong with the current darwin regression tests,
>> AFAICT. I just completed a full regression run of the latest RC
>> version and I get far lower failure rates that the current regression
>> results indicate (9% failures instead of 45%).
> 
> My guess is that there was a problem with the configuration. Since the
> command lines reported by both sets of tests are the same, it may have been
> fixed but hasn't been reflected in the results because it wasn't a fix in a
> dependent file, so bjam never recompiled those tests. Or something like
> that.
> 
> The solution would be to clear out the regression target directories (or
> maybe just rerun with the -a switch.) Experiment with, say, just array1 to
> verify that takes care of the problem.
> 
> A 9% failure rate is much more what would be expected for GCC based
> compilers.

I emailed Marshall about this a couple of weeks ago.  There is something
wrong with the cs-Darwin.html file.  If gcc toolset failed a test then that
test is marked failed for the darwin toolset too but the fail on the darwin
toolset isn't an html link.  Also of the gcc toolsets tests are marked as
Fail but they aren't links either.

I agree with you that Marshall needs clean the target directory and rerun
the regression.

Chris

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Re: Re: release procedure typo(?)

[Gennadiy Rozental]

> It looks pretty explicit to me.  If you think it can be improved,
> please propose a doc patch.

May be like this. See the patch attached.

Gennadiy.



begin 666 release_procedures.diff
[EMAIL PROTECTED](')E;&5A6-O9&4N
M:'!P(%MM97)G92!C:&%N9V5S(&9R;[EMAIL PROTECTED]')U;[EMAIL PROTECTED]&[EMAIL 
PROTECTED])A;F-H70T**R @
M(" \=6P^#0HK(" @(" @/&QI/D9I>&5D(&-O9&4@:7,@8V]M;6ET=&5D('1O
M(&UA:[EMAIL PROTECTED])A;F-H#0HK(" @(" @/"]L:3X-"BL@(" @(" \;&D^4W=I=&-H
M('1O('1H92!R96QE87-E(&-A;F1I9&%T92!B<[EMAIL PROTECTED]"BL@(" @(" @(" \
M+W!R93YC=G,@=7!D871E("UR(%)#7S%?,C9?,CPO<')E/@T**R @(" @(#PO
M;&D^#0HK(" @(" @/&QI/DUE6-O9&4N:'!P#0H@("TM)F=T.R!20U,@
[EMAIL PROTECTED]6-O
M9&4N:'!P#0HM#0HM8W9S(&-O;6UI=" M;2 F<75O=#M-97)[EMAIL PROTECTED](&9O
MB!F6-O9&4N:'!P#0HM8W9S('5P9&%T92 M02!;[EMAIL PROTECTED]:R!T;R!M86EN('1R
M=6YK70T*+6-V6-O9&4N:'!P(%MT86<@;F5W(&UE6-O9&4N:'!P/"]Phttp://lists.boost.org/mailman/listinfo.cgi/boost

[boost] [BGL] subgraph isomorphism algorithm

[vladimir josef sykora]

For those of you interested in subgraph isomorphism, I put a raw version of
Ullmann's algorithm at http://groups.yahoo.com/group/boost/files/ullmann.hpp
It uses BGL's interface.
Regards,

--

vladimir josef sykora
morphochem AG
gmunder str. 37-37a
81379 muenchen

tel. ++49-89-78005-0
fax  ++49-89-78005-555

[EMAIL PROTECTED]
http://www.morphochem.de




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Re: release procedure typo(?)

[David Abrahams]

"Gennadiy Rozental" <[EMAIL PROTECTED]> writes:

> I got it now. May be we could spell out explicitly what we are merging into
> branch: namely the deference between merged_to_RC_whatever and HEAD tags.
> Not all that fluent with cvs flags.



> A! I missed -F flag. Maybe we should spell it out explicitly?

It looks pretty explicit to me.  If you think it can be improved,
please propose a doc patch.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Meta programming 'debug' mode.

[Dirk Gerrits]

Gennaro Prota wrote:
On Mon, 10 Mar 2003 20:41:26 -0800, "Jaap Suter"
<[EMAIL PROTECTED]> wrote:

#define BOOST_STATIC_ASSERT(c)  \
  typedef char boost_static_assert_typedef
When using several asserts in the same context some compilers could
complain about the duplicate typedef; if so pasting the expansion of
__LINE__ shouldn't be that expensive either.
That seems indeed the best solution to me (with the __LINE__ included) as
most of the time is spend in calculations for the actual expression.


In effect I would prefer the one without __LINE__. But if any compiler
warns about duplicate typedefs than it's better having a single
version, with __LINE__, than #ifs.
Also I have a slight preference for using void instead of char, as
suggested by Greg:
  typedef void boost_static_assert_typedef
Perhaps I missed a part of the discussion, but what is wrong with Jaap's 
suggestion:

#ifdef BOOST_STATIC_NDEBUG
#define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true )
#else
#define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( B )
#endif
?

But all this conjectures
should be backed up by some measurement. Jaap?
Agreed. I will do some measurements this week and report back in a few days.


Nice :-)
Indeed. :)

Dirk Gerrits

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Darwin regression tests

[Beman Dawes]

At 11:01 AM 3/11/2003, Markus Schöpflin wrote:

>The must be something wrong with the current darwin regression tests,
>AFAICT. I just completed a full regression run of the latest RC
>version and I get far lower failure rates that the current regression
>results indicate (9% failures instead of 45%).
My guess is that there was a problem with the configuration. Since the 
command lines reported by both sets of tests are the same, it may have been 
fixed but hasn't been reflected in the results because it wasn't a fix in a 
dependent file, so bjam never recompiled those tests. Or something like 
that.

The solution would be to clear out the regression target directories (or 
maybe just rerun with the -a switch.) Experiment with, say, just array1 to 
verify that takes care of the problem.

A 9% failure rate is much more what would be expected for GCC based 
compilers.

>I uploaded the results to the regression tests directory, they can be
>found here:
>http://boost.sourceforge.net/regression-logs/cs-Darwin-RC_1_30_0.html
>
>I don't know the exact version of MacOS installed, but I would guess
>it's the latest one available.
Thanks,

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Re: release procedure typo(?)

[Gennadiy Rozental]

> > 1. I committed it in main trunk: cvs commit abc.cpp
> > 2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure
> > right now)
> > 3. I merge it to the release branch
>
> No, you got 2 and 3 reversed, and you only do the tagging after
> switching back to the trunk.

I got it now. May be we could spell out explicitly what we are merging into
branch: namely the deference between merged_to_RC_whatever and HEAD tags.
Not all that fluent with cvs flags.

> > Additionally if I need to change it again, before step 2  I will need to
> > untag it: cvs tag -d merged_to_RC_whatever,
>
> Absolutely not.

A! I missed -F flag. Maybe we should spell it out explicitly?

Gennadiy.



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Boost I/O Library Review (Ed B.)

[Ed Brey]

First, a reminder that today is the last day for sumbitting a review for the update to 
the I/O library.

This is my review of the I/O library, which is separate from my role as review manager.

I vote that the library update be accepted into boost.  I examined the documentation 
and code.  The new manipulaters will certainly be handy.  The streambuf and array 
stream components will be used less often, but have their place.  Following are 
suggestions for improvement:


Code/design suggestions:

array_stream.hpp:

- In the basic_array_stream classes, the char_type and traits_type definitions seem to 
duplicate those provided by the basic_wrapping_istream base class.

- The functions in the three basic_array_stream classes could be factored into a 
single base class to avoid copied code.

- Why stop at stream buffers?  Why not define array_stream templates?


Specific documentation suggestions:

streambuf_wrapping:

- Provide a short hello world example at the beginning of the documentation showing 
how the library is useful.  Since I haven't had reason to explicitly work with stream 
buffers for many months, it was very confusing coming on cold to this library.  For 
the example, the reader should be able to deduce how the library makes his life easier 
versus not using it.  Clearly, your array stream class would serve as a good example, 
but it needs to be digested down to a one minute tutorial version for the 
streambuf_wrapping documentation.


array_stream:

- Here again, a motivating example would be a good start to the documentation, 
especially if there is an array_stream class ready to use out-of-the-box.  An example 
could be formatting I/O for output to a fixed-character device such as an LCD.


iomanip:

- skipl:
Rationale: a dual to boost::io::newl -> Rationale: a counterpart to newl


General documentation comments:

- Remove references to namespace boost:io, except once in the documentation header.


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Darwin regression tests

[Markus Schöpflin]

The must be something wrong with the current darwin regression tests, 
AFAICT. I just completed a full regression run of the latest RC 
version and I get far lower failure rates that the current regression 
results indicate (9% failures instead of 45%).

I uploaded the results to the regression tests directory, they can be 
found here: 
http://boost.sourceforge.net/regression-logs/cs-Darwin-RC_1_30_0.html

I don't know the exact version of MacOS installed, but I would guess 
it's the latest one available.

Markus

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: release procedure typo(?)

[Beman Dawes]

At 10:36 AM 3/11/2003, Gennadiy Rozental wrote:
>> > P.S. Could you, please, clarify for me again what is the purpose of
>this
>> > tag? How does it related to the fixes I made in trunk after branch is
>> > created?
>>
>> The tag marks the last trunk revision that has been merged into the
>> branch, so that when you do a merge to the branch you can always do
>>
>> cvs up -jmerged_to_RC_whatever -jHEAD
>>
>> Then when you switch back to the trunk (HEAD) you move the
>> merged_to_RC_whatever tag to point at the HEAD again.
>
>Imagine I change the file abc.cpp.
>
>1. I commited it im main trank: cvs commit abc.cpp
>2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure
>right now)
No! abc.cpp will already have been tagged with merged_to_RC_whatever by the 
release manager (or by you, if you had previously applied a fix according 
to the procedure.)

>3. I merge it to the release branch
>
>Additionally if I need to change it again, before step 2  Iwill nedd to
>untag it: cvs tag -d merged_to_RC_whatever, which is also is not in 
release
>procedure right now.
>
>Did I get it correct?

No. AFAIK, the release procedure is correct as written, modulo typos. I've 
been using the WinCVS version repeatedly for the better part of a week now, 
and it is working like a charm. Much easier than previous procedures.

Please look at the procedure again and see if it is still unclear.

Thanks,

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: release procedure typo(?)

[David Abrahams]

"Gennadiy Rozental" <[EMAIL PROTECTED]> writes:

>> > P.S. Could you, please, clarify for me again what is the purpose of this
>> > tag? How does it related to the fixes I made in trunk after branch is
>> > created?
>>
>> The tag marks the last trunk revision that has been merged into the
>> branch, so that when you do a merge to the branch you can always do
>>
>> cvs up -jmerged_to_RC_whatever -jHEAD
>>
>> Then when you switch back to the trunk (HEAD) you move the
>> merged_to_RC_whatever tag to point at the HEAD again.
>
> Imagine I change the file abc.cpp.
>
> 1. I commited it im main trank: cvs commit abc.cpp
> 2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure
> right now)
> 3. I merge it to the release branch

No, you got 2 and 3 reversed, and you only do the tagging after
switching back to the trunk.

> Additionally if I need to change it again, before step 2  Iwill nedd to
> untag it: cvs tag -d merged_to_RC_whatever, 

Absolutely not.

> which is also is not in release procedure right now.
>
> Did I get it correct?

I guess not.  The procedures as written are absolutely perfect.  Why
second-guess them?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Meta programming 'debug' mode.

[Gennaro Prota]

On Mon, 10 Mar 2003 20:41:26 -0800, "Jaap Suter"
<[EMAIL PROTECTED]> wrote:

>> #define BOOST_STATIC_ASSERT(c)  \
>>typedef char boost_static_assert_typedef
>>
>> When using several asserts in the same context some compilers could
>> complain about the duplicate typedef; if so pasting the expansion of
>> __LINE__ shouldn't be that expensive either.
>
>That seems indeed the best solution to me (with the __LINE__ included) as
>most of the time is spend in calculations for the actual expression.

In effect I would prefer the one without __LINE__. But if any compiler
warns about duplicate typedefs than it's better having a single
version, with __LINE__, than #ifs.

Also I have a slight preference for using void instead of char, as
suggested by Greg:


  typedef void boost_static_assert_typedef


>> But all this conjectures
>> should be backed up by some measurement. Jaap?
>
>Agreed. I will do some measurements this week and report back in a few days.

Nice :-)


Genny.

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: release procedure typo(?)

[Gennadiy Rozental]

> > P.S. Could you, please, clarify for me again what is the purpose of this
> > tag? How does it related to the fixes I made in trunk after branch is
> > created?
>
> The tag marks the last trunk revision that has been merged into the
> branch, so that when you do a merge to the branch you can always do
>
> cvs up -jmerged_to_RC_whatever -jHEAD
>
> Then when you switch back to the trunk (HEAD) you move the
> merged_to_RC_whatever tag to point at the HEAD again.

Imagine I change the file abc.cpp.

1. I commited it im main trank: cvs commit abc.cpp
2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure
right now)
3. I merge it to the release branch

Additionally if I need to change it again, before step 2  Iwill nedd to
untag it: cvs tag -d merged_to_RC_whatever, which is also is not in release
procedure right now.

Did I get it correct?

Gennadiy.




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Increase in binary size

[Douglas Gregor]

On Monday 03 March 2003 10:03 am, Lars Gullik Bjønnes wrote:
> I see that when upgrading LyX to use the upcomming 1.30.0 release
> instead of the 1.29.0 release our binary size increases by more than
> 125kB...
>
> I have not tried to figure out where that increase comes from, but the
> usual suspecs are regex, function and signal since that is what we use
> most.

There haven't been many changes in function or signals that would increase 
binary size. However, I _will_ look into it, I've just been quite busy 
recently and haven't had the time.

Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Beta boost+spirit - VC7.1 "buffer overrun" error

[Carl Daniel]

Joel de Guzman wrote:
> What compiler errors are you getting? If it's the attached "Buffer
> overrun detected!" error, then that's clearly a VC7.1 compiler bug.

I was able to reproduce Viv's problem using VC7.1 RC3 and the Boost 1.30.0
beta 1 release.  It appears that the buffer overrun is related to expression
complexity during template instantiation.  In Viv's example, if you remove
any one of the several pairs of bind() calls from the definition of field,
the error doesn't occur.

My guess is that it's realted to the mangled name of the type that's being
formed by such expressions - these names can get mind=numbingly long.

This bug has been reported to MS, but it's probably too late for it to be
fixed in VC7.1 RTM, so all Boosters should be aware of it - if you see
buffer overruns from cl.exe, look to refactor or simplify.

-cd



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] release procedure typo(?)

[Martin Wille]

Gennadiy Rozental wrote:
Hi, Beman

In examples for release procedure you are using: "merged_to_1_26_2". While
in "Release Procedures for the Release Manager" section you are mention:
"merged_to_RC_n_n_n". What is correct?
We have no "merged_to_1_30_0" tag in the CVS but a
"merged_to_RC_1_30_0" tag, so, the latter is correct.
I ran into the same thing two days ago and posted a patch to the
document here.
Regards,
m
http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] release procedure typo(?)

[Beman Dawes]

At 12:23 AM 3/11/2003, Gennadiy Rozental wrote:
>Hi, Beman
>
>In examples for release procedure you are using: "merged_to_1_26_2". 
While
>in "Release Procedures for the Release Manager" section you are mention:
>"merged_to_RC_n_n_n". What is correct?

Should read "merged_to_RC_1_26_2". Martin Wille already submitted a patch.

>P.S. Could you, please, clarify for me again what is the purpose of this
>tag? How does it related to the fixes I made in trunk after branch is
>created?
I've added a FAQ to the page:

What is the purpose of the merged_to_RC_n_n_n tag?

This tag allows multiple merges from the main trunk to the release 
candidate branch. Without it, merging an initial main trunk fix into the 
release candidate branch would work, but merging a second fix from main 
trunk to release candidate branch would result in a merge conflict. 
Although this procedure seems convoluted, it works much better in practice 
than several prior procedures we tried.

HTH,

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] fixes to release_procedures.htm

[Beman Dawes]

At 04:16 AM 3/10/2003, Martin Wille wrote:

>the attached patch fixes two typos in the release procedures document.

Fixed. Thanks!

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] release procedure typo(?)

[David Abrahams]

"Gennadiy Rozental" <[EMAIL PROTECTED]> writes:

> P.S. Could you, please, clarify for me again what is the purpose of this
> tag? How does it related to the fixes I made in trunk after branch is
> created?

The tag marks the last trunk revision that has been merged into the
branch, so that when you do a merge to the branch you can always do 

cvs up -jmerged_to_RC_whatever -jHEAD

Then when you switch back to the trunk (HEAD) you move the
merged_to_RC_whatever tag to point at the HEAD again.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] boost/limits.hpp & Itanium2 & RC_1_30_0

[Beman Dawes]

At 08:12 PM 3/10/2003, David Abrahams wrote:

>> OK to check this into the RC_1_30_0 branch?
>
>Go for it!  You don't need to ask permission to make stuff work.
>(it's nice to notify the list when you do, though)
It helps me too; I'm trying to track outstanding issues with RC_1_30_0, so 
it helps to know when an issue is closed.

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Make boost work better when BOOST_NO_WREGEXis defined

[Beman Dawes]

At 03:37 AM 3/11/2003, Lars Gullik Bjønnes wrote:

>Who should I send this to, to make someone have a look at it?

Posting it here is fine.

I haven't seen any postings from John Maddock in several days; I'm guessing 
he has taken some time off after his push last week ago finishing the final 
regex and type traits proposals for the Library TR.

If he doesn't respond before 1.30.0 closes for patches, someone else will 
look at the patch and make the decision.

In the meantime, could you please post the patch as an attachment? The 
spacing got all screw up in the inline version.

Thanks,

--Beman 

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] [PATCH for 1.30.0] Make boost work better whenBOOST_NO_WREGEXis defined

[John Maddock]

> Who should I send this to, to make someone have a look at it?

Probably me, but I'm tied up right now, will be back around here once I get
cvs etc working on my new PC.

John.


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] tokenizer: Feature request: keep quotes with escaped_list_separator

[Roland Richter]

Dear all,

 I need to split a string into tokens, and split the
 resulting tokens again in a second pass. Currently,
 I do this with boost::tokenizer initialized
 with an escaped_list_separator.
 The problem is that all the quote characters are
 swallowed during the first pass, which makes
 things rather ugly at the second time. One
 workaround I thought of, namely to use two different
 (sets of) quote characters, is inacceptable in our
 case. Are there any other?
 If not, it would be rather nice to have a switch
 to tell escaped_list_separator whether it should
 drop quotes or keep quotes.
- Roland

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Beta boost+spirit - VC7.1 "buffer overrun" error

[Joel de Guzman]

vc wrote:
>> Hi all,
>> 
>> I am using the VS .NET 2003 (VC7.1) on Windows 2000 and I'm porting
>> a Linux application on Windows. I got the BETA sources
>> (http://boost.sourceforge.net/regression-logs/boost_1_30_0_b1.zip)
>> and I give it a try, but the compiler stops with the "Buffer overrun
>> detected!" error (see Vccrash.jpg attached).
>> 
>> For being easier to duplicate, attached is also a sample (see
>> spirit-problem.cc) that has this behavior.
>> 
>> I have to mention that on 2003.02.18 I took the spirit sources from
>> the cvs, and this sample compiles
>> fine with those sources. That is why I assume that this is a new
>> added problem into the spirit sources.
>> As a summary, when using:
>> - version 1.29 of boost and cvs sources of spirit from 2003.02.18 =>
>> the sample compiles ok
>> - boost 1.30 beta (boost and spirit) => the sample is not compiling
>> ok 
>> 
>> Can you tell me please if this is indeed a spirit problem or not?

What compiler errors are you getting? If it's the attached "Buffer overrun 
detected!" error, then that's clearly a VC7.1 compiler bug.

Anyway, since this is clearly a Spirit support related question, please
post your reply to Spirit-general mailing list:
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spirit-general

Let's continue our discussion there.

See 'ya,
-- 
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: possible addition to operators library

[Sam Partington]

Thanks for your comments Daniel, I will update the docs with a better
rationale and post the patch soon.

As for the issue below, I also have no idea how to go about automatically
selecting either method.  Plus I think this might introduce complexities
which make the compiler's job that much harder to optimise.  Could well be
wrong on that though.

Essentially I think the options are to

- document its unusual behaviour in the presence of other conversion
operators
- use the private operator int method.

So if we take the plusses and minuses for each method:

safe-bool:
+ obvious error messages (see list of error messages at end)
- problems with classes that provide other user-defined conversions
operators.
- requires declaration of operator! by user, which is a bit backward.

private operator int :
+ user provides operator bool, and our helper protects it from misuse, and
provides operator!
+ no clashes with other user-defined converion operators
- fails to work with if(a && func()) on MSVC 6 at least - 'operator && is
ambiguous'
- less helpful diagnostic messages.

The if (a && something) is quite a serious defect, but it compiles fine on
gcc 2.95.3.

So it comes down to two things,

1) How important is it to have legible diagnostics?
2) How important is it to behave properly with other user-defined
conversions?

My gut feeling is that I'd rather have the safe-bool method, but I suspect
my judgement is coloured by two things:
- I never use user defined conversion operators
- I use MSVC 6 as my main compiler, and not being able to do if (a && !a)
would bother me.

San


Diagonostic samples:
--

template struct
other_bool_testable : B
{
public:
operator bool() const { return !!static_cast(*this);  }
private:
typedef signed char private_number_type;
operator private_number_type() const;
};

#if defined(USE_OTHER_BOOL_TESTABLE)
class A : public other_bool_testable
#else
class A : public bool_testable
#endif
{
public:
bool operator!() const { return false;  }
};

void f(int);
void g(signed char);

void test(const A& a)
{
if (a && !a)
{
f(a);
g(a);
 }
}


MSVC 6
***

safe-bool:
 test.cpp(321) : error C2664: 'f' : cannot convert parameter 1 from 'const
class A' to 'int'
No user-defined-conversion operator available that can perform this
conversion, or the operator cannot be called

private operator :
test.cpp(319) : error C2593: 'operator &&' is ambiguous

// when the conversion is not an exact match to the private operator i.e.
int to signed char
test.cpp(347) : error C2664: 'f' : cannot convert parameter 1 from 'const
class A' to 'int'
Ambiguous user-defined-conversion

//when it is an exact match
test.cpp(322) : error C2248: 'operator`signed char'' : cannot access private
member declared in class 'other_bool_testable'
C:\Work\SS\debugger\CodeScape\CBuilder.cpp(323) : see declaration of
'operator`signed char''


gcc 2.95.3 :
*

safe-bool:

test.cpp: In function `void test(const A &)':
test.cpp:32: `const class A' used where a `int' was expected

with the private operator some_number() :

// if the private operator is not an exact match (e.g signed char to an int)
test.cpp:32: conversion from `const A' to `int' is ambiguous
test.cpp:6: candidates are:
other_bool_testable::operator bool() const
test.cpp:9:
other_bool_testable::operator signed char()
const

// if the private operator is an exact match you get
test.cpp:32: conversion from `const A' to `signed char' is ambiguous
test.cpp:6: candidates are:
other_bool_testable::operator bool() const
test.cpp:9:
other_bool_testable::operator signed char()
const
test.cpp:9: `other_bool_testable::operator
signed char() const' is private
test.cpp:35: within this context


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] When will be the next boost released?

[vc]

I just reported it.

Viv

- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, March 10, 2003 8:14 PM
Subject: Re: [boost] When will be the next boost released?


> "vc" <[EMAIL PROTECTED]> writes:
>
> >> Have you reported this to Microsoft?
> >
> > No, as the guys from spirit told me that the 1.5.1 version was
> > released before VS. NET 2003 so their code is not designed for this
> > new compiler.
>
> That doesn't matter; any "INTERNAL COMPILER ERROR" represents a
> compiler bug that should be reported.
>
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Beta boost+spirit - VC7.1 "buffer overrun" error

[vc]

Hi all,

I am using the VS .NET 2003 (VC7.1) on Windows 2000 and I'm porting
a Linux application on Windows. I got the BETA sources
(http://boost.sourceforge.net/regression-logs/boost_1_30_0_b1.zip)
and I give it a try, but the compiler stops with the "Buffer overrun
detected!" error (see Vccrash.jpg attached).

For being easier to duplicate, attached is also a sample (see
spirit-problem.cc) that has this behavior.

I have to mention that on 2003.02.18 I took the spirit sources from the cvs,
and this sample compiles
fine with those sources. That is why I assume that this is a new added
problem into the spirit sources.
As a summary, when using:
- version 1.29 of boost and cvs sources of spirit from 2003.02.18 => the
sample compiles ok
- boost 1.30 beta (boost and spirit) => the sample is not compiling ok

Can you tell me please if this is indeed a spirit problem or not?

Thanks in advance,
Viv
#include 
#include 
#include 
#include 
#include 
//#include 
//#include 
#include 
#include 

/*
  compile:
g++  -I  spirit-problem.cc -g  -o spirit-problem


*/

using namespace std;
using namespace boost;
using namespace spirit;
using namespace phoenix;

const spirit::chset lwsp_char_p(" \t");

struct crlf_parser : spirit::grammar
{
crlf_parser()
{
}
template
struct definition
{
definition(const crlf_parser& self)
{
using namespace spirit;

first = str_p("\r\n");
}
const spirit::rule& start() const
{
return first;
}
spirit::rule first;
};
};
const crlf_parser crlf_p;


struct lwsp_parser : spirit::grammar
{
lwsp_parser()
{
}
template
struct definition
{
definition(const lwsp_parser& self)
{
using namespace spirit;

first = lexeme_d
[
+( !crlf_p >> lwsp_char_p )
];
}
const spirit::rule& start() const
{
return first;
}
spirit::rule first;
};
};
const lwsp_parser lwsp_p;




//---

struct content_type_line
{
const char* type;
const char* type_end;
const char* subtype;
const char* subtype_end;
const char* param;
const char* param_end;
};

struct content_type_line_closure : spirit::closure
{
member1 val;
};


struct content_type_line_parser : spirit::grammar
{
content_type_line_parser()
{
}
template
struct definition
{
definition(const content_type_line_parser& self)
{

/*
   Borenstein & Freed  [Page 9]
   
   RFC 1521  MIMESeptember 1993

  In the Augmented BNF notation of RFC 822, a Content-Type header field
  value is defined as follows:
   
content  :=   "Content-Type"  ":"  type  "/"  subtype  *(";"
parameter)
  ; case-insensitive matching of type and subtype
   
type :=  "application" / "audio"
  / "image"   / "message"
  / "multipart"  / "text"
  / "video"   / extension-token
  ; All values case-insensitive
   
extension-token :=  x-token / iana-token
   
iana-token := 
   
x-token := 
   
subtype := token ; case-insensitive
   
parameter := attribute "=" value
   
attribute := token   ; case-insensitive
   
value := token / quoted-string
   
token  :=  1*
   
tspecials :=  "(" / ")" / "<" / ">" / "@"
   /  "," / ";" / ":" / "\" / <">
   /  "/" / "[" / "]" / "?" / "="
  ; Must be in quoted-string,
  ; to use within parameter values
   
   
   
   Borenstein & Freed [Page 10]
   
   RFC 1521  MIMESeptember 1993
   
   
  Note that the definition of "tspecials" is the same as the RFC 822
  definition of "specials" with the addition of the three characters
  "/", "?", and "=", and the removal of ".".
 */

 

[boost] [PATCH for 1.30.0] Make boost work better when BOOST_NO_WREGEXis defined

[Lars Gullik Bjønnes]

Who should I send this to, to make someone have a look at it?

--- Begin Message ---

The following patch fixes some compilation problems when
BOOST_NO_WREGEX is defined (as we do in LyX). These concern OpenBSD
(first hunk: when BOOST_NO_WREGEX is defined we end up including
) and something I found when trying to compile with lyxstring
(no need to define compare_string(wstring,wchar_t*)).

Note that the patch is made agaist the LyX sources, not the boost
tree.
If you want a patch that is directly applyable to boost please contact
me and I will create one.

Index: boost/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/boost/ChangeLog,v
retrieving revision 1.33
diff -u -p -r1.33 ChangeLog
--- boost/ChangeLog 3 Mar 2003 15:53:39 -   1.33
+++ boost/ChangeLog 7 Mar 2003 17:20:09 -
@@ -1,3 +1,11 @@
+2003-03-07  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
+
+   * boost/regex/v3/regex_match.hpp (string_compare): do not declare
+   a version for wstring is BOOST_NO_WREGEX is defined.
+
+   * boost/regex/config.hpp: do not try to include  and
+when BOOST_NO_WREGEX is defined.
+
 2003-03-03  Lars Gullik Bjxnnes  <[EMAIL PROTECTED]>
 
* update boost to version pre-1.30.0
Index: boost/boost/regex/config.hpp
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/boost/boost/regex/config.hpp,v
retrieving revision 1.4
diff -u -p -r1.4 config.hpp
--- boost/boost/regex/config.hpp3 Mar 2003 15:53:46 -   1.4
+++ boost/boost/regex/config.hpp7 Mar 2003 17:20:09 -
@@ -125,8 +125,10 @@
 // If there isn't good enough wide character support then there will
 // be no wide character regular expressions:
 //
-#if (defined(BOOST_NO_CWCHAR) || defined(BOOST_NO_CWCTYPE) || 
defined(BOOST_NO_STD_WSTRING)) && !defined(BOOST_NO_WREGEX)
-#  define BOOST_NO_WREGEX
+#if defined(BOOST_NO_CWCHAR) || defined(BOOST_NO_CWCTYPE) || 
defined(BOOST_NO_STD_WSTRING)
+#  ifndef BOOST_NO_WREGEX
+#define BOOST_NO_WREGEX
+#  endif
 #else
 #  if defined(__sgi) && defined(__SGI_STL_PORT)
   // STLPort on IRIX is misconfigured:  does not compile
Index: boost/boost/regex/v3/regex_match.hpp
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/boost/boost/regex/v3/regex_match.hpp,v
retrieving revision 1.1
diff -u -p -r1.1 regex_match.hpp
--- boost/boost/regex/v3/regex_match.hpp3 Mar 2003 15:53:46 -   1.1
+++ boost/boost/regex/v3/regex_match.hpp7 Mar 2003 17:20:09 -
@@ -56,8 +56,10 @@ inline int string_compare(const std::bas
 { return s.compare(p); }
 inline int string_compare(const std::string& s, const char* p)
 { return std::strcmp(s.c_str(), p); }
+# ifndef BOOST_NO_WREGEX
 inline int string_compare(const std::wstring& s, const wchar_t* p)
 { return std::wcscmp(s.c_str(), p); }
+# endif
 # define STR_COMP(s,p) string_compare(s,p)
 #endif

-- 
Lgb
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

--- End Message ---
-- 
Lgb
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost