Re: struct_pod - what struct should have been
""Crosbie Fitch"" <crosbie@digitalproductions.co.uk> skrev i
meddelandet news:26udncyqLZFvhTTZnZ2dnUVZ8t2dnZ2d@bt.com...
"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'.
What exactly is the definition then?
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'.
It is actually the other way round - the compiler can implement the
special functions, base classes and access specifiers any way it
wants. In the absence of such, there isn't very much to optimize, is
there?
The only restriction is that if all members are public, they have to
be allocated in the order they appear. That's all there is to PODs.
The compiler doesn't have to disable anything, beacuse there is
nothing to disable!
Few use classes in POD situations precisely because being able to
override the assign-copy operator is pretty essential. NB That
doesn't mean that the class cannot be designed to survive memcpy.
The most common reason for adding a copy constructor and assignment
operator is precisely beacuse the struct is not a pod in the first
place. If it is, the compiler generated defaults just work.
Alternatively, one could use explicit:
struct MyPod
{ int n;
explicit MyPod& operator=(const MyPod& m) { foo(); }
};
Because the assign-copy is marked 'explicit', it does not break the
podness of MyPod.
explicit would also be applicable in the same manner to default
constructors, and destructors.
Explicit already has another meaning in some constructors, that can
work as a default constructor:
struct notpod
{
explicit notpod(int x = 0);
};
You suggestion would change that.
Bo Persson
---
[ 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 ]