This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/20475] static_cast falsely allows const to be cast away


------- Additional Comments From gdr at integrable-solutions dot net  2005-05-16 17:00 -------
Subject: Re:  static_cast falsely allows const to be cast away

"schlie at comcast dot net" <gcc-bugzilla@gcc.gnu.org> writes:

| (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,

then, you're out of luck.

[...]

| >|   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.

If you fill a PR about C++ while you're testing C, you do not expect
anything useful out it.  Do you?  Anyway, you do get a warning with
both C and C++ front-end if you say -Wwrite-strings.

[...]

| (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?)

I'm claiming that
  (1) "const" has a different semantics in C++ than in C.
  (2) const objects cannot be modified in C++ -- if you do, you get
      what you deserve.
  (3) in C++, const objects initialized with constant expressions, can
      participate in constant expressions.  Consequently, if their
      addresses are never taken, the compiler will not allocate
      storage for them.  G++ has been doing that optimization for ages
      now.  Notice that, that differs from C.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]