[boost] Re: Serialization Library Draft # 10
> Hi Robert! > > I'm looking at the docs right now and so far it looks _far_ better than anything I'v > seen > before. > Congratulations! > > A small nit-pick: > > The pointer example uses a for-loop construct of the form: > > for(i = 0; i++ < 10;) > > unless there's some clause elsewhere, according to 5.4, the result of the expression > (i++ < 10) > is unspecified (there's no sequence point between the operators) > Sorry... I thought these operators had the same precedence, but ++ has higher precedence so it comes 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
[boost] Re: Serialization Library Draft # 10
Hi Robert! I'm looking at the docs right now and so far it looks _far_ better than anything I'v seen before. Congratulations! A small nit-pick: The pointer example uses a for-loop construct of the form: for(i = 0; i++ < 10;) unless there's some clause elsewhere, according 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
[boost] Re: Re: Re: Re: Re: Optional, tie, and iterator_adaptor
"Joel de Guzman" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > Andrei Alexandrescu <[EMAIL PROTECTED]> wrote: > > > By the way, could optional use variant as a backend? > > I suggested that before. Now I think that it is not practical. > It can, but it will not be optimal. > Indeed. Using variant<> as a backend would be overkill for optional<> One of the reasons is that variant<> uses the double-storage technique to achieve higher exception safety than optional<> > I see it the other way now. I suggest that a partial specialization of > variant be written that takes advantage of optional > in its implementation. > This sounds reasonable. > I think now that the partial specialization of variant will > satisfy the anti-pointer-like crowd. variant seems to have the right > interface. 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() will use BOOST_ASSERT, so that end users can decide how to deal with uninitialized access. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
"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 has a T or is empty. > > > > I agree there is nothing wrong with the union model, but I don't see > > why is it better than the other. > > In fear that this is becoming non-productive and as I've already mentioned > that I respect whatever you decide on (I'm satisfied with the optional regardless > of its quirks), this will be my final post on the issue. > > The problem, the way I see it, is that optional mixes at least 3 concepts > all at once. First, the concept of variant, second is the concept > of optional as a container and third (I know you disagree, but) pointer- > like concept. I understand that the optional started out with the pointer- > like concept and moved on to embrace other concepts to satisfy the > needs of people who want some features which do not fit quite nicely > with the pointer-like concept (e.g. == and != and soon direct assignment?). > 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. Best regards, Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Optional, tie, and iterator_adaptor
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 optional both be models of a > pointer-like syntactic concept? > pointers, iterators and optional are indeed models of the OptionalPointee syntatic concept, yes. But this concept is not about pointer semantics such as aliasing or shallow copy, it is about the possibly undefined behaviour implied in expressions that take the form (*o) and o->. > > I imagine that those who would answer yes do so because they may want > to write generic code that uniformly handles pointers and possibly > uninitialized variables. No, this is not the intention. The purpose of the model is to leverage to syntatic aid that warns about the implied possibly UB of the expressions covered by the concept. > Those who answer no to the above question may > prefer to write code that uniformly handles T and optional. > I doubt such uniformity can be implemented smoothly. > As you know, my (current) answer is no. There may be a third group who want > both. The problem is that I find that the pointer-like interface is > distracting, but that may be because I'm unfamiliar with the use-cases > where you might want to handle T*'s and optional's uniformly or > even replace raw pointers with optional's, since pointers also > bring allocation issues with them. Instead I have been mainly focused > on replacing T's with optional's. Being able to replace T's with optional's is indeed a reasonable goal. I did it myself quite a few times. But I don't see how this can be made as smoothly as you wish though. > This is why I gravitate towards > having an optional that models a syntactic concept such as PU that > makes no mention of pointer-like syntax. > I see. > > By the way, I would also like to thank you for your work on optional > and your contributions to boost. I also appreciate your open > discussion of the design of optional and optional-like classes. > Thank you! > My posts are just those of a potential user who is interested in finding > the right point in the design space for my needs. If my use cases or > arguments prove useful to others or if optional 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
[boost] Re: Re: Re: Optional, tie, and iterator_adaptor
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 optional as conceptually a specialized but > >>> nevertheless, *IS-A* T, with the added specialization that it can > >>> be in a dead-uninitialized state. Maybe we'll call it a zombie > >>> object, undead object, you name it ;-) > > > > Hmmm. I'm not so sure about this. When I hear the phrase optional > > IS-A T with an added specialization I am reminded of the phrase a > > Square IS-A Rectangle with an added specialization which usually gets > > folks into trouble. [Theoretical aside: I still see optional as a > > sum/union, e.g. T + nil/ T | nil. That is I don't think we really want > > A + B < B (the sum/union of A and B) to be a subtype of A.] > > This is the model that I was trying to *sell* from the very very start when > optional first came out for review. And it is a good model indeed, which I liked from the very moment you mentioned it. > I never really understood why people > didn't see it that way. This is exactly the reason why I suggested looking > at other languages: to be able to get a solid grasp of the concepts behind > such a *thing* so as to be able to answer with utmost certainty the question: > : what is optional? > > Some people say it is a container. Not! > Why? What's wrong with saying that an object of optional *contains* an object of type T or is empty? The fact that Haskell doesn't model it this way, or that a discriminated union, T+nil, is a good model, doesn't mean that the container model is wrong. I don't see any significant advantage with the union model over the container model, and in fact, the union model implies the explicit usage of 'nil', something I don't find particularly convenient. > Some people say it is like a pointer > that can be NULL. Not! Here I agree. > And this uncertainty leads us to confusion, and, > ultimately: missguided syntax and semantics. > And you know here I disagree.. but let's leave this out. > [snipped] > I never really understood why I wasn't able to sell the idea that an > optional is *REALLY REALLY REALLY* nothing else but a > union of T and nil. > 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 don't see why is it better than the other. > [snipped] > > I would certainly hope to hear more from you. In fact, > I wish to hear more from the type-theory people such as Mat and Vesa > ;-) > I adhere to this wish! Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Optional, tie, and iterator_adaptor
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 > > pointer/container/X?" At this point, I think we know what set of > > methods should be in the interface (indeed, there could be methods > > both to return pointers and references; both to > > throw/fail-undefinedly, etc.) and the names/documentation issues > > will fall out with more experience. Just MO. > > > > [*] See bottom of > >http://www.boost.org/more/discussion_policy.htm > > > I'm not sure that we are discussing the shed just yet. I think we have > finally identified some of the key design alternatives and their > rationales. But it is true that this thread has received a number of > posts now and I'd hate to think that it is degenerating into noise. > Well, it isn't noise for me yet. I'm still finding it useful, at least some of the derivations that are not directly related to the OptionalPointee special syntax. > 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 later... :-) > Summary of thoughts on the existing optional: > It now seems to me that the idea of the pointer-like interface wasn't > so much to treat pointers and optionals uniformly. Rather, what I'm > hearing is that the pointer-like interface was chosen because of the > familiar syntax and idioms with regard to checking for initialization. > Extactly. > Additionally, optional deliberately does not require a throw or assert > upon uninitialized use, preferring to leave this as a QoI issue. > Which by the way means that it is you, the user, who decides what to do. That is, "undefined behaviour" in this context means that optional itsef doesn't attempt to define it and leave that to the client. With the current implementation, you define this by supplying a definition of boost::assertion_failed > I can respect this set of design decisions, and optional in this form > certainly has its uses. If optional grows to allow more transparent > co-existence with T (implicit construction, smooth tie > interoperability) then I expect it will become even more useful. > This will be provided in the next update. > Summary of thoughts on an alternative to optional: > While optional offers much of what I need, I still have trouble with > the pointer-like interface, largely for reasons of explainability. I > believe that clients/maintainers of the libraries that I write would > be distracted and confused by the a pointer-like interface or > container-like ideas. > Hmmm. I certainly understand your concern about operators * and-> But I don't see what's wrong with container-like ideas. I bet it is easier to explain that optional is a container that has a T or is empty than that it is a disciminated union of T and nil_t. After all, containers are everyday structures, yey variants are not. > What I really want is a simple class template > that models Possibly Uninitialized variables with no mention of > pointers at all. Perhaps I'd call it Maybe, or SmartVar. > > How would I specify it? Well at a high level my (sloppy, late night) > design goals would include: >* Interface driven by the desire to replace "dumb variables" with > "smart variables" -- that is variables that check that they've been > initialized before use, offer smooth interoperability with dumb T's > (e.g. assignment and implict operations where sound). > This will be supported by the next update. >* Where transparency is not feasable forego pointer-like syntax to > avoid any appearance of relation to pointers/iterators > OK, this won't. >* The action upon use while in uninitialized state shall be > specified or even specifiable (throw/assert/etc.). > I've leaven it undefined so it can freely specified (but without the need of sophisticated protocols) >* Backdoor to uninitialized 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 piece of work and satisifies many of these > goals. If it satisified a few more of them then I might find it usable > in my current projects, perhaps completely ignoring the pointer-like > protocol. For now I may work an a small lib that directly addresses > the goals above. > Good. Dave Gomboc is also working on an alternative,so let's see what comes out. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
"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 to arbitrarily > > make the illusion of giving meaning to an operation that is undefined at > > the conceptual level. > > For myself, and I think also for Joel, "nil" is a fully legitimate value, > But you never get a 'nil' when trying to get a 'T' out of variant, you get an exception and the offending code is aborted up to the catch handler, if any. > > not a hopeless, meaningless, conceptually undefined value. It's quite > clear that you don't share this view. The conceptual divide here is > surprisingly large. > > I'm surprised to find myself suggesting this, but perhaps instead of > debating this issue further I and like-interested people should create and > submit a high-quality implementation of nilable.hpp to Boost. If > accepted, people could then choose whichever best meets their > needs/expectations. > >From the perspective of a test field, it is quite reasonable to have a competing alternative so we can see what works better on the long run. But from the perspective of a library that is largely becoming a de facto standard for production code, I'm not sure how that would work for the end users. Anyway, you have my support if you want to do that... I promise I'll try to review it as impartially as I can. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
"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 me, but you are clearly mistaken! > I'm clearly misphrasing it, that 's for sure. What I mean is that for an operation that reads a value, the value as a result is IMHO the only _meaningful_ behaviour. So, reading a value that isn't there has undefined meaningful behaviour as I see it, meaning that the defined behaviour of throwing an exception is of little help to the code that tried to read it. Let me put it another way: why is there the concept of "undefined behaviour" at all? Because for some operations, anything but the expected outcome is so meaingless that we prefer to leave the exceptional case undefined than to fix an arbitrary behaviour. There are cases when undefined behaviour is used because a fixed fall back behaviour may not be universally implementable, but that's not always the case. IMO, accesing the value of an uninitialized optional is undefined behaviour and this behaviour cannot be defined _meaningfuly_ since throwing an exception is not really meaningful for the operation per see. > Are you saying that variant's > get(v) leads to undefined behavior? NO! > I'm not saying that, don't worry :-) 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 undefined at the conceptual level. Trying to get the wrong kind of type from a variant, or an uninitialized value from an optional, or a past-the-end element of an array, or a reference to an object pointed to by a null-pointer, or a short int representation of a very huge long double value are all conceptually undefined operations. Defining them as core-dumps, thrown exceptions, or whatever; is certainly useful at the overall engineering level, but the operations remain conceptually undefined. My argument about the Undefined Behaviour problem referred to the conceptual meaningful behaviour of value access. Any fall back behaviour that I might choose for engineering purposes don't make the operation any more defined w.r.t to the expected outcome. That is, if the value isn't there, the task trying to get it will abort whether a core dump ocurrs or an exception is thrown. Which one of these is, as I said, relevant at the global application level, but not at the operation level. So, I agree with you that some behaviour can be defined, but I prefer to leave it undefined just as vector::front() leaves undefined an attempt to access the first element of an empty container. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Optional, tie, and iterator_adaptor
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. > >> > > Definitely! > > If HTML had blinking banners I think I'd use one to state this :-) > > Nor should it model a pointer. > It tries not to model a pointer at least. The OptionalPointee concept was coined to stress this fact, by formalizing the syntatic meaning of operators * and -> independently of pointers. What I'm defending here is the idea of giving operators * and -> a meaning on their own: the possibly undefined value of its operands. That this choice of operators still makes the appearance that optional<> models a pointer I need to address on the documentation by a better formalization of the concept. > That was my point and the point of others who dislike *opt. > > > > Yet iterators are not pointers either but they do use > > operators * and -> > > Iterators are not pointers, but they model the pointer. > > >> Right. In fact, looking at it more closely, I *could* almost agree with you > >> that an optional is not a T. There is in fact a getter function (get). > >> In fact all three (tuple, optional and variant) have a get function. That's > >> fine, yet, here again, the optional does not jive well because it returns > >> access *by pointer* whereas both tuple and variant return access by > >> reference. > >> > > This get() issue we agree should be fixed. > > Agreed. If there's a way to get at the values through a generic get > function that unifies the access of optional with variant such that I > can think of optional as an optimized specialization of variant, > I would be very happy. With such an interface, I can simply ignore > the pointer-like interface, if you wish to keep it ;-) > All right, we're settled then! > > Thanks you very much! And BTW, kudos for such a well engineered > library! Spirit has been using it since v1.7 and I am very happy with > it. The comments I gave so far are merely my opinion. You are of > course free to have your own preferences :-) > > Keep up the good work! > Thank you! Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Optional, tie, and iterator_adaptor
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 > > 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 undefined behaviour. > Aren't you throwing an > exception or something? > This doesn't define the "access value" operation. It just defines the function that is used to implement it. But defining such a call doesn't help much from the POV of the operation. i.e., you cannot get the value if it isn't there and an exception here is no better at it than a core dump. Therefore, the operation is flaged as possibly undefined. Whether to detect and throw, or assert, or do nothing is QoI issue. If optional<> were to be someday standarized, implementators would decide how to deal with the undefined behaviour here. >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. > Doing something similar as an implementation detail is fine. Currently, I use BOOST_ASSERT, which allows the end user to control how to deal with it. Doing it as part of the interface, that is, contracting that accesing an uninitialized optional throws an exception has performance and portability problems. In most typical usages, you don't really need a runtime check to get always in the way of getting the value. In fact, the pointer like syntax is there precisely to help you be confident that an explicit check is not needed since the access syntax lends itself to well written code were uninitialized access is properly guarded in the client code, allowing you to leverage the speed of unguarded access while giving you at the same time the idiomatic power of a familiar syntax to access possibly uninitialized values. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Optional, tie, and iterator_adaptor
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. The accessors have pointer behavior! > Well, we would argue forever since it is a matter of how much weight it is put in each part of the behaviour and how that sum up to make it "X semantic". In the case of pointers, it is IMO the aliasing and shallow copy behaviour what is relevant to consider a given behaviour as pointer semantics. The presence of operators *() and ->() don't count as pointer "semantics" to me. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: generic uses of optional
Eric Friedman <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Dave Gomboc wrote: > [snip] > > I don't like get() because I cannot write x.get() when x is a POD. This > > would mean I have to support nilable and T with different code, > > which is exactly what I'm trying to avoid. > > Why not overload boost::get again for optional? This would certainly improve > consistency with variant. For instance: > This was my intention from the very beginning. I was just waiting for variant<> to be out there. > > In the same line, we could make optional visitable: > And so about this. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Optional, tie, and iterator_adaptor
Joel de Guzman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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
> > practical evidence/experience, and I'm sure there are trade-offs either
> > way. I'll explain the crux of my own reasoning below.
>
> One can think of an optional as conceptually a specialized but
> nevertheless, *IS-A* T, with the added specialization that it can
> be in a dead-uninitialized state. Maybe we'll call it a zombie object,
> undead object, you name it ;-)
>
Theoretically, yes.
But there are practical barries here.
Unfortunately, in C++ subclassing is the only subtying mechanism,
but you can't subclass a non class type, so you can't subtype
an arbitrary T.
IOWs, there is no way to completely implement an optional which
*IS A* T.
The closer we could get is to have an implicit ctor and and implicit
conversion to T, but that would only take us half the way, so there
is little practical sense in approaching the problem this way.
> > 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
> >> optional. Example:
> >>
> >> F(tuple, C> args)
> >> {
> >> A a = get<1>(args);
> >> B b = *get<2>(args); // strange!
> >> C c = get<3>(args);
> >> }
> >
> > I don't think it's strange at all; an optional is not a B!
>
> Even if I agree with you that an optional should not be a T,
> an optional is definitely not a pointer to T.
>
Definitely!
If HTML had blinking banners I think I'd use one to state this :-)
Yet iterators are not pointers either but they do use
operators * and ->
>
> > As another example, FC++ lists support conversion-to-bool as a test for
> > NIL:
> >fcpp::list l = NIL;
> >if( l ) // if l not empty
> > cout << head(l); // print first element
> > Clearly if 'l' were an optional, the "if" test would have a different
> > meaning. I know you've been supporting a separate way to do the test
> > (with "==none"), but I think that's completely arbitrary. The two
> > issues are both really the same issue, in my mind.
> >
> >
> >> Of all the types involved in the passing of arguments to the semantic
> >> actions, the optional doesn't fit nicely because it is the only one
> >> that has mixed value/pointer semantics. I am tempted to not use
> >> optional because of this and instead use variant,
> >> but I hate to miss the performance advantage of optional vs.
> >> variant.
> >
> > I have not used variant and know little about it, but I imagine you have
> > to explicitly tell a variant "which type" you 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 optional is not a T. There is in fact a getter function (get).
> In fact all three (tuple, optional and variant) have a get function. That's
> fine, yet, here again, the optional does not jive well because it returns
> access *by pointer* whereas both tuple and variant return access by
> reference.
>
This get() issue we agree should be fixed.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Optional, tie, and iterator_adaptor
Brian McNamara <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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 explain the crux of my own reasoning below.
>
In a way you're right.
My original optional<> submision followed this rule.
safe-bool was added because of the ubiquitousness of the
implicit boolean evaluation idiom.
Implicit construction and direct assignment was left out
precisely in order to keep both interfaces separated.
> 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
> > optional. Example:
> >
> > F(tuple, C> args)
> > {
> > A a = get<1>(args);
> > B b = *get<2>(args); // strange!
> > C c = get<3>(args);
> > }
>
> I don't think it's 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
[boost] Re: Re: Optional, tie, and iterator_adaptor
Brian McNamara <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Sun, Aug 31, 2003 at 12:34:39AM -0700, Mat Marcus wrote: > [snipped] > > So, here's an idea for something completely new which maybe helps fit > your requirements. I start with the motivating example: > >PossUninitVar begin, end; >tie( +begin, +end ) = out_edges(v,g); >for( Iter i = ~begin; i != ~end; ++i ) ... > > (Effectively operator~() fetches the value (or asserts if there is none), > whereas operator+() returns a reference to the yet-nonexistent value so > it can be filled in by someone else.) > > My original submission used a proxy operator*() to allow assignment in the same way you do here with operator+(). During the review I removed it because if expressions (*opt) implied possibly undefined behaviour when used a rvalues so should when used as lvalues. Yet assignment is always defined so be changed it by reset(). It didn't ocurred to me though to use _another_ operator instead, and so allow the definitely useful lvalue expressions. Right now however, I'm inclined toward direct assignment, ala variant, because 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
[boost] Re: Re: Optional, tie, and iterator_adaptor
Mat Marcus <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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. > > [snip use case] > FWIW, your use case of pretty common to me. I've used optional<> precisely as you did many times. In fact, I often found mayself adding optional<> to a local variable just because the flow changed and now the variable may reach a point being uninitialized. > After reading the documentation more carefully I learned that optional > models pointer behavior. I spelled out how the code might look: > > boost::tie(*begin, *end); file://sorry, ASSERT && looks too strange > > Wow, that looked strange to me. I don't think of begin and end as > pointers at all here. > Right, they're not pointers and you shouldn't see them as such. I think that your report is very important because it shows me that while one may expect the need for special constructs in order to 'access' an optional value, such need isn't there when one wants to initialize or assign an optional. It was very reasonable to expect optional<> to work with tie as that is just assignment and assignment is always defined. >I just want to model values that haven't been > initialized, and I maintain that initialized/unintialized is the > concept worth modeling (I'm not sure what its name ought to be, so for > now I'll just refer to it as the PossiblyUninitialized Concept). I agree here. > Such > a concept might perhpaps embody notions of initialization via > construction or assignment, testing whether the model has been > initialized, etc. Right. > It may (or may not) also be true that there is some > use in thinking of pointer/NULL as model of PossiblyUnintialized > variables, but seems to me that the current version of optional has it > backwards: I don't want to model all cases of possibly unininitialized > behavior as OptionalPointees. > I think that OptionalPointee's documentation failed its purpose. That concept is intended to be exactly what you proposed, except that I left initialization/assignment aside. The concept just explains that the operator * and -> syntax is used to access the a value that is possibly uninitialized, WITHOUT implying that a model of this concept IS a pointer. The concept was invented precisely to allow 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 assignment. Anyway, both concepts are 'conceptually' the same. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Optional, tie, and iterator_adaptor
Brian McNamara <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Mon, Sep 01, 2003 at 09:03:17AM +0800, Joel de Guzman wrote: > > Do it the ref, tuple and variant way: get(). But get(), as an > > element-access interface, should return a reference, not a pointer, as > > it does currently. > > Clearly I had not been paying enough attention earlier in the thread; I > was oblivious to the fact that get() was returning a pointer and not a > reference. I think get() (or operator*(), or however it ends up being > spelled) should indeed return a reference. > operator*() does indeed return a reference, and I agree that operator get() should too. Anyway, there is a pragmetic advantage in having a function return a pointer. It allow us to mix test+access with one call, as in: if ( T* p = opt.get() ) but this functionality can be provided 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
[boost] Re: Re: Optional, tie, and iterator_adaptor
Joel de Guzman <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Daniel Frey <[EMAIL PROTECTED]> wrote: > > Joel de Guzman wrote: > >> Although I don't see this as problematic: > >> > >> optional x; > >> if (x) > >> foo(x); > >> > >> Or perhaps: > >> > >> optional 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: > >> > >> operator unspecified-bool-type() const; > >> bool operator!() const; > > > > IMHO, there is something terribly wrong here because now optional has > > two interfaces. The interface of optional itself and the interface of T. > > If you think that optional can be used like T (having the > > value-interface), you are immediately fooled by if(x) as it doesn't > > check T's value. A pointer-interface is much cleaner as it gives the > > user a hint that he is using a wrapper and in practice, I always prefer > > to be a little more explicit on these things (even at the cost of an > > occasional * here and there) than to have silent bugs. > > If you really want it to be explicit, the first version, which I prefer > (and you snipped ;-) is so much better: > > optional x; > if (x != none) > foo(x); > > safe_bool conversion wasn't part of the original submision. I was against it for the reasons you give, but at some point I was conviced that the expressive power of the highly idiomatic implicit boolean evaluation was worth it. So many objects provide boolean evaluation through implicit conversion that it is nowaday the most common interface for this operation. > Who's fooling who? You said 2 interfaces, the current optional is > actually the one with the 2 interfaces. In some ways, it has a value > interface (construction, reset , ==, !=) and pointer interface on some > (*, ->, get). > What's wrong operators * and ->? Iterators use them, and they're not pointers. If the problem is that it makes optional<> appear as a pointer, then it is the documentation job to avoid it. > > What I am trying very hard to say is to stick to only *ONE* interface > and one concept. > How does the presence of operator* and -> makes two interfaces? optional<> has only one interface and one concept. It just happen to use the ubiquitous * and -> syntax to express the same notion that is expressed through those operators when they're used with pointers and iterators, but this doesn't mean that optional<> pretends to be a pointer or an iterator. > Syntactically, there's nothing inherently wrong with: > > if (x) > foo(x); > > We see it all the time with ints: > > int x; > if (x) > foo(x); > > Yet, I have to admit that after thinking about it some more, I realized > an ambiguity when T is bool. Example: > > optional x; > if (x) > foo(x); > > That is why I really prefer the more explicit syntax: > > optional x; > if (x != none) > foo(x); > > Implicit safe_bool was supported becasue it is extremely idiomatic. > A small price to pay, considering the advantages. 1) Unification of > the optional and variant where optional <--> variant. variant doesn't support implicit conversion to any of its bounded types. It does support implicit construction and direct assignment, as I've proposed for optional at my first post in this thread. variant<> 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
[boost] Re: Re: Optional, tie, and iterator_adaptor
Joel de Guzman <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Brian McNamara <[EMAIL PROTECTED]> wrote: > > > Offhand, the "pointer interface" for reading the value of an optional > > seems good to me. Being able to say > > > >optional x; > >... > >if( x ) foo( *x ); > > > > seems like a natural way to "sugarize" this in C++. > > IMO, this is better: > > optional x; > if (x == none) > foo(x); > > Although I don't see this as problematic: > > optional x; > if (x) > foo(x); > > Or perhaps: > > optional x; > if (!!x) > foo(x); > > I see the implicit value access (in foo(x)) as problematic for the reasons I gave before. > We already have an implicit conversion to safe_bool and an > operator ! anyway. Keep it. There's nothing wrong with it: > > operator unspecified-bool-type() const; > bool operator!() const; > Yes, I think this should be kept. There is a special section on the documention dealing with the specific case of optional just in order to support these _very_ idiomatic operations. > Perhaps it's just me, but I really dislike the * syntax. Why make optional > pretend that it is a pointer when it's clearly not! Then, we go on and give > it value semantics! C'mon! > The * syntax is 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
[boost] Re: Re: Optional, tie, and iterator_adaptor
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.
> > >
> > > optional<> is now out on the field and it is the only utility of its
> > > kind I've ever seen in C++, at least in real use. This has the
> > > drawback that there is very little experience with it. Therefore, in
> >
> > There's a lot of experience with it in other languages. Why not
> > leverage that? Haskell::Maybe for instance.
>
> I feel like Maybe works more smoothly in Haskell than in C++, but I
> haven't ever really tried to nail down the reasons why. This thread has
> me thinking about it more, though, so I'll share some general thoughts
> (as well as some suggestions for "optional" at the end).
>
> Two issues spring to mind immediately: pattern matching and monads.
>
> Pattern matching:
> Haskell's Maybe is a type constructor, and thus the value constructors
> Just and Nothing can be used in pattern matches. Pattern
> matching provides a common way to do the "test" and the "unwrap"
> steps. Code like
>
>optional o;
>...
>if( o )
> do_something( *o );
>else
> maybe_do_other();
>
> in C++ sometimes takes a form like
>
>o :: Maybe int
>...
>case o of Just x -> doSomething x
> Nothing -> maybeDoOther
>
> in Haskell. Since this form of using pattern matching to "case-ify" and
> deconstruct a datatype is a standard idiom in Haskell, nothing special
> needs to be done for Maybe.
>
> Monads:
> In addition, Maybe forms a monad, which means that you can use
> do-notation to string together computations involving Maybes. Code like
>
>optional x, y, z, result;
>...
>if( x ) {
> y = foo( *x );
> if( y ) {
> z = bar( *x, *y );
> if( z )
> result = baz( *x, *y, *z );
> else
> result.reset(); // being more explicit than I have to be
> }
> else
> result.reset();
>}
>else
> result.reset();
>
> can be written as
>
>x, y, z, result :: Maybe int
>...
>do x <- x
> y <- foo x
> z <- bar x y
> result <- baz x y z
> return result
>
> in Haskell, which uses the Monad's bind operation to sugarize over all
> the if-then-else plumbing to push Nothings all the way through the
> computation. In FC++, we have monad comprehensions, so it could be
> written as just
>
>maybe x;
>...
>fcomp_m()[ baz[X,Y,Z] | X <= x,
> Y <= foo[X],
> Z <= bar[X,Y] ]
>
> Comprehensions are unlikely to be used much in normal C++ code, though.
>
>
> In any case, I suppose my point with both of those issues is that
> Haskell already has some kind of standard/idiomatic way to sugarize over
> the details of dealing with Maybes. I don't think we have anything
> equivalent in C++, so it's not clear to me what we can learn from
> Haskell when trying to design the interface for optional in C++.
>
Hi Brian,
thanks fot the input.
I've reach a similar conclusion when I looked at Maybe for inspiration.
>
> Offhand, the "pointer interface" for reading the value of an optional
> seems good to me. Being able to say
>
>optional x;
>...
>if( x ) foo( *x );
>
> seems like a natural way to "sugarize" this in C++.
>
Great!
That's for I think too.
> As for the constructors, why not have a separate function for
> initializing optionals, a la Just/Nothing in Haskell? I am imagining
> something like this:
>
>template
>class optional {
> optional(); // or maybe public, depending on preference
> optional( const T& ); // private
>public:
> optional( const optional& );// still copyable,
> optional& operator=( const optional& ); // assignable
> ... operator bool ... operator*
>};
>template
>optional just( const T& ); // the constructor (a friend)
>
> Then you no longer have the issue of
>
>optional x(3);
>int r = *x;
>optional y = 4;
>r = *y;
>
> looking "funny" or "unbalanced", because now it's
>
>optional x( just(3) );
>int r = *x;
>optional y = just(4);
>r = *y;
>
> a
[boost] Re: Re: Optional, tie, and iterator_adaptor
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 kind > > I've ever seen in C++, at least in real use. This has the drawback that there > > is very little experience with it. Therefore, in a way it is a sort of > > There's a lot of experience with it in other languages. Why not leverage that? > Haskell::Maybe for instance. > Do you know of anything else besides Haskell? I don't, and I took the time to investigate Maybe looking at Haskell programs using it. As Brian pointed out, it is not so easy to port Maybe to C++ because its usage is extensively supported by Haskell features that are not present in C++. 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. > > > experiment, even though it is now a fixed part of Boost. > > optional<> will evolve, that's for sure, as user's experience show which > > design desicions were right and which were wrong. > > I might even deprecate it and submit a replacement if it becomes clear that a > > drastic change is neccesary. > > > > Right now I still believe that the pointer-like interface is correct, because > > I add it specifically to solve a real problem and it did solve it. > > My first optional (named differently then) had the problem that it was really > > difficult to track which variables were 'optionals' and hence it was easy to > > forget to make the neccesary steps to mantain integrity (not to use an > > uninitialized optional). At some point I realized that I needed something at > > the syntax level that help me keep in mind that those variables are possibly > > uninitialized, and so I moved from value() member functions to operatos * and > > -> > > If that's the only rationale for having the pointer-like interface, then pardon > me but, I find that very flimsy. There should be other means to attack the > problem (if it is a problem) without sacrificing the beauty of the interface. > I account the possibly undefined behavior of accesing an uninitialized optional as a real and important problem. >From now on I'll refer to this as the Possibly Uninitialized Problem: the PU problem in short. The interface, in one way or another, should address this. > > The pointer-like interface is just about syntax really. > > Instead of opt.value() you type (*opt) or opt-> > > This alone shouldn't be a problem. > > Right. > > > What I think it is a problem are other design descicions that I made in order > > to make other parts of the interface with the pointer-like interface. Namely, > > the lack of implicit construction and direct assignment. > > Sacrificing this in order to "track which variables were 'optionals'" ?, IMO, > is not a good idea. > I agree. > > > These two points are raised here by Mat and have been raised by many others > > in the past. > > > > 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. > > If optional had value semantics, it would be a lot cleaner: > > optional opt; > opt = 1; > i = opt; > First of all, let's not confuse syntax with semantics. optional<> HAS strict value semantics. If the choice of 'operators *', 'operator ->' and 'get()' as value accessors makes the appearance that is has pointer semantics, then it is the documentation that has to be fixed, not the interface. vector<>::begin returns an object with operators * and ->, yet these objects are not pointers, and once that is learned, people do not think they are pointers. Also, let's not think of the pointer-like interface as a unity: there are three items involved, namely *,-> and get(). We'll be better off considering them separately. Direct initialization: opt = 1 seems right since this operation is never undefined. This would mirror variant's interface. Direct value accesing via implicit conversion: int i = opt seems wrong because this is the operation that can lead to undefined behaviour. > For those concerned about "track"ability, they can use an easy to > grep alternative: > > optional opt; > opt .reset(1); > i = opt.get(); > Addressing the PU problem via a 'get()'
[boost] Re: Optional, tie, and iterator_adaptor
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 wrong. What about this syntax: > > optional opt; > *opt = 3; > int i = *opt; > opt->foo(); > This was exactly the way the originally submmited optional<> worked. I dropped it becasue reviweres thought that (*opt)=3 would lead to undefined behaviour just as if *opt were an rvalue. I realized that with true pointers, for instance, (*opt)=3 is in fact undefined behaviour, so I replace it with .reset() Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: [boost.optional && boost.variant] Why can't weallowreferences?
"Joel de Guzman" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > David Abrahams <[EMAIL PROTECTED]> wrote: > > "Joel de Guzman" <[EMAIL PROTECTED]> writes: > > > >> optional::reset ( T const& ) ; > > > > 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
[boost] Re: [Fun] (( a xor b )) formal review request...
Daniel Frey wrote:
> Paul Mensonides wrote:
>>> #define xor )?BOOST_DETAIL_XOR(
>>
>> FYI, you cannot legally define "xor" because it is specifically *not* an
>> identifier--even to the preprocessor. This is the primary difference
>> between "keywords" and textual "alternative tokens."
>
> I admit that I forgot that 'xor' is an alternative token (which should
> better be called bitxor, but anyway).
>
> But according to the Boost guidelines, my macro has to be called
> BOOST_XOR anyway ("boostification"). 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_bool conversion but with operator!.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
"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_NAMESPACE > > > > and honestly, I didn't looked much at it as I should. > > > > BOOST_NO_STDC_NAMESPACE is documented to relate to C names, > > but swap is a C++ name so I don't think such macro > > should be used here. > > The CVS change of optional.hpp:1.10 is definitely incorrect, > because STDC_NAMESPACE refers to C names, not C++ names. > Sorry. > > However, just reverting the patch will make gcc-3.3 > non-functional, because std::swap(int,int) (for example) > is not going to be found. > > I've checked in a better fix to the main branch. optional_test.cpp > now works with gcc 2.95, gcc 3.0 and gcc 3.3 on Linux. > Please test on other platforms and (optionally) transport > the fix to the 1.30.0 CVS branch. > > Jens Maurer > Actually, I had fix it for RC_1_30_0 already. If the release goes OK, I think I should merge my fix back to the main trunk. Thanks anyway. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
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 guess that if I just commit it, it won't end on the right place) > > cvs update -rRC_1_30_0 ... > cvs edit ... > > [Make your changes] > > cvs commit ... > > # to get back to the main trunk: > cvs update -A ... > > > I have fixed the last regression (the one with crc_test) in CVS, so > as soon as you've made your patch and we've had one more round of > testing, I'm going to tag it for release. Please let me know the > instant you're finished. > Done. (I've also checked in a couple of typos in the doc that were reported to me) Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
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" <[EMAIL PROTECTED]> writes: > >> > The page is: http://boost.sourceforge.net/regression-logs/cs-Linux.html > >> > So it should correspond to the HEAD revision. > >> > IIUC, the HEAD revision contains Jen's broken patch, so this one should fail. > >> > >> I am only concerned with RC_1_30_0 here. > >> > > I see. > > > >> > I think that the correct patch is to revert Jens' fix. > >> > (go back to revision 1.9). > >> > > >> > Can you and others run a quick test to see if this fix is correct? > >> > >> RC_1_30_0 already works with GCC-3.2 work for me. > >> > > I see. > > I wonder what would happen with gcc3.3 and 3.3.1 without Jen's patch. > > Should I revert that anyway, even if it leaves those compilers unsupported? > > Are they healthier without the patch or with it? without it. >Can you use > BOOST_WORKAROUND to select the best answer for all GCC versions? > Yes, I think. Though I cannot test it myself. How do I apply the patch? I mean, what do I do with CVS to have it on the right branch/tag. (I guess that if I just commit it, it won't end on the right place) Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
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 specialization into _STL::.
> >>
> > It actually sufixes
>
> I assume you mean "suffices".
>
:-) yes
> > to put any 'std' extension in a nested namespace (say, stdx); then
> > injecting the names in 'std'.
>
> That's unfortunately illegal. You're not allowed to add names to
> std,
Oh Right...
I guess adding a namespace counts as adding a name.
>and anyway I don't see how it could help if you want to
> specialize something in std. Am I missing something?
>
If the specialization is injected into 'std' via
a using directive, as in
namespace std { using namespace stdx ; }
the problem goes away (the primary swap<> is now found).
The idea is to mimic the way the primary swap<> is defined
to avoid the conflict in as much a configuration-independent way
as possible.
STLPort (as shiped with BCB6) has various configuration flags
that affect the place were std names are effectively placed.
The following excrept from "stl\_config.h" shows the possibilities:
# if defined (_STLP_USE_OWN_NAMESPACE)
# ifdef _STLP_DEBUG
#define _STLP_STD _STLD
# else
#define _STLP_STD _STL
# endif
# else
# ifdef _STLP_DEBUG
#define _STLP_STD stdD
# else
#define _STLP_STD std
# endif
# endif
Names are declared/defined within _STLP_STD, where the actual value of
_STLP_STD depends on _STLP_USE_OWN_NAMESPACE and _STLP_DEBUG.
With the default configuration (the only one that really works with BCB6),
_STLP_STD=_STL
ALl these names are brought into 'std' by a using directive,
as shown by the following excrept from "stl/_epilog.h"
# if defined (_STLP_REDEFINE_STD) || ! defined (_STLP_USE_NAMESPACES)
// We redefine "std" to "stlport", so that user code may use std:: transparently
# undef std
# if defined(__cplusplus)
# ifndef _STLP_CONFIG_H
# include
# endif
namespace _STLP_STD { }
namespace std {
using namespace _STLP_STD;
}
# endif // __cplusplus
# endif
The conflict sown by Alisdair arises from the fact that
"std" names are actually in a nested namespace and injected
into namespace std.
According to 3.4.3.2/2, if 'swap' is found _directly_
in namespace std, then the nested namespace _STLP_STD is not
looked up. This is why the mere presence of a function
named 'swap' hides the primary swap<>.
The problem ocurrs even if the 'swap' in 'std' is not
a specialization but any function with that name.
The idea of my workaround was to put the specialization
at the same 'level': in a nested namespace and not in 'std' directly.
As I realize now it is illegal to do that.
Anyway, the alternative workaround is to put
the specializations right in _STLP_STD (as you suggested)
(but not in _STL as that is just one of the possible actual namespaces,
depending on the configuration).
Similarly, qualified names should use _STLP_STD
(and not _STL for the same reasons as above).
BTW, I have a question:
According to BCB, the primary swap is hidden when some swap is
declared directly in std even for ADL.
That is, not even this works:
using std::swap; swap(x,y);
is this conformant?
I can't decipher the Standard on this matter.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Release of 1.30.2 imminent
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 a couple of users of > > Optional out there. > > Simple and effective. It is in a production system here. > I'm glad to hear that! Best, Fernando ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
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. > > IIUC, the HEAD revision contains Jen's broken patch, so this one should fail. > > I am only concerned with RC_1_30_0 here. > I see. > > I think that the correct patch is to revert Jens' fix. > > (go back to revision 1.9). > > > > Can you and others run a quick test to see if this fix is correct? > > RC_1_30_0 already works with GCC-3.2 work for me. > I see. I wonder what would happen with gcc3.3 and 3.3.1 without Jen's patch. Should I revert that anyway, even if it leaves those compilers unsupported? > I checked in this > patch to fix vc6/7: > Great. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Hi, There are still problems with Optional, related to some compilers not finding std swap(). I wrote the original code following compressed_pair.hpp, which is via unqualified call (to activate ADL), plus a using declaration at function scope for GCC. Recently, Jens Maurer patched it adding an alternative using declaration at namespace scope (optional_detail) for GCC, but this seems not to work as the regressions show. I don't have access to any of the failing compilers so I cannot fix it myself. If anyone can do it, we might have this fixed for 1.30.2. Note: although this library 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
[boost] Re: swappable user defined types and STLport libraries
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?
> >>
> > If the specialization is injected into 'std' via
> > a using directive, as in
> >
> > namespace std { using namespace stdx ; }
> >
> > the problem goes away (the primary swap<> is now found).
>
> Err, no. Koenig lookup doesn't proceed through using directives.
>
Right, but ADL is not in stake here.
The problem is the _qualified_ call:
std::swap(px, other.px);
inside
shared_ptr::swap();
>
> namespace std { using stdx::swap; }
>
> works.
>
It works for ADL.
Still, according to 3.4.3.2/2, for the _qualified_ call "std::swap()",
to find the primary template there cannot be any 'swap' declared
directly in 'std' since the primary template is in a nested namespace.
Furthermore, the names are injected into namespace std via a
"using directive" and not a "using declaration",
so my workaround does work for the qualified case
(by the same mechanism the "using namespace _STLP_STD"
works for the library implementation)
As for unqualified calls (involving ADL),
you're right, but then there's a "conflict of interest"
as shown by this program (which I tested against Comeau Online)
***
#include
// This represents _STLP_STD
namespace N
{
template void f( T const& ) { std::cout << "primary.\n" ;}
template<> void f(int const& ) { std::cout << " specialization.\n" ; }
}
// This represents 'std' as implemented by STLPort
namespace A
{
using namespace N ;
}
// A sample user class.
class C{};
// A user-side namespace
namespace M
{
// A::f cannot be specialized here, but can be overloaded.
void f(C const& ) { std::cout << " overload.\n" ; }
}
namespace A
{
using namespace M ;
// using M::f ;
// template<> void f(C const& ) { std::cout << " specialization.\n" ; }
}
void qual()
{
A::f(std::cout); // should call primary template
A::f(1); // should call int specialization
C c ; A::f(c); // should user overload
}
void koenig()
{
using A::f ;
f(std::cout); // should call primary template
f(1); // should call int specialization
C c ; f(c); // should user overload
}
int main()
{
qual();
koenig();
}
***
Now, If I switch from the using directive to the using declaration,
Comeau reports that it can't convert to 'C',
thus hiding the 'f' in N.
That is, if the using declaration is used to enable ADL,
the std library names are hidden because those are not
found during koenig lookup, as you said, so a using
directive would be needed, mirroring the library
implementation.
OTOH however, you can't specialize swap neither in
stdx nor in std (even though BCB6 incorrectly allows it),
so as you initially said, the _only_ correct
woraround is to put the specialization in _STLP_STD,
were the primary template is.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
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" <[EMAIL PROTECTED]> writes: > >> > >> > > >> > There are still problems with Optional, related to some compilers > >> > not finding std swap(). I wrote the original code following > >> > compressed_pair.hpp, which is via unqualified call (to activate > >> > ADL), plus a using declaration at function scope for GCC. Recently, > >> > Jens Maurer patched it adding an alternative using declaration at > >> > namespace scope (optional_detail) for GCC, but this seems not to > >> > work as the regressions show. > >> > > >> > I don't have access to any of the failing compilers > >> > >> Which compilers are failing and where are the regression report pages? > >> > > Sorry for the delay, I was leaving the office when you posted this > > > > Most problems related to swap ocurr with GCC>3.3 > > Well, 3.4 isn't even a released compiler so As far as I'm concerned > it doesn't count. OK. > 3.3.x is another story. > > > and VC==6.0 > > Hmm. > > > It appears that this problem ocurrs both with 1.30.0 and the current rc 1.30.2 > > > > On Linux_1_30_0: > > gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test > > gcc-3.3 > > gcc3.3.1: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test > > gcc-3.3.1 > > > > Unfortunately, nearly all of these links point to invalid targets so > my browser doesn't find them :(. Could you just post links to the > summary page one level up? > Sure. >From the main status page, at: http://boost.sourceforge.net/regression-logs/ The link that reads "(Linux-1_30_0)", under the title "Linux", goes to: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0.html There are the failures I've shown for gcc3.3 and gcc3.3.1 This page shows the regression for 1.30.0 right? But they show that the newer gcc failed (without Jens patch). > > On Linux: All tests passed. (how come? > > I'm not sure what you mean. If it doesn't say 1_30_0 in the page > it's probably a test of the HEAD revision. > The page is: http://boost.sourceforge.net/regression-logs/cs-Linux.html So it should correspond to the HEAD revision. IIUC, the HEAD revision contains Jen's broken patch, so this one should fail. I wonder if the reports are swaped (the page titled 1.30.0 being the HEAD and viceversa) > > > On Libux-rc-1_30_0: >^ >? > > > gcc3.4: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test > > gcc-3.4-cvs > > gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test > > gcc-3.3 > > gcc3.3.1: > > http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test > > gcc-3.3.1 > > Aren't these the same tests as cited above? > Not exactly. This result appears in the page: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0.html which is the third Linux report from the main page. > > > On Win32_1_30_1: > > gcc: http://boost.sourceforge.net/regression-logs/cs-win32-1_30_1-links.html#optional_test-gcc > > Yeah, the "fix" by Jens looks broken to me. Jens, to which versions > of GCC does this patch apply? It was intended for 3.3 as he told me. I think that the correct patch is to revert Jens' fix. (go back to revision 1.9). Can you and others run a quick test to see if this fix is correct? Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Release of 1.30.2 imminent
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 > >> pages? > >> > > Sorry for the delay, I was leaving the office when you posted this > > > > Most problems related to swap ocurr with GCC>3.3 and VC==6.0 > > It appears that this problem ocurrs both with 1.30.0 and the current > > rc 1.30.2 > > What's so surprising here? Everything fails exactly as it should. > 1.30 has > > #ifndef __GNUC__ > using std::swap; > #endif > > and hence should fail on every non-broken GCC. > > > HEAD has > > #ifndef BOOST_NO_STDC_NAMESPACE > using std::swap; > #endif > > instead and hence should fail on every BOOST_NO_STDC_NAMESPACE compiler that > isn't a broken GCC. > There's something I don't understand. 1.30.0, as you said, doesn't has the using declaration at function scope, BUT is has it at namespace scope. See revision 1.9 or prior. The idea was that borken GCC don't like it at function scope but do at namespace scope. Recently, Jens Maurer changed the guard at function scope from: #ifndef __GNUC__ to #ifndef BOOST_NO_STDC_NAMESPACE and honestly, I didn't looked much at it as I should. BOOST_NO_STDC_NAMESPACE is documented to relate to C names, but swap is a C++ name so I don't think such macro should be used here. I don't understand the problem with the original code (as of revision 1.19), and I don't understand why 1.30.0 fails. I do understand why HEAD fails, by my 'fix' would be to revert Jens fix, but if I were right, 1.30.0 wouldn't fail as it does. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
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 the original code following > > compressed_pair.hpp, which is via unqualified call (to activate > > ADL), plus a using declaration at function scope for GCC. Recently, > > Jens Maurer patched it adding an alternative using declaration at > > namespace scope (optional_detail) for GCC, but this seems not to > > work as the regressions show. > > > > I don't have access to any of the failing compilers > > Which compilers are failing and where are the regression report pages? > Sorry for the delay, I was leaving the office when you posted this Most problems related to swap ocurr with GCC>3.3 and VC==6.0 It appears that this problem ocurrs both with 1.30.0 and the current rc 1.30.2 On Linux_1_30_0: gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test gcc-3.3 gcc3.3.1: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test gcc-3.3.1 On Linux: All tests passed. (how come? On Libux-rc-1_30_0: gcc3.4: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.4-cvs gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.3 gcc3.3.1: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.3.1 On Win32_1_30_1: gcc: http://boost.sourceforge.net/regression-logs/cs-win32-1_30_1-links.html#optional_test-gcc On Win32: Comeau 4302: http://boost.sourceforge.net/regression-logs/cs-win32-links.html#optional_test-como-win32 VC60 : http://boost.sourceforge.net/regression-logs/cs-win32-links.html#optional_test-msvc On Win32 metacomm: Comeau 4302: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-com o-4.3.2b-vc7 Intel 7.0: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-int el-7.1 Intel 7.0 STLPort: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-int el-7.1-stlport VC 6.0: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-msvc VC 6.0 STLPort : http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-msvc-stl port The following are errors in other dependent libraries (type_traits and mpl) On MAC OS: GNU-GCC: http://boost.sourceforge.net/regression-logs/cs-Darwin-links.html#optional_test_fail5a-darwin On HP-UX: aCC53800: http://boost.sourceforge.net/regression-logs/cs-HP-UX-links.html#optional_test-acc aCC33380: http://boost.sourceforge.net/regression-logs/cs-hpux-links.html#optional_test-acc This is a compiler crash. On Solaris: http://boost.sourceforge.net/regression-logs/cs-solaris-links.html#optional_test-sunpro Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: swappable user defined types and STLport libraries
Beman Dawes <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > At 07:49 PM 8/5/2003, Pavel Vozenilek wrote: > > > >"Edward Diener" <[EMAIL PROTECTED]> wrote in message > >news:[EMAIL PROTECTED] > >> Beman Dawes wrote: > >> > At 09:58 PM 8/4/2003, Alisdair Meredith wrote: > >> > > >> > >There is a problem with the Borland BCB6 compiler... > >> > > >> > What is the status of the Borland compiler as far as fixes and > >> > updates go? Have they announced any plans? > >> > >> Although they have not announced anything further about more BCB6 > service > >> packs, it is easy to guess that there will not be any more. All > >indications > >> are that Borland is working on a BCB7 release but, in true Borland > >fashion, > >> there is no date given when it will be released until it happens. > >... > > > >Something is happening right now - announcement and beta invitation is on > >http://bdn.borland.com/article/0,1410,30279,00.html. > > OK, 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 bugs Boosters don't have to cope with later. > > Any volunteers:-? > I signed for it already. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
David Abrahams <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Alisdair Meredith <[EMAIL PROTECTED]> writes:
>
> > The fix I am currently using looks like this in shared_ptr [line 284]
> >
> > void swap(shared_ptr & other) // never throws
> > {
> > #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x0564) )
> > _STL::swap(px, other.px);
> > #else
> > std::swap(px, other.px);
> > #endif
> > pn.swap(other.pn);
> > }
> >
> > I am not submitting this as a diff yet as I am not sure this is the
> > 'correct' patch yet, but I hope it gives the idea. A similar patch
> > needs to be applied everywhere in Boost std::swap is called, which could
> > be quite a bit of work. I am happy to go through all the 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 specialization into _STL::.
>
It actually sufixes to put any 'std' extension in a nested namespace (say, stdx); then
injecting
the names in 'std'.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Fun PP lib example
> 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's an example I just cooked up of using the PP lib to solve a > > > > classic C++ OO problem: repeated boilerplate in the definition of > > > > Pimpl classes. > > > > > > There is another variation of the idiom, sometimes called "hidden > state", > > > which doesn't have the shortcoming in the first place: > > > > > A shortcoming of the hidden state idiom compared to the classic delegation > > idiom is that only the state is encapsulated, not the behaviour. > > I am not sure what do you mean by "encapsulated". Hidden in a source file as > opposite to the header? > Sort of. Hidden in any other file different from the file containing the declaration of the public interface. > > IOWs, if you need to hide the operations, not just the state, you still > > need to mirror the interface class member functions into > > the impl class. > > How so? With the hidden state, what would be private member functions > becomes free functions at the file scope. > Ah... you didn't show this in your example... what you're right AFAICT. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fun PP lib example
"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 instance). >> >> Just a thought. > >FWIW, my macro only generates declarations, so it doesn't interfere >with debugging. > >-- >Dave Abrahams > Yep, I've noticed. I actually voiced that opinion even though your macro _in particular_ seemed OK just to set the records for the kind of trouble that can ocurr if code repetition tasks are replaced by macros without properly balancing the drawbacks and implied subtelties. For instance, many of the complains I've received were because invalid macro arguments led to impossible to understand error messages. Even if the macro just adds a declaration, figuring out the source of the error can be impossible without knowing the expanded text of the macro. We even tried to code-up some sort of utility to expand macros on-the-fly with the given arguments, but that was impractical for us because the complete macro expansion could depend on many other macros and so on, so the "utility" must have access to the entire source and include tree. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fun PP lib example
"Aleksey Gurtovoy" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > David Abrahams wrote: > > Here's an example I just cooked up of using the PP lib to solve a > > classic C++ OO problem: repeated boilerplate in the definition of > > Pimpl classes. > > There is another variation of the idiom, sometimes called "hidden state", > which doesn't have the shortcoming in the first place: > A shortcoming of the hidden state idiom compared to the classic delegation idiom is that only the state is encapsulated, not the behaviour. IOWs, if you need to hide the operations, not just the state, you still need to mirror the interface class member functions into the impl class. For this case, delegation would be preferred, and so Dave's macros. As for the macros, they are certainly handy... Though almost a decade ago I have had bad experiencies using macros to do the job of a good editor, so eventually I preferred to have only straight up C++ code to feed the compiler and use external tools to handle code generation. Problems were mostly related to very excesive preprocessing times (paid on each compilation), blind-debugging and the fact that a variate of handy macros started to proliferate as new code patterns wanted to be automated, pollutting the code base with so many macros that source code looked as being written in another language. For me who designed all those macros the resulting code looked very clear, but the rest of the team -who had to use them- kept complaining about having to learn too many non standard things. Nowaday, however, I would use the PP, and the handy macros like the one Dave just invented, to implement meta-code that generates the actual source files that get compiled and 'seen' by felow programmers. That way, only the actual maintainer has to know what extactly the macro does, while code 'users' (including the compiler that has to preprocess the file every day), deals with the expanded code only. 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 instance). Just a thought. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_nan
>| >| What don't you understand in the expression "isnan is a private function"? > >What being private has to do with being trapping or not? > Guillaume point is that this isnan(), being an implementation detail, is known to never recieve a sNAN, so it does not has to account for that situation. Just as you won't put bounds check in an internal function accessing an internal array with a fixed known size. Your point I can't understand though. Are you saying that an isnan() could trigger a sNAN trap even if it doesn't recieve a sNAN? That is, can a reasonable implementation of it be so wrong as to _generate_ a sNAN? Or are you arguing that the interval library should contend for possible sNAN as input? If the former, I'm sure we are all interested in knowing how can that happen. If the later, I agree with Guillaume that this is a design decision that is already made, and I don't see a compelling reason for changing it. Most likely, if the user inputs sNAN to the interval library, a trap will be triggered way before isnan() is called. An interval library _could_ be designed to cope with sNAN, but this is not the case 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
[boost] Re: Fixed-Point Decimal Formal Review
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: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fixed-Point Decimal Formal Review
Bill Seymour <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Paul Bristow has convinced me that I need longer, clearer names > for the I/O manipulators. First draft: > > pure_number > national_currency > international_currency > > number_stream_frac_digits > number_decimal_frac_digits > > money_stream_frac_digits > money_decimal_frac_digits > money_locale_frac_digits > Those look fine to me. > > I'll also take the suggestion to put frac_digits() in the public > interface and "fraction digits" in the text of the documentation. > fine > > Daryle Walker and Ilya Buchkin are raising some important issues > that probably go away if the scale is part of the type. I'm not sure how to decide if making the scale part of the type is a good idea. Do users really want that? Suppose we apply the LSP (*1) to decimals of different scales, that is, we subsitute a decimal of one scale with a decimal of a different scale, how much does the change affect the program behaviour? If the answer is "not much", it would indicate that type equivalence between decimals of different scales is important, thus making the scale part of the type will be more of a burden than a gain. OTOH, if it is important not to mix/substitue decimals of different scales without explicit intervention, then the scale should be part of the type. If the motivation is _only_ to allow for more efficient algorithms and more compact representations, then I don't think coupling the scale with the type is the right choice. (*1) Liskov Substitution Principle http://www.objectmentor.com/resources/articles/lsp.pdf > > Daryle suggests operations that increment and decrement by 1 ULP; > and I think that's a good idea. The names I like are next_value() > and previous_value(); Good. > and I'll probably include versions with > dummy int arguments to parallel the built-in postfix operators. > ??? > Daryle also suggests opening up the internal 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
[boost] Re: Thoughts on fixdec
Bill Seymour <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Daryle Walker wrote: > >(Yes, I know that some numeric purists [and GCC] hate "long double," >but I want to maximize the capabilities.) > The problem with a 'long double' ctor, either with or without 'double' ctor, is that long double is never the target of floating-point promotions, so decimal construction would become ambiguous from some types. > > > > 1. We have two math-related namespaces already. The boost::math > > namespace leans to theoretical work and boost::numeric leans to > > hard-core computation. > > > > I don't know that there's anything particularly theoretical about > decimal representations; and the library's target audience is not > those users who do "hard-code computation," which I understand to > mean numerical programming (in the sense of scientific and > statical programming). > > It's not a major issue for me; and I'll do whatever the majority > wants. > I'm inclined toward boost::numeric. > > > > You should probably pick one of those namespaces (numeric?) and > > possibly rename the class to "fixed_decimal". > > > > I'm reticent to require the user to type the extra "fixed_" in > every declaration of such an object. > I prefer just 'decimal' because most decimal numbers I know of are fixed-point. So I think 'fixed' can be left implicit. > > > > > 5. The conversion from "int" needs to check for overflow. > > The conversion from "double" needs to check also for underflow. > > The conversion from strings needs to check also for bad formats. > > > > But that would require some users to pay for something they don't > need. Users who need that level of correctness can write their > own checks; and others (probably most of the library's target > audience) get better efficiency. > Couldn't this be provided as a postcondition, in terms of BOOST_ASSERT? > > > > > 6. There should only be conversions from strings, and _no_ > > mixed operations with strings. > > > > In the absence of decimal literals, I think it's easier for the > user to be able to use strings as pseudo-literals in all contexts; > and I don't see how the mixed operations do any harm. > The problem is that quite unfortunately, string literals are just pointers to constant char, but such pointers are also used to access raw memory, so, char const* is the target to implicit conversions from a lot more than string literals. This would lead to unexpected implicit conversions. > > > > > 9. What, no "operator <<" nor "operator >>"? (The shift would > > be a power of ten.) > > > > Those operators don't exist for the floating-point types, and with > good reason IMO. Their use is best reserved for twiddling bits, > not for scaling. Even for binary integers, i << 1 is not generally > the same thing as i * 2 except on 2's-complement boxes. > I agree. > > > > 13. You have strange (regular) assignment semantics. You try to > > change the receiver's logical value to the source's logical value, > > but retain the receiver's original scale (internally shifting the > > new significand and doing any rounding if needed). ... you will > > get strange effects if you try to change containers of "decimal" > > through assignment. > > > > I thought it would be less surprising if a decimal object's scale > were immutable. This matches prior art (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
[boost] Re: Formal Review: fixed-point decimal library
Bill, Bill Seymour <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I've upload fixdec23.zip to the Yahoo files section. > > I made some changes that Jens suggested to allow compiling with > Comeau and gcc; and I've made the is_bounded and is_modulo fixes > that Fernando suggested along with interoperatability with > unsigned as well as int. > Great, > Fernando, > > I think that max_scale needs to be a constant expression > because it's used in the definition of numeric_limits: > > BOOST_STATIC_CONSTANT(int, digits=boost::fixdec::max_scale); > BOOST_STATIC_CONSTANT(int, digits10=boost::fixdec::max_scale); > Couldn't these be implemented right in terms of numeric_limits::digits? > And I think I'm right about numeric_limits<>::digits10. I believe > it's intended to be mean that, if the value is N, then /all/ N-digit > numbers can be represented. numeric_limits::digits10 can't > be 19 because only a subset of 19-digit numbers are representable. > > Also, I think that your statement: > > > > ... __int64 support 18 digits at most. > > > is factually incorrect. Your implementation's __int64 should support > anything up to 10**63 - 1 or (with commas as thousands separators) > 9,223,372,036,854,775,807. That's a 19-digit number. > You're right on both accounts. All numbers with 'N=digits10' 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
[boost] Re: Formal Review: fixed-point decimal library
Hi Bill, Yes, 'precision' is what I meant. I used the term' digits' because that's what is used for 'numeric_limits<>', but I much prefer 'precision'. There is one thing I noticed though that I'd like you to confirm: Because of the implementation (a normalized rep with two separate int_type members), given 'M' as numeric_limits::digits10, then the decimal 'precision' is M+1. If you look at the 'max values with different scales' output of my first post, you'll see that all values have 19 digits, while __int64 support 18 digits at most. That is, numeric_limits::digits = numeric_limits::digits10 = numeric_limits::digits10+1 > > I would say "digits to the right of the decimal point". (Digits > to the left of the point I would also call "decimal" because > they're base-10.) > Agreed. > > > > It cannot be > '(digits-1'), ... > > > > Yes, the scale can be equal to the precision (which I believe is > what you're calling "digits"); but then, in general, there won't be > any digits to the left of the point. > I tried to actually create a decimal with no whole digit to show the equality you mentioned above but failed. Could it be that because of the implementation there is always at least one whole digit? I think so, and in this case, the scale can be at most precision-1. > > > > 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)" > > > > 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 not clear enough. What I meant is this: if the string contains a total of more than 'precision' digits, the representation won't be exact. In fact, it will have an implementation-defined value. So, I would leave the original sentence, and add a next sentence stating the above additional constrian. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review: fixed-point decimal library
twice as large as 'int', there is a big range of valid decimal numbers that can not be given as initializers, namely (INT_MAX,]. Allowing unsigned int to be given, that range reduces to (UINT_MAX,]. IOWs, this considerably extends the range of integer values that can be used to initialize a decimal. > > > > 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. > > > > 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
[boost] Re: Formal Review: fixed-point decimal library
Hi, this is my review of the Fixed-Point Decimal Library.
I cannot vote as it is now.
I will vote subject to the resolution of the 'scale' issue I explain below:
Problems with 'scale':
==
To understand it, I wrote the following function which just creates two
decimals given a source integer and two scales:
void Show( int s, int scn, int scm)
{
decimal n(scn, s);
decimal m(scm, s);
cout << "s=" << s << endl
<< decscale
<< "[" << scn << ",s]=" << n << endl
<< "[" << scm << ",s]=" << m << endl
<< endl ;
}
When called with:
Show(numeric_limits::max(),9,10);
Show(9,17,18);
Show(10,17,18);
Show(0,17,18);
the output (in a system were int_type is __int64) is:
s=2147483647
[9,s]=2147483647.0
[10,s]=302809239.6290448384
s=9
[17,s]=9.0
[18,s]=9.00
s=10
[17,s]=10.0
[18,s]=-8.446744073709551616
s=0
[17,s]=0.0
[18,s]=0.00
Furhetmore, the following:
decimal eps = numeric_limits::epsilon() ;
decimal a = eps + 9 ;
decimal b = eps + 10 ;
cout << decscale
<< numeric_limits::digits10
<< eps
<< a << endl
<< b << endl ;
outputs:
18
0.01
9.01
-8.446744073709551615
These results seems to clearly show that 'scale' is actually the maximum
number of decimal digits allowed IIF only one digit is used for the whole
part.
If the whole part uses more than one digit, say N, the decimal part won't be
able to represent 'scale' digits, it will only represent 'scale+1-N' digits,
as shown by the following:
max with scale=0 : 9223372036854775807
max with scale=1 : 922337203685477580.7
max with scale=2 : 92233720368547758.07
max with scale=3 : 9223372036854775.807
max with scale=4 : 922337203685477.5807
max with scale=5 : 92233720368547.75807
max with scale=6 : 9223372036854.775807
max with scale=7 : 922337203685.4775807
max with scale=8 : 92233720368.54775807
max with scale=9 : 9223372036.854775807
max with scale=10 : 922337203.6854775807
max with scale=11 : 92233720.36854775807
max with scale=12 : 9223372.036854775807
max with scale=13 : 922337.2036854775807
max with scale=14 : 92233.72036854775807
max with scale=15 : 9223.372036854775807
max with scale=16 : 922.3372036854775807
max with scale=17 : 92.23372036854775807
max with scale=18 : 9.223372036854775807
Notice that the total number of represtanble digits is scale+1.
Therefore, I really dislike the term 'scale' and its explanation.
IMO, it should be called: 'digits', and it should be defaulted to 1 +
[int_type].digits10
(i.e 19),
Additionally, numeric_limits::digits and digits10 should be
max_scale+1,
not max_scale.
Here is a list of other minor issues:
=
I don't think that is_bounded and is_modulo should be inherited from
int_type.
is_bounded is intended to be false only for those types which can represent
numbers in any range. Even if int_type were unbounded (is_bounded=false),
decimal itself will always be bounded, so it should fix is_bounded to true.
Similarly, is_modulo tells whether the numeric type uses modulo arithmetic,
as do the unsigned integral types, yet decimal does not do that even if
int_type where unsigned, so this should be fixed to 'false'.
***
Currently, the library cannot be put in a precompiled header using BCC
because of the 'max_val,min_val' constants. This can be solved by making
those constants inlined functions.
I can send you a patch if you like.
The documentation is clearly written with some 'old' version in mind. I
think all references and comparisons with that older version should be
removed from the docs, or at least, put aside on a 'history' section.
*
IMO the documentation should begin with a brief (but complete) overview of
what is a 'fixed decimal' number, including the concept of a 'scale' (or
'digits' as I much prefer), and of rounding modes.
**
I understand why it is not supported to construct a decimal from an
int_type, but I think that construction from 'unsigned int' should 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
[boost] Re: Re: Interest in multiindex_set?(again)
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, index_n.begin() and index_n.end() let you enumerate *all* the > elements in mxs, regardless of n; the difference is in the order > they are enumerated, which depends on the comparison predicate > associated with index #n. By convention, my_mx_set inherits the > functionailty of index #0, that is > > my_mx_set::some_memfun(...); > > is the same as > > my_mx_set::index_type<0>::type::some_memfun(...); > Ah! I see. Sorry about the confusion. > In particular, my_mx_set::begin() and my_mx_set::end() let > you traverse through then entire set of elements contained, > with the order induced by index #0. Does this ask your question? > Absolutely! > If not, please let me know and I'll be happy to explain it further. > I'm most determined to eliminate this semantic barrier between > both of us :) > Me too... I got it wrong from the start though :-) > Also, may I suggest you download some distribution of g++ and > play with the library a little. Maybe then things become clearer. > >> Now, suppose that you can iterate over the all of the elements: >> what's the >> order in which elements will appear w.r.t the insertion sequence >> and the >> ordering implied by the indices? This is what I've asked you about >> the "ordering and clustering invariants" of the data structure. >> >> If, during a linear traversal (that is, iterating over all of the >> elementsas if it were a sequence), the elements will appear in an >> unspecified order, >> then the data structure is not an associative container (much less >> a set), >> so it should _definitely_ be called 'table' and not 'set'. >> >> I think I understand now why the term 'index'. It reseambles the >> filtering-key associated with the 'field' which designates a >> 'column' on a >> database table. However, if I'm not mistaken, the filtered-column >> itself,that is, the sequence of elements with such value in the >> correspondingfield, is not an 'index'. So the subsquence which is >> mapped to a given index >> shouln't be called index, I think. I would call it a 'cluster' as I >> suggested before. >> >> Since I can't play with the code I couldn't see how much of a set >> is each >> 'cluster'. Make sure to check with the requirements and document this >> clearly. >> > > Hopefully, this has been asked above. Again, please let me know > otherwise > so that I try to make myself clearer. > It's OK. I guess I got it right this time. >> Another thing I couldn't figure out is how to compose indices >> hierachically.That is, how to reproduce a typical SQL SELECT * >> ORDER BY X,Y,Z. >> Since you're modeling an indexed table, this functionality should be >> supported. > > This is an interesting subject to study, but as some others are > already > writing a relational framework I guess we should limit here to the > basics of the container. > SQL-like predicates can be built on top of it > in the context of more ambitious libraries. > I see. If this functionality can be built on top of it, then I think it is OK not to support it explicitely. >> >> I vote for a separate KeyExtraction because: >> >> (a) Key extraction and key comparison are conceptually orthogonal. >> >> (b) The orthogonality will be important in practice when users >> want to >> compare whith other predicates besides less_than and/or based on >> more than >> just data members. >> With your mixin approach, it would be more difficult to have an >> index based >> on a runtime expression >> (such as a hash value) combined with a comparison other than <. > > The most usual situation for specification of an index (standard > less_than comparison on some member of the element) is already > covered by less_by. Furthermore, less_by accepts an additional > template parameter for specifying a comparison predicate other > than std::less. For instance > > less_by > > specifies an index based on less_than comparison of employee::name > (a string). If you want to use some other comparison criterium on > empoyee::name (for instance, case insensitive comparison), you can > write > > less_by > > Is this what you're referring to? > Half of it. I see t
[boost] Re: Interest in multiindex_set?(again)
Hi Joaquín, Unfortunately, I douldn't compile the code with BCC because it extensively uses non-type template parameters which are only partially supported on Borland. After having read the documentation and looked at the code again, I realize now that your class is really a database-like table but not an associative container. In fact, it is not even a container. The problem is that you cannot traverse over _all_ the elements linerly. (See 23.1, Table 65) I previously took for granted that it was a container so I asked about the _global_ arrangement of the elements. I think that you shoud add iterators to traverse over the entire table as if it were a Sequence. This is the basic requirement of a container. Now, suppose that you can iterate over the all of the elements: what's the order in which elements will appear w.r.t the insertion sequence and the ordering implied by the indices? This is what I've asked you about the "ordering and clustering invariants" of the data structure. If, during a linear traversal (that is, iterating over all of the elements as if it were a sequence), the elements will appear in an unspecified order, then the data structure is not an associative container (much less a set), so it should _definitely_ be called 'table' and not 'set'. I think I understand now why the term 'index'. It reseambles the filtering-key associated with the 'field' which designates a 'column' on a database table. However, if I'm not mistaken, the filtered-column itself, that is, the sequence of elements with such value in the corresponding field, is not an 'index'. So the subsquence which is mapped to a given index shouln't be called index, I think. I would call it a 'cluster' as I suggested before. Since I can't play with the code I couldn't see how much of a set is each 'cluster'. Make sure to check with the requirements and document this clearly. Another thing I couldn't figure out is how to compose indices hierachically. That is, how to reproduce a typical SQL SELECT * ORDER BY X,Y,Z. Since you're modeling an indexed table, this functionality should be supported. I vote for a separate KeyExtraction because: (a) Key extraction and key comparison are conceptually orthogonal. (b) The orthogonality will be important in practice when users want to compare whith other predicates besides less_than and/or based on more than just data members. With your mixin approach, it would be more difficult to have an index based on a runtime expression (such as a hash value) combined with a comparison other than <. 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 mistake, I assign him the same number as Carla... the modify() will return 'false', but there won't be a Jhon anymore in the table Best, Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Review request: enable_if
"Thomas Witt" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > On Wednesday 09 July 2003 19:43, David Abrahams wrote: > > I doubt that the _c version are needed frequently enough to warrant the extra > types. > Plus it will induce many libraries to use these versions which will make them unsuable on weaker compilers, such as BCC. I've seen many recent libraries using constructs like: mpl::if_c::value,A,B> making those libraries unnecesarily broken for BCC. I much prefer to elude non-type versions of all metaprogramming stuff 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
[boost] Re: Re: test_fp_comparisons and rounding errors
"Gennadiy Rozental" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > > > There is BOOST_CHECK_PREDICATE > > > > > Yes, I know. > > My point was that with BOOST_CHECK_EQUAL_NUMBERS() the test library > > could output something readable of the form: > > > > "numbers x and y are not approximately equal" > > > > It could even add to the output something of the form: > > > > " according to " << Pred ; > > This is what BOOST_CHECK_CLOSE is doing basically. > Yes, that's the point. What I proposed is that the user can combine the macro with the comparator (I changed the macro name), becuase the comparison method is often application specific. I suggested to have an abosulte error comparator class as a default, but not as a fixed method inside the macro. The problem with any fixed scheme is that it can't be general enough, and the test library is highly general. I'm not sure if any fixed comparison method should be supplied at all. I would choose between my proposal, were specific targets can supply their own comparators, or not having fp comparison at all in the test library itself. >For majority of simple cases (not very big, nor very small values) they >should behave similarly. For egde cases relative error comparison produces >better results IMO No. It is not a matter of value magnitude or edge/non-edge cases. 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
[boost] Re: Re: test_fp_comparisons and rounding errors
Rozental, Gennadiy <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > A half-way solution is to have something like: > > > > BOOST_CHECK_EQUAL_NUMBERS(x,y,IsEqual) > > > > and let users specify their own Preciates. > > There is BOOST_CHECK_PREDICATE > Yes, I know. My point was that with BOOST_CHECK_EQUAL_NUMBERS() the test library could output something readable of the form: "numbers x and y are not approximately equal" It could even add to the output something of the form: " according to " << Pred ; which would use the comparator << operator so it can output the relevant information such as epsilon, scale, etc.. > > By default, the Test library could provide > > a straight-forward ABSOLUTE-ERROR comparator: > > By default, the Test library provides relative error comparator, which is > according to my understanding is more correct. > But there is no such thing as a "more correct" way to compare FP values in the context free level of a test library. You know already that relative errors have to be scaled to be meaningful, but choosing the right scaling is the complex. A default semantic that simply scales epsilon() times any of the arguments will be simply unusable for most practical tests because actual errors will easily exceed that; yet OTOH, suppling a factor to increase the scaling will mainly lead users to the problematic Illusion of Simplicity 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 to understand. BTW: The default comparator I showed before might better be named "DifferAtMostBy" Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: test_fp_comparisons and rounding errors
Beman Dawes <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> At 02:22 PM 7/7/2003, Rozental, Gennadiy wrote:
>
> >I could probably prohibit usage of CHECK_CLOSE with number of rounding
> >errors provided.
> >Is there any other general recommendations how to choose the tolerance
to
>
> >FP computation correctness checking?
>
> There has been some recent discussion on comp.lang.c++.moderated, subject
> "equality of two doubles". The last post was from Andrei Alexandrescu:
>
> >What's most of the time needed is relative precision.
> >
> >So, numerical gurus: how can one express "a equals b within 0.1%" over
> >the whole range of floating point numbers? If that can be done, it would
> >be a nice useful routine.
> >
> >bool approximately_equal(double lhs, double rhs, double relative_prec)
> >{
> >// fill in here please :o)
> >}
>
> But it really doesn't seem that a test library is the right home for such
> functions. I think all the fp stuff should be removed from Boost.Test, and
> passed on as a challenge to the numerics experts.
>
> After all, the user can always write:
>
>BOOST_CHECK( approximately_equal(...) );
>
> --Beman
>
A half-way solution is to have something like:
BOOST_CHECK_EQUAL_NUMBERS(x,y,IsEqual)
and let users specify their own Preciates.
By default, 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
: ( y - x ) <= m_tol ;
}
N m_tol ;
} ;
Which would be used as follows:
double n = ..., m = ... ;
BOOST_CHECK_EQUAL_NUMBERS(n,m,IsNearlyEqual());
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_nan
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: test_fp_comparisons and rounding errors
IMHO, the problem with test_fp_comparisons is that it is fundamentally flawed. As Guillaume said, ULPs just don't add. The approach of trying to bound the relaive error based on the number of roundings, which is what is intended, just doesn't work, and it won't work no matter how you try the adjust the 'number of errors' factor. I tried to explain this before but didn't had the time to go with a throughout explanation. But I'll give it another shot: ULPs are _relative_ quantities, so you cannot just add them as such becasue normally each ulp is relative to a different number. Altough for a _single_ operation the relative error is bounded by 1/2ulp, the idea that for an expression with N binary operands, the relative error is bounded by N * 1/2ulp is simply wrong. And the whole test is designed with this wrong idea. I've told this to Gennadiy back then, but he needed to understand why and I didn't have the time to explain it so the flaw just slipped through (so in a way this problem is my fault). The test library tries to mimic a static error analyzer. But this is way too complex and way off the test library scope. I still think that the test library should not offer a built-in FP comparison check. The argument in favor of it was that with an external user supplied test, we loose the possibility of outputing the offending operands. But I argued that fixing an fp comparison scheme right into the test library might lead to false 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 & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_nan
"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) > >> implementation. > >> > > Right. We should say that more often. It is incorrect > > however 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. > > Hi, > > We have an is_nan(float) implementation (for quiet NaNs of course) > that does just that. Right now, it supports most compilers on Win32 but it > should be straight-forward to support others. Right now, it is tested on: > > g++2.95.3 (MinGW) > g++3.1 (MinGW) > Borland 5.5.1 > Comeau 4.24 (Win32) > Microsoft Visual C++ 6 > Microsoft Visual C++ 7 > Microsoft Visual C++ 7.1 > Metrowerks CodeWarrior 7.2 > > The default implementation assumes IEEE754 floating point. It takes advantage > of the fact that IEEE754 has a well defined binary layout for quiet NaNs. Platform > specific implementations forward the call to the correct platform header when > available. The code does not rely on the availability of numeric_limits. > > I hope this can be used as the basis of a standardized boost::is_nan utility. > Thoughts? > It works for me Checking directly for the bit patterns is the way it has been done for years in the Windows platform. As long as this implementation is correctly dispatched from the user function I see no problem. BTW, it just poped my mine: could SFINAE be arranged to detect the existence of a global non-member function? We could write an implementation that dispatches to _isnan(), __isnan(), an so on if available. (though this would break the ODR on the other hand) Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_nan
--
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
> > news:[EMAIL PROTECTED]
> > > "jvd" <[EMAIL PROTECTED]> writes:
> > >
> > > | Dear boosters,
> > > |
> > > | seems like this code
> > > |
> > > | template< typename T >
> > > | bool is_nan( const T& v )
> > > | {
> > > | return std::numeric_limits::has_quiet_NaN && (v != v);
> > > | }
> > > |
> > > | does not work correctly on some machines.
> > >
> > > Yes. It is an incorrect (unfortunately popular) implementation.
> > >
> > Right. We should say that more often. It is incorrect however popular.
>
> Yes, it is incorrect for C++. But it's something we can hope to see one
> day. For example, in the LIA-1 annex I about C langage bindings, it is
> written that != is a binding for IEEE-754 ?<> operator (unordered
> compare). In the C9X annex F.8.3 about relational operators, it is written
> that the optimization "x != x -> false" is not allowed since "The
> statement x != x is true if x is a NaN". And so on.
>
Yes of course... but we will have to wait until the LIA-1 bindings
make into C++.
But not too long I hope.
> > Most compilers provide a non standard extension for this purpose.
> > For instance, Borland uses _isnan.
> > In general, these extensions are found on .
>
> In fact, since it is not specified by the C++ standard, isnan comes from
> the C headers and is supposed to be found in .
>
Right.. I was actually thinking on the C header but wrote it incorrectly.
I meant .
> > The best approach, IMO, is to have a boost::is_nan() with compiler specific
> > implementations.
>
> Yes, and there also were discussions on this mailing-list about a
> header. But unless somebody finds the time to tackle this
> whole problem...
>
Thanks to Gabriel we may have an is_nan() right now.
Is there anything else that the interval library uses which might be better
packed as a compiler-platform specific routine?
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_nan
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "jvd" <[EMAIL PROTECTED]> writes:
>
> | Dear boosters,
> |
> | seems like this code
> |
> | template< typename T >
> | bool is_nan( const T& v )
> | {
> | return std::numeric_limits::has_quiet_NaN && (v != v);
> | }
> |
> | does not work correctly on some machines.
>
> Yes. It is an incorrect (unfortunately popular) implementation.
>
Right. We should say that more often. It is incorrect however 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
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: [In response to Fernando Cacciola]Re:Interestinmultiindex_set?(again)
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/mailman/listinfo.cgi/boost
[boost] Re: Re: [In response to Fernando Cacciola] Re: Interestinmultiindex_set?(again)
ntainer to build a hierarchical
priority queue were the priority sequence is detached from
the element. But as you say, with your design (or with a separate
Extractor/Compare), a map can be built on top of this already,
so we might not need an explicit map.
>Hashing of user-specified indices is a very good option to have.
> I'm currently exploring it, but given the little amount of time I
> can devote to this I'd prefer to leave this out for the moment.
Great.
A hashing associative container might be better expressed in
terms of key equality (since ordering is not needed), so this
would need a different interface, but I agree that having
the ordered vesion first is a priority.
[...]
>> 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 ) ;
>
>Ummm... I'm afraid this cannot be done. What happens if the updated
>element does not fit into the multiindex_set due to collision with some
>other element? For instance:
>
>multiindex_set ms;
>ms.insert(0);
>ms.insert(1);
>ms.update(ms.begin(),increment_by_one);
>
>The last call will call increment_by_one() on the first element with
>value 0, changing it to 1. When reordering of the element is tried,
>a collision with the second element will ensue. What's worse, one
>cannot revert to the original situation, because the element has been
>already rewritten.
>
I see. You are correct.
The original update is transactional, which protects the integrity.
It is pitty that we can't think of a way to avoid the double-duplication,
but at least it works now as it is.
>At least, I hope current update() is no longer a showstopper for you.
>
It isn't anymore :-)
>> One last concern: keys are related hierarchycally?
>>
>Only for implementation purposes: derivation from one key
>(or index) to another is protected. From the user's point of
>view, keys/indices are structurally unrelated types obtained via
>get() from the source multiindex_set object.
>
I see.
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 some key-related property are placed
together (clustered), and clusters are ordered in some way.
But I can't tell how is this exactly and which operations maintain
these invariants.
For example: can I expect a specific arrangement with a lineal
traversal (as with set/map), or only via 'get()'?
> I'd greatly appreciate your interest in examining the library, and
>realize the difficulty in doing it without any documentation (which
>should follow promptly if finally multiindex_set catches boosters'
>eyes).
You're welcome. I greatly appreciate your doing it!
Best,
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [In response to Fernando Cacciola] Re: Interest inmultiindex_set?(again)
Joaquín Mª López Muñoz <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>Fernando wrote:
>
>>This looks fine in general.
>>I've needed something like it so I'm intereseted on seeing this on
>boost.
>
>>Some issues:
>
>>(1)
>>Why 'index' instead of 'key'? Associative containers use the term key
>>instead of index,
>>since index is typically related with random access instead of look up
>>access.
>
>Well, 'index' is borrowed from database technology meaning an internal
>sorting on a given key of a record. I haven't used 'key' instead
>because,
>in general, the whole element serves as a key (the comparison predicate
>for a given index need not be based on a particular member of the
>element,
>but can be any functor with bool operator(const element&,const element&)
>
>signature; less_by is just a convenient facility for the usual case in
>which the
>comparison depends solely on a single member of the element.
>Also, as every index has a std::set-like interface, its key_type typedef
>must
>be equal to the type of the elements contained, which contributes to the
>
>confusion.
>
>
C++ already has the concept of an Associative Container, and this
concept includes that of a 'Key'. In std terms, a 'key' can be
integrated with the value type (ala 'set') or not (ala 'map');
so this particularity shouldn't indicate the need for another term.
I think that following the std associative containers as much
as possible is the way to go.
For example: if possible, having both 'set' and 'map' variants
would be great (that is, with integrated or external keys).
Also, having 'hash' variants would also be great, that is,
with equal_key clustering but no particular ordering.
>On earlier versions, I used 'view' instead of 'index', but I don't like
>that
>either. I'm open to suggestions on more convenient terminology.
>
>>(2) I would explore a friendlier interface. For instance:
>
>>(2.1) key uniqueness could be specified along with the key itself
>>and not with a separate template parameter.
>
>Do you have an idea of how the interface can be like? I could try this
>approach.
>
>>(2.2) keys could be tagged so that 'get' could be parametrized by
>>key tag instead of number.
>
>I'd do it if I only knew how. Basically I'm using the same technique
>as get() member functions in boost::tuple, which don't have tags
>either. I really don't know how this could be done.
>
I see.
I'm pretty sure this can be done, though I'm not sure how exactly :)
Named template parameters mechanisms come to mind.
Perhaps other boosters can suggest something.
>>(3) This is a showstopper for me: The key mutating operations should
>>use a higher level interface which protects clustering and ordering
>>invariants.
>>With the current interface, if I understood correctly, I could forget
>to
>>call update() which would break such invariants.
>>A better setup would be to use something along the lines of
>>the 'modifiers' used by the CGAL Library.
>[stuff deleted]
>
>Maybe I'm not explaining myself clearly enough, or else I'm not catching
>your point. update() does not break the integrity of multiindex_set.
>
Wait...
I read your original example as if you were mutating
the element in-place though the iterator,
then calling update().
But you're not, update() takes a _copy_ of the
possibly mutated element, so I figure that
iterators are non-mutable (as should).
OK, I grant 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
[boost] Re: Interest in multiindex_set? (again)
This looks fine in general. I've needed something like it so I'm intereseted on seeing this on boost. Some issues: (1) Why 'index' instead of 'key'? Associative containers use the term key instead of index, since index is typically related with random access instead of look up access. (2) I would explore a friendlier interface. For instance: (2.1) key uniqueness could be specified along with the key itself and not with a separate template parameter. (2.2) keys could be tagged so that 'get' could be parametrized by key tag instead of number. (3) This is a showstopper for me: The key mutating operations should use a higher level interface which protects clustering and ordering invariants. With the current interface, if I understood correctly, I could forget to call update() which would break such invariants. A better setup would 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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
"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 Cacciola wrote:
> > > [...]
> > > > Motivated by A. Terekhov concerns, I think the license should, if at all
> > > > possible, expressely PROHIBIT anyone, including the copyright holder,
> > > > from patenting the covered Software and any implied intellectual production.
> > >
> > > That would make no sense.
> > >
> > Why?
>
> Because a patent protects against the unauthorized manufacture,
> use, sale... {subset of} rights that *ARE GRANTED* by a license
> {subject to whatever requirements} we're discussing here.
>
I don't understand.
Isn't the license and its copyright notice itself which protects those rights?
If we only seek to retain the copyright notice which each _copy_, as required by the
license, do we _need_ a patent? I think not.
AFAICT, a patent gives you far more rights than those expressed in the copyright
notice, and in particular, gives you right to _control_ the use of the covered subject
by,
for example, requiring a royalty for each use of it. This is far more than what we
really need, isn't it?
Maybe you saw nonsense in disallowing the boost developers ourselves
to issue a pantent on our own software. Well, the intention is to reduce
loopholes: without this provision, I might be forced to prove that I am
the orginal developer (names are far from unique).
> Also, a public disclosure of an invention prior to the patent
> application renders the invention no longer "novel" under the
> IP laws of almost all countries outside North America.
>
I see.
If I understood correctly, this means that the release itself prohibits
_further_ patents to be registered on the software. Is that right?
But as you say this does not apply in the USA, so a express
provision is still necesary.
> Finally,
> AFAICS, a sort of "common practice" at companies practicing
> "the open source" (e.g. IBM) is to seek the patent protection
> and grant rights to the open source community (again: CPL *is*
> the preferred license) but seek "compensation" from the
> proprietary "closed source" competitors. What's wrong with that?
>
Nothing is wrong with that per see, it is a matter of goals.
Companies like IBM do businesses with their software, thus it makes sense
for them to seek patent protection, because patents regulates competition.
But competition is the key to evolution, so to the users and computing comunity
at large, patents are a BIG nuisance.
I don't think boost developers really want to protect themselves against comptetition,
we just want to retain credit for what we originally did, but via a simple mechanism.
Retaining _copy_ rights is far more easier than retaining _intellectual_ rights.
Currently, anyone can write from scratch the smart pointer libraries under his own
name.
We cannot protect that without a patent, right, but my guess is that boost developers
don't
really care, otherwise, we wouldn't release our work through boost.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
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, > > from patenting the covered Software and any implied intellectual production. > > That would make no sense. > Why? Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
"Beman Dawes" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > Thanks to Dave Abrahams, Diane Cabell, Devin Smith, and Eva Chen, we now > have a pretty close to final draft of a new Boost Software License. > Congratulations! Excelent work!! > * Boosters for whom English isn't their primary language; is the license > understandable? > I'm from Argentina so Spanish if my first language. I had no problem at all reading and understanding the license, though I've trained myself at reading licenses way ago, just to make sure I don't infringe copyrights while using Open Source/Free code. > > * Boosters (or their lawyers) from countries other than the US; do they > spot any issues missed by Boost's US-centric legal team? > None that I can tell. > * Boost developers; if there are aspects of the license that make you > hesitate about adopting it, what are the issues? > I'd like to see the issue of the coverage of the term "Software" resolved. Motivated by A. Terekhov concerns, I think the license should, if at all possible, expressely PROHIBIT anyone, including the copyright 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
[boost] Formal Review Request: Numeric Conversions
Hi All! I hereby request a formal review of the Numeric Conversions library, which can be found here: http://groups.yahoo.com/group/boost/files/numeric_conversions.zip Here's an except of the 'Overview' documentation section: -- The Boost Numeric Conversion library is a collection of tools to describe and perform conversions between values of different numeric types. The library includes a special alternative for a subset of std::numeric_limits<>, the bounds<> traits class, which provides a consistent way to obtain the boundary values for the range of a numeric type. It also includes a traits class conversion_traits<> which describes the compile-time properties of a conversion from a source to a target numeric type. Both arithmetic and user-defined numeric types can be used. A policy-based converter object which uses conversion_traits<> to select an optimized implementation is supplied. Such implementation uses an optimal range checking code suitable for the source/target combination. The converter's out-of-range behavior can be customized via an OverflowHandler policy. For floating-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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: proposal for efficient geom. vector class
Johannes Brunen <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi, > > There is already a mature traditional library, namely the > Computational Geometry Algorithm Library (CGAL). > > http://www.cgal.org/index2.html > > They have already done a lot of work in the field. > > Unfortunaltly, it has special licening conditions. But it is still worth > a look! > Furthermore, the CGAL 2/3D Kernels -which are very very good and mature- will be available under the LGPL license somewhere this year, so I guess it won't payout to write a boost basic geometric library. Checkout: http://www.geometryfactory.com/components/index.html Once the Kernels are made publicly available, we can see to convice the developers to have them (or a subset) under the Boost license instead of LGPL. In any event, the Kernel documentation is available, 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
[boost] Re: Re: optional<>: size optimization
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.
> >> 'max_size_type_that_fit_in_padding'
> >> must better be one of the intergral types
> >> to make easy and safe to use, so I guess that
> >> there might ocurr that some bits
> >> are wasted anyway.
> >
> > Why couldn't it be a char[]?
>
> char[] makes sense. Add a tag_size constant int and we're
> in business :-)
>
The reason why I discarded an array (or my problem with it, maybe)
is that it is difficult to get/set it because of
its semantics (array are not first class objects).
Furthermore, suppose there is no padding in a particular
implementation, how is the user supposed to allocate
the tag?
Of course, he can allocate it in its own structure, but he'll
need some awkward metaprogramming in such a case because
the tag will be either in the aligned_storage or somewhere
else.
I think that an usable solution, which might not exploit the
padding 100%, but which will be quite easy to use is this:
template
struct aligned_storage
{
void const* address() const ;
void* address();
// If tag_t fits in the padding, it is allocated there,
// else it is allocated separately (but in here)
tag_t const& tag() const ;
tag_t& tag();
}
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: optional<>: size optimization
"Gennadiy Rozental" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> > In fact, it might be tempting to use the other bits as well.
> > For example, I'd imagine a variant implementation that uses
> > 8 bits to flag the currently active type. I imagine this interface:
> >
> > template
> > class aligned_storage
> > {
> > public:
> >
> > void const* address() const;
> > void* address();
> >
> > unsigned char tag() const;
> > voidtag(unsigned char data);
> > };
>
> In fact it might be tempting to use all of them available:
>
> template
> class aligned_storage
> {
> typedef ... max_size_type_that_fit_in_padding;
> public:
>
> 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_in_padding'
must better be one of the intergral types
to make easy and safe to use, so I guess that
there might ocurr that some bits
are wasted anyway.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [lambda]/[spirit-phoenix]Lazyevaluation+expressiontemplates
"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 > > that pheonix is distributed with boost 1.30.0? or only part of it? > > There will be an LL/Phx merger. I hope it will be soon. That > depends a lot on which is the least compiler to support. Right > now, I have the core up and running on VC7 but ICEs on VC6. > Either I leave VC6 behind (now that 7.1 is imminent), or I > spend more time hunting by trial and error. The new LL/Phx > merger is MPL based. > I'm, looking fwd to it! > BTW, Borland works as it does in Phoenix as do a lot more > compilers: > > http://spirit.sourceforge.net/wiki/index.php?page=Compiler+Table > > So the question is *to-vc6-or-not-to-vc6*, please send in your votes. > I prefer to have a tool that works only on new compilers than not to have it at all. > Second question: I'm trying to do something which I > > think could be done with some of the functional programming > > libraries and tools available here at boost, perhaps > > in combination with other tools from elsewhere. > > [snip] > > Ah..Lazy-evaluation... This was asked in the past. Phoenix named > placeholders: Phoenix+boost::function :-)... > This link might be of interest to you: > > http://article.gmane.org/gmane.comp.parsers.spirit.general/3393/match=placeh older+cpp > > This feature will hopefully, if Jaakko agrees, be part of the new > merger. > I just swa it, looks great! > > I'm heavily investigating *true* lazy evaluation, not to be confused > with partial evaluation that's currently done in LL and Phoenix. > To avoid confusion, I should change everything "lazy" in the Phx > docs to probably be "deferred". These are subtly different concepts. > Intereseting I think to remeber having read about a C++ framework with true lazyiness in one of the FC++ papers (but not in FC++ itself). If I get to remember it, I'll let you now. BTW, I actually need 'deferred' eval for my purposes, not truly lazy, so the "named-placeholder+function object" trick would do I guess. Thanks, Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [lambda]/[spirit-phoenix] Lazy evaluation+expressiontemplates
Hi, First question: I see that there is a phoenix subdirectory under both boost/spirit and lib/spirit; does this mean that pheonix is distributed with boost 1.30.0? or only part of it? Second question: I'm trying to do something which I think could be done with some of the functional programming libraries and tools available here at boost, perhaps in combination with other tools from elsewhere. Consider this: // Just two 2D vectors. Vector2D v(1,1), u(2,2); // A vector given by a vector expression. Vector2D s = v + u ; What I want is to have 's' not having a real value but storing the _expression_ (v+u) instead, so that if I subsequently do something like: Vector2D t(3,3); double dot = s * t ; // operator * is dot product is the dot product operation who evaluates 's' to produce the result. Similarly, I should be able to construct even more complex expressions with other vector operations, such as multiplication by a scalar, which are evaluated only at certain specific points. I've been palying with PETE (the Portable Expression Template Engine) but all I can do is something like: & s = v + u ; but as soon as 's' is assigned to a Vector2D it is fully evaluated. Thus, I need to combine PETE with some sort of lazy evaluation tool. Can something like this be done with (boost) Lambda, Bind or Phoenix? FYI, what I'm trying to do is to combine what is known as "floating-point filtering" (explained below) with expression templates+lazy evaluation to allow the construction of geometric objects via algebraic expressions. Ideally, a user would be able to write the following: // // Objects created via ordinary construction // (reduced form in FC terms) // point a(0,0), b(10,10); line D(a,b); // a diagonal line point c(2,0), d(2,10); line L1(c,d); // a vertical line at x=2 point e(2+epsilon,0), f(2+epsilon,10); line L2(e,f); // a vertical line at x=2+espilon // // Objects created via expressions // /* Here, the coordinates for points i0,i1 are given by unevaluated expressions. */ point i0 = intersect(L1,D); point i1 = intersect(L2,D); // // Application of lazy evaluation + floating-point filtering // /* Here, the member function int line::ordering(p0,p1) returns the relative ordering of the input points along the line w.r.t to the line orientation: (i.e., if p0 is before p1, returns +1) */ int order = L1.ordering(i0,i1); /* The thing is that if points i0,i1 are given actual coordinates during the intersection computation, the ordering predicate will deal with unaccurrate data already and won't be able to give a correct result no matter how fancy aritmetic it uses. OTOH, if i0,i1 can be internally represented by the expressions used for the intersection computation, the ordering predicate can use the technique known as "floating-point filtering": evaluate the expression first with standard double precision, and if it detects loose of significand data, do it again with an unlimited precision number type. This technique has been used for years but with 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
[boost] Re: boost::optional feature request.
"Joe Gottman" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] >It would be nice if boost::optional had operator< defined whenever > operator< was defined for T. This would allow us to use optional as the > key of an associative container. I suggest the following semantics: > > bool operator<(optional const &x, optional const &y); > > Returns: If y is uninitialized, false. If y is initialized and x is > uninitialized, true. If x and y are both initialized, (*x < *y). > > > >This results in a strict weak ordering with uninitialized optional > objects being sorted first. > > I don't see any problem introducing this with the given semantic as long as the choice is well documented and a rationale for it is included. I like the semantic you are proposing, it looks right to 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 that, I'll add it. Thank you. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] two problems with BCB 6 and 1.30b
Pavel Vozenilek <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> - Original Message -----
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > > Following snippet of code fails:
> > > -
> > > #include
> > > #include
> > >
> > > void foo(const boost::optional >& aux =
> > > boost::optional >())
> > > {}
> > >
> > > int main() {}
> > > -
> [snip]
> > Hmm..
> > I can't reproduce the problem here with the 1.30.0 release,
> > BCB6, update 4, from within the IDE.
> > Which command line options are you using?
> >
>
> The BCB flags are:
OK, I finally reproduced the problem:
It has nothing to do with compiler flags (I made a mistake when
I tried the snippet which masked the error), but it has nothing to
do with optional either :-)
The following produces the same error:
#include
void foo( std::pair >& aux
= std::pair >() // (1)
)
{}
int main() {}
-
Commenting line (1) we can see that the problem
is related to the default value expression.
Furthermore, adding: using std::pair ; solves
the problem.
Further investigations revleas that this is a
subtle ADL bug related to default arguments:
In the following:
--
namespace A {
template
struct X {} ;
template
struct Y {} ;
}
void foo ( A::X& aux
= A::X() // (1)
) ;
void bar ( A::Y& aux
= A::Y() // (2)
) ;
int main() {}
(1) compiles
but (2) doesn't, unless "using A::Y" is added.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Un-named unions and Borland Internal Compiler Error
Russell Hind <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Line 56 of optional.hpp states that Borland ICEs if the union is > un-named. This is correct for C++Builder 5 (0x551), but C++Builder 6 > Update 4 (0x564) doesn't have this problem. > > Not 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
[boost] Re: [optional] two problems with BCB 6 and 1.30b
/*
Pavel Vozenilek <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I use Borland C++ Builder 6, update 4, STLPort 4.5.1 (provided by Borland)
> and Boost is 1.30.0beta1.
>
Sorry for the delay...
> Following snippet of code fails:
>
> -
> #include
> #include
>
> void foo(const boost::optional >& aux =
> boost::optional >())
> {}
>
> int main() {}
> -
>
> with error message:
> [C++ Error] Unit1.cpp(12): E2188 Expression syntax
> [C++ Error] Unit1.cpp(12): E2299 Cannot generate template specialization
> from '_STLD::pair<_T1,_T2>'
> [C++ Error] Unit1.cpp(12): E2299 Cannot generate template specialization
> from 'boost::optional'
> [C++ Error] Unit1.cpp(13): E2257 , expected
> [C++ Error] Unit1.cpp(33): E2151 Type mismatch in default value for
> parameter 'aux'
> [C++ Error] Unit1.cpp(12): E2293 ) expected
>
>
> The same code compiles OK with Intel C++ 7.0.
>
> If I use typedef it works OK with both BC++B and Intel C++:
> -
> #include
> #include
>
> typedef boost::optional > AType;
>
> void foo(AType aux = AType())
> {}
>
> int main() {}
> -
>
Hmm..
I can't reproduce the problem here with the 1.30.0 release,
BCB6, update 4, from within the IDE.
Which command line options are you using?
>
> Borland also fails with this construct:
> -
> #include
>
> int main()
> {
> boost::optional aux(0);
> if (aux && *aux == 0) {
> aux.reset(1);
> }
> }
> -
>
> with this error message:
> [C++ Error] Unit1.cpp(24): E2094 'operator&&' not implemented in type
> 'boost::optional' for arguments of type 'bool'
>
> Intel C++ 7.0 compiles and executes this snippet OK.
>
> This works in BC++B:
> -
> #include
>
> int main()
> {
> boost::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
[boost] Re: [optional] C'tor forwarding
"David B. Held" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > I would like to use optional<> with some fat types, but I don't really > want to pay for the copy in construct(). I would rather see a c'tor > forwarding interface, tedious 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/Mail/Message/1539796 Regards, Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Outstanding patches and fixes
"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 case BOOST_TYPENAME or BOOST_NO_TYPENAME might be an > appropriate name. I like BOOST_TYPENAME, FWIW. > I'm glad I didn't move on the renaming before you > revealed the Borland issue! > Me too... I would have spoken early, but Internet Access became very restricted on the office, so it took me some time to arrange things to get back to a regular list reading, and I missed quite some posts during the transition. I'm not on-line during the whole day anymore, but I'm getting in a couple of times daily. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] Doc edits
"David B. Held" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > Under "A note about optional" is the line: > > Second, optional<> provides and implicit conversion to bool. > > Of course, it should be "an". > Fixed, thanks! >An even subtler nitpick is that in the > line: > > First, it is functionally similar to a tristate boolean (false, > maybe,true) -such as boost::tribool-, except that in a tristate > boolean, the maybe state represents a valid value, unlike the > corresponding state of an uninitialized optional. > > I think two hyphens should be used for the em-dashes (or the > actual em-dash character, which is probably not portable). Also, > the comma after the em-dash is probably not necessary (even > though it would be if the parenthetical 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 found many boost documents using it. > Otherwise, the documentation looks great! > Thank you! Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] Possible alignment bug?
Markus Schöpflin wrote: > Markus Schöpflin wrote: > >> gmane wrote: >> >>> Andreas Huber <[EMAIL PROTECTED]> wrote in message >>> news:[EMAIL PROTECTED] >> >> >>>> typename type_with_alignment< >>>> ::boost::alignment_of::value >::type aligner_; >> >> >>> You're absolutely right!!! >>> >>> BTW: I wish I had a platform were misalignment does cause a fault, >>> unlike Windows. >>> >>> Fixed. >> >> Fernando, I think you missed the "typename" above. The optional test >> now fails for VA6, and I would think for other compilers as well. > > I just commited a fix for this to the release branch and the trunk. I > added "BOOST_DEDUCED_TYPENAME" instead of "typename", which should > 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
[boost] Re: Re: Outstanding patches and fixes
"David Abrahams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Fernando Cacciola" <[EMAIL PROTECTED]> writes: > > >> * [config] BOOST_DEDUCED_TYPENAME > >> Status currently unknown. John? Aleksey? > >> > > >Dave A. introduced the macro I would prefer him to change it as he knows > >>what's required - or have I nissed something? > > > > BTW, I've used BOOST_DEDUCED_TYPENAME in my own code with bcc5.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. > > I guess that rules out BOOST_MSVC_TYPENAME as a name. > Is typename ever required with BCC 5.5.1? > With BCC5.5.1 typename is _never required_ AFAIK, but it is with BCC5.6.0(4) Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Outstanding patches and fixes
> * [config] BOOST_DEDUCED_TYPENAME > Status currently unknown. John? Aleksey? > >Dave A. introduced the macro I would prefer him to change it as he knows >what's required - or have I nissed something? BTW, I've used BOOST_DEDUCED_TYPENAME in my own code with bcc5.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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Jamfile patches for Borland
"Alisdair Meredith" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > Borland fails several tests due to missing exports from in its > dynamic runtime library. > > The following two patches will use static linking on the problem > libraries (for borland only) > I'm not sure if this is correct because the problem is not with boost but with STLPort numeric_limits<> as shipped with BCB6. (I reported this before). The problem I see is that the test will now pass but becasue of a particular condition (the static RTL). As a boost 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 column showing particular uncommon constrians. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Borland C++ Builder patch 4 released
FYI, with Update 4 __BORLANDC__==0x564 Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: postponed<> proposal
"Philippe A. Bouchard" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > David B. Held wrote: > > > "Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > >> David Abrahams wrote: > >> > >> > "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > >> > > >> >> I would like some feedback about the logic behind it. > >> > > >> > Do you have a use-case for this? > >> > >> Sorry, I do not understand; you mean someone that would want to > >> use it this way? I am not sure, but it would be better for continous > >> optional<>s this way? > > > > Dave is asking you if you are solving a problem that doesn't exist. ;) > > Your 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 proposal is that as I said before the boolean flag is initialized before the object is really constructed. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] Polymorphism
"Philippe A. Bouchard" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
>
> "Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> [...]
>
> > int main()
> > {
> > optional b;
> > optional c;
> >
> > foo(b);
> > //foo(c);
> > }
>
> BTW implicit cast to reference types are not implicit under GCC, they have
> to be called explicitly.
Yes, this is the conformant behaviour AFAIK
>Template casts do not seem to be defined in the
> standard...:
>
> template
> struct optional
> {
> template
> operator optional const & () const
> {
> return * reinterpret_cast const
*>(static_cast const *>(reinterpret_cast(storage_)));
> }
>
> ...
> };
>
This is seriously wrong:
(a) reinrepret_cast<> has implementation-defined behaviour,
which means that is totally useless in portable code.
(b) you don't need reinterpret_cast<> to obtain a 'T const*'
from the aligned_storage whithin the optional: look at the optional code.
(c) EXTREMELY WRONG: you're converting a pointer to aligned_storage<>
into a pointer to optional<>, !!! but aligned_storage is a _data_member_
of optional!!!
> inline void foo(optional const &)
> {
> }
>
> int main()
> {
> optional b;
>
> //foo(b);
> foo(b.template operator optional const & ());
> }
>
>
> Also, the advantage of casts to reference types is that they do not create
> any temporary objects implicitly.
>
But does not create a new objet either!
A conversion is REQUIRED to give a NEW OBJECT,
otherwise there's no conversion at all: since the object remains exactly
the same, you just BROKE the type system by binding a reference of a
completely unrelated type to the same object.
The only case when you can do something _similar_, that is, when
you can't do a _convertion_ but you can do a _cast_, is when the
reference type (or pointer type, for that matter) is of the type of a
non-ambiguous accesible base-class subobject
(because the object dynamic type is covariant with the
reference/pointer static-type).
>
> I do not see in what it can be dangerous.
>
I do :-)
And I see the danger in reinterpret_cast<>; stay away from it.
>
> What do you think?
>
Please, read my original response to David Held and look carefully at
the optional implementation.
As I said, you could only get half away with such a _conversion_ 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
[boost] Re: [optional] Polymorphism
"David B. Held" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> I think optional might be perfect for an issue I have, but there is one
> catch.
> I have a polymorphic hierarchy that I would like to use with optional, but
> optional is not a base of optional. Of course, this isn't
> really a problem with optional, par se, but any suggestions on how to
store
> pointers to optional when T is polymorphic would be appreciated.
>
> I know I can use aggregation like so:
>
> class Base
> {
> virtual ~Base() { }
> };
>
> template
> class PolyOptional : public Base
> {
> optional value_;
> };
>
> and then just store Base*, but this requires explicit run-time checking of
> types which would otherwise be automatic with pointers to T instead of
> optional. If this is the only solution, so be it; but any clever
> alternatives are welcome.
>
> Dave
>
I think I have bad news...
Let me see:
Given:
struct B { virtual ~B() ; } ;
struct D : B {} ;
You can have optional and optional; but as you say,
they are not inheritance related.
You would like to be dealing with:
optional* and optional*
but you can do this as well, so I figure that what you really need
is a 'dynamic-type preserving' conversion between these optionals.
Something that would allow the following:
D dval ;
optional dopt(dval);
optional bopt ( optional_cast(dopt) ) ;
optional dopt2 ( optional_cast(bopt) ) ;
assert ( dval == *dopt2);
Is this what you need?
If it is, I'm afraid it's not possible:
The problem is that even though the conversion will succeed
(it would probably work with the current optional as it is now),
it will inevitably _slice_.
The reason is that optional will get exactly the B subobject
within D and there's no way to get back the rest of D from the B
subobject alone.
AFAICT, this can only be done with pointers because the shallow copy
semantics of pointers is which retains the dynamic type (that is, the
object is always the same, you just refer to different parts of it).
This can't be done with value semantics, unless not if you don't cheat and
traffic always the most derived object by-value.
I think that a solution which uses the PolyOptional technique
is the only way to go.
BTW, that technique is essentialy 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
[boost] Re: Re: Re: Re: Re: partial<> proposal
"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 'int' > > unless T happens to be aligned just like 'int', which won't always be > > the case, so I don't > > see the relation between optional's storage and the correlation > > bool<->int you > > make above. > > For example, the storage for optional won't be aligned > > to a double-word boundary like 'int' does on 32-bit platforms, for > > instance. > > Yes it does, because m_storage is preceded by m_initialized which is of type > bool in optional<>. m_storage will thus follow bool alignment requirement. > Aha, now I know what did you mean... "within" optional<>, m_storage is aligned to the next word boundary... I agree this would be the case if sizeof(bool)==sizeof(int). Ithough you were talking about m_storage itself, that is, of aligned_storage per se. Anyway, just for the record, the C++ type 'bool' has an 'underlying type' which is required to be one of the integer types but not necessarily 'int'. > > [snip optimized array] > > I could have made a mistake in my example, but operator [] in assembler code > will be quite fast (and, shl, ...) when it comes to logical operations. I > don't think it will be twice slower. > That would have to be _measured_; my guess is that it could be twice slower, specially considering that I don't think boost sources will ever include assembly code; it's a portability nightmere. > > > So, what are you trying to optimize with this bool array? > > and most importantly, why do you feel that such optimization is > > needed? Consider that gaining storage, say 31 bits, per optional<> > > will incurr in > > a significant overhead, so in order to think that the gain is needed > > you need to weight size/speed benefits. > > This sort of things are typically considered only afer some benchmarks > > shown the need for the optimization. > > Even tough array is not optimized, the boolean values will follow each > other and will not waste any space between themselves. > Yes, though I still can't see if this would be _needed_. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: Re: partial<> proposal
"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 discard it, though to me it looks
> >> kind of akward in anything but deeply low-level code.
> >>
> >> Anyway, doesn't this require a definition of placement operator new
> >> for each T?
> >
> > I don't know, possibly so. It's been so long I've forgotten more than
> > I ever knew ;-)
>
> It only requires
>
> template void * operator new(size_t n, optional & t);
>
> I think.
>
> One problem is that there is no reliable way to prevent
>
> optional opt;
> new(opt) Y; // oops
>
> since the type being created is not communicated to operator new, only its
> size is.
>
Yes, that's why I was thinking of something that were overloaded for T
rather than for optional.
Anyway, there are still problems with this: operator new is called _before_
the T is constructed, so there won't be a way, AFAICT, to properly set the
initialized flag ('cause if T ctor throws, placement new won't be aware of
it)
--
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: questions and comment about optional
"Stephen Lamb" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > I'm not absolutely sure I have the latest class optional but here goes. > > Why does optional not have an assignment operator which takes a value? > Experience shown that this question is hard to answer convincely.. :-) The very short answer is: Because it would break its pointer-like interface (in this case, it would break symmetry) For the long answer go through the review were the interface and it's implications (like the lack of direct assignmen) were discussed at length. > > Why is the following constructor explicit? > template > explicit optional ( optional const& rhs ) > > I would think that this would actually be a case where implicit copy > construction would be welcomed. Notice that that is a _converting_ copy constructor. As such, it is explicit in order to prevent implicit conversions. The regular copy ctor is not explicit. > > > The version of optional I have implements operators -> and * in terms of > the get function. The get function has a conditional that is > unnecessary extra work 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
[boost] Re: Re: Re: Re: Re: partial<> proposal
"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, > > > > ^^^ > > Were does this 'int' comes from? > > sizeof(bool) may vary, you just don't know (1, 4, 8, ...). On Intel, if > sizeof(bool) == 4 == sizeof(int) optional<>::m_storage will be aligned to > the next integer boundary. > It seems there is something one of us don't understand... optional::m_storage has nothing to do with alignment to 'int' unless T happens to be aligned just like 'int', which won't always be the case, so I don't see the relation between optional's storage and the correlation bool<->int you make above. For example, the storage for optional won't be aligned to a double-word boundary like 'int' does on 32-bit platforms, for instance. > > >> m_storage will be aligned to the next word boundary i.e. aligned > >> like an integer. > >> > > Anyway, you just said that it depends on the platform, so I wouldn't > > say > > that m_storage *is* > > aligned like bool, at most, it could be. > > Yes, exactly. > > >>>> - 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? > >> > >> I don't know, it is just another alternative that I personally > >> prefer. > >> > > Why do you prefer this? > > Because the main purpose of aligned_storage<> is to postpone its > construction? > No. The main purpose is to represent _raw_ aligned storage. Storage byt itself is orthogonal to object state (and construction is about _state_ initialization). Just like operator new returns a 'storage' (i.e, a raw aligned memory block), but construction must occur afterwards and independetly of the storage allocation, aligned_storage also gives you a raw aligned memory block and is also independent of object construction. > This means that it *must* be constructed sooner or later? Some object must be constructed sooner or later within the aligned storage, yes, but that's not the job of aligned_storage itself, just as it is not the job for operator new. > > >>>> - Maybe we could create 2 separate type lists if optional<> is used > >>>> many times in the same object, gathering m_initialized types and > >>>> m_storage in separate lists: > >>>> > >>> What for ? > >> > >> I think bool arrays use bitfields > >> > > Which bool arrays? > > > > bool x[..] ; > > > > dont't. > > > > std::vector > > > > maybe, but are less efficient in that case. > > I guess boost::array is also optimized...? > No, it isn't. But anyway, remember that bit-allocation _necesarily_ optimizes size at the expense of speed. So, what are you trying to optimize with this bool array? and most importantly, why do you feel that such optimization is needed? Consider that gaining storage, say 31 bits, per optional<> will incurr in a significant overhead, so in order to think that the gain is needed you need to weight size/speed benefits. This sort of things are typically considered only afer some benchmarks shown the need for the optimization. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: partial<> proposal
"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 the forwarding > > problem, but I couldn't get it to really work. > > What would it be like, exactly? > > > > I considered: > > > > (a) > > > > optional opt ( new ( optional_tag ) int(1) ) ; > > > > this won't work because 'opt.m_storge' doesn't exist yet inside placement > > new. > > > > (b) > > > > optional opt ; > > new (opt) int(2); > > > > this would be close, but what should I do with the 'int*' > > which is the result of the new? > > Why do you feel the need to do something with it? Do you do something > with the pointer when you do placement new in the optional > implementation? > No, right're right :-) Is perfectly possible to simply discard it, though to me it looks kind of akward in anything but deeply low-level code. Anyway, doesn't this require a definition of placement operator new for each T? Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: partial<> proposal
"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-place construction (which bypasses the
> > copy). In this case, 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?
>
> Yes, something like that. I am curious to know how in_place<> works.
>
Look at the thread "'optional' - request for extension"
Essentilly,
in_place(a0,a1,a2...)
just creates a function object which holds onto the argument list:
template
struct in_place_factory2
{
in_place_factory2( A0& a0, A1& a2) : m_a0(a0), m_a1(a1) {}
A0& m_a0 ;
A1& m_a1 ;
}
and which has the following function call operator:
void operator() ( void* address ) const
{
new (address) T(m_a0,m_a1);
}
optional<> ctor just calls the function object passing its own m_storage as
a parameter.
--
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: partial<> proposal
"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's ctor argument to optional<> so that > > T is effectively constructed in-place right within the aligned storage. > > > > Is this what you want? > > I have to say that I like the idea of using placement-new with an > optional<> argument better, since it doesn't get you involved with > the const ref/non-const ref/rvalue forwarding problem. > I thougth about placement new as a way to achieve in-place optional construction, precisely because of the forwarding problem, but I couldn't get it to really work. What would it be like, exactly? I considered: (a) optional opt ( new ( optional_tag ) int(1) ) ; this won't work because 'opt.m_storge' doesn't exist yet inside placement new. (b) optional opt ; new (opt) int(2); this would be close, but what should I do with the 'int*' which is the result of the new? int* p = new (opt) int(2) ? But this is just: int v=2; int* p=&v; -- Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: partial<> proposal
- 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 the fact optional<>::m_storage is aligned like a bool...: > >> > > It is not aligned like a bool... > > Well it depends on the platform but if sizeof(bool) == sizeof(int) on Intel, ^^^ Were does this 'int' comes from? > m_storage will be aligned to the next word boundary i.e. aligned like an > integer. > Anyway, you just said that it depends on the platform, so I wouldn't say that m_storage *is* aligned like bool, at most, it could be. > >> - 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? > > I don't know, it is just another alternative that I personally prefer. > Why do you prefer this? > >> - Maybe we could create 2 separate type lists if optional<> is used > >> many times in the same object, gathering m_initialized types and > >> m_storage in separate lists: > >> > > What for ? > > I think bool arrays use bitfields > Which bool arrays? bool x[..] ; dont't. std::vector maybe, but are less efficient in that case. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: partial<> proposal
"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > David Abrahams wrote: > > "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > > > >> Yes, exactly. Sorry if I wasn't precise enough. > >> > >> The bool type will cancel type_with_alignment<> effects (at least on > >> Intel compatible platforms); i.e. unique alignment of each > >> optional type. > > > > Sounds like you want > > > >type_with_alignment::type storage; > >new ((void*)&storage) T(x, y, z) > > > > Can you really do anything to make this cleaner? I guess: > > > > aligned_storage storage; > > new (storage.bytes) T(x, y, z); > > > > might be a help. What else are you gaining? And how do you destroy > > the T? If not explicitly and you don't have a "constructed" flag, > > you're going to have exception-safety problems. > > Everything seems already defined ;) > > Given the fact optional<>::m_storage is aligned like a bool...: > It is not aligned 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 create 2 separate type lists if optional<> is used many > times in the same object, gathering m_initialized types and m_storage in > separate lists: > What for ? -- Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: partial<> proposal
- Original Message - From: "Philippe A. Bouchard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 24, 2003 4:29 PM Subject: [boost] Re: Re: Re: partial<> proposal > David Abrahams wrote: > > [...] > > >> Example: > >> optional i; > >> > >> new (i) int(17); > > > > Which copy ctor are you referring to? > > And why do we want to prevent copy ctor usages? > > Because optional<> will be able to handle types without copy constructors > (this was the main purpose of partial<> in fact). I was referring to the > copy constructor of optional<>'s template parameter. > I'm still not sure I understand what are you trying to do, but it looks like you want optional with in-place construction (which bypasses the copy). In this case, 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
[boost] Re: shared_ptr and null pointer values.
"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:
> >
> > struct C
> > {
> > C() : ptr(0) {}
> >
> > shared_ptr ptr ;
> > } ;
> >
> > this one is very useful because its very idiomatic.
>
> Use
>
>C() : ptr() {}
>
> instead; it is supposed to work for any pointer.
>
I know I can do this instead.
But my point is that we rarely do it :-)
Value-initialization is not as idiomatic as it should, specially if you
consider the highly generic case of a 'general' pointer (either built-in or
smart).
Neither is (!p) and (!!p) or (p) instead of (p==0) and (p!=0),
unfortunately.
Just take a look at almost any boost code (shared_ptr.hpp, for example); the
null pointer value is used a lot (not only in initialization but in testing
too)
So, having support for null-pointer-value in a smart ptr makes it more
'pointer-like' in light on the de-facto idioms still in broad usage today.
Anyway, I agree with Daniel Frey in that putting this into shared_ptr will
disallow stricter guidelines.
--
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shared_ptr and null pointer values.
"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 my old
> > smart pointers replacing them by shared_ptr<>.
> > There is however one idiomatic usage that it's pretty
> > hard to locate and edit, so I wondered if shared_ptr<>
> > could support it.
> > One is initialization from a null pointer value, as in:
> >
> ...
> >
> > this one is very useful because its very idiomatic.
> >
> > The other one, definitely not recommended but which *I* need
> > to support because my code if full of it,
> > is assignment of a null pointer value as a synonym for reset(),
> > as in:
>
> ...
>
> > What do you think?
>
> I think this looks like a job for
>
> template
> struct my_shared_ptr : shared_ptr
> {
> ... // additional interface here
> };
>
Yes, this is what I did actually...
I just thought that the addition, -> the initialization from 0, was good
enough to be considered as a formal extension.
--
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
