Peter Dimov wrote:
[snip]
Provide operator. Wait six months. Collect feedback. If there is evidence
that operator is evil, remove it and document why it is not supplied.
OK, I'm willing to go along with this. I'll probably also include
operator==, with a similar plan for future evaluation.
Mat Marcus [EMAIL PROTECTED] wrote:
--On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola
[EMAIL PROTECTED] wrote:
Joel de Guzman [EMAIL PROTECTED] wrote in message
One can think of an optionalT as conceptually a specialized but
nevertheless, *IS-A* T, with the added
Fernando Cacciola [EMAIL PROTECTED] wrote:
Direct value accesing via implicit conversion: int i = opt
seems wrong because this is the operation that can lead to undefined
behaviour.
Doesn't have to be undefined behaviour.
Yes it does.
Accesing a value that isn't there is by all means
Dave Gomboc [EMAIL PROTECTED] wrote:
[Fernando Cacciola]
The most fundamental point is that being Haskell a pure functional
language there is no possibly undefined behaviour to worry about,
so Maybe doesn't need to address this issue as optional does.
... and later ...
I account the possibly
On Mon, Sep 01, 2003 at 04:05:59PM -0600, Dave Gomboc wrote:
[Brian McNamara]
do_something( adapt( 3 ) );
do_something( adapt( nilableint(3) ) );
do_something( adapt( foo ) ); // foo has unknown type
But I'd like to write
do_something(3);
On Tue, Sep 02, 2003 at 09:05:59AM +0800, Joel de Guzman wrote:
My attempt to image optionalT as conceptually a specialized but
nevertheless, *IS-A* T, with the added specialization that it can
be in a dead-uninitialized state. Is a feeble attempt to re-sell the idea
of the concept that will
On Friday 29 August 2003 10:53 pm, Eric Friedman wrote:
P.S. Has there been any progress in handling BoostBook documentation in
CVS? Perhaps Greg or MetaComm can run nightly builds? (This of course does
not solve the problem of offline access though...)
There has been no progress, though it is
Joel de Guzman [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED]
Fernando Cacciola [EMAIL PROTECTED] wrote:
variant throws throws a bad_get exception
when you get a reference to a T which is not the held type. I don't see
a problem why you can't do something similar.
Pardon
On Saturday 30 August 2003 08:00 am, David Abrahams wrote:
Misha Bergal [EMAIL PROTECTED] writes:
Eric Friedman wrote:
P.S. Has there been any progress in handling BoostBook documentation in
CVS? Perhaps Greg or MetaComm can run nightly builds?
We can do that. Is there any info on how
[Fernando Cacciola]
I'm saying that the choice made by variant in this regards is to the
code using get as hopeless as undefined behaviour. I don't think that
preconditions (and exceptions thereof) should be used to arbitrarily
make the illusion of giving meaning to an operation that is
On Monday 01 September 2003 07:53 am, Alexander Nasonov wrote:
I'm asking for voting for the new name of dynamic_any. Please, give you
preference.
Here is my discussion about the name with Kevlin Henney ( and empty
prefix - Kevlin, - me)
Between the two: adaptable_any is better, I think.
On Mon, Sep 01, 2003 at 09:22:01PM -0600, Dave Gomboc wrote:
[Fernando Cacciola]
I'm saying that the choice made by variant in this regards is to the
code using get as hopeless as undefined behaviour. I don't think that
preconditions (and exceptions thereof) should be used to arbitrarily
Dave Gomboc [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED]
[Fernando Cacciola]
I'm saying that the choice made by variant in this regards is to the
code using get as hopeless as undefined behaviour. I don't think that
preconditions (and exceptions thereof) should be used
--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
Apropos of which, I now think that the Boost UserAllocator requirements
should be the default for components that parameterize how they use
memory, with the Standard Allocator requirements being used only for
components that need what they
--On Monday, September 01, 2003 9:52 PM -0400 Brian McNamara
[EMAIL PROTECTED] wrote: [snip]
As a final aside, I think much of this thread is degenerating into
Parkinson's Bicycle Shed[*], with respect to is it a
pointer/container/X? At this point, I think we know what set of
methods should be
--- David Abrahams [EMAIL PROTECTED] wrote:
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
Dave Gomboc [EMAIL PROTECTED] writes:
[Fernando Cacciola]
The most fundamental point is that being Haskell a pure functional
language there is no possibly undefined behaviour to worry about,
so Maybe doesn't need to address this issue as optional does.
... and later ...
I account the
Eric Friedman [EMAIL PROTECTED] writes:
Peter Dimov wrote:
[snip]
Provide operator. Wait six months. Collect feedback. If there is evidence
that operator is evil, remove it and document why it is not supplied.
OK, I'm willing to go along with this. I'll probably also include
operator==,
John Maddock schrieb:
[snip]
If that is true: Why does the flag regbase::use_except (officially)
exist?
It's a historical accident and should have been removed from the docs.
OK. So it seems that I should not write code which explicitely mentions
regbase::use_except?
Lets assume, that
Douglas Gregor wrote:
Between the two: adaptable_any is better, I think.
Because I like throwing wrenches: have you considered a very different
name such as polymorphic or just poly. The idea is that we read:
polyless_than_comparable, equality_comparable
as a type that is polymorphic
I have been attempting to build boost 1.30.2 for a number of platforms.
I also wish to generate the html testsuite output for several reasons -
My own peace of mind, because we are using a reasonably large number of
platforms (some of which do not appear on the status tables), and so I
can see
[EMAIL PROTECTED] writes:
I've recently been discussing the guideline recently added to the exceptions
policy page with Dave Abrahams and he has asked me to post my views here.
There is a seductive form of arguement that I've seen repeatedly lead
projects into trouble which has made me very
I've done this before as well.
But it's a very simple function.
And I assume TestAutoSelect is a macro.
Can I take a look at the code?
Yes, TextAutoSelect is a macro, because without using a macro, there is
no way to generate a wchar_t string literal (prefixed with L) from a
char string
David Abrahams [EMAIL PROTECTED] writes:
Dave Gomboc [EMAIL PROTECTED] writes:
[Fernando Cacciola]
The most fundamental point is that being Haskell a pure functional
language there is no possibly undefined behaviour to worry about,
so Maybe doesn't need to address this issue as optional
On Tuesday, Sep 2, 2003, at 05:42 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Monday, Sep 1, 2003, at 14:48 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
Conforming containers had better use them.
I'm sorry, but I think
At 05:17 PM 9/1/2003, Daniel Frey wrote:
On Thu, 28 Aug 2003 16:19:24 +0200, Douglas Gregor wrote:
On Thursday 28 August 2003 08:20 am, Daniel Frey wrote:
utility/tie was moved to tuple, so should we remove the obsolete
docs/references in utility now?
Please do.
Done. I also updated the
At 09:09 AM 9/2/2003, Matthew Towler wrote:
I have been attempting to build boost 1.30.2 for a number of platforms.
I also wish to generate the html testsuite output for several reasons -
My own peace of mind, because we are using a reasonably large number of
platforms (some of which do not
Hi Pavel!
Thank you very much for your comments. I agree with most of them. Thanks also for
the picture. Here are my notes to some of your comments.
Few notes to latest source:
1. circular_buffer_adaptor.html: the link in
The circular_buffer_space_optimized is defined in
the file
Gregory Colvin [EMAIL PROTECTED] writes:
I think part of my point was that *nobody* needs what they offer, if
you include construct/destroy.
Or rather that some implementations have failed to use what they
offer, and our standard unfortunately doesn't insist that they do.
It's not
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
I think part of my point was that *nobody* needs what they offer, if
you include construct/destroy.
Or rather that some implementations have failed to use what they
offer, and our
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
...
Dave:
I think I would rather see a MPL lambda expression or metafunction
class interface for allocator type parameters. It makes little sense
for the allocator's user to be
--- David Abrahams [EMAIL PROTECTED] wrote:
[...]
Just how do you propose to prevent people from writing their own
construct/destroy functions? And if they write an allocator from
scratch, but *don't* provide construct/destroy manually, where will
they come from?
What I meant is that if
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams
wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
I think part of my point was that *nobody* needs what they offer,
--- David Abrahams [EMAIL PROTECTED] wrote:
[...]
I think construct/destroy can be implemented as non-customizable
static functions in boost just for convinence.
I think the word static is not what you meant, and is what led me
to challenge the suggestion.
I used word 'static' because
Gregory Colvin wrote:
You are assuming that there was no good reason to allow an allocator
to hook construct and destroy, for instance to do some bookkeeping.
I'm curious. Have you ever seen such an allocator? I've always assumed that
construct/destroy/pointer are a but someone might need to
On Tuesday, Sep 2, 2003, at 11:39 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams
wrote:
...
I think you're missing my point. There's no reason that a stateful
allocatorT should have access to the
Iain K. Hanson [EMAIL PROTECTED] writes:
But is this a good design? It certainly isn't the only possible one.
(Making all the code depend upon the definitions of both Network_err and
File_system_err - which no doubt drags other stuff into the translation unit
- isn't a design choice I'd make
On Tuesday, Sep 2, 2003, at 12:27 America/Denver, Peter Dimov wrote:
Gregory Colvin wrote:
You are assuming that there was no good reason to allow an allocator
to hook construct and destroy, for instance to do some bookkeeping.
I'm curious. Have you ever seen such an allocator? I've always
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
So you would rather use this than use construct?
template typename T T* addressof(T v)
{
return reinterpret_castT*(
--On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor
[EMAIL PROTECTED] wrote:
On Tuesday 02 September 2003 01:36 pm, Mat Marcus wrote:
We're trying to use optional from 1.30.0 (sorry legal hasn't
approved our use of 1.30.2 yet). However on one compiler
(Metrowerks 8.3 PPC CFM) we're
On Tuesday, Sep 2, 2003, at 13:00 America/Denver, Peter Dimov wrote:
Gregory Colvin wrote:
On Tuesday, Sep 2, 2003, at 12:27 America/Denver, Peter Dimov wrote:
Then again, the Dinkumware implementation
dutifully calls construct and destroy, paying (and forcing me to pay)
the abstraction penalty
On Tuesday, Sep 2, 2003, at 12:51 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams
wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
So you would rather use this than use construct?
template
On Tue, 2 Sep 2003, Mat Marcus wrote:
--On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor
[EMAIL PROTECTED] wrote:
I suspect they are both '4', but that leaves me even more confused
as to why the alignment of std::pairdouble, double would be 8
(and how to get a POD type with
I'm just getting started with the date_time library, and I think I'm
gonna like it. I have some quibbles with the naming choices though
(shocking! me of all people!) For example, why is the nested
namespace called posix_time instead of, simply, posix? Once you're in
a date_time context it
The metacomm regression tests run failed last night because of the
following bjam failure:
boost-test(RUN) iterators : libs\multi_array\test\iterators.cpp
boost-test(RUN) compare : libs\multi_array\test\compare.cpp
boost-test(RUN) access : libs\multi_array\test\access.cpp
boost-test(RUN)
Gregory Colvin [EMAIL PROTECTED] writes:
Also, if shared_ptr only needs to allocate at construction time (I'm
not sure of this) we can avoid storing the allocator at all.
Then how to deallocate?
Using the custom deleter?
I'm reeling from the implication that the following is undefined
Douglas Gregor [EMAIL PROTECTED] writes:
http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/
You can build local copies of the documentation with BBv2 once you've read it
Thanks. It worked. We will be publishing HTML docs starting with this night's run.
--
Misha Bergal
On Tuesday, Sep 2, 2003, at 13:18 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
Yep. I still think UserAllocator is a good default, and that where it
doesn't suffice there is some value to playing nicely with STL.
So even when we come up with some beautiful new
Peter Dimov [EMAIL PROTECTED] writes:
Douglas Paul Gregor wrote:
[...]
struct A {
double d;
int i;
};
[...]
Are there any other crazy rules like this that you know of? We could
just add struct A from above to the list of types, or if there is a
CodeWarrior-specific extension (e.g.,
Pavel Vozenilek [EMAIL PROTECTED] writes:
14. Btw, isn't cb_iterator::operator[]() added by mistake? I have
never seen such an operation for iterator. No, iterators do have
this operator.
Oops, newer used before :-o
Is there some reason you're defining your own iterators instead of
--On Tuesday, September 02, 2003 3:32 PM -0400 Douglas Paul Gregor
[EMAIL PROTECTED] wrote:
On Tue, 2 Sep 2003, Mat Marcus wrote:
--On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor
[EMAIL PROTECTED] wrote:
I suspect they are both '4', but that leaves me even more confused
as to
Misha Bergal wrote:
The metacomm regression tests run failed last night because of the
following bjam failure:
boost-test(RUN) iterators : libs\multi_array\test\iterators.cpp
boost-test(RUN) compare : libs\multi_array\test\compare.cpp
boost-test(RUN) access : libs\multi_array\test\access.cpp
On Tuesday, Sep 2, 2003, at 15:00 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
Also, if shared_ptr only needs to allocate at construction time (I'm
not sure of this) we can avoid storing the allocator at all.
Then how to deallocate?
Using the custom deleter?
David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
Also, if shared_ptr only needs to allocate at construction time (I'm
not sure of this) we can avoid storing the allocator at all.
Then how to deallocate?
Using the custom deleter?
The deleter takes care of the pointee, but we
On Tuesday 02 September 2003 04:58 pm, Misha Bergal wrote:
Douglas Gregor [EMAIL PROTECTED] writes:
http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/
You can build local copies of the documentation with BBv2 once you've
read it
Thanks. It worked. We will be publishing HTML
--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
3. If your class is using STL containers, use boost::memory::allocator
adapter (see bellow).
Why not just use std::allocator?
Because boost::memory::allocator will use UserAllocator under the covers.
So if you customized UserAllocator
From: David Abrahams [mailto:[EMAIL PROTECTED]
Subject: [boost] date_time naming
I'm just getting started with the date_time library, and I
think I'm gonna like it. I have some quibbles with the
naming choices though (shocking! me of all people!) For
example, why is the nested
--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
T* _p;
Leading underscores are a no-no.
I didn't see it in boost naming convention docs.
Have I missed it?
Some STL implmentations use leading underscores for members.
Eugene
__
Do you Yahoo!?
Yahoo!
Suppose I want to know how many minutes there are in a particular
duration d? My intuition says:
d / minutes(1)
But there's no such operator. Why not?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other
On Tuesday 02 September 2003 05:01 pm, David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
Maybe adding struct { double x; } would be enough?
I think it would be safer to add struct { double T; } for each T in
the list of types, just in case.
I agree. I've checked in the following
The fractional seconds concept is undocumented. My guess it's
something like:
x.fractional_seconds() == x.ticks() % seconds(1).ticks()
This needs to be nailed down.
Also, the assymetry of those nice Construction by Count factories down
to nanosec(x) with the accessors which only include
Where is this documented, and what is nano in the table entry below?
static boost::date_time::time_resolutions resolution()
Describes the resolution capability of the time_duration class.
time_duration::resolution() -- nano
--
Dave Abrahams
Boost Consulting
Daniel Frey [EMAIL PROTECTED] writes:
Sorry, my fault. tie_example.cpp no longer exists, as 'tie' no longer
lives in 'utility'. Can you please remove the reference from the
test-file?
Sure.
A last question to the
build-wizards: Would it make sense to make the build system continue
if a
Mat Marcus [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
--On Monday, September 01, 2003 9:52 PM -0400 Brian McNamara
[EMAIL PROTECTED] wrote: [snip]
As a final aside, I think much of this thread is degenerating into
Parkinson's Bicycle Shed[*], with respect to is it a
Joel de Guzman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Mat Marcus [EMAIL PROTECTED] wrote:
--On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola
[EMAIL PROTECTED] wrote:
Joel de Guzman [EMAIL PROTECTED] wrote in message
One can think of an optionalT as
Mat Marcus [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
[snip]
Here's a question that tries to get to the crux of the pointer-like
interface matter. Should T* and optionalT both be models of a
pointer-like syntactic concept?
pointers, iterators and optionalT are indeed models of
--On Tuesday, September 02, 2003 10:48 PM -0300 Fernando Cacciola
[EMAIL PROTECTED] wrote:
[snip]
For this reason, and for the fact that I have some upcoming
deadlines at work, I'll summarize what I see and where I stand now,
then I'll step back a bit for a while.
I hope you come back
From: Fernando Cacciola [mailto:[EMAIL PROTECTED]
Mat Marcus [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Those who answer no to the above question may
prefer to write code that uniformly handles T and optionalT.
I doubt such uniformity can be implemented smoothly.
Fernando Cacciola [EMAIL PROTECTED] wrote:
You did sell the idea that it can be a union, but I held to the idea that
it can just as well be considered as *REALLY REALLY REALLY*
nothing else but a container that has a T or is empty.
I agree there is nothing wrong with the union model, but I
Joel de Guzman [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED]
Fernando Cacciola [EMAIL PROTECTED] wrote:
You did sell the idea that it can be a union, but I held to the idea that
it can just as well be considered as *REALLY REALLY REALLY*
nothing else but a container that
Fernando Cacciola [EMAIL PROTECTED] wrote:
Point taken.
There's no need to argue anymore.
I guess significantly more feedback will weight the balance.
Thanks for all your comments!
It might look the other way around but they were very helpful.
Bottom line is, and most importantly,
71 matches
Mail list logo
