Re: Feature Proposal: Explicitly declare a struct (or class) as POD
jmucchiello wrote:
On Aug 26, 12:49 pm, Alan Woodland <aj...@aber.ac.uk> wrote:
You also talked about C compatibility for PODs, but this:
template <typename T>
struct foo {
T bar;
};
is a POD, yet not 'C' compatible in respect, and doesn't even result in
any symbols in the output anyway to inspect the 'POD status' of it as
you'd like us to do.
No, it is not a POD. T can be a non-POD type and that would make foo
non-POD. This example is exactly what my proposal is for. In my
proposal, you would say:
template <typename T>
struct static foo {
T bar;
};
class C {
public:
virtual ~C() {}
};
foo<C> aFoo; // compiler error
How would you get the same functionality using a static assert?
The fact that foo<T> is/isn't a POD isn't what actually matters when you
declare/define foo though. It's where foo<T> gets used that it matters.
It's not an error to pass some T that makes foo non-POD, unless you
later hand foo off to something that assumes foo<T> is always POD.
If foo assumes that T itself is POD then it's easy enough to modify
ASSERT_POD to work inside of foo's definition.
Where it really matters that foo<T> is a POD would be the place where
you do something that assumes it is a POD (e.g. memcpy or whatever), and
that's the place I'd be looking to put the ASSERT_POD call. An
ASSERT_POD in some function that calls memcpy serves as documentation to
a reader, and enforces it through the compiler. In fact if you didn't
put ASSERT_POD in places where you actually did things that assumed it
was POD you'd still be open to breakages later on, even with your
proposed way of doing things.
e.g.:
template <typename T>
void super_optimised_pod_routine(const T& bar) {
ASSERT_POD(T);
// do some clever fast things here
}
Under your proposal there is no way to say T must be a POD here, which
is by far the most useful scenario for POD testing.
I fail to see any strong arguments for benefits of what you propose that
can't already be covered (arguably better) by checking PODness where it
really counts.
I'd be more enthusiastic about a proposal for allowing you to write:
template <POD T>
except for the fact it's already possible to achieve this functionality
as I outlined.
As far as I know most implementations don't store any type info of
instances in the symbols they export, e.g:
foo<int> inst;
Of course not, there's nothing about that in the spec: try this and
watch how much type info is generated. I specifically talked about
name mangling, not global data.
foo<int> func(foo<int> a) {
return 0;
}
It's completely implementation defined what I see from that. There's no
reason why your implementation can't write POD in big letters there
already if whoever made your implementation thought it mattered. It
seems somewhat bizarre to leave mangling completely open-ended yet add
one small caveat requiring implementations to mention if the arguments
and return types are POD or not. For what's required of an
implementation right now the mangling could be done based on a MD5 hash!
Alan