Aleksey Gurtovoy wrote:
>> > b) resolving the 'wchar_t' support issue before the library makes
>> >into official Boost distribution.
>>
>> I'm actually not that happy about solving general issue alone...
>
> You don't have to. I am sure a lot of people on this list have dealt
> with the issu
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 version in the sandbox, I still see the foll
Vladimir Prus wrote:
> > There've been a fair amount of suggested changes, many of which are
> > documented on Wiki [1], and since the author himself keeps track of
> > the issues, I won't reiterate them here - except for stressing the
> > need for
> >
> > a) extensively reworked and extended docum
Support Requests item #748903, was opened at 2003-06-04 14:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=207586&aid=748903&group_id=7586
Category: None
Group: None
Status: Open
Resolut
Hi,
I am a newbie to boost, and I don't know if this issue has been addressed.
I am trying to build the boost libraries on a Win2k machine with MSVC++ 6
installed, so I downloaded bjam, added it to the path, added the boost
libraries path to the include path and started the build with the command
Support Requests item #748869, was opened at 2003-06-04 14:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=207586&aid=748869&group_id=7586
Category: None
Group: None
Status: Open
Resolut
I see the need for two new configuration macros. The need popped up
when I was trying to add a copy constructor to a stream buffer template
class (for completeness) but GCC blocked it.
The std::basic_streambuf<> class template and the std::ios_base class
don't mention any copying semantics in
David Abrahams wrote:
This is going to break every boost library and every user which is
depending on the current CVS version of iterator_adaptors. The new
adaptors are so much better designed and easier to use that making the
transition should be cake, but before I do anything drastic I want to
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
> This is going to break every boost library and every user which is
> depending on the current CVS version of iterator_adaptors. The new
> adaptors are so much better designed and easier to use that making the
> transition should be cake, but before I do anything drastic I want to
> hear how loud
> 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: http://list
sequence_array, acts as a vector of vector, 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
an
David Abrahams wrote:
This is going to break every boost library and every user which is
depending on the current CVS version of iterator_adaptors. The new
adaptors are so much better designed and easier to use that making the
transition should be cake, but before I do anything drastic I want to
h
> 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 fi
> 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 typed
> 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)"
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 (http://www.b
"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
>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 ins
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).
> >
> > "
> > Unfortunatel
>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
- 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
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 nee
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
> mo
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
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 th
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'l
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 i
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 fo
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 version
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 wi
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.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
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 nat
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.
>
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 Micro
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 conditions/
"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
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
> 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
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
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 cu
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 i
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]
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 be
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
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 watc
> "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 ?
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)
48 matches
Mail list logo
