Re: private destructor and templates
Ben Voigt wrote:
"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:eh652e$ept$1@news.datemas.de...
Ben Voigt wrote:
"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:eh5pnc$i7m$1@news.datemas.de...
Ben Voigt wrote:
I have a POD type with a private destructor.
No such thing. PODs cannot not have private anything, PODs cannot
have user-defined destructors (8.5.1/1, 9/4).
Hmmm, think you're right about the destructor. However private
helper functions are certainly possible in a POD.
_By definition_ the presence of private or protected member makes the
class non-POD. There can be no discussion or argument about it.
A POD cannot have non-public variables. But it can have public member
functions, correct? Then naturally these can use private helpers
internally. Or no?
Are you not reading what I type here? Public member functions are OK
as long as they are not virtual. Nothing private and nothing protected.
_By definition_. If you want to challenge the definition, you should
go to 'comp.std.c++'. But I wouldn't recommend it. Learn the tools,
don't try to change them. If you need different tools, get different
tools, don't try to squeeze the existing tools into a different mold.
I thought a POD was anything that is a drop-in replacement for some C
struct. That means (1) layout compatible
Yes. C++ Standard says that the layout is pretty much known _between_
access specifiers. So, *across* access specifiers the layout is
somewhat a mystery (implementation-defined, yadda yadda).
and (2) no reduced
visibility for any member.
OK, so private and protected isn't that? Or are you trying to pull
some temporal characteristic here as well? There isn't any.
If any existing variable became hidden,
it would break code that worked on the struct.
Sigh... So, if you're writing _new_ code, it doesn't matter? What
kind of argument is that?
If any new variables
were added, they would break the layout. Therefore there can be no
non-public variables.
What if I add new public variables? Don't they break the layout of
an _existing_ struct?
However member functions and static members of
any type do not affect the layout,
Says who?
and do not break existing code
referring to structure members, so they are permitted, regardless of
visibility.
What existing code? What if I'm writing a new program altogether?
How the hell should the compiler know where the code comes from?
What do you call a class whose instances have no v-table, but isn't
a POD?
A class. A UDT, if you need to use a TLA. And what does v-table
have to do with it?
A v-table is what makes an object. Without a v-table, there is no
polymorphism, no RTTI, in fact no awareness of 'type'. A class
without a v-table is just an assembly of variables and functions in a
naming scope, hardly any different from a namespace.
Bull. An object is an area of computer memory, ones and zeros. There
are no RTTI, no 'type', no "awareness". Program is another set of
the same ones and zeros. See, anything can be taken to extreme and
made absurd, if one pleases. Object is a concept that exists in terms
of the program you write. Nothing more and nothing less. Same as
a class, a POD-struct, a function, a namespace, a variable, whatever.
Pull it out of its context and you can do whatever you want with it.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask