James Kuyper <kuyper@wizard.net> writes:

>Mike Rubenstein wrote:
>>
>> > Section 7.1.5.1 [dcl.type.cv] paragraph 3 of the C++ standard says:
>> >
>> > | A  pointer or reference to a cv-qualified type need not actually point
>> > | or refer to a cv-qualified object, but it is treated as if it does;  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.  [Note: cv-qualifiers are supported by
>> > | the type system so that  they  cannot  be  subverted  without  casting
>> > | (_expr.const.cast_).  ]
...
>> In fact, in fact 7.1.5.1 of the C++ standard also includes an example
>> that makes it quite clear that it is legal to cast away const as long
>> as the object is not defined as const:
[...]
>This example leaves me confused. What is an 'access path'?

An lvalue expression that refers to an object.

>The C++ standard leaves the term undefined.

Yes, unfortunately the language used in that part of the draft
is not very precise and is prone to misinterpretation.

>What I thought was that any pointer created from another pointer to the
>same object was on the same access path as the original, whether the new
>pointer was created by assignment, casts, conversions, pointer
>arithmetic, or subscripting. By that definition, ip and cip would be on
>the same access path, and this example would therefore be prohibited by
>section 7.1.5.1. Without such a definition, 7.1.5.1 is so easily
>side-stepped that it seems pointless to me.

7.1.5.1 paragraph 3 is simply there to say that examples such as

 int x;
 const int &y = x;
 y++;

are ill-formed.

--
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:
>
> James Kuyper <kuyper@wizard.net> wrote:
...
> > I do have a copy of the draft standard for C++. The C++ standard says in
> > section 5.2.11 [expr.const.cast], paragraph 7:
> >
> > |[Note: Depending on the type of the object, a write operation  through
> > | the  pointer,  lvalue  or  pointer  to  data  member  resulting from a
> > | const_cast that casts away a const-qualifier may produce  undefined
> > | behavior (_dcl.type.cv_).  ]
> >
> > Section 7.1.5.1 [dcl.type.cv] paragraph 3 of the C++ standard says:
> >
> > | A  pointer or reference to a cv-qualified type need not actually point
> > | or refer to a cv-qualified object, but it is treated as if it does;  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.  [Note: cv-qualifiers are supported by
> > | the type system so that  they  cannot  be  subverted  without  casting
> > | (_expr.const.cast_).  ]
> >
> > If C9X does not currently have comparably strong language, I strongly
> > recommend that it be added.
>
> That's not any stronger than the C wording, though I do like it
> better.  It more explicitly says that you can modify the variable
> using a different path, including one obtained by casting away const.
> Note that my  example does use a cast to change the pointer to a
> pointer to non-const.
>
> In fact, in fact 7.1.5.1 of the C++ standard also includes an example
> that makes it quite clear that it is legal to cast away const as long
> as the object is not defined as const:
>
>           int i = 2;         // not cv-qualified
>           const int* cip;    // pointer to const int
>           cip = &i;          // okay: cv-qualified access path to
>                              // unqualified
>           *cip = 4;          // ill-formed: attempt to modify through
>                              // ptr to const
>           int* ip;
>           ip = const_cast<int*>(cip);
>                              // cast needed to convert const int* to
>                              // int*
>           *ip = 4;           // defined: *ip points to i, a non-const
>                              // object

[This has changed to become a question about C++ itself, so I'm cross
posting to comp.std.c++]

This example leaves me confused. What is an 'access path'? The C++
standard leaves the term undefined. I thought I knew what was meant, but
my understanding is incompatible with this example, which I hadn't
noticed before.

What I thought was that any pointer created from another pointer to the
same object was on the same access path as the original, whether the new
pointer was created by assignment, casts, conversions, pointer
arithmetic, or subscripting. By that definition, ip and cip would be on
the same access path, and this example would therefore be prohibited by
section 7.1.5.1. Without such a definition, 7.1.5.1 is so easily
side-stepped that it seems pointless to me.

What is the correct definition of 'access path' for this rule?
---
[ 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
]