 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Daryle Walker
Guest
|
 Posted: Thu Jul 29, 2004 3:58 pm Post subject: We should allow official suppressing of automatically define |
 |
|
I was going to write on this subject completely from my own thoughts,
but I've also looked at:
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1582.pdf>
I think the problem is worse than that author stated. A class
automatically gets:
1. default constructor
2. copy constructor
3. destructor (non-virtual)
4. operator =
5. operator & (unary, i.e. address-of)
6. operator ,
So that proposal also needs to consider [5] and [6].
A big problem with blocking any of the list above is that the current
method is purely convention. You just declare the method private and
then don't define it. The flaw is that the compiler _cannot_ check the
"never gets defined" part. In fact, there could be legitimate uses of
declaring these methods private and defining them anyway. Since the
compiler can't distinguish the two cases, it can't optimize the common
first case since it can't risk that we actually have the second case.
Finally, we have a similar problem with "pure" virtual methods. These
don't actually exist in C++ either. Programmers use the same "declare
but never define" trick. But "pure" virtual methods can be defined.
(In fact, a derived class can use them in its mandatory re-definition!)
--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
Francis Glassborow
Guest
|
| Posted: Fri Jul 30, 2004 4:34 am Post subject: Re: We should allow official suppressing of automatically de |
|
|
In article
<dwalker07-0BF192.03190429072004 (AT) newsclstr01 (DOT) news.prodigy.com>, Daryle
Walker <dwalker07 (AT) snet (DOT) net> writes
| Quote: | I was going to write on this subject completely from my own thoughts,
but I've also looked at:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1582.pdf
I think the problem is worse than that author stated. A class
automatically gets:
1. default constructor
2. copy constructor
3. destructor (non-virtual)
4. operator =
5. operator & (unary, i.e. address-of)
6. operator ,
So that proposal also needs to consider [5] and [6].
|
They are already under consideration. 6 will probably not be touched, 5
is a matter of considering pros and cons. Ideas presented here will be
noted.
| Quote: |
A big problem with blocking any of the list above is that the current
method is purely convention. You just declare the method private and
then don't define it. The flaw is that the compiler _cannot_ check the
"never gets defined" part. In fact, there could be legitimate uses of
declaring these methods private and defining them anyway. Since the
compiler can't distinguish the two cases, it can't optimize the common
first case since it can't risk that we actually have the second case.
|
Which is another reason for the concept of an explicit class.
| Quote: |
Finally, we have a similar problem with "pure" virtual methods. These
don't actually exist in C++ either. Programmers use the same "declare
but never define" trick. But "pure" virtual methods can be defined.
(In fact, a derived class can use them in its mandatory re-definition!)
|
No, pure virtual methods are an entirely different issue already covered
by the Standard. Pure virtuals must have a subsequent overrider in a
derived class. Providing a definition in the ABC has no effect on that
requirement.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
John Nagle
Guest
|
| Posted: Mon Aug 02, 2004 7:26 pm Post subject: Re: We should allow official suppressing of automatically de |
|
|
Francis Glassborow wrote:
| Quote: | In article
[email]dwalker07-0BF192.03190429072004 (AT) newsclstr01 (DOT) news.prodigy.com[/email]>, Daryle
Walker <dwalker07 (AT) snet (DOT) net> writes
I was going to write on this subject completely from my own thoughts,
but I've also looked at:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1582.pdf
I think the problem is worse than that author stated. A class
automatically gets:
1. default constructor
2. copy constructor
3. destructor (non-virtual)
4. operator =
5. operator & (unary, i.e. address-of)
6. operator ,
So that proposal also needs to consider [5] and [6].
They are already under consideration. 6 will probably not be touched, 5
is a matter of considering pros and cons. Ideas presented here will be
noted.
|
From a safety perspective, this is desirable:
- If a class has a private or protected member whose initial
value is unsafe if uninitalized (typically a pointer), it
must have an explicit constructor which initializes that
value. Otherwise, the object is "born broken", with
a random value in a pointer.
- Any class with a non-virtual destructor cannot be subclassed.
- If you need a copy constructor, you also need a destructor
and "operator=". Enforce this.
With this enforcement, most of the mistakes one can make with
the defaults become errors.
This requires no new syntax, but causes some programs currently
considered valid to be in error. Such programs are probably
broken, and forcing a cleanup is a positive good.
I realize there's a "I am so l33t I should be allowed to break
the rules when I want to" lobby. They should be overridden.
Safety is more important. C++ is the least safe language in
mainstream use today. This needs to be recognized as a serious
problem.
John Nagle
Animats
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
JKop
Guest
|
| Posted: Mon Aug 02, 2004 11:04 pm Post subject: Re: We should allow official suppressing of automatically de |
|
|
| Quote: | A class
automatically gets:
1. default constructor
2. copy constructor
3. destructor (non-virtual)
4. operator =
5. operator & (unary, i.e. address-of)
6. operator ,
|
Would you not say that there's 8, ie.
class SomeClass
{
public:
SomeClass();
SomeClass(const SomeClass&);
~SomeClass();
SomeClass& operator=(const SomeClass&);
SomeClass* operator&();
const SomeClass* operator&() const;
template<class T> T operator,(T&) const;
template<class T> const T operator,(const T&) const;
};
-JKop
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Terje Slettebø
Guest
|
| Posted: Tue Aug 03, 2004 1:29 am Post subject: Re: We should allow official suppressing of automatically de |
|
|
"John Nagle" <nagle (AT) animats (DOT) com> wrote
| Quote: |
From a safety perspective, this is desirable:
- Any class with a non-virtual destructor cannot be subclassed.
|
I think this is very much debatable! :)
There's been lots of threads on this. Two possibilities - both being safe -
is to have the destructor public and virtual, or protected and non-virtual.
The latter case ensures that the class has to be inherited from, and that
you can't delete an object of it through a pointer to the base class, so
it's safe to have a non-virtual destructor.
Inheriting from a class with a public non-virtual destructor is also very
common. Take for example the standard library's unary_function and
binary_function.
It's also quite a lot in use in template metaprogramming.
| Quote: | - If you need a copy constructor, you also need a destructor
and "operator=". Enforce this.
|
There may also be legetimate cases where this doesn't apply. A compiler
might give a "notice" about it, though, just as it may do so if you have a
non-vritual destructor (and some do give a "notice" about this).
Regards,
Terje
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Loïc Joly
Guest
|
| Posted: Tue Aug 03, 2004 1:30 am Post subject: Re: We should allow official suppressing of automatically de |
|
|
John Nagle wrote:
| Quote: | From a safety perspective, this is desirable:
|
I am not really sure what you mean by safety here. Do you mean easier to
use correctly, or more resilent to piracy ?
| Quote: | - If a class has a private or protected member whose initial
value is unsafe if uninitalized (typically a pointer), it
must have an explicit constructor which initializes that
value. Otherwise, the object is "born broken", with
a random value in a pointer.
|
At one time, I was a proponent of 'all variables should be initialised,
if we do not know to which value, default initialise them'. I was told
that this wuold be very detrimental for performances is some cases. I
beleived your proposal would have the same effect.
By the way, what do you mean by 'whose initial value is unsafe if
uninitalized' ? From my comprehension of the standard, only with
unsigned char are we sure that any uninitialised value is safe.
| Quote: | - Any class with a non-virtual destructor cannot be subclassed.
|
Not very often, but once of twice, I subclassed a class with no virtual
destructor. And I beleive there was no better solution (this usually
happens when I cannot modify the base class or when performaces really
matter, and I know this type will not be used polymorphically, it was
derivation for re-use, but delegation was not a very good solution,
since the base class interface was very large).
| Quote: | - If you need a copy constructor, you also need a destructor
and "operator=". Enforce this.
With this enforcement, most of the mistakes one can make with
the defaults become errors.
This requires no new syntax, but causes some programs currently
considered valid to be in error. Such programs are probably
broken, and forcing a cleanup is a positive good.
I realize there's a "I am so l33t I should be allowed to break
the rules when I want to" lobby.
|
I'm rather part of the "sometimes, I have no choice" lobby. I beleive
all your propositions can be implemented with no change in the standard,
as compiler warnings. They are pretty good candidates for such
warnings., and maybe as a non normative note, the standard should
encourage those verifications, but if they are mandatory, and there is
no possibility for the user to force the previous behaviour, it would
hurt the programmers in some rarely encountered but nevertheless
existant and annoying cases.
| Quote: | They should be overridden.
Safety is more important. C++ is the least safe language in
mainstream use today.
|
What about C ? At least, in C++, there is only a very limited number of
points you have to be careful of in order to make a class safe. Compare
std::string to char* and its infamous buffer overflows.
| Quote: | This needs to be recognized as a serious
problem.
|
--
Loïc
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
JKop
Guest
|
| Posted: Tue Aug 03, 2004 1:14 pm Post subject: Re: We should allow official suppressing of automatically de |
|
|
| Quote: | class SomeClass
{
public:
SomeClass();
SomeClass(const SomeClass&);
~SomeClass();
SomeClass& operator=(const SomeClass&);
SomeClass* operator&();
const SomeClass* operator&() const;
template<class T> T operator,(T&) const;
template<class T> const T operator,(const T&) const;
};
|
CORRECTION
The comma operator should return a reference.
class SomeClass
{
public:
SomeClass();
SomeClass(const SomeClass&);
~SomeClass();
SomeClass& operator=(const SomeClass&);
SomeClass* operator&();
const SomeClass* operator&() const;
template<class T> T& operator,(T&) const;
template<class T> const T& operator,(const T&) const;
};
-JKop
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Bob Bell
Guest
|
| Posted: Tue Aug 03, 2004 5:05 pm Post subject: Re: We should allow official suppressing of automatically de |
|
|
[email]nagle (AT) animats (DOT) com[/email] (John Nagle) wrote in message news:<ZjwPc.102953$6r3.60036 (AT) newssvr29 (DOT) news.prodigy.com>...
| Quote: | From a safety perspective, this is desirable:
- If a class has a private or protected member whose initial
value is unsafe if uninitalized (typically a pointer), it
must have an explicit constructor which initializes that
value. Otherwise, the object is "born broken", with
a random value in a pointer.
- Any class with a non-virtual destructor cannot be subclassed.
- If you need a copy constructor, you also need a destructor
and "operator=". Enforce this.
|
Absolutely not. IMHO, none of these are desireable. I don't believe
it's the job of the language to hold my hand in this way. If you want
this kind of thing, there are other languages that do this much better
than C++ (e.g., Java).
| Quote: | With this enforcement, most of the mistakes one can make with
the defaults become errors.
|
As do some appropriate uses of the defaults.
| Quote: | This requires no new syntax, but causes some programs currently
considered valid to be in error. Such programs are probably
broken, and forcing a cleanup is a positive good.
|
A practical definition of "broken" would be something along the lines
of "doesn't work." Presumably, the programs you say are probably
broken are currently working.
| Quote: | I realize there's a "I am so l33t I should be allowed to break
the rules when I want to" lobby. They should be overridden.
Safety is more important. C++ is the least safe language in
mainstream use today. This needs to be recognized as a serious
problem.
|
Sorry, can't agree. It has nothing to do with being "l33t", it's just
that C++ is not designed to be "safe" ("safe" in the sense of
preventing you from making mistakes). I think the approach of n1582
makes a lot more sense, because it doesn't attempt to restrict the
kinds of programs I can write, whereas your idea of safety does. Also,
it doesn't break existing code; your idea does.
I have had valid reasons to violate all three of your safety
guidelines; having the language forbid me from doing so would not have
made my programs any safer, but would have made them more complicated.
Bob
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Bob Bell
Guest
|
| Posted: Tue Aug 03, 2004 7:10 pm Post subject: Re: We should allow official suppressing of automatically de |
|
|
[email]nagle (AT) animats (DOT) com[/email] (John Nagle) wrote in message news:<ZjwPc.102953$6r3.60036 (AT) newssvr29 (DOT) news.prodigy.com>...
| Quote: | From a safety perspective, this is desirable:
- If a class has a private or protected member whose initial
value is unsafe if uninitalized (typically a pointer), it
must have an explicit constructor which initializes that
value. Otherwise, the object is "born broken", with
a random value in a pointer.
- Any class with a non-virtual destructor cannot be subclassed.
- If you need a copy constructor, you also need a destructor
and "operator=". Enforce this.
|
Absolutely not. IMHO, none of these are desireable. I don't believe
it's the job of the language to hold my hand in this way. If you want
this kind of thing, there are other languages that do this much better
than C++ (e.g., Java).
| Quote: | With this enforcement, most of the mistakes one can make with
the defaults become errors.
|
As do some appropriate uses of the defaults.
| Quote: | This requires no new syntax, but causes some programs currently
considered valid to be in error. Such programs are probably
broken, and forcing a cleanup is a positive good.
|
A practical definition of "broken" would be something along the lines
of "doesn't work." Presumably, the programs you say are probably
broken are currently working.
| Quote: | I realize there's a "I am so l33t I should be allowed to break
the rules when I want to" lobby. They should be overridden.
Safety is more important. C++ is the least safe language in
mainstream use today. This needs to be recognized as a serious
problem.
|
Sorry, can't agree. It has nothing to do with being "l33t", it's just
that C++ is not designed to be "safe" ("safe" in the sense of
preventing you from making mistakes). I think the approach of n1582
makes a lot more sense, because it doesn't attempt to restrict the
kinds of programs I can write, whereas your idea of safety does. Also,
it doesn't break existing code; your idea does.
I have had valid reasons to violate all three of your safety
guidelines; having the language forbid me from doing so would not have
made my programs any safer, but would have made them more complicated.
Bob
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Bob Bell
Guest
|
| Posted: Tue Aug 03, 2004 7:15 pm Post subject: Re: We should allow official suppressing of automatically de |
|
|
[email]nagle (AT) animats (DOT) com[/email] (John Nagle) wrote in message news:<ZjwPc.102953$6r3.60036 (AT) newssvr29 (DOT) news.prodigy.com>...
| Quote: | From a safety perspective, this is desirable:
- If a class has a private or protected member whose initial
value is unsafe if uninitalized (typically a pointer), it
must have an explicit constructor which initializes that
value. Otherwise, the object is "born broken", with
a random value in a pointer.
- Any class with a non-virtual destructor cannot be subclassed.
- If you need a copy constructor, you also need a destructor
and "operator=". Enforce this.
|
Absolutely not. IMHO, none of these are desireable. I don't believe
it's the job of the language to hold my hand in this way. If you want
this kind of thing, there are other languages that do this much better
than C++ (e.g., Java).
| Quote: | With this enforcement, most of the mistakes one can make with
the defaults become errors.
|
As do some appropriate uses of the defaults.
| Quote: | This requires no new syntax, but causes some programs currently
considered valid to be in error. Such programs are probably
broken, and forcing a cleanup is a positive good.
|
A practical definition of "broken" would be something along the lines
of "doesn't work." Presumably, the programs you say are probably
broken are currently working.
| Quote: | I realize there's a "I am so l33t I should be allowed to break
the rules when I want to" lobby. They should be overridden.
Safety is more important. C++ is the least safe language in
mainstream use today. This needs to be recognized as a serious
problem.
|
Sorry, can't agree. It has nothing to do with being "l33t", it's just
that C++ is not designed to be "safe" ("safe" in the sense of
preventing you from making mistakes). I think the approach of n1582
makes a lot more sense, because it doesn't attempt to restrict the
kinds of programs I can write, whereas your idea of safety does. Also,
it doesn't break existing code; your idea does.
I have had valid reasons to violate all three of your safety
guidelines; having the language forbid me from doing so would not have
made my programs any safer, but would have made them more complicated.
Bob
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
John Nagle
Guest
|
| Posted: Wed Aug 04, 2004 6:21 pm Post subject: Re: We should allow official suppressing of automatically de |
|
|
===================================== MODERATOR'S COMMENT:
Submitted three times and got sent to three different moderators? Got
approved and then the newsserver went into a loop? Lots of possibilities on
a place like Usenet...
===================================== END OF MODERATOR'S COMMENT
Bob Bell wrote:
| Quote: | Absolutely not. IMHO, none of these are desireable. I don't believe
it's the job of the language to hold my hand in this way. If you want
this kind of thing, there are other languages that do this much better
than C++ (e.g., Java).
|
How did three copies of the same comment make it through
moderation?
John Nagle
Animats
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
John Nagle
Guest
|
| Posted: Wed Aug 04, 2004 7:11 pm Post subject: Re: We should allow official suppressing of automatically de |
|
|
Loïc Joly wrote:
| Quote: | John Nagle wrote:
From a safety perspective, this is desirable:
I am not really sure what you mean by safety here. Do you mean easier to
use correctly, or more resilent to piracy ?
|
I mean less likely to result in defective programs.
A clear understanding of language safety issues is essential
for language design.
| Quote: | - If a class has a private or protected member whose initial
value is unsafe if uninitalized (typically a pointer), it
must have an explicit constructor which initializes that
value. Otherwise, the object is "born broken", with
a random value in a pointer.
By the way, what do you mean by 'whose initial value is unsafe if
uninitalized' ? From my comprehension of the standard, only with
unsigned char are we sure that any uninitialised value is safe.
|
Given the way the standard is written, that's a pickey, but
probably correct, point. In theory, you could have an implementation
for a machine for which not all bit patterns are valid integers.
Decimal machines, like the IBM 1401, the IBM 1620, and the UNIVAC I
have that property. Somehow, I don't think that backwards
compatibility with machines from the early 1960s is a major issue.
Since C++ allows shift operations on integers, there's an
assumption that the underlying representation is binary.
| Quote: |
- Any class with a non-virtual destructor cannot be subclassed.
Not very often, but once or twice, I subclassed a class with no virtual
destructor.
|
We can fix that.
Define an "empty destructor" as a default destructor for a class
which contains no data members with non-empty destructors. An
"empty destructor" doesn't do anything to the object before
its space is released.
Then, we should have the rule that a class with a non-empty
non-virtual destructor cannot be subclassed.
This is both safe and tolerant of existing valid code.
It's OK to have a non-virtual destructor in a derived class
when it's harmless. This defines and checks "harmless".
If you're overriding a destructor for a class that has a
destructor that does something, the program does have a bug.
A destructor that does something is being silently skipped.
That should be caught at compile time.
John Nagle
Animats
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Hyman Rosen
Guest
|
| Posted: Wed Aug 04, 2004 7:48 pm Post subject: Re: We should allow official suppressing of automatically de |
|
|
John Nagle wrote:
| Quote: | If you're overriding a destructor for a class that has a
destructor that does something, the program does have a bug.
A destructor that does something is being silently skipped.
That should be caught at compile time.
|
No. This is not an error, and will break existing code.
It is perfectly OK to derive from a class which has a
non-virtual "does something" destructor, and to have a
"does something" destructor in the derived class.
The only time an error occurs is if an object of this
derived class is deleted through a pointer to the base
class. If the object is deleted through a pointer to
the derived class, or if an automatic object of the
derived type goes out of scope, the entire chain of
destructors is called properly.
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
John Nagle
Guest
|
| Posted: Thu Aug 05, 2004 4:39 pm Post subject: Re: We should allow official suppressing of automatically de |
|
|
Hyman Rosen wrote:
| Quote: | John Nagle wrote:
If you're overriding a destructor for a class that has a
destructor that does something, the program does have a bug.
A destructor that does something is being silently skipped.
That should be caught at compile time.
No. This is not an error, and will break existing code.
It is perfectly OK to derive from a class which has a
non-virtual "does something" destructor, and to have a
"does something" destructor in the derived class.
The only time an error occurs is if an object of this
derived class is deleted through a pointer to the base
class. If the object is deleted through a pointer to
the derived class, or if an automatic object of the
derived type goes out of scope, the entire chain of
destructors is called properly.
|
That's easy to check for at run time. If the size
at "delete" doesn't match the proper size for the type,
an error should be reported.
John Nagle
Animats
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Hyman Rosen
Guest
|
| Posted: Thu Aug 05, 2004 8:46 pm Post subject: Re: We should allow official suppressing of automatically de |
|
|
John Nagle wrote:
| Quote: | That's easy to check for at run time. If the size
at "delete" doesn't match the proper size for the type,
an error should be reported.
|
No. There is no reason that a derived type is any larger
than the base type. There is no reason that an alloactor
necessarily keeps track of the exact size of an allocated
block. That could be required, increasing the overhead for
small objects, and at that point you may as well store a
vtbl pointer in every object, making the whole issue moot.
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
