From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-18 19:06:51
Peter Dimov wrote:
> > > C99 VLA.
> > Thats called a C99 VLA. :-)
> No, it's not. It's called a vector that is as efficient as a VLA. Meaning
> that it's no less efficient than a VLA as long as it's on the stack and not
> resized, and no less functional or efficient than std::vector / new
But such an animal cannot exist. There is no way
to allocate n elements of an array on the stack with n being
dynamically determined -- without using VLA's. That is the whole
point of VLA's.
> > > * a variant type, both unconstrained (any, or variant<void>) and
> > > (variant<T>).
> > Waste of time. I built one of these, and it is too hard to
> > use to bother.
> My experience is somewhat different.
> class xml_element;
> class xml_text: public xml_element;
> class xml_tag: public xml_element;
This is not a proper variant construction, unfortunately.
It is a common abuse of inheritance to try to emulate the missing
functionality. To make it work, you have to use RTTI, and the result
isn't safe: you can try to make it safer by providing some
'convenience' functionality, but you can't force people
to use it. :-(
Compare with SML:
type t = X of int | Y of float
match e with
| X x -> print_int x
| Y y -> print_float y
where type safety is enforced, and, in most cases,
completeness of decoding checked.
My point is: you gain very little with any
emulation of variants in C++, over the C technique
of casting a void *. That's also precisely how I
implement variants in the code generated by Felix.
[Of course, I know the casts are safe]
If we're going to enshrine variants in C++,
they should be done properly: by an extension
to the core language.
> > What we really need is core language support :-(
> I could use LOTS of core language support.
But you're unlikely to get it.
I've _already_ tried to get most of the important missing
functionality into C++, and that was before Standardisation.
Even though the current group of committee members is likely
to be more receptive to adding support, the compatibility
obstacles are now enshrined in Stone insead of just Soap.
That includes the existence of vendor ABIs (binary interface
standards) which are harder to budge than source code.
The only core language support that is really
feasible is for something which can
a) look like a library
b) actually be implemented as a library
in which case, compiler support is optional, and it
isn't 'really' core language support. Tuples are
a good example. There are a few exceptions:
IMHO only a few will be accepted. The one that
is most likely to be accepted -- and most needed,
IMHO, is threading.
-- John (Max) Skaller, mailto:skaller_at_[hidden] 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 New generation programming language Felix http://felix.sourceforge.net Literate Programming tool Interscript http://Interscript.sourceforge.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk