Robert C White Jr <HumansRemoveThis_rwhite@bellatlantic.net> writes:

 >Mike Rubenstein wrote:
 >
 >> "Igor Chudov @ home" <ichudov@algebra.com> wrote:
 >>
 >> > Draft> 3 A pointer or reference to a cv-qualified type need not
 >> > Draft>   actually point or refer to a cv-qualified object, but it is
 >> > Draft>   treated as if it does; a const-qualified access path cannot
 >> > Draft>   be used to modify an object even if the object referenced
 >> > Draft>   is a non-const object and can be modified through some
 >> > Draft>   other access path.  [Note: cv-qualifiers are supported by
 >> > Draft>   the type system so that they cannot be subverted without
 >> > Draft>   casting (_expr.const.cast_).  ]
 >
 >> OK.  You are mistaken.  Note that 3. specifically says
 >>
 >>         a const-qualified access path cannot be used to modify an
 >>         object even if the object referenced is  a  non-const  object
 >>
 >>         and  can  be  modified through some other access path.
 >>
 >> That says you can't change the object using the const pointer, but you
 >> can change it through a different one ("through some other access
 >> path").
 >
 >Actually, you are *BOTH* right...

Nope, the original poster who thought that `const int *p' allowed
the compiler to optimize assuming that what `p' points to will not
change is wrong.

 >Note that #3 does say that "...it is treated as if it does..."

That is non-normative fluff; it is just there to explain the remainder
of the sentence.

 >What this means is that if you activate the anit-alias(ed) features of
 >your optimizer you will get the highly optimized code, if you don't you wont.

Any optimizer which has "anti-alias(ed) features" that allow it to make
the assumption described above is *not* a standard-conforming implementation.

 >It is also why virtually every implimintation of a C/C++ optimizer has the
 >fully-anti-aliased-or-not option.

I think the _real_ reason for the existence of optimizer options that
cause compilers to become non-standard-conforming and that can break
standard-conforming code is simply that such optimizer options can
result in better performance on influential benchmarks.

It would be deplorable and irresponsible for any compiler vendor to offer
such an option without documenting its potential dangers.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Mike Rubenstein wrote:

> "Igor Chudov @ home" <ichudov@algebra.com> wrote:
>
> > Draft> 3 A  pointer or reference to a cv-qualified type need not actually point
> > Draft>   or refer to a cv-qualified object, but it is treated as if it does;  a
> > Draft>   const-qualified access path cannot be used to modify an object even if
> > Draft>   the object referenced is  a  non-const  object  and  can  be  modified
> > Draft>   through some other access path.  [Note: cv-qualifiers are supported by
> > Draft>   the type system so that  they  cannot  be  subverted  without  casting
> > Draft>   (_expr.const.cast_).  ]



> OK.  You are mistaken.  Note that 3. specifically says
>
>         a const-qualified access path cannot be used to modify an
>         object even if the object referenced is  a  non-const  object
>
>         and  can  be  modified through some other access path.
>
> That says you can't change the object using the const pointer, but you
> can change it through a different one ("through some other access
> path").

Actually, you are *BOTH* right...

Note that #3 does say that "...it is treated as if it does..."

What this means is that if you activate the anit-alias(ed) features of your optimizer you will
get the highly optimized code, if you don't you wont.  The thing is that "const" ness is
*really* a promise from the programmer to the compiler as much as it is a lingual restriction.
I believe Bjarne S. (I can't spell it 8-) referes to this vaguely when discussing the
difference between actual constness and logical constness.

It is also why virtually every implimintation of a C/C++ optimizer has the
fully-anti-aliased-or-not option.

Rob.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]