Re: struct_pod - what struct should have been
"Crosbie Fitch" wrote:
"James Dennett" <jdennett@acm.org> wrote in message
news:BhUpg.845$lv.10@fed1read12...
The thing is that it's *not* POD -- POD has a definition,
Sorry, I've been assuming it's obvious: The definition of POD would be
amended to include 'struct_pod'.
You seem to think of POD-ness as being defined in terms of how it's
implemented; it isn't - it's defined in terms of which types qualify as
POD types. The implementation of POD types is constrained, but not
defined, by the many promises the standard makes about POD types that
it doesn't make about other types.
It's generally a bad idea to re-define an existing concept to apply to
things it didn't previously apply to. If it were modified, then every
one of the dozens of guarantees that the standard makes about POD
types would have to be reviewed, and many of them would have to be
re-written to say that they apply only to POD types which aren't
struct_pod types. It's far simpler to re-write the descriptions of the
guarantees that would apply to struct_pod types, and specify that they
do apply to both PODs and struct_pod types. And, as I pointed out
earlier, if we take that approach, then struct_pod is a bad name for
the relevant keyword.
I don't think there's any chance of something
like this being standardized until/unless it's implemented
in some compilers, so you might be better to work on getting
it used in the real world before trying to device the perfect
syntax for standardization.
It is implemented in compilers. They currently have tests to disable the
implementation that would otherwise occur, e.g. 'If class has assign-copy it
is non-POD - disallow in situations where only POD may occur'.
Yes, but this isn't exactly what you're advocating. The first step
should be to get someone to implement exactly the thing that you're
advocating, as an extension, and get some real world experience with
using it. That experience will give you hard data to document that it
is a) efficiently implementable and b) sufficiently useful to justify
changing the standard, which are important things that the committee
wants to know before it changes the standard.
The standard isn't the place for experimentation with new features
(though it has been misused that way in the past). The stardard is the
place for writing in stone those features which have been tested
sufficiently thoroughly to justify making them permanent unalterable
features of the language. That's because the need for backwards
compatibility makes it very difficult, bordering upon the impossible,
to remove any feature from the language, once it's been added.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]