------- Additional Comments From schlie at comcast dot net 2005-05-16 13:25
-------
(In reply to comment #9)
Subject: Re: static_cast falsely allows const to be cast away
> Gabriel Dos Reis writes:
>| ------- Additional Comments From schlie at comcast dot net 2005-05-16
>| (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.
- to me "constant expression" is an oxymoron, as any expression which can't
be resolved to a literal value prior to program execution is a runtime
"computed" expression. (so all expressions resolve at compile time to
either literals or otherwise, where the "otherwise"s may result in
'const' objects and/or references or not.
>| > | 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.
- no worries; yes I simply believe attempting to capture the necessary
subtleties of literal objects and references imply the necessity of
a distinct qualifier, although not necessary in the source language, as
literal objects are declared by context and syntax, not by explicitly
typed declaration.
>| 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.
- I admit some "hand-waving", but would be pleased to try to be more
specific, if you could point out a more specific complexity which it
introduces? (as I've already tried to point out issues that it helps
resolve for which 'const' is not sufficiently differentiating.)
>| 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.
- I believe I understand that 'const' implies a set of semantics depending
on the context of the object's use; one of which relate to the ability to
modify it's value directly and/or indirectly dependant on the objects then
current contextual 'const' qualification. Which I attempt to differentiate
from literal objects, which have so such valid disqualification.
>| #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?
- sorry, actually complied using C on the most current tools for OSX 10.3.9.
>| // ((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.
- but does compile without error?
(because once assigned to a pointer GCC couldn't differentiate between
a 'const' reference which may be potentially validly cast away, and a
literal reference which may never be validly cast away?)
>| 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.
- yes, as expected; but would further expect a warning/error for:
const char *ccp = "(c)";// which is fine.
((char *)ccp)[1] = 't'; // unless one attempts to cast away a reference
// to a literal, as opposed to a 'const' variable.
(or are you asserting that in C++ unlike C, 'const' objects are all literal
values, who's values are never allocated and subsequently computed and/or
modified at run-time, which doesn't seem to be purely the case?)
-paul-
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
