[2003-08-30] Jeff Garland wrote:
Just did a CVS update and I am now unable to build date_time. This is on
Linux. I'm looking at the CVS check-ins, but maybe someone workon on the
build stuff might know right away what's wrong
bjam from libs/date_time/test results in:
[snip]
[2003-08-30] Jeff Garland wrote:
Replies to self...
Just did a CVS update and I am now unable to build date_time. This
is on Linux. I'm looking at the CVS check-ins, but maybe someone
workon on the build stuff might know right away what's wrong
Had to roll back the lastest change in
David Abrahams wrote:
Eric Friedman [EMAIL PROTECTED] writes:
Ultimately, I do not believe any ordering scheme will provide
meaningful, straightforward semantics. Assuming I am correct, I
propose that the variant library offer your ordering scheme -- but
only as an explicit comparison
Joel de Guzman wrote:
Although I don't see this as problematic:
optionalint x;
if (x)
foo(x);
Or perhaps:
optionalint x;
if (!!x)
foo(x);
We already have an implicit conversion to safe_bool and an
operator ! anyway. Keep it. There's nothing wrong with it:
Threading support is on when BOOST_HAS_THREADS is defined, and off when
it's
not, or forced off by defining BOOST_DISABLE_THREADS, you'll find both
of
these mentioned in the configure generated user.hpp (and in the config
docs).
So if I my program runs only on systems that I know support
David Abrahams [EMAIL PROTECTED] wrote
Eric Friedman [EMAIL PROTECTED] writes:
std::set my_variant, boost::variant_lessmy_variant
I had the same thought myself, though I'd be inclined to spend a
little time searching for a better name than less, since it doesn't
really mean that. Maybe
Hello Eric,
Eric Friedman [EMAIL PROTECTED] wrote
Dirk Schreib wrote:
[...]
In this example
typedef boost::variantT1, T2, ..., TN V;
V v1 = T1( x );
V v2 = T2( y );
V v3 = T1( z );
v1 v2 should always be true. And v1 v3 should be the same as T1( x )
T1( z ).
For
Jeff Garland wrote:
The regression test page seems to be on a diet
http://boost.sourceforge.net/regression-logs/
You can find some of the other results at
http://boost.sourceforge.net/regression-logs/release
However, I'm not sure wether that is official already.
Regards,
m
In this post I will put forward a use-case or two to help see whether
something a little different then the current version of optional
might be useful. I also begin making a case that a Concept like
PossiblyUninitializedVariable might be more generally useful than
OptionalPointee. As I mentioned
Daniel Frey wrote:
Fernando Cacciola wrote:
My main argument is that if those were allowed, you could write:
optionalint opt ;
opt = 1 ;
int i = *opt ;
and the assymetry didn't look right to me.
I agree that this looks wrong. What about this syntax:
optionalint opt;
*opt = 3;
int i =
So I completely disagree that optionals should mix the interfaces of
optional and the wrapped object into one. I think there should be an
explicit unwrapping operation. But this is just my opinion, based on no
practical evidence/experience, and I'm sure there are trade-offs either
way. I'll
--On Sunday, August 31, 2003 10:29 AM -0400 Brian McNamara
[EMAIL PROTECTED] wrote:
On Sun, Aug 31, 2003 at 12:34:39AM -0700, Mat Marcus wrote:
In this post I will put forward a use-case or two to help see
whether something a little different then the current version of
optional might be
[2003-08-31] Jeff Garland wrote:
On Sun, 31 Aug 2003 09:59:26 +0200, Martin Wille wrote
Jeff Garland wrote:
The regression test page seems to be on a diet
http://boost.sourceforge.net/regression-logs/
You can find some of the other results at
Hi all,
I have written a relatively small library which I've found pretty useful
in my own projects. I have to deal with std::basic_string objects a lot
in my applications, and I almost always write template code so that the
same code works with both std::string and std::wstring types. The only
Daniel Frey [EMAIL PROTECTED] wrote:
Joel de Guzman wrote:
Although I don't see this as problematic:
optionalint x;
if (x)
foo(x);
Or perhaps:
optionalint x;
if (!!x)
foo(x);
We already have an implicit conversion to safe_bool and an
operator !
On Aug 31, 2003, at 7:45 AM, Hartmut Kaiser wrote:
Please have a look at the FAQ here:
http://www.boost.org/libs/spirit/doc/faq.html#scanner_business
This should solve your problem.
Thanks, that helps, but I still have a question or two. The FAQ says
it is best to avoid rules as arguments to
--On Sunday, August 31, 2003 1:35 PM -0400 Brian McNamara
[EMAIL PROTECTED] wrote:
So I completely disagree that optionals should mix the interfaces of
optional and the wrapped object into one. I think there should be an
explicit unwrapping operation. But this is just my opinion, based
on no
James W. Walker wrote:
Thanks, that helps, but I still have a question or two. The FAQ says
it is best to avoid rules as arguments to the parse functions, but
then what are rules good for? How else am I going to do any
nontrivial parsing?
Use grammars (see here:
Joel de Guzman [EMAIL PROTECTED] writes:
What I am trying very hard to say is to stick to only *ONE* interface
and one concept.
Optional is a container. I've never seen a container in C++ which didn't
have both a value interface and an element-access interface. How do
you propose to achieve
Joel de Guzman [EMAIL PROTECTED] writes:
Hi,
Here's another use-case...
We are working on an alternative semantic action scheme with Spirit
that will be a lot more easier to use than the current scheme. With this
scheme, the signature of the semantic action will be dependent on the
rule
Gregory Colvin [EMAIL PROTECTED] writes:
But indeed allocate/construct/deallocate/destroy is more work than
^^^^
Oyeah. These two absolutely don't belong in allocator, period. Do
any implementations even use them? Allocators exist to provide a
Peter Dimov [EMAIL PROTECTED] writes:
David Abrahams wrote:
Eric Friedman [EMAIL PROTECTED] writes:
Ultimately, I do not believe any ordering scheme will provide
meaningful, straightforward semantics. Assuming I am correct, I
propose that the variant library offer your ordering scheme --
On Sun, Aug 31, 2003 at 10:41:15AM -0700, Mat Marcus wrote:
--On Sunday, August 31, 2003 10:29 AM -0400 Brian McNamara
First off, let me say I do think this is a compelling use-case.
...
I missed the beginning of this thread, but I imagine the motivation
is to avoid having to say
On Sun, Aug 31, 2003 at 11:11:10AM -0700, Mat Marcus wrote:
--On Sunday, August 31, 2003 1:35 PM -0400 Brian McNamara
On Sun, Aug 31, 2003 at 11:59:42PM +0800, Joel de Guzman wrote:
It's really strange (and hard to explain) that you have to
dereference optionalB. Example:
F(tupleA,
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
If you want a second opinion, I'm in the just provide operator== and
operator camp.
But, IIUC, if operator is not provided, you'd oppose a std::less
specialization, right?
Right. When there is one and only one strict weak ordering
Brian McNamara wrote:
The point is, that Jan proposed to add something which has a hidden
overhead and I'm not sure it's a good idea. Instead of nested
if-else-cascades, the user could also write:
bool operator( const person lhs, const person rhs )
{
return
lhs.lastname != rhs.lastname ?
Gregory Colvin wrote:
[...]
Two small corrections:
shared_ptr currently uses std::allocator to allocate counts
regardless.
No, it uses plain new/delete by default. It is possible to get it to use
std::allocator via a #define.
[...]
versus standard Allocator
Allocator::pointer p =
On Sunday, Aug 31, 2003, at 13:13 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
But indeed allocate/construct/deallocate/destroy is more work than
^^^^
Oyeah. These two absolutely don't belong in allocator, period.
On Sunday, Aug 31, 2003, at 13:51 America/Denver, Peter Dimov wrote:
Gregory Colvin wrote:
[...]
Two small corrections:
shared_ptr currently uses std::allocator to allocate counts
regardless.
No, it uses plain new/delete by default. It is possible to get it to
use
std::allocator via a
Peter Dimov [EMAIL PROTECTED] wrote
David Abrahams wrote:
But, IIUC, if operator is not provided, you'd oppose a std::less
specialization, right?
Right. When there is one and only one strict weak ordering (equality) for
a
type, not using operator and operator== because some users might
30 matches
Mail list logo
