Vincent N. Virgilio wrote:
> FYI, xParam (sourceforge) seems to fulfill similar requirements.
I had a brief look at the project before, and looked for another time now.
Are you sure that project called
"XParam - General-Purpose Object Serialization Framework for C++"
has the same requiremens and
Rob Stewart wrote:
> From: Vladimir Prus <[EMAIL PROTECTED]>
>
> > Rob Stewart wrote:
> > > The purpose of command line parsing is to decode the arguments
> > > list into pieces of information, abstracting the syntax of the
> > > command line away from the program. Thus, the library should be
> >
"Beman Dawes" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> At 02:49 PM 2/18/2003, Itay Maman wrote:
>
> >"Rodolfo Lima" <[EMAIL PROTECTED]> wrote in message
> >b2tm6v$9o7$[EMAIL PROTECTED]">news:b2tm6v$9o7$[EMAIL PROTECTED]...
> >> How different is boost::
On Tue, 18 Feb 2003, Gennadiy Rozental wrote:
> > > 1. Does not Boost.Thread already have locking mechanisms
> >
> > The only thing boost threads offer is #1 on my list, that is "The ability
> > to acquire a lock and release it when the object goes out of scope
> > effectively implemented the "Mon
Hi,
I want to encapsulate boost::find in a template
method in a base class for easier use.Here is some code:
#include #include
class CWindow {public: CWindow()
{ SetEventHandler(&CWindow::OnCreate); // this call
works } long OnCreate() { return
0; } template void SetEventHandler(l
> > 1. Does not Boost.Thread already have locking mechanisms
>
> The only thing boost threads offer is #1 on my list, that is "The ability
> to acquire a lock and release it when the object goes out of scope
> effectively implemented the "Monitor" concept". Implementing this idea is
> rather easy
> > 2. IMO any locking mechanisms should be implemented in terms of
smart_ptr
>
> I don't see the fundamental connection between locking and smart
> pointers.
>
> In particular, which smart_ptr are we talking about? shared_ptr [which
> may need locking internally for reference count anyway]
> or s
"Vincent N. Virgilio" <[EMAIL PROTECTED]> writes:
> FYI, xParam (sourceforge) seems to fulfill similar requirements.
>
> In article <[EMAIL PROTECTED]>, Rob
> Stewart wrote:
>> From: Vladimir Prus <[EMAIL PROTECTED]>
>>> Rob Stewart wrote:
As a matter of nettiquette, please limit the length of
Title: RE: [boost] Formal review or Variant Library (Ed B.)
From: David Abrahams [mailto:[EMAIL PROTECTED]]
>> Extract is confusing. One problem is that it is deceivingly named.
>
>The name was my suggestion, so I'm going to argue with you a bit about
>that.
>
>> It doesn't extract data from
FYI, xParam (sourceforge) seems to fulfill similar requirements.
In article <[EMAIL PROTECTED]>, Rob
Stewart wrote:
> From: Vladimir Prus <[EMAIL PROTECTED]>
>> Rob Stewart wrote:
>>
>> > The purpose of command line parsing is to decode the arguments
>> > list into pieces of information, abstract
On Tue, 18 Feb 2003, Gennadiy Rozental wrote:
> Two comments:
>
> 1. Does not Boost.Thread already have locking mechanisms
The only thing boost threads offer is #1 on my list, that is "The ability
to acquire a lock and release it when the object goes out of scope
effectively implemented the "Mon
At 11:56 AM 2/18/2003, William E. Kempf wrote:
>Well, I'm in favor of that, since we're moving at least some of the
>documentation to Boost.Book with this release (or so I gathered). So
>what's the group opinion on this one?
I'd like to hold off as many changes as possible until after the releas
At 05:26 PM 2/18/2003, Bo Persson wrote:
>A lot of the failures seems to be a "warning" that 7.1 actually does the
>right thing. A bit unfair to count this as a failure!
Warnings aren't counted as failures. A test compile, link, or run has to
actually report failure (via non-zero return code).
I think we are about ready. Dave Abrahams has asked that we hold off
branching for a couple of more days so he can verify some Boost.Python
issues are cleared, so we will wait as a courtesy to him.
In the meantime, for people who submitted patches in the last couple of
weeks, you might want to
At 02:49 PM 2/18/2003, Itay Maman wrote:
>"Rodolfo Lima" <[EMAIL PROTECTED]> wrote in message
>b2tm6v$9o7$[EMAIL PROTECTED]">news:b2tm6v$9o7$[EMAIL PROTECTED]...
>> How different is boost::any from this new variant library? Don't they
>> address the same issue?
>>
>
>In short:
>
>(1) boost::any ca
> -Original Message-
> From: William E. Kempf [mailto:[EMAIL PROTECTED]]
> This a minor difference here, though. The bjam executable boot straps
> fairly easily on most platforms. XSLT processors aren't quite as
> convenient. At least that was my experience that last time I tried to
do
>
Peter Dimov wrote:
> Eric Friedman wrote:
> >
> > In the past we sought to support the following...
> >
> > variant<...> var;
> > T* p = extract(&var);
> > T& r = extract(var);
> >
> > ...but it had to be dropped because (essentially) ambiguity exists
> > between the following:
> >
> > templa
David Abrahams wrote:
[snip]
> BTW, I just realized that a conversion from variant to optional
> could be used to do extraction as well. Maybe it would be better to
> ditch extract altogether and just use optional?
I had thought about this before, but I dismissed it (perhaps too quickly)
because
Richard Hadsell wrote:
> Some of the data are in scoped_arrays of scoped_ptrs.
Ah ah, you've done what I said was impossible, you HAVE created a
container of scoped_ptrs!!!
As I suspected, live and learn
Thanks for the explaination.
--
AlisdairM
"William E. Kempf" <[EMAIL PROTECTED]> writes:
> Gennadiy Rozental said:
>>> > 1. Boost.Thread with depend on multithreaded version of Boost.Test.
>>> 2. Boost.Test will try to use minimal/basic part of Boost.Thread
>>> > functionality
>>>
>>> There's no "minimal/basic part" of Boost.Thread that d
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> Looks like a no-brainer, &k can't be a compile-time constant if k is
> thread-local.
>
> 1.
>
> void f()
> {
> C<&k> ck;
> }
>
> 2.
>
> void f()
> {
> typedef C<&k> ck_type;
> ck_type ck;
> }
>
> 3.
>
> typedef C<&k> ck_type;
>
> void f()
> {
David Abrahams wrote:
> BTW, I just realized that a conversion from variant to optional
> could be used to do extraction as well. Maybe it would be better to
> ditch extract altogether and just use optional?
I think this makes sense. The disadvantage is the overhead of optional
just to do "extr
"Jeff Garland" <[EMAIL PROTECTED]> writes:
>> Many of the regression tests for the date time library are failing
>> currently because the library relies on std::abs being
>> available. AKAIK, the C++ standard doesn't require this so the library
>> shouldn't make use of it.
>>
>> Maybe datetime
Alisdair Meredith wrote:
I am curious why the size of scoped_ptr matters so much?
I certainly worry about the size of shared_ptr as I may store many of
them in containers. However, this is not possible with scoped_ptr so I
am curious about usage where size might still matter? [Whenever I think
Gennadiy Rozental wrote:
> 1. Does not Boost.Thread already have locking mechanisms
> 2. IMO any locking mechanisms should be implemented in terms of smart_ptr
I don't see the fundamental connection between locking and smart
pointers.
In particular, which smart_ptr are we talking about? shared_
"Eric Friedman" <[EMAIL PROTECTED]> wrote in message
b2uflv$86s$[EMAIL PROTECTED]">news:b2uflv$86s$[EMAIL PROTECTED]...
> [...]
> const T& r = ...;
> r.~T();
>
> Even if my understanding is correct though, it may be best for destroyer
> to take a non-const reference to avoid confusion.
Comeau
David B. Held wrote:
[snip]
> I realize that the operator ought to be const. But should the reference
> be? I guess I don't know if you should be able to call a d'tor on a
> const& or not.
My understanding is that since the following is legal...
const T* p = ...;
delete p;
...so is what yo
Gennadiy Rozental said:
>> > 1. Boost.Thread with depend on multithreaded version of Boost.Test.
>> 2. Boost.Test will try to use minimal/basic part of Boost.Thread
>> > functionality
>>
>> There's no "minimal/basic part" of Boost.Thread that doesn't need
>> testing.
>
> I did not mean that it doe
"Itay Maman" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
"David B. Held" wrote:
> > [...]
> > template
> > void operator()(const T& operand) const
> > {
> > operand.~T();
> > }
> > [...]
>
> Is the destructor really a const function?
>
"Ed Brey" <[EMAIL PROTECTED]> writes:
> Extract is confusing. One problem is that it is deceivingly named.
The name was my suggestion, so I'm going to argue with you a bit about
that.
> It doesn't extract data from the variant at all, but rather provides
> type-specific access to data that stil
(I appologize for the two awkward replies I had sent before. It seems that my news client and myself have some issues to resolve...)
<[EMAIL PROTECTED]> wrote:
[snip]>> 2) The Visitor concept brings a couple questions to mind:> a) Why allow modification (termed "persistency" in the docs)? No oth
"David B. Held" wrote:
> > [...]> > template > > void operator()(const T& operand) const> > {> > operand.~T();> > }> > [...]> > Is the destructor really a const function?> > Dave> The object being destroyed is the formal parameter "operand". The object whose operator() is ca
> If you consider a test suite a test case (which should be how it is, no?),
> then yes, that's all I'd need.
Yes. test suite is a test case.
> > 1. Boost.Thread with depend on multithreaded version of Boost.Test. 2.
> > Boost.Test will try to use minimal/basic part of Boost.Thread
> > functional
Richard Hadsell wrote:
> Although someone mentioned this earlier, I have not seen it reiterated
> -- if the size of scoped_ptr grows to more than just the pointer itself,
> I can not use it. I imagine that others also need it to remain simple,
> at least in this respect.
>
> If someone adds anyt
"Greg Colvin" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Any thoughts on this issue?
>
> >From: Steve Clamage <[EMAIL PROTECTED]>
> >To: C++ core language mailing list
> >Message c++std-core-9820
> >
> >Some compilers implement thread-local storage (TLS) for
"Beman Dawes" <[EMAIL PROTECTED]> skrev i meddelandet
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> At 02:21 PM 2/18/2003, Peter Dimov wrote:
>
> >Beman Dawes wrote:
> >> Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work
> >> together, I've posted regression tests.
> >>
> >
Those not getting responses to queries posted to this list should be aware
that it is crunch time for a lot of Boost developers - some of us are
variously trying to finish off release 1.30.0, participate in a public
review, meet looming deadlines for submissions to the C++ standards
committee a
Greg Colvin wrote:
And I don't see a problem with adding constructors to
scoped_ptr that support custom deallocation, especially
since C++ has no 'finally' construct.
Although someone mentioned this earlier, I have not seen it reiterated
-- if the size of scoped_ptr grows to more than just th
At 02:21 PM 2/18/2003, Peter Dimov wrote:
>Beman Dawes wrote:
>> Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work
>> together, I've posted regression tests.
>>
>> See http://boost.sourceforge.net/regression-logs/
>
>You might want to disable warning 4675, "resolved overload was
"Eric Friedman" <[EMAIL PROTECTED]> wrote in message
003c01c2d6f7$2a812c90$49390c80@erk">news:003c01c2d6f7$2a812c90$49390c80@erk...
> [...]
> template
> void operator()(const T& operand) const
> {
> operand.~T();
> }
> [...]
Is the destructor really a const function?
Dave
<[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]..
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At 02:35 PM 2/18/2003, Alisdair Meredith wrote:
>> Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work
>> together, I've posted regression tests.
>>
>> See http://boost.sourceforge.net/regression-logs/
>
>>From the department of nitpickers ;¬ )
>
>The links to the fail messages ref
<[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]..
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Fernando Cacciola (Home)" wrote:
>
> Kevin, we're currently in the middle of a release and a formal review...
> If you wait a week or so.. and recall our attention, you're likely to get a
> response.
> Just hold on.
And, in the meantime, you might want to post your stuff to:
new
Greg Colvin wrote:
>
> Any thoughts on this issue?
My thoughts:
a) *errno* (the C99/POSIX.1-2001/SUSv3 "edition" of it).
b) *lazy* is good.
Well,
http://groups.google.com/groups?selm=3DA6C62A.AB8FF3D3%40web.de
(Subject: Re: local statics and TLS objects)
https://listman.redhat.com/pipermai
Sorry... I sent the last post but I forgot this:
The following pragmas turn off the warnings about "condition is always
'true/false"
and "unreachable code" on Borland:
int foo() {
#if BOOST_WORKAROUND(__BORLANDC__)
#pragma option push -w-ccc -w-rch
#endif
if ( true )
return 2 ;
return 0
[2003-02-18] Chris Little wrote:
>on 2/18/03 10:58 AM, Beman Dawes at [EMAIL PROTECTED] wrote:
>
>> In looking at the Mac OS (Darwin) regression tests to see why there are
so
>> many failures, a number of tests are failing with only this message:
>>
>> /usr/local/boost/boost/type_traits/is_float.
Two comments:
1. Does not Boost.Thread already have locking mechanisms
2. IMO any locking mechanisms should be implemented in terms of smart_ptr
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, 18 Feb 2003, Fernando Cacciola (Home) wrote:
> Kevin, we're currently in the middle of a release and a formal review...
> If you wait a week or so.. and recall our attention, you're likely to get a
> response.
> Just hold on.
No problem. I'm in no rush. If I don't get any response expre
"Eric Friedman" <[EMAIL PROTECTED]> wrote in message
b2s4b1$eof$[EMAIL PROTECTED]">news:b2s4b1$eof$[EMAIL PROTECTED]...
> Fernando Cacciola wrote:
> > I'm trying the variant library, by currently it doesn't
> > compile with bcc551.
> > I'd like to be able to compile it with my compiler so I can bas
on 2/18/03 10:58 AM, Beman Dawes at [EMAIL PROTECTED] wrote:
> In looking at the Mac OS (Darwin) regression tests to see why there are so
> many failures, a number of tests are failing with only this message:
>
> /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: use of `long
> double'
Kevin, we're currently in the middle of a release and a formal review...
If you wait a week or so.. and recall our attention, you're likely to get a
response.
Just hold on.
Thanks,
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.o
Greg Colvin wrote:
> Any thoughts on this issue?
>
>> From: Steve Clamage <[EMAIL PROTECTED]>
>> To: C++ core language mailing list
>> Message c++std-core-9820
>>
>> Some compilers implement thread-local storage (TLS) for what would
>> otherwise be global variables. The compiler and runtime system
I posted this a couple days ago and have yet to seen any sort of reply or
any sign that anyone is interested. If people are having trouble
understanding the concept please let me know and I will try harder to
explain it. If you meant to reply but haven't yet, sorry for being
impatient.
If no
-Itay
"Rodolfo Lima" <[EMAIL PROTECTED]> wrote in message
b2tm6v$9o7$[EMAIL PROTECTED]">news:b2tm6v$9o7$[EMAIL PROTECTED]...
> How different is boost::any from this new variant library? Don't they
> address the same issue?
>
In short:
(1) boost::any can accept a value of any possible type. boo
Any thoughts on this issue?
>From: Steve Clamage <[EMAIL PROTECTED]>
>To: C++ core language mailing list
>Message c++std-core-9820
>
>Some compilers implement thread-local storage (TLS) for what would
>otherwise be global variables. The compiler and runtime system
>arrange for each thread to see
Beman Dawes wrote:
> Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work
> together, I've posted regression tests.
>
> See http://boost.sourceforge.net/regression-logs/
>From the department of nitpickers ;¬ )
The links to the fail messages refer to
.../cs-win32-links.htm#...
Beman Dawes wrote:
> Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work
> together, I've posted regression tests.
>
> See http://boost.sourceforge.net/regression-logs/
You might want to disable warning 4675, "resolved overload was found by
argument-dependent lookup".
Rani Sharoni wrote:
> Peter Dimov wrote:
>> Rani Sharoni wrote:
>>>
>>> You can probably use a similar approach to implement yet another
>>> is_class (not void, reference and doesn't have an implicit standard
>>> conversion to bool).
>>
>> I wonder whether "int () const" has an implicit standard co
Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work
together, I've posted regression tests.
See http://boost.sourceforge.net/regression-logs/
The folks at Microsoft asked that we identify these tests as "beta", since
the actual release may get slightly different results. And of
William E. Kempf wrote:
> Michael Glassford said:
>> Scott McCaskill wrote:
>>> I was just looking at the win32 implementation of the
>>> condition variable class in the thread library and
>>> noticed something odd. In version 1.7 of
>>> condition.cpp, there is a bug fix for
>>> condition::notify_
On Tue, 18 Feb 2003, William E. Kempf wrote:
> > If there are no complains, I would _love_ to move BoostBook out of the
> > sandbox and into its (presumably) permanent place in Boost CVS.
>
> Well, I'm in favor of that, since we're moving at least some of the
> documentation to Boost.Book with this
From: Vladimir Prus <[EMAIL PROTECTED]>
> Rob Stewart wrote:
>
> > The purpose of command line parsing is to decode the arguments
> > list into pieces of information, abstracting the syntax of the
> > command line away from the program. Thus, the library should be
> > able to understand any of va
Peter Dimov wrote:
> Rani Sharoni wrote:
>>
>> You can probably use a similar approach to implement yet another
>> is_class (not void, reference and doesn't have an implicit standard
>> conversion to bool).
>
> I wonder whether "int () const" has an implicit standard conversion
> to bool. ;-)
Good
> >Take a look at bosot/date_time/compiler_config.hpp which
> >does something similar. All we need to do to fix these regressions
> >is add the compiler to the list of those that don't have std::abs
> >at line 34.
>
> Based on the above, I've bump the VC++ version up to 1310 to cover version
"William E. Kempf" wrote:
> Boost.Threads is the only library that needs thread-safe versions of
> Boost.Test *TODAY* (at least that are part of the actual Boost project,
> but Boost.Test is also being used outside of the Boost project, and I
> won't begin to claim that I know they don't need thre
Rani Sharoni wrote:
>
> You can probably use a similar approach to implement yet another
> is_class (not void, reference and doesn't have an implicit standard
> conversion to bool).
I wonder whether "int () const" has an implicit standard conversion to bool.
;-)
__
"Eric Friedman" <[EMAIL PROTECTED]> wrote in message
b2s34c$bav$[EMAIL PROTECTED]">news:b2s34c$bav$[EMAIL PROTECTED]...
> Fernando Cacciola wrote:
> [snip]
> > (3) variant<> dependency.
> >
> > We are just about to review boost::variant<>.
> > I was planning to wrap optional<> around variant disca
How different is boost::any from this new variant library? Don't they
address the same issue?
rod.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At 11:26 AM 2/18/2003, Jeff Garland wrote:
>Take a look at bosot/date_time/compiler_config.hpp which
>does something similar. All we need to do to fix these regressions
>is add the compiler to the list of those that don't have std::abs
>at line 34.
Based on the above, I've bump the VC++ version
Eric Friedman wrote:
>
> In the past we sought to support the following...
>
> variant<...> var;
> T* p = extract(&var);
> T& r = extract(var);
>
> ...but it had to be dropped because (essentially) ambiguity exists
> between the following:
>
> template
> T& extract(Extractable & operand);
Gennaro Prota wrote:
> On Mon, 17 Feb 2003 10:02:58 +0100, Daniel Frey
> <[EMAIL PROTECTED]> wrote:
>
>> I started to implement my own type-traits to see if I can do it and
>> to
>> learn something. While doing so, my design lead me to some
>> dependencies:
>
>> is_enum needed is_class
>
> Daniel,
> The problem is, VA _has_ std::abs. You just need a specialization for
> long long then.
>
> namespace std {
> template<> long long abs(long long n) { return llabs(n); }
> }
>
> Don't know if this is legal, though.
How about just skipping the template:
#ifdef _VA_WHATEVER_COMPILER_MACRO_IS
n
Michael Glassford said:
> Scott McCaskill wrote:
>> I was just looking at the win32 implementation of the
>> condition variable class in the thread library and
>> noticed something odd. In version 1.7 of
>> condition.cpp, there is a bug fix for
>> condition::notify_one. At the beginning of the
>
On Tue, 18 Feb 2003, Alexander Nasonov wrote:
> With a help of boost::dynamic_any::call operation (not yet implemented) it's
> possible to use boost::dynamic_any::any instead of Boost.Function. Though
> this new solution is less specialized and probably slower then
> Boost.Function it has one ad
Douglas Paul Gregor said:
> On Tue, 18 Feb 2003, William E. Kempf wrote:
>> Douglas Gregor said:
>> A reasonable concern. But if we keep only release versions of
>> generated documentation in CVS, I don't think it will be too severe.
>> Intermediate doc changes would either have to be accessed d
On Mon, 17 Feb 2003, Beman Dawes wrote:
> At 06:24 PM 2/17/2003, Douglas Gregor wrote:
> >Well, you'll have the doc source on your machine, and can generate
> whatever
> >format you want.
>
> Where is this documented? How long does it take? It there a way to only
> regenerate the files that chang
On Tue, 18 Feb 2003, William E. Kempf wrote:
> Douglas Gregor said:
> > You probably caught me messing with the scripts (and therefore
> > regenerating the documentation in-place).
>
> Long term, this wouldn't be satisfactory. The scripts should be generated
> in a seperate location to minimize t
Jeff Garland wrote:
Take a look at bosot/date_time/compiler_config.hpp which
does something similar. All we need to do to fix these regressions
is add the compiler to the list of those that don't have std::abs
at line 34. Turns out that some compilers that support long long
do define a versi
First, let me say that this looks like a good library. Secondly, let me say
that I have not looked at the implementation... Now, on to the comments :)
1) I'd like to see a short high-level document that compares Boost.Variant
with Boost.Any, showing the advantages and disadvantages of each. Thi
> Many of the regression tests for the date time library are failing
> currently because the library relies on std::abs being
> available. AKAIK, the C++ standard doesn't require this so the library
> shouldn't make use of it.
>
> Maybe datetime should specify it's own version of abs like this:
In looking at the Mac OS (Darwin) regression tests to see why there are so
many failures, a number of tests are failing with only this message:
/usr/local/boost/boost/type_traits/is_float.hpp:22: warning: use of `long
double' type; its size may change in a future release
/usr/local/boost/boost/
Hi there,
currently, the is_member_func_test fails for VACPP6 with the following
error messages:
"/home/auto/schoepf/src/extern/boost-cvs/boost/type_traits/is_member_function_pointer.hpp",
line 37.29: 1540-1206 (S) The class template instantiation of
"is_mem_fun_pointer_impl" is ambiguous.
"/h
Fernando Cacciola wrote:
> I'm trying the variant library, by currently it doesn't
> compile with bcc551.
> I'd like to be able to compile it with my compiler so I can base my
> vote (tentatively to accept it) on more than the documentation
> and interpretation of the code.
Thanks for the tentativ
With a help of boost::dynamic_any::call operation (not yet implemented) it's
possible to use boost::dynamic_any::any instead of Boost.Function. Though
this new solution is less specialized and probably slower then
Boost.Function it has one advantage demonstrated in the example below:
typedef b
Many of the regression tests for the date time library are failing
currently because the library relies on std::abs being
available. AKAIK, the C++ standard doesn't require this so the library
shouldn't make use of it.
Maybe datetime should specify it's own version of abs like this:
#include
Hi there,
currently, dynamic bitset tests fail for VA6 because the library
doesn't correctly detect that a standard compliant allocator is available.
Therefore I propose the attached patch to be applied to
boost/detail/dynamic_bitset.hpp. The patch uses BOOST_NO_STD_ALLOCATOR
to check if a wor
Hi there,
currently the constructors test of the multi array library fails for
VACPP6. This is due to the fact that the test uses an unsigned int
where a size_type should be used.
The attached patch replaces the unsigned int with size_t which allows
the test to pass for VACPP6 and hopefully do
{This is a second attempt to post}
With a help of boost::dynamic_any::call operation (not yet implemented) it's
possible to use boost::dynamic_any::any instead of Boost.Function. Though
this new solution is less specialized and probably slower then
Boost.Function it has one advantage demonstrat
Scott McCaskill wrote:
> I was just looking at the win32 implementation of the
> condition variable class in the thread library and
> noticed something odd. In version 1.7 of
> condition.cpp, there is a bug fix for
> condition::notify_one. At the beginning of the
> function, a mutex is acquired,
Gennadiy Rozental said:
>> > The code never promised to work in multithreaded environment, nor
>> even to be thread save. It is in my to-do list. Though recent hands
>> in several situations may require address some of these issues
>> sooner.
>>
>> What?!? Where's the big, bold disclaimer about t
Jeff Garland writes:
> Today is the start of the formal review of the Variant library
> by Eric Friedman and Itay Maman.
Firstly, I vote to ACCEPT the Variant library into boost, as it fills a real
need. However, I have some comments:
* Nowhere is it documented that using incomplete as a type
Douglas Gregor said:
> On Monday 17 February 2003 04:49 pm, Beman Dawes wrote:
>> At 02:00 PM 2/17/2003, Douglas Gregor wrote:
>> >They're always available here, regenerated nightly in HTML, DocBook,
>> FO, PDF, and man pages:
>> > http://www.cs.rpi.edu/~gregod/boost/doc/html/libraries.html
>>
On Monday 17 February 2003 02:30 am, Samuel Krempp wrote:
> The mandrake 9 box used for the linux regression tests seem to fail
> static-linking tests.
>
> http://boost.sourceforge.net/regression-logs/cs-linux-links.html#format_tes
>t1%20gcc /usr/bin/ld: cannot find -lstdc++
> collect2: ld returned
Ed Brey wrote:
>
> I vote that variant be accepted into boost. I read all the
> documentation, and tried out the code in a simple test under
> VC7. I am very pleased with this library. Following are a
> comments I have that can help make it even better:
Thanks for the favorable review. I'll t
At 06:24 PM 2/17/2003, Douglas Gregor wrote:
>On Monday 17 February 2003 04:49 pm, Beman Dawes wrote:
>> Having the docs locally on my own machine is just a lot more
>> satisfactory. Cheaper, too (my Internet access is metered service.)
>
>Well, you'll have the doc source on your machine, and can
96 matches
Mail list logo
