[boost] Re: Re: Re: [boost.variant] It is possible to makeavariantLessThanComparable
Peter Dimov wrote: [snip] Provide operator. Wait six months. Collect feedback. If there is evidence that operator is evil, remove it and document why it is not supplied. OK, I'm willing to go along with this. I'll probably also include operator==, with a similar plan for future evaluation. Early evidence that operator is evil though may be demonstrated in the following: boost::variantint, double var(3.0); ... if (var = 3) // false ... While the obvious objection is but operator isn't meant for variant-nonvariant comparison, I don't see how to prevent it since variant has implicit constructors. Ideas? Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Optional, tie, and iterator_adaptor
Mat Marcus [EMAIL PROTECTED] wrote:
--On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola
[EMAIL PROTECTED] wrote:
Joel de Guzman [EMAIL PROTECTED] wrote in message
One can think of an optionalT as conceptually a specialized but
nevertheless, *IS-A* T, with the added 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 optionalT
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 optionalT 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. 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! Some people say it is like a pointer
that can be NULL. Not! And this uncertainty leads us to confusion, and,
ultimately: missguided syntax and semantics.
My attempt to image optionalT as conceptually a specialized but
nevertheless, *IS-A* T, with the added specialization that it can
be in a dead-uninitialized state. Is a feeble attempt to re-sell the idea
of the concept that will be immediately obvious to the OO programmer. I
never really understood why I wasn't able to sell the idea that an
optionalT is *REALLY REALLY REALLY* nothing else but a
union of T and nil.
Here's a question that tries to get to the crux of the pointer-like
interface matter. Should T* and optionalT both be models of a
pointer-like syntactic concept?
Definitely No!
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. Those who answer no to the above question may
prefer to write code that uniformly handles T and optionalT. 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 optionalT's uniformly or
even replace raw pointers with optionalT's, since pointers also
bring allocation issues with them. Instead I have been mainly focused
on replacing T's with optionalT's. 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 agree 200%. I think the *only* meaningful argument against this
was posed by Brian. That, in C++, you cannot make XT be a
drop-in replacement of T because implicit conversion will not
allow code such as:
struct A { void foo(); }
template class T
void bar(T t) { t.bar(); }
bar(A());
bar(XA()); // HERE
Unless:
class XT : public T {...};
But then again, that's just a technical impediment.
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. 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.
Same here. 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
;-)
Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Optional, tie, and iterator_adaptor
Fernando Cacciola [EMAIL PROTECTED] wrote: Direct value accesing via implicit conversion: int i = opt seems wrong because this is the operation that can lead to undefined behaviour. Doesn't have to be undefined behaviour. Yes it does. Accesing a value that isn't there is by all means 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. Wrong! 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. Pardon me, but you are clearly mistaken! Are you saying that variant's getT(v) leads to undefined behavior? NO! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: optional, tie, and iterator_adaptor
Dave Gomboc [EMAIL PROTECTED] wrote: [Fernando Cacciola] The most fundamental point is that being Haskell a pure functional language there is no possibly undefined behaviour to worry about, so Maybe doesn't need to address this issue as optional does. ... and later ... I account the possibly undefined behavior of accesing an uninitialized optional as a real and important problem. You can get rid of the possibly undefined behaviour by defining it! Throw an exception when there's an attempted coercion from nil/undefined to a normal value. Exactly! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: generic uses of optionalT
On Mon, Sep 01, 2003 at 04:05:59PM -0600, Dave Gomboc wrote:
[Brian McNamara]
do_something( adapt( 3 ) );
do_something( adapt( nilableint(3) ) );
do_something( adapt( foo ) ); // foo has unknown type
But I'd like to write
do_something(3);
do_something(foo); // of type T
do_something(bar); // of type nilableT
Can I have my cake and eat it too? ;-)
Yes:
template class T
void do_something( T x ) {
do_something_helper( adapt(x) );
}
template class T
void do_something_helper( nilableT x ) {
/* actually do it */
}
(Shameless plus: Note that with FC++,
do_something = compose( do_something_helper, adapt );
or
do_something = do_something_helper ^of^ adapt;
provided that things are defined as functoids.)
--
-Brian McNamara ([EMAIL PROTECTED])
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Optional, tie, and iterator_adaptor
On Tue, Sep 02, 2003 at 09:05:59AM +0800, Joel de Guzman wrote:
My attempt to image optionalT as conceptually a specialized but
nevertheless, *IS-A* T, with the added specialization that it can
be in a dead-uninitialized state. Is a feeble attempt to re-sell the idea
of the concept that will be immediately obvious to the OO programmer. I
never really understood why I wasn't able to sell the idea that an
optionalT is *REALLY REALLY REALLY* nothing else but a
union of T and nil.
It's been pointed out before, but to re-emphasize it: from a
type-theoretic standpoint, it is not the case that optionalT-isa-T.
Rather T-isa-optionalT. (Dog-isa-Animal because Animal has more
possible values.) I don't mind the suggestive conceptual
analogy/similarity, but when you get down to technicalities, the isa
relationship doesn't hold in the same direction you're saying (in your
first sentence above).
I agree 200%. I think the *only* meaningful argument against this
was posed by Brian. That, in C++, you cannot make XT be a
drop-in replacement of T because implicit conversion will not
allow code such as:
struct A { void foo(); }
template class T
void bar(T t) { t.bar(); }
bar(A());
bar(XA()); // HERE
Unless:
class XT : public T {...};
But then again, that's just a technical impediment.
As I just mentioned in a previous mail, if bar() has the foresight to
expect this, it can use an adapter in its implementation to smooth out
this issue. (E.g.
template class T
void bar(T t) { adapt(t).bar(); }
)
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
--
-Brian McNamara ([EMAIL PROTECTED])
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: variant questions
On Friday 29 August 2003 10:53 pm, Eric Friedman wrote: P.S. Has there been any progress in handling BoostBook documentation in CVS? Perhaps Greg or MetaComm can run nightly builds? (This of course does not solve the problem of offline access though...) There has been no progress, though it is much more likely now that I'm back at home base. Perhaps I can get something up and running at Sourceforge (if we have enough space!). Doug ___ 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 getT(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
Re: [boost] Re: variant questions
On Saturday 30 August 2003 08:00 am, David Abrahams wrote: Misha Bergal [EMAIL PROTECTED] writes: Eric Friedman wrote: P.S. Has there been any progress in handling BoostBook documentation in CVS? Perhaps Greg or MetaComm can run nightly builds? We can do that. Is there any info on how to use Boost.Build v2 to build BoostBook? I missed Misha's reply somehow. There is information on using BBv2 and BoostBook here: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ You can build local copies of the documentation with BBv2 once you've read it g. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
[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, 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. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] adaptable_any vs any_with
On Monday 01 September 2003 07:53 am, Alexander Nasonov wrote: I'm asking for voting for the new name of dynamic_any. Please, give you preference. Here is my discussion about the name with Kevlin Henney ( and empty prefix - Kevlin, - me) Between the two: adaptable_any is better, I think. Because I like throwing wrenches: have you considered a very different name such as polymorphic or just poly. The idea is that we read: polyless_than_comparable, equality_comparable as a type that is polymorphic over all less_than_comparable equality_comparable types. And because I'm feeling silly and reading a book on lattice theory... it could also be named models_meet, as in a type that models the meet of the following concepts in the concept lattice. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
On Mon, Sep 01, 2003 at 09:22:01PM -0600, Dave Gomboc wrote:
[Fernando Cacciola]
I'm saying that the choice made by variant in this regards is to the
code using get as hopeless as undefined behaviour. I don't think that
preconditions (and exceptions thereof) should be used to arbitrarily
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,
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.
I think this is a good idea too. Personally, I side with Fernando's
conception of 'optional', but clearly there are two groups which each
want a different (though similar) class.
My contribution with this message is to mention that, rather than
having two completely separate implementations, one could be built atop
the other (or both from a common root). My hunch is that your nilable
idea could easily be built as a very thin wrapper around optional
(provided optional has a wide enough interface, but I think it does).
Something along the lines of
template class T
class nilable {
optionalT o;
public:
T get() {
if( o ) return *o;
throw oops;
}
// etc.
};
--
-Brian McNamara ([EMAIL PROTECTED])
___
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 variantT,nil, 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
Re: [boost] Re: Boost memory management guidelines
--- Gregory Colvin [EMAIL PROTECTED] wrote: [...] Apropos of which, I now think that the Boost UserAllocator requirements should be the default for components that parameterize how they use memory, with the Standard Allocator requirements being used only for components that need what they offer: a potentially very efficient way to allocate large numbers of small objects of known type, and/or a way to access storage via proxied pointers. Perhaps the boost allocator requirements should just combine both, the UserAllocator and StandardAllocator requirements. In a way, StandardAllocators can be considered as an extension of UserAllocators. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Optional, tie, and iterator_adaptor
--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. 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. 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. Additionally, optional deliberately does not require a throw or assert upon uninitialized use, preferring to leave this as a QoI issue. I can respect this set of design decisions, and optional in this form certainly has its uses. If optionalT grows to allow more transparent co-existence with T (implicit construction, smooth tie interoperability) then I expect it will become even more useful. 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. 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). * Where transparency is not feasable forego pointer-like syntax to avoid any appearance of relation to pointers/iterators * The action upon use while in uninitialized state shall be specified or even specifiable (throw/assert/etc.). * Backdoor to uninitialized storage available, e.g. unsafe_reference() * Works reasonably well with tie() * No double storage penalty 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. As I mentioned at the start, I've spilled enough words on this so I'll step back for a bit now. But if others are interested in working together in this area (on or off list) then perhaps we might collaborate. Thanks again to Fernando, Joel, Brian, Dave G. and others for discussing all of this. - Mat ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- David Abrahams [EMAIL PROTECTED] wrote:
But indeed allocate/construct/deallocate/destroy is more work than
^^^^
Oyeah. These two absolutely don't belong in allocator, period. Do
any implementations even use them? Allocators exist to provide a
point of customization for users, but you cannot/should not customize
these.
[...]
The class getting constructed/destroyed has full control over that or
the language is utterly bustificated.
I think construct/destroy can be implemented as non-customizable
static functions in boost just for convinence.
static template typename A
typename A::pointer construct( A a, size_t n )
{
typename A::pointer p = a.allocate(n)
try
{
p = new(p) A::value_type[n];
}
catch(...)
{
a.deallocate( p, n );
}
return p;
}
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: optional, tie, and iterator_adaptor
Dave Gomboc [EMAIL PROTECTED] writes: [Fernando Cacciola] The most fundamental point is that being Haskell a pure functional language there is no possibly undefined behaviour to worry about, so Maybe doesn't need to address this issue as optional does. ... and later ... I account the possibly undefined behavior of accesing an uninitialized optional as a real and important problem. You can get rid of the possibly undefined behaviour by defining it! Throw an exception when there's an attempted coercion from nil/undefined to a normal value. That could have a significant negative impact on performance and code size, FWIW. 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. No, the interface should be changed, because it _looks_ like it has pointer semantics. So do the proxies required by input iterators over classes and a few other such proxy pointers. They all contain the value they point at. IMO getX(y) is the solution to this problem. But they are iterators, and random-access iterators exhibit pointer semantics. That's the reason iterators use operator* and operator- in the first place! Input iterators also contain the values *they* reference. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [boost.variant] It is possible to makeavariantLessThanComparable
Eric Friedman [EMAIL PROTECTED] writes: Peter Dimov wrote: [snip] Provide operator. Wait six months. Collect feedback. If there is evidence that operator is evil, remove it and document why it is not supplied. OK, I'm willing to go along with this. I'll probably also include operator==, with a similar plan for future evaluation. Early evidence that operator is evil though may be demonstrated in the following: boost::variantint, double var(3.0); ... if (var = 3) // false ... While the obvious objection is but operator isn't meant for variant-nonvariant comparison, I don't see how to prevent it since variant has implicit constructors. Ideas? Arrange for a compile-error if x = 3 is legal for more than one of the types in the variant? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::regex w/o exceptions?
John Maddock schrieb: [snip] If that is true: Why does the flag regbase::use_except (officially) exist? It's a historical accident and should have been removed from the docs. OK. So it seems that I should not write code which explicitely mentions regbase::use_except? Lets assume, that throwing boost::bad_expression is a general policy (I can live with that), it would be **very** nice to have at least one (probably static) member function, which takes a textual regular expression and an optional bunch of regbase flags as arguments and returns a bool, which simply returns true in case of a valid expression, otherwise false. What do you think of that? You could call the undocumented member function set_expression which would return 0 on success, alternatively you're back to rolling your own, BTW why do you want this? If a regular expression is valid, then presumably at some point you would want to use it? I ask because the job of checking the expression for validity is essentially the same as compiling it to a state machine. Thanks for the tip concerning set_expression (although I fear, that I should view its usage as deprecated, don't I?). The reason for my proposal is quite simple: It is sometimes quite natural, that there is a long way between the actual user input of a regular expression in textual form, lets say some GUI framework, and its actual interpretation via boost::regex. Now consider the situation when you have two **separated** task: 1) Simply verify the validity of user input (Compare this situation with a test mask or whatever). This is not the place, where the actual evaluation of input is possibly. 2) The remote procedure which is the actual workhorse and does its job, and possibly throws during exceptional situations. You are right: In most cases its makes sense that evaluation and verification are performed in one step, but if you are in an environment, where its not **an exceptional** situation to give an invalid textual reg expression as an argument to regex, it seems natural (to me) to usage a verification function, which possibly needs not to make as much work as the actual processor. I think this situation comes near to problems of user input of filenames, which under several conditions can not be viewed as exceptional but nearly as a normal case. This is one of the reasons I belief that the two ways of using iostreams (via exceptions or not) is not such a bad Thing. I don't generally recommend to incorporate such a dichotomous nature into boost::regex, but it is sometimes useful to just have a test for cases of nearly equal probability instead of exceptions for rare error situations. Similar valuable as 'has_facet' compared to 'use_facet' if you have the task to ask the system for its very long list of locales to check whether they provide some 'umlaut' facet or not Greetings from Bremen, Daniel. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: adaptable_any vs any_with
Douglas Gregor wrote: Between the two: adaptable_any is better, I think. Because I like throwing wrenches: have you considered a very different name such as polymorphic or just poly. The idea is that we read: polyless_than_comparable, equality_comparable as a type that is polymorphic over all less_than_comparable equality_comparable types. And because I'm feeling silly and reading a book on lattice theory... it could also be named models_meet, as in a type that models the meet of the following concepts in the concept lattice. Doug Both suggestions are too extreme, IMHO. -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] trouble with generating html compiler status pages
I have been attempting to build boost 1.30.2 for a number of platforms. I also wish to generate the html testsuite output for several reasons - My own peace of mind, because we are using a reasonably large number of platforms (some of which do not appear on the status tables), and so I can see which parts of the libraries work on all our platforms. In general I have been successful with the building of the tools/libraries and running the testsuites as per the documentaion to produce bjam.log. However when I try to process the bjam.log I get a number of errors and/or erroneous output. I will describe my gcc/linux experience as this is the platform I expected to have least trouble with. On linux 6.2 based gcc 3.2.1, process_jam_log runs ok, but on running compiler_status $BOOST_ROOT cs-linux.html I get the following output *** Error: std::runtime_error: boost::filesystem::directory_iterator constructor: /scratch8/buildman/builds/linux-boost-1.30.2/0.2/status/bin: No such file or directory The directory the compiler_status exe was located in was in my PATH and was /scratch8/buildman/builds/linux-boost-1.30.2/bin I checked that BOOST_ROOT was set to /scratch8/buildman/builds/linux-boost-1.30.2/0.2/status/bin and TOOLS was set to gcc I was running under a bash shell although I do not think this is significant. scratch8 is an automounted directory just in case this matters. It would appear that the filesystem code has erroneously duplicated part of the path (the 0.2/status part). In case this was already fixed I also tried the code in the sourceforge cvs repository (as of 11:30 on Tuesday 2nd September). This built without incident, but the stage process_jam_log bjam.log gave the following output: Usage: bjam [bjam-args] | process_jam_log [locate-root] locate-root is the same as the bjam ALL_LOCATE_TARGET parameter, if any. Default is boost-root. boost_root: /scratch/towler/boost locate_root: /scratch/towler/boost exception(205): std::out_of_range: basic_string::substr errors detected; see standard output for details On other platforms (IRIX Mipspro 7.3.1.3, Dec Alpha 6.5) the html generation process works ok, but the webpages mark most (but not all) of the tests as Missing, even though they can be seen to have passed in the bjam.log file. Unexpectedly the only platform I have successfully generated the webpage for is MS Visual Studio 6. Any help gratefully received. Matt ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Virtual inheritance in exception hierarchies
[EMAIL PROTECTED] writes: I've recently been discussing the guideline recently added to the exceptions policy page with Dave Abrahams and he has asked me to post my views here. There is a seductive form of arguement that I've seen repeatedly lead projects into trouble which has made me very suspicious of the form: provide X because someone might want to do Y. One common example is provide public access to member data because someone might need to do something with the members that isn't supported directly. (I hope that this is a forum that would reject this argument.) Another arguement I've encountered recently is that all classes should have a virtual destructor because someone may want to specialise them. The arguement is especially seductive when the cost of providing X is either small or hidden. But many a project has failed through creeping featuritis driven by such concerns. The cost of virtual inheritance from std::exception may well appear small - indeed, most of it is the intellectual cost of understanding the intent. Arguments of this form need to be challenged on the basis of whether to do Y is a reasonable expectation. If not, then the solution isn't provide X it is discourage Y. Now, unlike the examples cited above, I've *never* encountered anyone arguing that exception hierarchies should be designed to support MI in a real design scenario. Nor, when challenged on this point, has Dave. The hypothetial example cited seems very implausible: when developing a subsystem to meet two interfaces I invariably develop a pair of adaption wrappers over the core functionality. (And, in general, repackaging of exceptions is a very small part of that wrapper.) Alan, did you read http://aspn.activestate.com/ASPN/Mail/Message/boost/1781628 ?? FWIW, the rest of the thread is http://aspn.activestate.com/ASPN/Mail/Message/boost/112 The obvious conclusion from the example cited is don't multiply inherit from classes that are not designed to support it. I'm always willing to learn, but in the absence of a compelling example that MI is useful in exception heirarchies, I am unwilling to support the new guideline. I'm feeling ambivalent about it now, but I do think Bjarne's example is a pretty good one, and I wouldn't guess he'd claim it happens often without some evidence. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Any interest in a string literal selector helper library?
I've done this before as well. But it's a very simple function. And I assume TestAutoSelect is a macro. Can I take a look at the code? Yes, TextAutoSelect is a macro, because without using a macro, there is no way to generate a wchar_t string literal (prefixed with L) from a char string literal at compile time. The macro also hides a bit of template code which is used for type detection purposes. I have uploaded the code to: http://groups.yahoo.com/group/boost/files/TextSelector.hpp It's directly copied from the project it's residing in, so please don't pay any attention to the namespace naming conventions. I have successfully compiled this code using VC++ 7.1, Intel C++ 7.1, gcc 2.95.3-6 (mingw32) on Windows, and gcc 3.20 on Linux. Let me know what you think. Ehsan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: optional, tie, and iterator_adaptor
David Abrahams [EMAIL PROTECTED] writes: Dave Gomboc [EMAIL PROTECTED] writes: [Fernando Cacciola] The most fundamental point is that being Haskell a pure functional language there is no possibly undefined behaviour to worry about, so Maybe doesn't need to address this issue as optional does. ... and later ... I account the possibly undefined behavior of accesing an uninitialized optional as a real and important problem. You can get rid of the possibly undefined behaviour by defining it! Throw an exception when there's an attempted coercion from nil/undefined to a normal value. That could have a significant negative impact on performance and code size, FWIW. 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. No, the interface should be changed, because it _looks_ like it has pointer semantics. So do the proxies required by input iterators over classes and a few other such proxy pointers. They all contain the value they point at. IMO getX(y) is the solution to this problem. But they are iterators, and random-access iterators exhibit pointer semantics. That's the reason iterators use operator* and operator- in the first place! Input iterators also contain the values *they* reference. Just to clarify, I don't claim this makes optionalT pointer-like: I think it's an _approximation_ to exactly what the anti-pointer crowd have been saying it is, a T or not. I do think that renders the pointer interface non-ridiculous, and I see the author's point about the syntax being a useful clue as to its possible nil value. Unfortunately the C++ language makes it impossible for it to ever really act like a T, and I think a core syntax which doesn't try to hide that fact is probably a good idea. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
On Tuesday, Sep 2, 2003, at 05:42 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Monday, Sep 1, 2003, at 14:48 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
Conforming containers had better use them.
I'm sorry, but I think that's flat wrong. What do you suppose that
entry in column 2 of the allocator requirements table (20.1.5)
means,
after all?
It means any value returned by construct, destroy, or deallocate
goes
unused.
And once you are down in the coal mine customizing what a pointer
is, I'm not sure you won't need to customize how to construct and
destroy.
The class getting constructed/destroyed has full control over that
or
the language is utterly bustificated.
Yes, but the allocator may want to do something else as well, and
construct and destroy serve as hooks for whatever that may be.
Regardless, there is absolutely _nothing_ in the standard AFAICT
which
indicates the containers must use the allocator's construct and
destroy, and several implementations in fact do not.
Well then, I consider the standard broken in that regard. But we are
off the topic that started this thread.
Apropos of which, I now think that the Boost UserAllocator
requirements
should be the default for components that parameterize how they use
memory, with the Standard Allocator requirements being used only for
components that need what they offer: a potentially very efficient way
to allocate large numbers of small objects of known type, and/or a
way to access storage via proxied pointers.
I think part of my point was that *nobody* needs what they offer, if
you include construct/destroy.
Or rather that some implementations have failed to use what they
offer, and our standard unfortunately doesn't insist that they do.
Another reason construct is needed is that Allocator::pointer might
be a proxy, with operator* and operator- but not necessarily a
conversion to void* or even T*.
In fact, construct requires undefined
behavior for non-POD T because you can't copy its T* argument which
points into raw storage.
I don't understand what you mean by this. Are you claiming that
it is undefined to copy just a pointer to raw storage? If so,
then how is placement new not undefined? The standard says:
a.construct(p,t)
Effect: new((void*)p) T(t)
I think I would rather see a MPL lambda expression or metafunction
class interface for allocator type parameters. It makes little sense
for the allocator's user to be choosing its value_type.
Something like:
some_allocator_1
or
struct select_allocator
{
template class T
struct apply
{
typedef some_allocatorT type;
};
};
with some_allocator's interface being like what's required for
std::allocator but not including misplaced interface bits such as
address/construct/destroy, and possibly max_size -- these can be added
by a std::allocator facade wrapper if neccessary.
I'm not sure we need a simple version and a complicated version.
I'm not clear how you intend the above to be used, or what you
intend it to be a replacement for.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Deprecation/removal of libraries
At 05:17 PM 9/1/2003, Daniel Frey wrote: On Thu, 28 Aug 2003 16:19:24 +0200, Douglas Gregor wrote: On Thursday 28 August 2003 08:20 am, Daniel Frey wrote: utility/tie was moved to tuple, so should we remove the obsolete docs/references in utility now? Please do. Done. I also updated the Revisited ..., but there is some checksum in the HTML-source. I have no clue what it's good for, so if I broke it, please fix it and tell me how to avoid it next time :o) The checksum is used by some HTML editors to automatically timestamp revisions. It is in a comment and it doesn't hurt to break it if you happen to edit the file manually. So you don't need to worry about it. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] trouble with generating html compiler status pages
At 09:09 AM 9/2/2003, Matthew Towler wrote: I have been attempting to build boost 1.30.2 for a number of platforms. I also wish to generate the html testsuite output for several reasons - My own peace of mind, because we are using a reasonably large number of platforms (some of which do not appear on the status tables), and so I can see which parts of the libraries work on all our platforms. In general I have been successful with the building of the tools/libraries and running the testsuites as per the documentaion to produce bjam.log. However when I try to process the bjam.log I get a number of errors and/or erroneous output. I will describe my gcc/linux experience as this is the platform I expected to have least trouble with. Are you using run_tests.sh from CVS or your own script? The kinds of troubles you describe can be caused by (1) wrong BOOST_ROOT, (2) failing to cd $boost_root/status before running the tests, (3) wrong arguments to the actual programs. ... I checked that BOOST_ROOT was set to /scratch8/buildman/builds/linux-boost-1.30.2/0.2/status/bin That looks very suspicious and is almost certainly wrong. What I would expect is BOOST_ROOT set to: /scratch8/buildman/builds/linux-boost-1.30.2 or possibly (if you have copied the tree to 0.2): /scratch8/buildman/builds/linux-boost-1.30.2/0.2 Which of those directories has c++boost.gif, LICENSE, and README? Those live in the root directory, so can be checked for to verify you have BOOST_ROOT set correctly. HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: circular_buffer ver. 3.3 [long]
Hi Pavel!
Thank you very much for your comments. I agree with most of them. Thanks also for
the picture. Here are my notes to some of your comments.
Few notes to latest source:
1. circular_buffer_adaptor.html: the link in
The circular_buffer_space_optimized is defined in
the file boost/circular_buffer.hpp.
points to wrong source file.
I just want the user to include the circular_buffer.hpp regardless if she uses
either circular_buffer or its adaptor. Maybe I should write that the
circular_buffer is defined in circular_buffe.hpp but the link will point to
circular_buffer_base.hpp. Similarly for the circular_buffer_space_optimized.
5. Borland C++ Builder 6.4 doesn't allow to bring
operator[] via using.
This is workaround in circular_buffer_adaptor.hpp:
#include boost/detail/workaround.hpp
...
#if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564) )
reference operator [] (difference_type n) { circular_bufferT,
Alloc::operator[](n); }
const reference operator [] (difference_type n) const {
circular_bufferT, Alloc::operator[](n); }
#else
using circular_bufferT, Alloc::operator[];
#endif
What about just overriding operator[] for all compilers? (With the note that some
compilers doesn't support using for operators.)
Also the 1 and 1 can be in this case safely replaced by * 2 and /
2
(it is unsigned).
What is wrong with 1 and 1. I think it is safe and it is more effective
for some compilers which don't optimize the *2 operation.
Shrink algorithm can be:
a. allow hysteresis when shrinking
if new_size current_capacity / 3 then shrink_to(std::max(min_capacity,
current_capacity / 2))
Why current_capacity / 3 ?
The constructors and set_capacity() would need one more paramerer or
overload,
capacity() could return pair. clear() would need change.
Maybe new method can be introduced e.g. min_capacity(). The capacity method stays
unchanged.
8. circular_buffer_space_optimized constructor with circular_buffer
parameter can be provided, similarly operators , , ==, !=,
and possibly swap() (swaping only items).
No, I don't want to go this way. Suppose some new circular_buffer adaptor with new
features will be introduced. Then you will have to provide operators for the base
circular_buffer and the circular_buffer_space_optimized. If you add another
adaptor the number of functions will rise exponencially.
If you look e.g. on std::stack it also doesn't provide operators for std::deque.
9. circular_buffer_base.hpp and circular_buffer_adaptor.hpp:
instead of check
#if !defined(BOOST_NO_FUNCTION_TEMPLATE_ORDERING) || defined(BOOST_MSVC)
is enough to use
#if !defined(BOOST_NO_FUNCTION_TEMPLATE_ORDERING)
(it is defined for MSVC).
I don't know why, but this does not work. You have to include ||
defined(BOOST_MSVC) too.
14. Btw, isn't cb_iterator::operator[]() added by mistake?
I have never seen such an operation for iterator.
No, iterators do have this operator.
16. RAII vs try blocks:
1. IMO the macro based exception handling isn't needed, it is better
to use RAII, like:
...
can be replaced by:
void set_capacity(size_type new_capacity) {
if (new_capacity == capacity()) return;
pointer buff = allocate(new_capacity);
struct deleter_t {
pointer data;
size_type capacity;
deleter_t(pointer p, size_type s) : data(p), capacity(s) {}
~deleter_t() { deallocate(data, capacity); }
};
deleter_t guard(buff, new_capacity);
size_type new_size = new_capacity size() ? new_capacity : size();
std::uninitialized_copy(end() - new_size, end(), buff);
destroy();
m_size = new_size;
m_buff = m_first = buff;
m_end = m_buff + new_capacity;
m_last = full() ? m_buff : m_buff + size();
guard.data = 0;
}
I think this is not a good idea because
- it won't work - the ~deleter_t() destructor does not have access to
the deallocate() method
- the original macros are more explanatory (it is easier to understand)
- every STL implementation is using such macros
It may be possible to pass member function pointer or make deleter friend.
(Another possibility would be to use Alexandrescu's ScopeGuard.)
There's one good reason to avoid catch(...): on Win32 it interferes with
system exceptions handling. If someone uses __try/__catch/__finally,
these won't be called after throw; and also it won't be possible
to fix and continue system exception.
If I remember right, Digital Unix compiler had similar option for signals.
My colleague told me, if such a system exception ocurrs the destructor of the
exception guard won't be called. Check this out please. He also told me that the
system exceptions have nothing to do with C++ exceptions except that catch(...)
catches them. Btw. I would wonder if all the STL implementations would be just
wrong.
24. Question: do you plan to add Mojo to
[boost] Re: Boost memory management guidelines
Gregory Colvin [EMAIL PROTECTED] writes:
I think part of my point was that *nobody* needs what they offer, if
you include construct/destroy.
Or rather that some implementations have failed to use what they
offer, and our standard unfortunately doesn't insist that they do.
It's not unfortunate if it adds nothing, which is what I believe.
Another reason construct is needed is that Allocator::pointer might
be a proxy, with operator* and operator- but not necessarily a
conversion to void* or even T*.
Doesn't matter; you can always get the address of an object. See
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#390
In fact, construct requires undefined behavior for non-POD T
because you can't copy its T* argument which points into raw
storage.
I don't understand what you mean by this. Are you claiming that
it is undefined to copy just a pointer to raw storage?
Unless the pointer has the right type, yes.
If so, then how is placement new not undefined?
It uses a void*, as shown in your code snippet below.
The standard says:
a.construct(p,t)
Effect: new((void*)p) T(t)
I think I would rather see a MPL lambda expression or metafunction
class interface for allocator type parameters. It makes little sense
for the allocator's user to be choosing its value_type.
Something like:
some_allocator_1
or
struct select_allocator
{
template class T
struct apply
{
typedef some_allocatorT type;
};
};
with some_allocator's interface being like what's required for
std::allocator but not including misplaced interface bits such as
address/construct/destroy, and possibly max_size -- these can be added
by a std::allocator facade wrapper if neccessary.
I'm not sure we need a simple version and a complicated version.
I'm not clear how you intend the above to be used, or what you
intend it to be a replacement for.
I intend it to be the sort of type parameter that gets passed to our
objects which need custom allocation in place of a standard allocator.
It's ridiculous, IMO, to pass allocatorT to a node-based container
which is *never* going to allocate a T object. The container itself
should decide which type the allocator template gets instantiated on,
via:
mpl::applympl::lambdaS, Node::type
[
this is approximately the same as:
S::template applyU::type == some_allocatorU
except that it works when S is the lambda expression
some_allocator_1 as well as when it's the select_allocator
metafunction class below it.
]
What the rebind requirement in the allocator means for pool
allocation, for example, is that a pool_allocatorT object must
either be stateless (in which case allocator inequality is
meaningless) or effectively be able to allocate blocks of *any* size
and alignment, rather than just as appropriate for T. It's a
conceptual mess.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
I think part of my point was that *nobody* needs what they offer, if
you include construct/destroy.
Or rather that some implementations have failed to use what they
offer, and our standard unfortunately doesn't insist that they do.
It's not unfortunate if it adds nothing, which is what I believe.
Another reason construct is needed is that Allocator::pointer might
be a proxy, with operator* and operator- but not necessarily a
conversion to void* or even T*.
Doesn't matter; you can always get the address of an object. See
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#390
So you would rather use this than use construct?
template typename T T* addressof(T v)
{
return reinterpret_castT*(
const_castchar(reinterpret_castconst volatile char
(v)));
}
In fact, construct requires undefined behavior for non-POD T
because you can't copy its T* argument which points into raw
storage.
I don't understand what you mean by this. Are you claiming that
it is undefined to copy just a pointer to raw storage?
Unless the pointer has the right type, yes.
In which case the A::pointer return from A::allocate() is already
undefined behavior?
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
...
Dave:
I think I would rather see a MPL lambda expression or metafunction
class interface for allocator type parameters. It makes little sense
for the allocator's user to be choosing its value_type.
Something like:
some_allocator_1
or
struct select_allocator
{
template class T
struct apply
{
typedef some_allocatorT type;
};
};
with some_allocator's interface being like what's required for
std::allocator but not including misplaced interface bits such as
address/construct/destroy, and possibly max_size -- these can be
added
by a std::allocator facade wrapper if neccessary.
I'm not sure we need a simple version and a complicated version.
I'm not clear how you intend the above to be used, or what you
intend it to be a replacement for.
I intend it to be the sort of type parameter that gets passed to our
objects which need custom allocation in place of a standard allocator.
It's ridiculous, IMO, to pass allocatorT to a node-based container
which is *never* going to allocate a T object.
But given rebind() it doesn't really matter. We could just as
well have specified that all containers take allocatorvoid
arguments.
The container itself
should decide which type the allocator template gets instantiated on,
via:
mpl::applympl::lambdaS, Node::type
[
this is approximately the same as:
S::template applyU::type == some_allocatorU
except that it works when S is the lambda expression
some_allocator_1 as well as when it's the select_allocator
metafunction class below it.
]
Sorry, but I'm still not following this, but that may be
because I don't know much MPL, so I can only guess at what
you are up to. I probably need a detailed example of how to
write and use one of these thingys to make any sense of your
proposal.
Does your proposal support stateful allocators?
What the rebind requirement in the allocator means for pool
allocation, for example, is that a pool_allocatorT object must
either be stateless (in which case allocator inequality is
meaningless)
Yes, all stateless allocators compare equal, and stateless
allocators are the easiest kind to make compare equal, as
the standard currently requires allocators to do.
or effectively be able to allocate blocks of *any* size
and alignment, rather than just as appropriate for T.
Yes, because node-based containers need to allocate nodes,
perhaps of various kinds, but they don't expose their
node types in their interface. So you have to pass in
something, and we went with T rather than void or whatever.
It might have been better to have different allocator
interfaces for array-based versus node-based containers,
since array-based containers have no need of rebind(), and
node-based containers have no need of allocatorT.
It's a conceptual mess.
Alex didn't have MPL when he invented allocators. So they are
messier than they need to be, but I still say they are not so
bad as you claim, and that it would be easier for the next
standard to repair them than to replace them.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- David Abrahams [EMAIL PROTECTED] wrote: [...] Just how do you propose to prevent people from writing their own construct/destroy functions? And if they write an allocator from scratch, but *don't* provide construct/destroy manually, where will they come from? What I meant is that if boost allocators won't include constuct/destroy, all boost developers will probably implement their own construct/destroy helper functions (outside allocators) to construct/destroy object using allocators. In such case, I suggested to include standard construct/destroy functions in boost (not in allocators). Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams
wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
I think part of my point was that *nobody* needs what they offer,
if
you include construct/destroy.
Or rather that some implementations have failed to use what they
offer, and our standard unfortunately doesn't insist that they do.
It's not unfortunate if it adds nothing, which is what I believe.
Another reason construct is needed is that Allocator::pointer might
be a proxy, with operator* and operator- but not necessarily a
conversion to void* or even T*.
Doesn't matter; you can always get the address of an object. See
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#390
So you would rather use this than use construct?
template typename T T* addressof(T v)
{
return reinterpret_castT*(
const_castchar(reinterpret_castconst volatile char
(v)));
}
As long as it's packaged away and I don't have to look at the
implementation. A customization point like an allocator should not be
required to supply boilerplate that's always going to be the same.
You are assuming that there was no good reason to allow an allocator
to hook construct and destroy, for instance to do some bookkeeping.
When I need to find out what I need to implement in order to customize
allocation, I don't want to have to read through something which is
50% irrelevant to the task, as the allocator requirements are.
Which is why I'm now suggesting that Boost UserAllocator is a better
default.
But in some cases, like the shared_ptr feature request that got me
thinking on this, what you want is just to have objects allocate
their internals using the same allocator as the container they
are being placed in, in which case you don't need to implement an
allocator, just call get_allocator().
n fact, construct requires undefined behavior for non-POD T
because you can't copy its T* argument which points into raw
storage.
I don't understand what you mean by this. Are you claiming that
it is undefined to copy just a pointer to raw storage?
Unless the pointer has the right type, yes.
In which case the A::pointer return from A::allocate() is already
undefined behavior?
Wow. Yes, IIUC. DR, I guess.
I'm reeling from the implication that the following is undefined
behavior for non-POD T:
T* p = (T*)malloc(sizeof T);
Are you sure?
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- David Abrahams [EMAIL PROTECTED] wrote:
[...]
I think construct/destroy can be implemented as non-customizable
static functions in boost just for convinence.
I think the word static is not what you meant, and is what led me
to challenge the suggestion.
I used word 'static' because I assumed that construct/destroy
functions would be implemented in some 'memory' data type
(just to qualify it).
struct memory
{
static template typename A
typename A::pointer construct( A a, size_t n ) {...}
static template typename A
void destroy( typename A::pointer ) {...}
};
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
Gregory Colvin wrote: You are assuming that there was no good reason to allow an allocator to hook construct and destroy, for instance to do some bookkeeping. I'm curious. Have you ever seen such an allocator? I've always assumed that construct/destroy/pointer are a but someone might need to do that feature that nobody has ever used. Then again, the Dinkumware implementation dutifully calls construct and destroy, paying (and forcing me to pay) the abstraction penalty price... so maybe I'm wrong, and construct/destroy are useful? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
On Tuesday, Sep 2, 2003, at 11:39 America/Denver, David Abrahams wrote: Gregory Colvin [EMAIL PROTECTED] writes: On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote: ... I think you're missing my point. There's no reason that a stateful allocatorT should have access to the state data required to allocate U objects, but that's the status quo. I'm probably missing your point, but the idea is that a container needs to allocate various kinds of things, and they all get allocated with the same allocator, either directly or via rebind. For instance, maybe you are are using memory-mapped files as a persistent storage. The Ts and the Us and whatever the container needs all have to go into the same file, so the allocatorT and all its rebinds must know which file to use and how. ... It's a conceptual mess. Alex didn't have MPL when he invented allocators. So they are messier than they need to be, but I still say they are not so bad as you claim Are you saying my factual claims are wrong, or just that all those issues don't amount to a very important problem? Just that it doesn't look nearly as messy to me as it does to you. and that it would be easier for the next standard to repair them than to replace them. That may be, but we're here at Boost, talking about the interface we should be using in Boost components. Yep. I still think UserAllocator is a good default, and that where it doesn't suffice there is some value to playing nicely with STL. So even when we come up with some beautiful new thing to do the allocation job better, we will still need adaptors both ways, so that one can get an allocator from an STL container and turn it in to one of our new things, or take one of our new things and turn it into an allocator to use in an STL container. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Virtual inheritance in exception hierarchies
Iain K. Hanson [EMAIL PROTECTED] writes: But is this a good design? It certainly isn't the only possible one. (Making all the code depend upon the definitions of both Network_err and File_system_err - which no doubt drags other stuff into the translation unit - isn't a design choice I'd make lightly.) In certain places it may be the most natural design choice. Whether it is a good idea to pay for virtual inheritance in every exception derived from class exception is a separate issue. Exception handling incurs a significant cost once an exception is thrown. Adding to that cost could drive more users away from exception handling. Do you think dynamic downcasting through a layer of virtual inheritance is significantly more expensive than downcasting through a layer of regular inheritance? Also, I'm not sure that this use case is sufficiently common to burden all exceptions with. What's the burden? I'm just askin', is all. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
On Tuesday, Sep 2, 2003, at 12:27 America/Denver, Peter Dimov wrote: Gregory Colvin wrote: You are assuming that there was no good reason to allow an allocator to hook construct and destroy, for instance to do some bookkeeping. I'm curious. Have you ever seen such an allocator? I've always assumed that construct/destroy/pointer are a but someone might need to do that feature that nobody has ever used. I've heard allocators described that probably used construct() to navigate efficiently from a proxy pointer to the raw memory in which to construct. But I never saw the code. Then again, the Dinkumware implementation dutifully calls construct and destroy, paying (and forcing me to pay) the abstraction penalty price... so maybe I'm wrong, and construct/destroy are useful? I don't see that there need be any performance price for what Dinkumware does, or is that not what you mean by abstraction penalty? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost memory management guidelines
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
So you would rather use this than use construct?
template typename T T* addressof(T v)
{
return reinterpret_castT*(
const_castchar(reinterpret_castconst volatile char
(v)));
}
As long as it's packaged away and I don't have to look at the
implementation. A customization point like an allocator should not be
required to supply boilerplate that's always going to be the same.
You are assuming that there was no good reason to allow an allocator
to hook construct and destroy, for instance to do some bookkeeping.
The fact that nobody's required to use construct and/or destroy is
testament to that.
When I need to find out what I need to implement in order to
customize allocation, I don't want to have to read through
something which is 50% irrelevant to the task, as the allocator
requirements are.
Which is why I'm now suggesting that Boost UserAllocator is a better
default.
But in some cases, like the shared_ptr feature request that got me
thinking on this, what you want is just to have objects allocate
their internals using the same allocator as the container they
are being placed in, in which case you don't need to implement an
allocator, just call get_allocator().
Is it enough for all of Boost? If so, great! If not, we still need
to think about what a more-sophisticated interface looks like.
Also, if shared_ptr only needs to allocate at construction time (I'm
not sure of this) we can avoid storing the allocator at all.
I'm reeling from the implication that the following is undefined
behavior for non-POD T:
T* p = (T*)malloc(sizeof T);
Are you sure?
Nope. 3.8/5 shows that I'm wrong. It still doesn't make any sense to
return a T* from allocate since normally with a non-singular T* p,
either p == 0 or *p refers to a constructed T.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] optional/type_with_alignment.hpp vs. metrowerks8.3 PPC CFM
--On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor
[EMAIL PROTECTED] wrote:
On Tuesday 02 September 2003 01:36 pm, Mat Marcus wrote:
We're trying to use optional from 1.30.0 (sorry legal hasn't
approved our use of 1.30.2 yet). However on one compiler
(Metrowerks 8.3 PPC CFM) we're getting static asserts from the
alignment calculation metafunctions. Below is an abstracted example
of the problem. I'm curious about what's going on and what
workarounds might be possible.
Thanks,
Mat
Looks like the code was unable to find an 8-byte aligned type. Could
you check the results of:
std::cout boost::alignment_ofdouble '\n';
std::cout boost::alignment_oflong double '\n';
I suspect they are both '4', but that leaves me even more confused
as to why the alignment of std::pairdouble, double would be 8
(and how to get a POD type with alignment 8 for ourselves!).
Doug
Yes, they are both 4. I suspect that the problem may have to do with
some unusual alignment rules on this platform. I believe that the rule
is something like: a double at the beginning of a struct forces 8 byte
alignment, but a double in the middle does not. That is, given
struct A {
double d;
int i;
};
struct B {
int i;
double d;
};
then:
sizeof(A) == 16;
sizeof(B) == 12;
alignment_ofA::value == 8;
alignment_ofB::value == 4;
Fun, eh? I can double check the compiler release notes for the exact
rule if you like.
- Mat
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
On Tuesday, Sep 2, 2003, at 13:00 America/Denver, Peter Dimov wrote: Gregory Colvin wrote: On Tuesday, Sep 2, 2003, at 12:27 America/Denver, Peter Dimov wrote: Then again, the Dinkumware implementation dutifully calls construct and destroy, paying (and forcing me to pay) the abstraction penalty price... so maybe I'm wrong, and construct/destroy are useful? I don't see that there need be any performance price for what Dinkumware does, or is that not what you mean by abstraction penalty? I'm not saying that there need be any price in a perfect world. I am saying that in practice, on the compiler I use, there is a price, like calling a non-inline destroy() O(N) times for a value_type that has an inline, empty, nonvirtual destructor. Or even for a built-in value_type. That is most unfortunate. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
On Tuesday, Sep 2, 2003, at 12:51 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams
wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
So you would rather use this than use construct?
template typename T T* addressof(T v)
{
return reinterpret_castT*(
const_castchar(reinterpret_castconst volatile char
(v)));
}
As long as it's packaged away and I don't have to look at the
implementation. A customization point like an allocator should not
be
required to supply boilerplate that's always going to be the same.
You are assuming that there was no good reason to allow an allocator
to hook construct and destroy, for instance to do some bookkeeping.
The fact that nobody's required to use construct and/or destroy is
testament to that.
Thanks to the weasel-wording nobody's required to use much of
anything besides allocate, deallocate, and rebind. That doesn't
mean there was no point to all the rest in the original design.
When I need to find out what I need to implement in order to
customize allocation, I don't want to have to read through
something which is 50% irrelevant to the task, as the allocator
requirements are.
Which is why I'm now suggesting that Boost UserAllocator is a better
default.
But in some cases, like the shared_ptr feature request that got me
thinking on this, what you want is just to have objects allocate
their internals using the same allocator as the container they
are being placed in, in which case you don't need to implement an
allocator, just call get_allocator().
Is it enough for all of Boost?
It's probably overkill for some things.
If so, great! If not, we still need
to think about what a more-sophisticated interface looks like.
Only if UserAllocator is inadequate?
Also, if shared_ptr only needs to allocate at construction time (I'm
not sure of this) we can avoid storing the allocator at all.
Then how to deallocate?
I'm reeling from the implication that the following is undefined
behavior for non-POD T:
T* p = (T*)malloc(sizeof T);
Are you sure?
Nope. 3.8/5 shows that I'm wrong.
That's a relief.
It still doesn't make any sense to
return a T* from allocate since normally with a non-singular T* p,
either p == 0 or *p refers to a constructed T.
The idea was that AllocatorT::pointer might be a proxy type
that cannot be converted to void* and back, so allocate() must
return and construct() must take an AllocatorT::pointer rather
than a void*.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] optional/type_with_alignment.hpp vs. metrowerks 8.3 PPCCFM
On Tue, 2 Sep 2003, Mat Marcus wrote:
--On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor
[EMAIL PROTECTED] wrote:
I suspect they are both '4', but that leaves me even more confused
as to why the alignment of std::pairdouble, double would be 8
(and how to get a POD type with alignment 8 for ourselves!).
Yes, they are both 4. I suspect that the problem may have to do with
some unusual alignment rules on this platform. I believe that the rule
is something like: a double at the beginning of a struct forces 8 byte
alignment, but a double in the middle does not. That is, given
struct A {
double d;
int i;
};
struct B {
int i;
double d;
};
then:
sizeof(A) == 16;
sizeof(B) == 12;
alignment_ofA::value == 8;
alignment_ofB::value == 4;
Fun, eh? I can double check the compiler release notes for the exact
rule if you like.
- Mat
Are there any other crazy rules like this that you know of? We could just
add struct A from above to the list of types, or if there is a
CodeWarrior-specific extension (e.g., something like #pragma pack or
atttribute(aligned...)) we could start using compiler-specific
extensions to do this, which wouldn't be a bad thing to do anyway.
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] date_time naming
I'm just getting started with the date_time library, and I think I'm gonna like it. I have some quibbles with the naming choices though (shocking! me of all people!) For example, why is the nested namespace called posix_time instead of, simply, posix? Once you're in a date_time context it seems to me that _time adds nothing. Similarly, what's the p in ptime stand for? I can guess, but I can guess it's also redundant ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] CVS main trunk regression test failure
The metacomm regression tests run failed last night because of the following bjam failure: boost-test(RUN) iterators : libs\multi_array\test\iterators.cpp boost-test(RUN) compare : libs\multi_array\test\compare.cpp boost-test(RUN) access : libs\multi_array\test\access.cpp boost-test(RUN) constructors : libs\multi_array\test\constructors.cpp ...patience... ...patience... don't know how to make libs!utility!test..\tie_example.cpp ...found 53858 targets... ...updating 40256 targets... ...can't find 1 target... ...can't make 50 targets... -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost memory management guidelines
Gregory Colvin [EMAIL PROTECTED] writes: Also, if shared_ptr only needs to allocate at construction time (I'm not sure of this) we can avoid storing the allocator at all. Then how to deallocate? Using the custom deleter? I'm reeling from the implication that the following is undefined behavior for non-POD T: T* p = (T*)malloc(sizeof T); Are you sure? Nope. 3.8/5 shows that I'm wrong. That's a relief. It still doesn't make any sense to return a T* from allocate since normally with a non-singular T* p, either p == 0 or *p refers to a constructed T. The idea was that AllocatorT::pointer might be a proxy type that cannot be converted to void* and back, so allocate() must return and construct() must take an AllocatorT::pointer rather than a void*. Wow, creepy. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Douglas Gregor [EMAIL PROTECTED] writes: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ You can build local copies of the documentation with BBv2 once you've read it Thanks. It worked. We will be publishing HTML docs starting with this night's run. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
On Tuesday, Sep 2, 2003, at 13:18 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
Yep. I still think UserAllocator is a good default, and that where it
doesn't suffice there is some value to playing nicely with STL.
So even when we come up with some beautiful new thing to do the
allocation job better, we will still need adaptors both ways, so that
one can get an allocator from an STL container and turn it in to one
of our new things, or take one of our new things and turn it into an
allocator to use in an STL container.
Am I right in trying to summarize your suggestion about UserAllocator?
If you want to parametrize how a boost class manages memory,
use UserAllocator parameter.
Unless you need the standard Allocator interface.
1. The allocator parameter should implement the UserAllocator
interface.
2. All instances of UserAllocator must be equal and stateless.
The Boost pools use UserAllocator only as a type parameter. It is not
required to be constructible or comparable.
3. If your class is using STL containers, use boost::memory::allocator
adapter (see bellow).
Why not just use std::allocator?
4. To construct/destroy objects, use boost::memory::construct/destroy.
See below.
5. Avoid using explicit references to allocators.
... Usage example:
==
template typename T, typename UserAllocator =
boost::default_user_allocator_new_delete
class X
{
What if you want X to use the same allocator as some other STL container
constructed with a non-Boost allocator? That would be difficult unless
you have
templatetypename T, class StdAllocator = std::allocatorT
struct X {
X(const StdAllocator);
Also, it might sometimes be desirable, as it is for shared_ptr, to
defer the choice of allocator until construction time:
templatetypename T
struct X {
templateclass StdAllocator = std::allocatorT
X(const StdAllocator);
Or, if UserAllocator suffices:
templatetypename T
struct X {
templateclass UserAllocator X();
T* _p;
Leading underscores are a no-no.
std::vectorT, boost::memory::allocatorT, UserAllocator _v;
X()
{
_p = boost::memory::constructT, UserAllocator( 1 )
How to pass arguments to T's constructor? Better just
p = new(UserAllocator::malloc(sizeof T)) T(...)
}
~X()
{
if( _p )
boost::memory::destroyT, UserAllocator( _p, 1 );
In which case, why not just
p-~T(), UserAllocator::free(p);
?
}
};
Eugene
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: optional/type_with_alignment.hpp vs. metrowerks 8.3 PPCCFM
Peter Dimov [EMAIL PROTECTED] writes:
Douglas Paul Gregor wrote:
[...]
struct A {
double d;
int i;
};
[...]
Are there any other crazy rules like this that you know of? We could
just add struct A from above to the list of types, or if there is a
CodeWarrior-specific extension (e.g., something like #pragma pack or
atttribute(aligned...)) we could start using compiler-specific
extensions to do this, which wouldn't be a bad thing to do anyway.
Maybe adding struct { double x; } would be enough?
I think it would be safer to add struct { double T; } for each T in
the list of types, just in case.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer ver. 3.3
Pavel Vozenilek [EMAIL PROTECTED] writes: 14. Btw, isn't cb_iterator::operator[]() added by mistake? I have never seen such an operation for iterator. No, iterators do have this operator. Oops, newer used before :-o Is there some reason you're defining your own iterators instead of using iterator_facade or iterator_adaptor? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] optional/type_with_alignment.hpp vs. metrowerks8.3 PPC CFM
--On Tuesday, September 02, 2003 3:32 PM -0400 Douglas Paul Gregor
[EMAIL PROTECTED] wrote:
On Tue, 2 Sep 2003, Mat Marcus wrote:
--On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor
[EMAIL PROTECTED] wrote:
I suspect they are both '4', but that leaves me even more confused
as to why the alignment of std::pairdouble, double would be 8
(and how to get a POD type with alignment 8 for ourselves!).
Yes, they are both 4. I suspect that the problem may have to do with
some unusual alignment rules on this platform. I believe that the
rule is something like: a double at the beginning of a struct
forces 8 byte alignment, but a double in the middle does not. That
is, given
struct A {
double d;
int i;
};
struct B {
int i;
double d;
};
then:
sizeof(A) == 16;
sizeof(B) == 12;
alignment_ofA::value == 8;
alignment_ofB::value == 4;
Fun, eh? I can double check the compiler release notes for the exact
rule if you like.
- Mat
Are there any other crazy rules like this that you know of? We could
just add struct A from above to the list of types, or if there is a
CodeWarrior-specific extension (e.g., something like #pragma pack
or atttribute(aligned...)) we could start using compiler-specific
extensions to do this, which wouldn't be a bad thing to do anyway.
Doug
There is a #pragma pack. This is the craziest rule that I know of.
Perhaps Howard or Andreas could give a more definitive answer.
Following is an excerpt from some release notes for this
platform/target:
- Mat
=
===
General Notes for 3.0
==
==
- extended alignment modes, Metrowerks conformed to the Macintosh
C/C++ ABI
Standard Specification Revision 1.3 dated Dec. 5, 1996, and Inside
Mac OS X:
Mac Mach-O Runtime Architecture, version Preliminary dated March
2002. Apple
has now decided that both documents are incorect, and that the
defintion of
align=power is what ever MrC and GCC are doing.
The rub here is that acording to this change in behavior doubles in
a structure
are not 8 byte aligned unless the user aligns them manual by
inserting padding,
or if they happen to be the first element in the structure.
Rather then not support the existing behavior a number of new
alignment modes now
exist:
#pragma options align=power_mw
always implements the rule: When in power_mw alignment
mode, a special exception
is made when the first embedding element of a struct or any
element of a union has
the data type of double -- in this case, the embedding
alignment for all (directly
included/top level) double members in the aggregate is 8. By
the rules of
computing the embedding alignment for the struct being
declared, this will also cause
the embedding alignment of the entire struct or union to be at
least 8 as well. The
aggregate table entry for power is 8 for such structs.
#pragma options align=power_gcc
always implements the rules used by gcc/MrC:
- the embedding alignment of the first element in a data
structure is equal to
the elements natural alignment
- for subsequent elements with a natural alignment less than
4, the embedding
alignment of each element is equal to its natural alignment
- for subsequent elements that have a natural alignment greater
than 4
bytes, the embedding alignment is 4, unless the element is a
vector data type
#pragma options align=natural
always implement simple alignment with no special rules based on
the type
of the first member of a structure. doubles and long longs are 8
byte aligned.
#pragma options align=power
maps to either power_mw or power_gcc depending on the setting of
the option:
#pragma alignment_metrowerks on|off|reset
If struct alignment preferences were set to PowerPC
alignment_metrowerks defaults on.
If struct alignment preferences were set to PowerPC MrC/GCC
alignment_metrowerks defaults off.
If struct alignment preferences were set to PowerPC Natural
alignment_metrowerks defaults off.
When on power==power_mw
when off power==power_gcc.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS main trunk regression test failure
Misha Bergal wrote: The metacomm regression tests run failed last night because of the following bjam failure: boost-test(RUN) iterators : libs\multi_array\test\iterators.cpp boost-test(RUN) compare : libs\multi_array\test\compare.cpp boost-test(RUN) access : libs\multi_array\test\access.cpp boost-test(RUN) constructors : libs\multi_array\test\constructors.cpp ...patience... ...patience... don't know how to make libs!utility!test..\tie_example.cpp ...found 53858 targets... ...updating 40256 targets... ...can't find 1 target... ...can't make 50 targets... Sorry, my fault. tie_example.cpp no longer exists, as 'tie' no longer lives in 'utility'. Can you please remove the reference from the test-file? I don't have access to CVS from here, otherwise I'd do it myself. Thanks. Also, if someone wants to restore the regression tests for 'tie', I suggest they are added to 'tuple' where they belong now. As there is no need to hurry about this, it's enough to speak up and I'll place them there when I have time. A last question to the build-wizards: Would it make sense to make the build system continue if a leaf is missing? I don't see a compelling reason to stop the other regressions from running just because there is one little failure in the configuration of an otherwise unrelated test. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
On Tuesday, Sep 2, 2003, at 15:00 America/Denver, David Abrahams wrote: Gregory Colvin [EMAIL PROTECTED] writes: Also, if shared_ptr only needs to allocate at construction time (I'm not sure of this) we can avoid storing the allocator at all. Then how to deallocate? Using the custom deleter? Which will need to store a copy of the allocator, unless one takes advantage of the weasel wording that lets you instantiate a new one for the purpose. ... It still doesn't make any sense to return a T* from allocate since normally with a non-singular T* p, either p == 0 or *p refers to a constructed T. The idea was that AllocatorT::pointer might be a proxy type that cannot be converted to void* and back, so allocate() must return and construct() must take an AllocatorT::pointer rather than a void*. Wow, creepy. Yes. But unless you grant the desire to support such creepy beasts then not much of Allocator makes any sense. And such beasts can do useful work, like persistent stores and shared memory. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
David Abrahams wrote: Gregory Colvin [EMAIL PROTECTED] writes: Also, if shared_ptr only needs to allocate at construction time (I'm not sure of this) we can avoid storing the allocator at all. Then how to deallocate? Using the custom deleter? The deleter takes care of the pointee, but we are talking about the count. I think. I still find the list shared_ptrX hypothetical example where everything needs to use the same custom allocator somewhat artificial. In custom allocator situations I find vector X* a somewhat better choice since it has much less overhead. But I may be wrong. :-) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: variant questions
On Tuesday 02 September 2003 04:58 pm, Misha Bergal wrote: Douglas Gregor [EMAIL PROTECTED] writes: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ You can build local copies of the documentation with BBv2 once you've read it Thanks. It worked. We will be publishing HTML docs starting with this night's run. That's great, thank you! Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
3. If your class is using STL containers, use boost::memory::allocator
adapter (see bellow).
Why not just use std::allocator?
Because boost::memory::allocator will use UserAllocator under the covers.
So if you customized UserAllocator parameter, you customized
how STL allocate their memory as well.
4. To construct/destroy objects, use boost::memory::construct/destroy.
See below.
5. Avoid using explicit references to allocators.
... Usage example:
==
template typename T, typename UserAllocator =
boost::default_user_allocator_new_delete
class X
{
What if you want X to use the same allocator as some other STL container
constructed with a non-Boost allocator? That would be difficult unless
you have [...]
Yes.
T* _p;
How to pass arguments to T's constructor? Better just
p = new(UserAllocator::malloc(sizeof T)) T(...)
}
~X()
{
if( _p )
boost::memory::destroyT, UserAllocator( _p, 1 );
In which case, why not just
p-~T(), UserAllocator::free(p);
?
The boost::memory::construct/destroy are just convinience wrappers
that will do like just that.
They can also handle exceptions properly.
struct memory
{
template typename T, typename A
static void destroy( T* p )
{
try
{
p-~T();
A::free(p);
}
catch( ... )
{
A::free(p); //free memory even if the destructor crashes.
throw;
}
}
};
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] date_time naming
From: David Abrahams [mailto:[EMAIL PROTECTED] Subject: [boost] date_time naming I'm just getting started with the date_time library, and I think I'm gonna like it. I have some quibbles with the naming choices though (shocking! me of all people!) For example, why is the nested namespace called posix_time instead of, simply, posix? Once you're in a date_time context it seems to me that _time adds nothing. Similarly, what's the p in ptime stand for? I can guess, but I can guess it's also redundant ;-) -- Dave Abrahams Have to agree. The lib is tremendous. I use it a fair bit and the first thing I always do is alias the namespaces to something more sensible. Would also like to see the xtime helper in the thread stuff migrate to it. As well as the much discussed support of the pentium+ cycle counter. Matt. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- Gregory Colvin [EMAIL PROTECTED] wrote: [...] T* _p; Leading underscores are a no-no. I didn't see it in boost naming convention docs. Have I missed it? Some STL implmentations use leading underscores for members. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [date_time] time_duration division
Suppose I want to know how many minutes there are in a particular duration d? My intuition says: d / minutes(1) But there's no such operator. Why not? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: optional/type_with_alignment.hpp vs. metrowerks 8.3PPC CFM
On Tuesday 02 September 2003 05:01 pm, David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
Maybe adding struct { double x; } would be enough?
I think it would be safer to add struct { double T; } for each T in
the list of types, just in case.
I agree. I've checked in the following patch, which implementations (a
corrected version of) the above. The preprocessor library rocks.
Mat, does this fix the problem for you?
Doug
Index: type_with_alignment.hpp
===
RCS file: /cvsroot/boost/boost/boost/type_traits/type_with_alignment.hpp,v
retrieving revision 1.12
diff -u -r1.12 type_with_alignment.hpp
--- type_with_alignment.hpp 9 Jun 2003 22:16:19 - 1.12
+++ type_with_alignment.hpp 2 Sep 2003 22:39:51 -
@@ -12,6 +12,8 @@
#include boost/preprocessor/list/for_each_i.hpp
#include boost/preprocessor/tuple/to_list.hpp
#include boost/preprocessor/cat.hpp
+#include boost/preprocessor/list/transform.hpp
+#include boost/preprocessor/list/append.hpp
#include boost/type_traits/alignment_of.hpp
#include boost/type_traits/is_pod.hpp
#include boost/static_assert.hpp
@@ -38,11 +40,22 @@
typedef int (alignment_dummy::*member_ptr);
typedef int (alignment_dummy::*member_function_ptr)();
-#define BOOST_TT_ALIGNMENT_TYPES BOOST_PP_TUPLE_TO_LIST( \
+#define BOOST_TT_ALIGNMENT_BASE_TYPES BOOST_PP_TUPLE_TO_LIST( \
11, ( \
char, short, int, long, float, double, long double \
, void*, function_ptr, member_ptr, member_function_ptr))
+#define BOOST_TT_HAS_ONE_T(D,Data,T) boost::detail::has_one_TT
+
+#define BOOST_TT_ALIGNMENT_STRUCT_TYPES \
+BOOST_PP_LIST_TRANSFORM(BOOST_TT_HAS_ONE_T, \
+X, \
+BOOST_TT_ALIGNMENT_BASE_TYPES)
+
+#define BOOST_TT_ALIGNMENT_TYPES\
+BOOST_PP_LIST_APPEND(BOOST_TT_ALIGNMENT_BASE_TYPES, \
+ BOOST_TT_ALIGNMENT_STRUCT_TYPES)
+
#define BOOST_TT_CHOOSE_MIN_ALIGNMENT(R,P,I,T)
\
typename mpl::if_c
\
(alignment_ofT::value == target !BOOST_PP_CAT(found,I)),
\
@@ -52,6 +65,12 @@
#define BOOST_TT_CHOOSE_T(R,P,I,T) T BOOST_PP_CAT(t,I);
+template typename T
+struct has_one_T
+{
+ T data;
+};
+
template std::size_t target
union lower_alignment
{
@@ -73,6 +92,9 @@
)
};
+#undef BOOST_TT_ALIGNMENT_BASE_TYPES
+#undef BOOST_TT_HAS_ONE_T
+#undef BOOST_TT_ALIGNMENT_STRUCT_TYPES
#undef BOOST_TT_ALIGNMENT_TYPES
#undef BOOST_TT_CHOOSE_MIN_ALIGNMENT
#undef BOOST_TT_CHOOSE_T
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [date_time] time_duration
The fractional seconds concept is undocumented. My guess it's something like: x.fractional_seconds() == x.ticks() % seconds(1).ticks() This needs to be nailed down. Also, the assymetry of those nice Construction by Count factories down to nanosec(x) with the accessors which only include units down to seconds() but not millisec()...nanosec() is disturbing and frankly inconvenient. BTW, why plural hours, minutes, seconds, but singular millisec, microsec, nanosec? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::date_time::time_resolutions
Where is this documented, and what is nano in the table entry below? static boost::date_time::time_resolutions resolution() Describes the resolution capability of the time_duration class. time_duration::resolution() -- nano -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS main trunk regression test failure
Daniel Frey [EMAIL PROTECTED] writes: Sorry, my fault. tie_example.cpp no longer exists, as 'tie' no longer lives in 'utility'. Can you please remove the reference from the test-file? Sure. A last question to the build-wizards: Would it make sense to make the build system continue if a leaf is missing? I don't see a compelling reason to stop the other regressions from running just because there is one little failure in the configuration of an otherwise unrelated test. Well, the build hasn't been stopped, its the processing of its log failed. The build system is fine, though the process_jam_log (program that creates test results files from build log) probably needs some improvement. -- Misha Bergal MetaCommunications Engineering ___ 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 optionalT 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 optionalT 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: 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 optionalT 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 optionalT 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 optionalT 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 optionalT *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 optionalT 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] [snip] Here's a question that tries to get to the crux of the pointer-like interface matter. Should T* and optionalT both be models of a pointer-like syntactic concept? pointers, iterators and optionalT are indeed models of 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 optionalT. 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 optionalT's uniformly or even replace raw pointers with optionalT's, since pointers also bring allocation issues with them. Instead I have been mainly focused on replacing T's with optionalT's. Being able to replace T's with optionalT'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
Re: [boost] Re: Re: Re: Optional, tie, and iterator_adaptor
--On Tuesday, September 02, 2003 10:48 PM -0300 Fernando Cacciola [EMAIL PROTECTED] wrote: [snip] For this reason, and for the fact that I have some upcoming deadlines at work, I'll summarize what I see and where I stand now, then I'll step back a bit for a while. I hope you come back later... :-) Thanks. 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. Ok, I got it now. Thanks for your patience in explaining your rationale. [snip] I can respect this set of design decisions, and optional in this form certainly has its uses. If optionalT 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. Great! 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 optionalT 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. Hmmm. Food for thought. Perhaps I should test out explainability on some potential clients of my code from this viewpoint. [snip] * 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. Great! [snip] * Backdoor to uninitialized storage available, e.g. unsafe_reference() What do you need this for? (provided direct assignment is supplied) I thought that I might needed this for tie or output reference parameters to work. * Works reasonably well with tie() This will be covered. Thanks. Still curious as to the details of how optional might work with tie, but perhaps I'm missing something obvious. Anyway, if optional is going to provide this too then you've smoothed over the main difficulties that I found in my initial usage. The existence of the pointer syntax is not troubling enough to me to warrant working on an alternative. [snip] Thanks again for considering these matters and taking the time to clarify your rationale. I look forward appreciatively to the planned enhancements. - Mat ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Re: Optional, tie, and iterator_adaptor
From: Fernando Cacciola [mailto:[EMAIL PROTECTED] Mat Marcus [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Those who answer no to the above question may prefer to write code that uniformly handles T and optionalT. I doubt such uniformity can be implemented smoothly. 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 optionalT's uniformly or even replace raw pointers with optionalT's, since pointers also bring allocation issues with them. Instead I have been mainly focused on replacing T's with optionalT's. Being able to replace T's with optionalT'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. I use optionalT quite a bit and am glad T and optionalT are different. Saves my bacon when I do silly things, especially when something transitions from a T to an optionalT. Strongly typed maintenance is something I'm thankful for. T* and optionalT substitutability seems fine to me. Matt. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Optional, tie, and iterator_adaptor
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 variantT, nil, 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?). Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ 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 variantT, nil, 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
Re: [boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
Fernando Cacciola [EMAIL PROTECTED] wrote: Point taken. There's no need to argue anymore. I guess significantly more feedback will weight the balance. Thanks for all your comments! It might look the other way around but they were very helpful. Bottom line is, and most importantly, optional gets the job done and it does it really well! :-) FWIW, it's easy to write a wrapper around optional that satisfies our wishes (in fact, I sent a class interface scheme to Dave G. tell me if you are interested). It might also be a nice idea to write a partial-specialization of variantT, empty that takes advantage of the optimizations of optional. Best Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
