omes first.
There's still something wrong with the example though:
the first
stops[i]
index from 1 (because 'i' is 1 already when the body is entered)
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
to 5.4, the result of the expression
(i++ < 10)
is unspecified (there's no sequence point between the operators)
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
nterface. Perhaps we were barking up the wrong tree?
>
Maybe,
BTW, the right variant would be variant, not variant
since variant requires the first type to be default constructible.
A small issue is that variant<>::get() always check and possibly throws,
while optional<>::get() wil
"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 *REAL
onal is influenced to meet
> more of my needs, then of course I will be pleased. If not, I'm still
> learning about the design space from you and others on this list, so I
> benefit either way.
>
So do I.
I've already planned important fixes thanks to you, Joel and Dave G.!
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
lized storage available, e.g.
> unsafe_reference()
What do you need this for? (provided direct assignment is supplied)
>* Works reasonably well with tie()
This will be covered.
>* No double storage penalty
And this of course is provided now.
> Clearly optional is a fine pi
"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
"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&#
Joel de Guzman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Fernando Cacciola <[EMAIL PROTECTED]> wrote:
>
> >> Even if I agree with you that an optional should not be a T,
> >> an optional is definitely not a pointer to T.
> >>
>
Joel de Guzman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Fernando Cacciola <[EMAIL PROTECTED]> wrote:
> > Joel de Guzman <[EMAIL PROTECTED]> wrote in message
>
>
> > Direct value accesing via implicit conversion: int i = opt
> > s
Joel de Guzman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Fernando Cacciola <[EMAIL PROTECTED]> wrote:
>
> > First of all, let's not confuse syntax with semantics.
> > optional<> HAS strict value semantics.
>
> No it does not.
same line, we could make optional visitable:
>
And so about this.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ou expect to get out of it.
> > I think the same is true of optional; the call to operator*() (or
> > whatever) says "I want the T type" (rather than the 'none').
>
> Right. In fact, looking at it more closely, I *could* almost agree with you
> that an op
strange at all; an optional is not a B!
>
Right.
Just like any XYZ is not an B, so the middle line should have
the cannonical form:
XYZ b = get<2>(args).get();
Therefore, it is optional::get() that needs to be fixed, not optional::operator*(),
and not adding an implicit conversion to T.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
e the only problem with this is the
potential conceptual confusion (since this operation is always
defined), and I prefer to address this problem at the
documentation level.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ow the same
syntax to be used with entities that are NOT pointers.
The particular choice of operators is to allow pointers to be
models of the concept.
Perhaps it is the name which is misleading. It can be renamed as
PossiblyUninitialized if that helps.
And it should incorporate initialization and a
rovided but a separate methods called
get_ptr() given the expected meaning of a method named get() for
something that is a value container.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
t; has get() as a value accessor.
optional<> has operator*() with the same semantic
(forget about optional's get() now)
> 2) Only one underlying semantics (value-semantics) as opposed to
> (sometimes value, sometimes pointer semantics)
There is just one underlying semantic in optional: value semantics.
> and 3) Plays well
> with generic code (I'll give another use-case in addition to Mat's).
>
This can be addressed by fixing optional::get() to return a reference
instead of a pointer.
(more on this on another post)
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
s not supposed to make optional<> pretend it is a pointer.
It is clearly not and the documentation says so quite clearly, I think.
And if it doesn't, then it is the documentation that needs to be fixed.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Brian McNamara <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Sun, Aug 31, 2003 at 09:58:45AM +0800, Joel de Guzman wrote:
> > Fernando Cacciola <[EMAIL PROTECTED]> wrote:
> > > Hi Mat,
> > >
> > > Thanks for the input.
> > &g
Joel de Guzman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Fernando Cacciola <[EMAIL PROTECTED]> wrote:
> > Hi Mat,
> >
> > Thanks for the input.
> >
> > optional<> is now out on the field and it is the only utility of its k
Daniel Frey wrote:
> Fernando Cacciola wrote:
>> My main argument is that if those were allowed, you could write:
>>
>> optional opt ;
>> opt = 1 ;
>> int i = *opt ;
>>
>> and the assymetry didn't look right to me.
>
> I agree that this looks
>
> > Does it matter what happens when T is an auto_ptr?
>
> Hmmm, an optional auto_ptr. What an interesting mix. Well, I'm
> not sure. Fernando?
>
Can't really tell... but'll play with it to see the implications.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
fication"). Or how about alternatives like
> 'eor', 'lxor', 'logicxor', you-name-it...?
>
Good idea :-)
I'd use 'BOOST_LXOR'.
I'd implement it as:
#define BOOST_DETAIL_LXOR(x) !(x) : !!(x)
which would work with classes without bool/safe
"Jens Maurer" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
> Fernando Cacciola wrote:
> > Recently, Jens Maurer changed the guard at function scope
> > from:
> >
> > #ifndef __GNUC__
> > to
> > #ifndef BOOST_NO_STDC_NAMESP
David Abrahams <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> [sniped]
> > How do I apply the patch?
> > I mean, what do I do with CVS to have it on the right branch/tag.
> > (I gu
David Abrahams <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> > David Abrahams <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >> "Fernando Ca
David Abrahams <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> >> I'm trying to say that I think it's the wrong patch. The right patch
> >> would put the swap specializatio
Hurd, Matthew <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > -Original Message-
> > From: Fernando Cacciola [mailto:[EMAIL PROTECTED]
>
> > Note: although this library is new, google shows (to my
> > satisfaction) that there are already
David Abrahams <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> > The page is: http://boost.sourceforge.net/regression-logs/cs-Linux.html
> > So it should correspond to the HEAD revision.
>
ry is new, google shows (to my satisfaction) that there are
already a
couple of users of Optional out there.
TIA
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Abrahams <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> >>and anyway I don't see how it could help if you want to
> >> specialize something in std. Am I missing something?
&
David Abrahams <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> > David Abrahams <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >> "Fernando Cacciola&quo
Peter Dimov <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Fernando Cacciola wrote:
> > David Abrahams <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >> Which compilers are failing and where are the regression report
> >&g
David Abrahams <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > There are still problems with Optional, related to some compilers
> > not finding std swap(). I wrote
, sounds good. Thanks for the heads up.
>
> I'd like to be sure that some Booster signs up for this beta and starts
> running the Boost regression tests against it. And then follows up with bug
> reports to Borland as needed. Any bugs fixed in the compiler before it
> ships are b
he libraries and
> > submit appropriate diffs, but first I would like agreement a patch is
> > appropriate, and the correct form.
>
> I'm trying to say that I think it's the wrong patch. The right patch
> would put the swap special
> Aleksey Gurtovoy <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Fernando Cacciola wrote:
> > "Aleksey Gurtovoy" <[EMAIL PROTECTED]> escribió en el mensaje
> news:[EMAIL PROTECTED]
> > > David Abrahams wrote:
> > > > Here&#x
"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> [snipped]
>> So, I like Dave's macro, though I would prefer code generation macros
>> not to be put in code directly requiring users to know the inner
>> details of expanded code (for debugging, for in
ro, though I would prefer code generation macros not to be put in
code directly requiring users to know the
inner details of expanded code (for debugging, for instance).
Just a thought.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
se
here and I don't see a real benefit for
adding such complexity.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
In spite of the issues still to be resolved, I vote to ACCEPT the library, provided
that suitable test suites are added (which
could be along the lines Bill proposed + Jens latest suggestion)
Fernando Cacciola
___
Unsubscribe & other changes:
nternal representation
> with accessors. How about:
>
> int_type raw_value() const; // value in ULPs
> int_type unity_value() const; // representation of 1.0
> int frac_digits() const; // formerly scale()
>
H.
Why not: significand() (or mantisa()), and one()?
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
t (the BCD type on IBM
> mainframes, for example) in which the scale is part of the type.
>
> You're right about container; but remember that this class
> isn't intended for number-crunching; so I don't really care about
> assigning matrices, etc.
>
But this isn't about assigning matrices and number-crunching, it's about C++
assignment semantics.
The postcondition of equivalence for assignment is a strongly fundamental
feature of the C++ object model, and everything and everyone, not just
containers, relies on that.
No class, specially a class modeling a number, should violate that.
You can use something of the form "x[keep_scale]=y;" for that special
semantics.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
digits should be representable, including
N-nines.
That explains why numeric_limits<__int64>::digits10 is 18 even though
numeric_limits<__int64>::max() is a 19 digit number.
The leading digit, being a partial digit, cannot be accounted for in
'digits10'.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
)"
> >
>
> I don't think that's right. I can assign 123.45 to a decimal with
> a scale of 2 without rounding.
As long as 'precision' is >= 5.
> Do I misunderstand what you're saying?
>
No, the statement was n
t if the string contains no more
> > than scale digits to the right of the decimal point; otherwise
> > the value will be rounded as specified"
> >
> > This is incorrect, I think. If the string contains more than
> > (scale+1) digits, whether to the left or right of the decimal
> > point (or both), rounding will ocurr.
> >
>
> I think the documentation is basically correct; although if
> n * scale**10 can't fit in an int_type, then the behavior is
> undefined; so I guess rounding could occur in that case. 8-)
>
It is basically correct, but incomplete.
If the concept of 'digits' is formalized, alon with its relation to 'scale',
then this statement could simply say that "The conversion will be exact if
the string contains no more than 'digits()' digits (whole and/or decimal)"
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ld be
supported since, AFAICT, the promotion rules won't give ambiguity if that
additional ctor is added.
The docs say:
"The conversion will be exact if the string contains no more than scale
digits to the right of the decimal point; otherwise the value will be
rounded as specified"
This is incorrect, I think. If the string contains more than (scale+1)
digits, whether to the left or right of the decimal point (or both),
rounding will ocurr.
**
Best,
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Joaquín,
JOAQUIN LOPEZ MU?Z wrote:
> Hi Fernando,
>
> - Mensaje Original -----
> De: Fernando Cacciola <[EMAIL PROTECTED]>
> Fecha: Sábado, Julio 12, 2003 1:22 am
> Asunto: [boost] Re: Interest in multiindex_set?(again)
>
>> [snip]
>
> Now, in
Finally, I'm not entirely happy with the coallision response of 'modify' (or
maybe I don't understand it).
Is it ever possible to afford removing the colliding modified element?
Imagine I change the Social Security Number of Jhon, and by mi
as much as
possible,
at least for the meantime, since brand new compilers still lack proper support for it.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ses.
It is a matter of the number and type of operations performed yielding
the values to be compared. This is why the best method is highly
domain specific.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
city that brought us
to this discussion.
A comparison based on absolute errors is pesimistic, but for unbiased
comparisons it often results on what is expected, much more often
that relative-error based comparisons.
It isn't smart but is easy t
the Test library could provide
a straight-forward ABSOLUTE-ERROR comparator:
template
struct IsNearlyEqual
{
IsNearlyEqual ( N a_tol = N(1e-6) ) : m_tol(a_tol) {}
bool operator() ( N x, N y ) const
{
return x >= y ? ( x - y ) <= m_tol
Fernando Cacciola <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Thanks to Gabriel we may have an is_nan() right now.
>
Oops!
It was Joel de Guzman who offered his is_nan() implementation.
Sorry Joel :-)
Fernando
se expectations
about how the test works.
The poblems we are having now shows precisely the sort
of misconceptions I was referring to, so I suggest again
to uncouple the fp comparisons from the test library.
Fernando Cacciola
___
Unsubscribe &a
"Joel de Guzman" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
> Fernando Cacciola <[EMAIL PROTECTED]> wrote:
> > Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in
>
> >> Yes. It is an incorrect (unfortunately popular)
> >&g
--
Fernando Cacciola
fernando_cacciola-at-movi-dot-com-dot-ar
"Guillaume Melquiond" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
> On Fri, 4 Jul 2003, Fernando Cacciola wrote:
>
> > Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in message
>
popular.
Most compilers provide a non standard extension for this purpose.
For instance, Borland uses _isnan.
In general, these extensions are found on .
The best approach, IMO, is to have a boost::is_nan() with compiler specific
implementations.
Fernando Cacciola
Hi Joaquín,
I'm probably just misunderstanding your class.
So I'll wait for you to upload the documentation and
I will repost the issues then.
Best
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailma
e.
Depending on the application, this independece might
not be a good property.
How do I 'cluster' (that is, get all of) elements which
share some primary key and some secondary key, and so on?
BTW: I figure that there is some clustering and ordering invariant.
That is, elements sharing so
t this interface is invariant-safe,
but it strikes me as inneficient, not because of
the update per see but because of the element
copy (which has to be done twice)
An alternative would be something like this:
class multiindex {
...
template
Modifier update ( const_iterator it, Modifier Mod )
{
// iterator is private, so is access()
iterator mit = access(it);
Mod(*it);
update(*it);
}
...
} ;
Modifier is a user-suplied function object
which signature of the form:
void operator() ( element& e ) ;
One last concern: keys are related hierarchycally?
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ould be to use something along the lines of
the 'modifiers' used by the CGAL Library.
Check out the section named "Protected Access to Internal Representations"
on this page:
"http://www.cgal.org/Manual/doc_html/frameset/fsSupport.html";
Best,
Fernando Cacciola
"Alexander Terekhov" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
>
> Fernando Cacciola wrote:
> >
> > Alexander Terekhov <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > >
> > > Fernando Cacci
Alexander Terekhov <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Fernando Cacciola wrote:
> [...]
> > Motivated by A. Terekhov concerns, I think the license should, if at all
> > possible, expressely PROHIBIT anyone, including the copyright holder,
>
t holder,
from patenting the covered Software and any implied intellectual production.
Just my 0.02...
BTW, make sure to express our gratitude to those lawers for their time and
great work!!
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-point to integral conversions, the rounding mode can
be selected via the Float2IntRounder policy.
can be passed via a RawConverter policy.
The optimized automatic range-checking logic can be overridden
via a UserRangeChecker policy.
-
Fernando Cacciola
___
so I recommend to look
at it before designing a basic geometry library.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Joel de Guzman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> David B. Held wrote:
> > "Fernando Cacciola" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >> [...]
> >> I think I like this enhanced version.
&g
void const* address() const;
> void* address();
>
> max_size_type_that_fit_in_padding tag() const;
> void tag(max_size_type_that_fit_in_padding data);
> };
>
> Gennadiy.
>
I think I like this enhanced version.
'max_size_type_that_fit_
"Joel de Guzman" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> Fernando Cacciola wrote:
> > Hi,
> >
> > First question: I see that there is a phoenix subdirectory
> > under both boost/spirit and lib/spirit; does this mean
> >
entirely runtime algebraic number types
which mantain the expression tree dynamically
via software, which has really slow performance.
TIA,
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
me:
'nothing' is always less than 'something' but never less then 'nothing'.
I'll try to find some other background on this sort of ordering to see
other possible semantics (if any), and if there are any subtelties with
this one.
If it still looks OK after t
Pavel Vozenilek <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> - Original Message -----
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > > Following snippet of code fails:
> > > -
> > > #include
worth removing it but just thought I'd point it out incase anyone is
> interested.
>
Thanks for the info!
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ost::optional aux(0);
> if ((!!aux) && *aux == 0) {
> aux.reset(1);
> }
> }
> -
>
This one is a known Bortland bug.
In fact, operator!() is provided precisely in order
to allow the second form (with !!) to be used when
needed.
In Borland, the safe_bool operators works only if
the optional is the only element in the boolean
expression, as in: if ( aux ) ...
Thanks for the report!
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
s as that is. What is the chance of that
> happening?
>
It will happen one way or another... :-)
I only need to make my mind around the two alternatives I considered.
Look at the following thread and let me know which form would you prefer,and
why.
http://aspn.activestate.com/ASPN/Ma
"David Abrahams" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> > With BCC5.5.1 typename is _never required_ AFAIK, but it is with
BCC5.6.0(4)
>
> I guess in that ca
l phrase were not present).
>
Fixed. Thanks again!!
BTW: It took me a little to understand what you've said because
I didn't know about the em-dash. But I found a nice explanation
on the web about em/en-dashes, the hyphen, and their correct uses.
I used — directly since I foun
> work for all compilers. I hope you don't mind.
>
Thank you! :-)
You just saved me, becaue I was unsuccessfuly
trying to match the release procedures to
reflect main trunk changes on the release
candidate using TortoiseCVS, which is what
I've been using, but was kind of lost.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> >> * [config] BOOST_DEDUCED_TYPENAME
> >> Status currently unknown. John? Aleksey?
> >>
> &g
5.1 because
this compiler ICEs sometimes if typename is given inside <>, as in
typedef foo< typename bar::type > the_foo ;
but not always, so I'm not sure what to do in general.
bcc560 update 4 (bcc564) does not show this problem, though.
Fernando Cacciola
_
user, I wouldn't expect a 'Passed' to require something which is
not explicit in the regression results and which is not very common.
It wouldn't be so much of a problem, IMHO, if the status tables contained an
additional
FYI, with Update 4 __BORLANDC__==0x564
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
answer seems to indicate as much. ;)
>
> I do not have any use-case. Thanks anyways.
>
> Maybe it would be better to simply disable EH overhead with some BOOST
> macro. _That_ would be really really great then...
>
>
Which EH overhead?
Anyway, the problem with your propos
nversion_ if you
purposedly _slice_ the U subobject out of a T object
(if U is in fact a subobject of T), and wrap it into a NEW optional.
But you can't go back to a T, so this is not polymorphism, is straight up
conversion, just like converting a long double to a short loosing
along the way all the bits that don't fit.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ialy the same one used by boost::any,
thus, you can store the different optionals in a 'any' object
and traffic the 'anies' instead.
HTH,
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Philippe A. Bouchard" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> Fernando Cacciola wrote:
>
> [...]
>
> > It seems there is something one of us don't understand...
> > optional::m_storage has nothing to do with alignment to
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> David Abrahams wrote:
> > "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> >
> >> No, right're right :-)
> >> Is perfectly possible to simply discar
for -> and *. I think that -> and * should
> either be implemented in terms of a function that doesn't have a
> conditional in it or should be implemented in place.
>
Good point! Thank you.
I'll see to fix it, _probably_ for 1.30.0.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Philippe A. Bouchard" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> Fernando Cacciola (Home) wrote:
>
> [...]
>
> >> Well it depends on the platform but if sizeof(bool) == sizeof(int) on
> > Intel,
> >
> > ^^^
&g
"David Abrahams" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> > I thougth about placement new as a way to achieve
> > in-place optional construction, precisely because of
"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Fernando Cacciola (Home) wrote:
>
> [...]
>
> > I'm still not sure I understand what are you trying to do, but it
> > looks
> > like you want optional with in-p
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Fernando Cacciola \(Home\)" <[EMAIL PROTECTED]> writes:
>
> > optional opt( in_place(point(0,0),point(10,10)));
> >
> > here, in_place() is used to forward T&#x
- Original Message -
From: "Philippe A. Bouchard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 24, 2003 6:31 PM
Subject: [boost] Re: Re: Re: Re: partial<> proposal
> Fernando Cacciola wrote:
>
> [...]
>
> >> Given
gned like a bool...
> - Maybe aligned_storage<> should always destruct its object. It would be
> the user's responsability to construct the object before its destruction,
> otherwise the result would be undefined.
>
Why would this be useful?
> - Maybe we could creat
ase, I recently explored something which would look like:
optional opt( in_place(point(0,0),point(10,10)));
here, in_place() is used to forward T's ctor argument to optional<> so that
T is effectively constructed in-place right within the aligned storage.
Is this what you want?
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
006901c2d9c2$1db8fa60$1d00a8c0@pdimov2">news:006901c2d9c2$1db8fa60$1d00a8c0@pdimov2...
> Fernando Cacciola (Home) wrote:
> [...]
> > One is initialization from a null pointer value, as in:
>
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Fernando Cacciola \(Home\)" <[EMAIL PROTECTED]> writes:
>
> > Hi!
> >
> > I'm under the process of getting rid of some of m
1 - 100 of 247 matches
Mail list logo
