Daryle,
On Thursday 05 June 2003 01:28, Daryle Walker wrote:
Actually, that reason isn't accurate. The '\n' is an expression of
type char, and all output streams can print a char object with operator
, even if the stream's character type isn't char. (The stream will
secretly call the
This now looks very extensively tested. But when I tried to build the test.cpp
using MSVC 7.0 and Boost 1.30, there are zillions of errors from the test
modules. Do I need to use a more recent version of the test code?
Thanks
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
Hi Paul!
I used the Boost version 1.29 and I was able to compile it under MSVC7 with no error
messages.
Jan
Paul A. Bristow wrote:
This now looks very extensively tested. But when I tried to build the test.cpp
using MSVC 7.0 and Boost 1.30, there are zillions of errors from the test
Even with boost 1.30 I got just some warnings, but no errors. I don't know what's
wrong.
Jan
Paul A. Bristow wrote:
This now looks very extensively tested. But when I tried to build the test.cpp
using MSVC 7.0 and Boost 1.30, there are zillions of errors from the test
modules. Do I need to
- Original Message -
From: Toon Knapen [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]; Maarten Hilferink
[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 12:59 PM
Subject: Re: [boost] sequence_array contribution
On Thursday 22 May 2003 12:51, Maarten Hilferink wrote:
From: Alexander Terekhov [EMAIL PROTECTED]
Terje Slettebø wrote in message [EMAIL PROTECTED]:
why shouldn't std::exception use std::strings?
See here (http://www.boost.org/more/error_handling.html).
You should perhaps point out that this is from a comp.lang.c++.moderated
posting, and
David Abrahams wrote:
Alexander Terekhov [EMAIL PROTECTED] writes:
Terje Slettebø wrote in message [EMAIL PROTECTED]:
[...]
why shouldn't std::exception use std::strings?
See here (http://www.boost.org/more/error_handling.html).
Unfortunately, operating systems other
From: Pavel Vozenilek [EMAIL PROTECTED]
lexical_cast constructs and destroys std::stringstream
(including dynamic memory allocation/free.)
each time a conversion is done.
Maybe specialised version of lexical_cast can be developed
which takes external, existing stringstream instance as
Terje Slettebø wrote:
From: Alexander Terekhov [EMAIL PROTECTED]
Terje Slettebø wrote in message [EMAIL PROTECTED]:
why shouldn't std::exception use std::strings?
See here
How do I use the conditional expression in a format string when my
true_expression is a number? For example the format (?1foo) will replace
the 1st subexpression with the string foo, but how do I replace the 1st
subexpression with 123? I try (?1123) and that fails. I can do (?1
123),
but it
I don't know about Intel-Win32 but I brought much of this up regarding
MSVC
7.0+ and most everybody yawned. I am glad that some people have woken up
to
the fact that there is a problem using wide characters with compilers
which
support both the native C++ wide character and a previous typedef
I've tried to use the random.hpp header using Visual Studio C++ 6.0, and
it
does not
compile. I found a message thread in the mailing list about this on VC7,
where some work-arounds were suggested. Jens then asked for feedback, and
I
didn't find any feedback, so here it is...
This got fixed
sequence_arrayT, acts as a vector of vectorT, but faster.
I have made the mentioned attatchments available in the boost files section
in
a directory with the name sequence_array. A separate documentation file will
follow, but the header file contains a desription of the main design
considerations
Gak! These compiler vendors are going to drive us all crazy! What do they
expect us to do, use ESP to know what compiler options are set?
If you had ESP, then you would know the answer to that :-
John.
___
Unsubscribe other changes:
Fredrik Blomqvist [EMAIL PROTECTED] writes:
David Abrahams wrote:
Fredrik Blomqvist [EMAIL PROTECTED] writes:
David Abrahams wrote:
I'm going to want to replace the old Boost iterator adaptors
implementation with the new one in the Boost sandbox pretty soon,
and while they are similar in
My apologies for the very late reply. I was away for a while and am still
sorting through my inbox...
Platform:
Mac OS 10.2
gcc 3.3 compiled from sources
boost cvs from last Friday
When porting the Boost.Python bindings for some custom libraries I ran
into a problem with static
How do I use the conditional expression in a format string when my
true_expression is a number? For example the format (?1foo) will replace
the 1st subexpression with the string foo, but how do I replace the 1st
subexpression with 123? I try (?1123) and that fails. I can do (?1 123),
but it gives
Hello,
I am using boost 1_30_0 (NOT current cvs snapshot) and Visual Studio.NET
2003. There is a strange problem with lexical_cast in the following
scenario (rough aproximation of my code, all in one header):
std::ostream operator(std::ostream out, const ConcreteType v);
namespace foo
{
hi there,
I'v been trying to find some info as to why semaphores
are considered harmful by the boost::thread authors,
without luck. Is there any concise text describing
the problem ?
I'v been using semaphores for years and can't think of
what should be wrong with it.
Thanks,
Terje Slettebø wrote in message [EMAIL PROTECTED]:
[...]
why shouldn't std::exception use std::strings?
See here (http://www.boost.org/more/error_handling.html).
Unfortunately, operating systems other than Windows also wind non-C++
exceptions (such as thread cancellation) into the
Stefan == Stefan Seefeld [EMAIL PROTECTED] writes:
Stefan hi there,
Stefan I'v been trying to find some info as to why semaphores are
Stefan considered harmful by the boost::thread authors, without
Stefan luck. Is there any concise text describing the problem ?
Stefan I'v
Aleksey Gurtovoy wrote:
The Command Line Config library by Vladimir Prus has been accepted
into Boost, pending the incorporation of suggestions brought up in
the review.
These are good news!
I would like to thank all the reviewers. Being the library submitter is quite
different from
Robin Hu wrote:
Semaphore can always be stimulated by using mutex + cond_var. and
the only place that semaphore is a must is in signle-handler, but
this is not within the area of threading programming. ;-)
right, semaphores can be emulated by other primitives. But does
that mean
Stefan Seefeld wrote:
hi there,
I'v been trying to find some info as to why semaphores
are considered harmful by the boost::thread authors,
without luck. Is there any concise text describing
the problem ?
Well,
http://www.boost.org/libs/thread/doc/faq.html#question10
I'v been using
I can confirm that those examples I have tried work OK with MSVC 7.1
type_deduction compiles and runs and looks as is it works.
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
John Maddock wrote:
That will certainly work, but you shouldn't have to do that since the
compiler itself defines _WCHAR_T_DEFINED. Since I made the fix
earlier
this
afternoon I am able to compile some non-boost code correctly which
had previously be failing.
Just let me jump in here: you
Hello Andreas, thanks for the detailed reply.
[clip]
No, but you are right in your observation that there's currently not much
support for interacting FSMs. Most importantly, the current library is
single-threaded, there's no support yet for FSMs running in their own
threads. I made the
Alexander Terekhov wrote:
Stefan Seefeld wrote:
hi there,
I'v been trying to find some info as to why semaphores
are considered harmful by the boost::thread authors,
without luck. Is there any concise text describing
the problem ?
Well,
http://www.boost.org/libs/thread/doc/faq.html#question10
A disappointing aspect of this in regards to MSVC 7.0+ is
that there is no preprocessor macro ( as of 7.0, I haven't
checked 7.1 yet ) which MSVC defines for distinguishing
native C++ wide character from the previous typedef for
wchar_t.
The MS-specific macro _NATIVE_WCHAR_T_DEFINED
Stefan Seefeld wrote:
[...]
I'm still not convinced.
http://google.com/groups?selm=3CED3306.DF6DB829%40web.de
(Subject: Re: many semaphores)
regards,
alexander.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
John Maddock [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
That will certainly work, but you shouldn't have to do that since the
compiler itself defines _WCHAR_T_DEFINED. Since I made the fix earlier
this
afternoon I am able to compile some non-boost code correctly which had
Alexander Terekhov wrote:
Stefan Seefeld wrote:
[...]
I'm still not convinced.
http://google.com/groups?selm=3CED3306.DF6DB829%40web.de
(Subject: Re: many semaphores)
Would it be possible to post some code that experience has shown to be
error-prone using semaphores comparing with
Nicolas Fleury wrote:
[...]
http://google.com/groups?selm=3CED3306.DF6DB829%40web.de
(Subject: Re: many semaphores)
Would it be possible to post some code that experience has shown to be
error-prone using semaphores comparing with conditions/mutexes?
Sure... thanks to the Microsoft
At 07:58 AM 6/4/2003, John Maddock wrote:
That will certainly work, but you shouldn't have to do that since the
compiler itself defines _WCHAR_T_DEFINED. Since I made the fix earlier
this
afternoon I am able to compile some non-boost code correctly which had
previously be failing.
Just let
At 11:24 AM 6/4/2003, Edward Diener wrote:
I don't know about Intel-Win32 but I brought much of this up regarding
MSVC
7.0+ and most everybody yawned. I am glad that some people have woken up
to
the fact that there is a problem using wide characters with compilers
which
support both the native
Alexander Terekhov wrote:
Nicolas Fleury wrote:
[...]
Would it be possible to post some code that experience has shown to be
error-prone using semaphores comparing with conditions/mutexes?
Sure... thanks to the Microsoft Corp.
Chris Russell wrote:
I understand. I need to design a state-based harness for a plug-in
system
and I'm going to use your FSM submission code and see how it goes.
Likely
the review will be over before I'm done, but at a minimum I will be
able to
give you feedback on how it works out with the
On Monday, June 2, 2003, at 12:21 PM, Ed Brey wrote:
Daryle Walker wrote:
I fixed up the I/O library I had reviewed a few months ago. It was
some little things last week, but some big documentation and testing
this week. It's in the sandbox if you want to try it out.
Looking at today's
On Tuesday, June 3, 2003, at 9:19 AM, Thomas Witt wrote:
[SNIP]
To me there are basically two reasons that make newl desirable beside
the formatting issue.
[SNIP]
2. IIUC the difference between a character and a manipulator is that
the manipulator is not tied to the streams character type. So
lexical_cast constructs and destroys std::stringstream
(including dynamic memory allocation/free.)
each time a conversion is done.
Maybe specialised version of lexical_cast can be developed
which takes external, existing stringstream instance as
template parameter and reuses it.
Very rough
On Wednesday, June 4, 2003, at 3:54 PM, Beman Dawes wrote:
Hum... I just had a thought. Is it possible to detect if wchar_t is a
typedef at compile time?
Yes, I think so. Won't boost::is_same unsigned short, wchar_t
::value be true if wchar_t is a typedef, and false if a distinct type?
I'll
41 matches
Mail list logo
