Re: Abandonment of aggregate types
Dave Steffen wrote:
truedfx@gmail.com (Harald van D=C3=BE=C3=BF_3k) writes:
Dave Steffen wrote:
giecrilj@stegny.2a.pl ("Kristof Zelechovski") writes:
Uzytkownik "Dave Steffen" <dgsteffen@numerica.us> napisal w wiadomo=
sci
news:qqmwt99pyia.fsf@yttrium.numerica.us...
skaller <skaller@users.sourceforge.net> writes:
On Tue, 15 Aug 2006 14:00:18 +0000, Dave Steffen wrote:
fgothamNO@SPAM.com (Frederick Gotham) writes:
[...]
Well, "farce" might be a little harsh. Constructors are clean =
and
built in;
Huh? they actually allow you to break the type system without
casting (store non-const pointer to const object).
I'm not sure why you think that breaks the type system. Adding
const-ness to something doesn't break anything IMHO. Do you hav=
e
[...]
class T {
public:
T(T *&p_t) { p_t = this; }
int m;
};
int main() {
T *p_t;
const T t(p_t);
p_t->m = 0; // oops!
}
OK, but I still don't see why this is an example of "constructors
breaking the type system". IANALanguageL, but I don't think
that 'const' applies during construction. I would also opine that is
is a silly, or at least strange, piece of code to write. We all know
that most of the protections and restrictions designed into C++ are
designed to guard against Murphy, not against Machiavelli (I'm pretty
sure Dr. Stroustrup said that).
How is this any worse than
int* ip = new int(3);
const int* const_ip = ip;
*ip = 42; // what happened to my const data?
"const int *" essentially means pointer to read-only int, not pointer to
constant int, and your code is valid. The original code modifies an objec=
t
defined as const, and when that happens, the behaviour is undefined.
Agreed, your example is less obvious than this example, or the usual
'cast-away-constness-and-lie-to-the-compiler' tricks seen on the
other newgroups so often; but you're reaching into an object during
construction and returning a pointer to its internal data. Don't Do
That.
I continue to refute the statement made earlier by "skaller", in
response to my statement that constructors are clean, where he said
Huh? they actually allow you to break the type system without
casting (store non-const pointer to const object).
By your example, they only allow this sort of bad behavior when
explicitly told to do so (against all guidelines I know of).
The same could be said for modifying string literals in C (not
const-qualified); C++ does attempt to not let you modify const objects
without casts, or running into undefined behaviour earlier, right?
Exceptions exist where doing so breaks C compatibility too much, but that
is not a problem for constructors.
And there are legitimate reasons for an object to store a pointer to itse=
lf
elsewhere during construction. An easy example is a call to
parent.insert(this);.
I hold
that this is less egregious than many other, much more problematic
issues (such as the issues raised by Frank Gotham that started this
thread).
Frederick, but no argument there.
I'd also ask if you, or skaller, have any suggestions on how to fix
your example; how, for example, would you change the syntax of the
language to dissalow your example?
It's probably too late to fix it now, but pretending C++ is designed anew=
,
one option is to make constructors just like member functions in that the=
re
can be const and non-const versions, possibility permitting constness to =
be
cast away during construction.
---
[ 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 ]