------- Additional Comments From gdr at integrable-solutions dot net
2005-05-16 09:07 -------
Subject: Re: static_cast falsely allows const to be cast away
"schlie at comcast dot net" <[EMAIL PROTECTED]> writes:
| ------- Additional Comments From schlie at comcast dot net 2005-05-16 05:07
-------
| (In reply to comment #7)
| > Subject: Re: static_cast falsely allows const to be cast away
| > That is your view. However, not because GCC implements the ISO C++
| > view of types, means that GCC has a narrow view of a type is. I
| > suspect that part of your speculation is based on unfamiliarity with
| > both the C++ type system and the GCC internal notion of types.
|
| - but apparently inadequate to express the necessary differentiation between
| constant and literal objects, as needed to be tracked by a compiler for
| these languages?
I don't think the distinction is necessary -- I can see arguments why
people would want it, but it is not necessary. You're speaking of
literals but seem to forget that 0 and 0+0 should be put in the
same category though the latter is not a literal. So, "literal" is not
the right thing. The notion used in C++ is "constant expressions", that
directly leads to "const object"s.
| > | A literal string is not simply a 'const char [N]' object, as a
| > | literal value may not be specified as a target of an assignment,
| > | directly or indirectly though a pointer cast to a non-const object
| > | reference, unlike as a plain old 'const' objects may be.
| >
| > But, a plain old 'const' object cannot be a target of an assignment.
| > There is no different there -- and certainly "static" does not imply a
| > difference there -- so the basis of your argument seems fragile to
| > begin with.
|
| - subtle possibly, but not fragile; the following simple program illustrates
without being insulting, I don't believe it is subtile -- it just
emphasizes some unfamiliarity with the C++ type system. Once you
start adding a type qualifier, you have to spell out clearly its
interaction with the type system (including overload resolution) and
separate compilation.
| the problem, where if hypothetically 'literal' were a valid qualifier,
| then the problem would be easy to solve, and also flexibly enable the
that "solve" is only apparent. It introduces a whole can of worms you
seem to handwave.
| definition of functions which accept and return references to literals,
| as being distinct from const, where const means simply not writeable
| presently, not necessary never (i.e. can't ever assign to references,
| which is what literal semantics would seem to dictate.):
But "const" in C++ does not mean "no writeable". This is another
symptom of unfamiliarity with the C++ type system.
| #include <stdio.h>
|
| int main (void)
| {
| // non-const pointers to literals should at least warn,
| // and assignments to literals should generate an error.
| char *cp = "(a)"; // compiles without warning/error (literal*)?
I have a warning on my system -- what are you using?
| // ((char *)cp)[1] = 't'; // compiles without warning/error -> bus error!
because you shall not. The rule is quite simple : thou shalt not
modify a const object. No but, no if. Period.
| printf(cp); // dies above if uncommented, otherwise "(a)"
|
| char ca[4] = "(b)"; // compiles without warning/error.
| ((char *)ca)[1] = 't'; // compiles without warning/error.
| printf(ca); // outputs "(t)", as expected.
because of initialization of the array.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
