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
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 try
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 1
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
That really
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 incompleteT as a type
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 that!
It's
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, but
{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
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
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
Many of the regression tests for the date time library are failing
currently because the library relies on std::abslong long 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:
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 tentative
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_implvoid (UDT::*)() is
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
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 the
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 change, or
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 directly
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
function,
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
namespace
Eric Friedman wrote:
In the past we sought to support the following...
variant... var;
T* p = extractT(var);
T r = extractT(var);
...but it had to be dropped because (essentially) ambiguity exists
between the following:
template typename T, typename Extractable
T
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 up
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
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 discarding its current
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.
;-)
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
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
7.1.
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 catch.
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 various
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
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_one. At the
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
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 conversion
to bool.
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.
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#...
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 its own
-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.
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
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
arrange for
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:
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'
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 base my
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
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
[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.hpp:22:
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 ;
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)
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:
[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 refer to
[EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]..
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Eric Friedman [EMAIL PROTECTED] wrote in message
003c01c2d6f7$2a812c90$49390c80@erk">news:003c01c2d6f7$2a812c90$49390c80@erk...
[...]
template typename T
void operator()(const T operand) const
{
operand.~T();
}
[...]
Is the destructor really a const function?
Dave
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 found by
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
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
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.
See
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 what would
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 anything
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
functionality
"David B. Held" wrote:
[...] template typename T 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 called is not changed at all, thus
(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 other
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 still
Itay Maman [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
David B. Held wrote:
[...]
template typename T
void operator()(const T operand) const
{
operand.~T();
}
[...]
Is the destructor really a const function?
The object
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 does not need
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 you
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 says it's
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?
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
Jeff Garland [EMAIL PROTECTED] writes:
Many of the regression tests for the date time library are failing
currently because the library relies on std::abslong long being
available. AKAIK, the C++ standard doesn't require this so the library
shouldn't make use of it.
Maybe datetime
David Abrahams wrote:
BTW, I just realized that a conversion from variantT to optionalT
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
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()
{
Ck ck;
}
2.
void f()
{
typedef Ck ck_type;
ck_type ck;
}
3.
typedef Ck ck_type;
void f()
{
ck_type ck;
}
The type of ck
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 doesn't need
testing.
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 g
Thanks for the explaination.
--
AlisdairM
David Abrahams wrote:
[snip]
BTW, I just realized that a conversion from variantT to optionalT
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
-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
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).
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 release.
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 Monitor
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, abstracting the syntax
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 the
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
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 and
Hi,
I want to encapsulate boost::find in a template
method in a base class for easier use.Here is some code:
#include boost/function.hpp#include
boost/bind.hpp
class CWindow {public:CWindow()
{SetEventHandler(CWindow::OnCreate); // this call
works}long OnCreate() {return
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 Monitor
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::any from this
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
able to
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
86 matches
Mail list logo
