"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "David Abrahams" <[EMAIL PROTECTED]>
> To: "Boost mailing list" <[EMAIL PROTECTED]>
> Sent: Thursday, March 20, 2003 2:59 AM
> Subject: Re: [boost] Boost::format, MSVC, BOOST_TESTED_AT
>
>
>> > #if BOOST_WORKAROUND(
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, March 20, 2003 2:59 AM
Subject: Re: [boost] Boost::format, MSVC, BOOST_TESTED_AT
> > #if BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1300))
> > #error blah
> > #e
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
> Hello,
>
> I had a problem compiling boost::format with MSVC 7.1 (final beta). It
> appears that BOOST_TESTED_AT is confusing MSVC preprocessor, in fact the
> following code
>
> #if BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1300))
> #error blah
> #e
Hello,
I had a problem compiling boost::format with MSVC 7.1 (final beta). It
appears that BOOST_TESTED_AT is confusing MSVC preprocessor, in fact the
following code
#if BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1300))
#error blah
#endif
always aborts compilation. I had to remove the BOOST_TE
std::exception once had a where() member for this purpose, but it
didn't survive.
Without runtime library support it will be difficult to do, but not
impossible --
the Oracle runtime has platform-specific code for capturing the stack
trace on all
the of the many platforms we support. I can't p
Joel de Guzman wrote:
> Beman Dawes wrote:
>> At 05:40 PM 3/19/2003, Joel de Guzman wrote:
>>
>> >Spirit version 1.5.2 will also have to be bumped to 1.6.0 (the
>> >final release version). By convention, odd numbered minor
>> >versions are developmental. The final release will have the
>> >ver
I would love boost to provide an exception class/framework/something
with this capability to encourage collection of context information,
which would make problem diagnosis so much easier.
Perhaps I could relate some of my experience and put some ideas up
for discussion?
I'm interested (in fact I n
Beman Dawes wrote:
> At 05:40 PM 3/19/2003, Joel de Guzman wrote:
>
> >Spirit version 1.5.2 will also have to be bumped to 1.6.0 (the
> >final release version). By convention, odd numbered minor
> >versions are developmental. The final release will have the
> >version change. The patches do no
At 05:40 PM 3/19/2003, Joel de Guzman wrote:
>Spirit version 1.5.2 will also have to be bumped to 1.6.0 (the
>final release version). By convention, odd numbered minor
>versions are developmental. The final release will have the
>version change. The patches do not affect the code.
Unless there is
Beman Dawes wrote:
> At 04:36 PM 3/19/2003, David Abrahams wrote:
> >Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> >> At 12:52 PM 3/19/2003, Beman Dawes wrote:
> >> >Please speak up now if you have any uncommitted RC_1_30_0
> changes or >> other
> >> >problems.
> >> >
> >> >Otherwise
At 04:36 PM 3/19/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> At 12:52 PM 3/19/2003, Beman Dawes wrote:
>> >Please speak up now if you have any uncommitted RC_1_30_0 changes or
>> other
>> >problems.
>> >
>> >Otherwise we will tag for release at 3 PM US Eastern Ti
At 04:35 PM 3/19/2003, Terje Slettebø wrote:
>I see from the CVS that the above has only been put in the header, not
the
>test, as well. It needs to be in both. If it's just in the header, it'll
>try
>the wide character tests - on a header that has wide character
conversions
>disabled - a recipe
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 12:52 PM 3/19/2003, Beman Dawes wrote:
> >Please speak up now if you have any uncommitted RC_1_30_0 changes or
> other
> >problems.
> >
> >Otherwise we will tag for release at 3 PM US Eastern Time (20:00 UTC).
>
> Currently holding waiting for res
>From: "Beman Dawes" <[EMAIL PROTECTED]>
> At 03:13 AM 3/19/2003, Terje Slettebø wrote:
>
> >Ok, it seems we may have to exclude wide character support for
> lexical_cast
> >on MSVC 6, to avoid breaking Date/Time. I suggest something like:
> >
> >#if defined(BOOST_NO_STRINGSTREAM) || \
> >
At 12:52 PM 3/19/2003, Beman Dawes wrote:
>Please speak up now if you have any uncommitted RC_1_30_0 changes or
other
>problems.
>
>Otherwise we will tag for release at 3 PM US Eastern Time (20:00 UTC).
Currently holding waiting for resolution of Boost.Python link problem.
Also, CVS is running s
Gennaro Prota wrote:
>
>> Mis-use of endl doesn't seem to be adequet justification for a new
>> end-of-line specifier. However, a difference in behavior between
>> '\n' and endl does.
>
> Indeed. And there are obvious differences:
>
> http://article.gmane.org/gmane.comp.lib.boost.devel/17737
I
This is quite neat, and works for me using MSVC 7.0 but:
1 The layout is screwed up by the mail attachment process and requires some
editing to avoid compile errors.
2 The filename formatlist.hpp might be better?
3 Requires language extensions enabled.
Compiling...
testFomatList.cpp
testFomat
Alisdair Meredith wrote:
Beman Dawes wrote:
There just isn't any time left. See "OK to tag for release?" message just
posted.
Sorry,
The line has to be drawn somewhere, and it is human nature to wish we
were the other side
I will be able to test properly with the new BCB patch myself next
On Wed, 19 Mar 2003 11:12:28 -0600, "Ed Brey" <[EMAIL PROTECTED]>
wrote:
>It's interesting that the people you read about don't think of '\n' conceptually as
>an object.
It's interesting that some people think they should :-)
>Mis-use of endl doesn't seem to be adequet justification for a new
>
Beman Dawes wrote:
> There just isn't any time left. See "OK to tag for release?" message just
> posted.
> Sorry,
The line has to be drawn somewhere, and it is human nature to wish we
were the other side
I will be able to test properly with the new BCB patch myself next
week. My worry is that
At 09:35 AM 3/19/2003, Alisdair Meredith wrote:
>Alisdair Meredith wrote:
>
>> I am currently doing a search for other places where borland v 0x0561
is
>> assumed, as I don't think the latest patch fixed any issues that would
>> affect boost and it would be a shame to have to choose between boost
Please speak up now if you have any uncommitted RC_1_30_0 changes or other
problems.
Otherwise we will tag for release at 3 PM US Eastern Time (20:00 UTC).
--Beman
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Daryle Walker wrote:
>> Stream-buffer-wrapping:
>>
>> - Why are these facilities provided? What are their uses? What do
>> they do better than the Standard Library's current classes?
>
> I don't think the Standard Library has classes like these. The
> standard streams (string, file, etc.) prob
Samuel Krempp wrote:
Le mer 19/03/2003 à 14:27, Russell Hind a écrit :
and this _USE_OLD_RW_STL macro is then an adequate mean to detect such
cases ? if so, I could disable the workaround, depending to this macro.
but not right before the release.
My take on this is:
BCB5 (0x550 to 0x551) doesn't
Le mer 19/03/2003 à 15:19, Beman Dawes a écrit :
> >I am currently doing a search for other places where borland v 0x0561 is
> >assumed, as I don't think the latest patch fixed any issues that would
> >affect boost and it would be a shame to have to choose between boost and
> >the patch.
> >(
Le mer 19/03/2003 à 14:27, Russell Hind a écrit :
> Thanks Alisdair, I don't suppose you can make changes can you? Another
> question in my original post was that it isn't required with BCB5 or
> BCB6 if _USE_OLD_RW_STL as the RogueWave STL appears to implement
> isdigit correctly (with locales
Alisdair Meredith wrote:
> I am currently doing a search for other places where borland v 0x0561 is
> assumed, as I don't think the latest patch fixed any issues that would
> affect boost and it would be a shame to have to choose between boost and
> the patch.
OK, borland 0x561 is assumed in quit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Trevor Taylor wrote:
|
| Perhaps I could relate some of my experience and put some ideas up
| for discussion?
I would be interested.
Thomas
- --
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet
Hannover
voi
At 08:54 AM 3/19/2003, Alisdair Meredith wrote:
>I don't know how close the release schedule is now, but if we could at
>least change the version check from 0x0561 to 0x0564 that would be
>extrely useful.
>
>This would make the difference between our being able to use boost 1_30
>'out-the-box' (as
On Tuesday, March 18, 2003, at 8:32 AM, Ed Brey wrote:
I'd like to thank those who took time to review the update to the
Boost I/O Library during the review period, which ended several days
ago. The reviewers raised important questions about the usefulness of
the new portions of the library.
I use Borland C++ Builder 6, update 4, STLPort 4.5.1 (provided by Borland)
and Boost is 1.30.0beta1.
Following snippet of code fails:
-
#include
#include
void foo(const boost::optional >& aux =
boost::optional >())
{}
int main() {}
-
with error message:
[C
Beman Dawes wrote:
>
> At 08:06 AM 3/19/2003, Alisdair Meredith wrote:
>
> >Russell Hind wrote:
> >>
> >> Does anybody know if this needs fixing, or is it my mistake. If it
> >> needs fixing, is someone able to do it before 1.30.0 is released?
> >
> >Yes, I think it needs fixing!
>
> Unle
Alisdair Meredith wrote:
Russell Hind wrote:
Does anybody know if this needs fixing, or is it my mistake. If it
needs fixing, is someone able to do it before 1.30.0 is released?
Yes, I think it needs fixing!
I think simply dropping the separate test for 0x0561 is easiest, given
the Kylix test
At 08:06 AM 3/19/2003, Alisdair Meredith wrote:
>Russell Hind wrote:
>>
>> Does anybody know if this needs fixing, or is it my mistake. If it
>> needs fixing, is someone able to do it before 1.30.0 is released?
>
>Yes, I think it needs fixing!
Unless others disagree strongly, this should be held
Russell Hind wrote:
>
> Does anybody know if this needs fixing, or is it my mistake. If it
> needs fixing, is someone able to do it before 1.30.0 is released?
Yes, I think it needs fixing!
I think simply dropping the separate test for 0x0561 is easiest, given
the Kylix test covers both. Otherw
At 03:13 AM 3/19/2003, Terje Slettebø wrote:
>Ok, it seems we may have to exclude wide character support for
lexical_cast
>on MSVC 6, to avoid breaking Date/Time. I suggest something like:
>
>#if defined(BOOST_NO_STRINGSTREAM) || \
>defined(BOOST_NO_STD_WSTRING) || \
>defined(BOOST_NO_STD
Hi guys,
Would you be interested in an infinite precision float with parallelized
arithmetics which could become policy-based eventually?
Philippe
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Trevor Taylor wrote:
> As a software user I am frequently frustrated by "an error occurred"
> like failure messages. As a developer I know that the software *knows*
> exactly what failed, why, and exactly what it was doing at the time, but
> doesn't pass any of this information on.
Alexei Alexand
On Tue, 18 Mar 2003 19:45:26 -0500, "Gennadiy Rozental"
<[EMAIL PROTECTED]> wrote:
>> > > Notice the weird misspellings in the error messages. :)
>> >
>> > What do you mean?
>>
>> "boolle" and "intr"? :)
>>
>> Could this be a problem in the unit test framework?
>
>Could be. What should it be?
>I w
At 03:13 AM 3/19/2003, Terje Slettebø wrote:
>Ok, it seems we may have to exclude wide character support for
lexical_cast
>on MSVC 6, to avoid breaking Date/Time. I suggest something like:
>
>#if defined(BOOST_NO_STRINGSTREAM) || \
>defined(BOOST_NO_STD_WSTRING) || \
>defined(BOOST_NO_STD
> > > > Notice the weird misspellings in the error messages. :)
> > >
> > > What do you mean?
> >
> > "boolle" and "intr"? :)
> >
> > Could this be a problem in the unit test framework?
>
> Could be. What should it be?
> I wil try to reproduce this locally after 1.30 is out.
I posted some messages
> >>Is this happening somewhere in the type traits code? Can you post an
> >>instantiation backtrace?
> >>
> >
> > It seems to be. Here's the error message:
>
> I guess the question here is: "should
> is_polymorphic::value compile?"
>
> If so, then we have a bug in is_polymorphic. If not, we shou
> In other words, lexical_cast will work if the instructions in the config
> file are followed. According to the config file anyone running 2.95 is
> in effect on their own. Terje's changes should be applied: any remaining
> g++ 2.95 problems would then be down to local config and rather than
> lex
Trevor Taylor wrote:
As a software user I am frequently frustrated by "an error occurred"
like failure messages. As a developer I know that the software *knows*
exactly what failed, why, and exactly what it was doing at the time, but
doesn't pass any of this information on.
Recently I developed som
As a software user I am frequently frustrated by "an error occurred"
like failure messages. As a developer I know that the software *knows*
exactly what failed, why, and exactly what it was doing at the time, but
doesn't pass any of this information on.
Recently I developed some C++ where for the f
"Martin Bosticky" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi
>
> Me and my colleagues have come across an issue when using a
shared_ptr.
>
> void myFunction(shared_ptr const & vp_Pointer)
> {
> vp_Pointer->call any non-const function
> }
>
> i.e. a const shared_ptr
> === //depot/devel/lib/boost/vendor/boost/test/unit_test_suite.hpp#1 -
/home/green/p4/devel/lib/boost/boost/test/unit_test_suite.hpp
> ***
> *** 267,273
> if( name_[0] == '&' )
> name_.erase( 0, 1 );
>
> ! return name_.data();
> }
>
> } // namespace d
> -Original Message-
> From: Terje Slettebø [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 19 March 2003 7:43 AM
> lexical_cast_test.cpp(105): error in "test_conversion_to_intr": exception
> boost::bad_lexical_cast is expected
> lexical_cast_test.cpp(111): error in "test_conversion_to_intr":
>From: "Kevlin Henney" <[EMAIL PROTECTED]>
> In article <[EMAIL PROTECTED]>, Terje Slettebø
> <[EMAIL PROTECTED]> writes
> >
> >However, the three failing tests for each of MSVC 6 and g++ 2.95
(different
> >ones for the two) are in the middle of some wide character tests.
>
> My original intent wa
Actually, the log4J and log4N are examples of what logging libs could be...
Marc
Alisdair Meredith <[EMAIL PROTECTED]>@lists.boost.org on
19/03/2003 10:17:31
Please respond to Boost mailing list <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: [boost
Dave Gomboc wrote:
> Just curious if anyone's doing something along these lines. A quick
> google search on boost turned up only Boost.Test, which (I think?) is
> something quite different.
I was just thinking the same thing last week, and trawling through
old lists found a real mess of views
In article <[EMAIL PROTECTED]>, Terje Slettebø
<[EMAIL PROTECTED]> writes
>
>However, the three failing tests for each of MSVC 6 and g++ 2.95 (different
>ones for the two) are in the middle of some wide character tests.
My original intent was to disable wide character support for any
platform that
In article <[EMAIL PROTECTED]>, Terje Slettebø
<[EMAIL PROTECTED]> writes
>>From: "Kevlin Henney" <[EMAIL PROTECTED]>
>>
>> In other words, lexical_cast will work if the instructions in the config
>> file are followed. According to the config file anyone running 2.95 is
>> in effect on their own. T
>From: "Gennadiy Rozental" <[EMAIL PROTECTED]>
> > > > Notice the weird misspellings in the error messages. :)
> > >
> > > What do you mean?
> >
> > "boolle" and "intr"? :)
> >
> > Could this be a problem in the unit test framework?
>
> Could be. What should it be?
They should be:
test_conversi
>From: "Beman Dawes" <[EMAIL PROTECTED]>
> A fresh version of the Win32 regression tests has just been posted. See
> http://boost.sourceforge.net/regression-logs/cs-win32-RC_1_30_0-diff.html
>
> There are seven new fails in date_time tests; presumably all caused by
> lexical_cast.hpp problems. See
55 matches
Mail list logo
