Jeff Greif wrote in message ...
>
>It appears that at least one compiler treats the type const PString,
>defined by
>typedef char* PString;
>as char const *, hence differently from the type CPString, defined as
>typedef const char* CPString;

I suspect you mean "as char* const"; "char const *" and "const char*"
are one and the same thing -- "char* const" is a different thing.

Anyway, yes: a "const PString" is a PString (a pointer) that does
not vary -- nothing is said that stops _what it points to_ from
varying.  Hence, "const PString" == "char* const" != "cons char*".



Alex



-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
 http://www.newsfeeds.com/       The Largest Usenet Servers in the World!
-----------== Over 66,000 Groups, Plus  a  Dedicated  Binaries Server ==----------


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

It appears that at least one compiler treats the type const PString,
defined by
typedef char* PString;
as char const *, hence differently from the type CPString, defined as
typedef const char* CPString;

Is this correct according to the standard (I could not find relevant chapter
and verse)?

Here is an example showing the failure:


#include <vector>

/*  This does not compile
 *   in MSVC++ 5.0 SP2 -- complains about duplicate definitions of
 *  allocator::address(), presumably for pointer
allocator::address(reference) and
 *  const_pointer allocator::address(const_reference)

typedef char* PString;
typedef std::vector<const PString, std::allocator<const PString> > HCList;

HCList zork;
*/

/* This compiles */
typedef const char* CPString;
typedef std::vector<CPString, std::allocator<CPString> > CHCList;

CHCList czork;





[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Jeff Greif" <jmg@spam-me-not.trivida.com> writes:

>It appears that at least one compiler treats the type const PString,
>defined by
>typedef char* PString;
>as char const *, hence differently from the type CPString, defined as
>typedef const char* CPString;

>Is this correct according to the standard (I could not find relevant chapter
>and verse)?

It's required by the standard.

If T is the name of a type,
    const T p;
means the same as
    T const p;

If you write
    typedef char* PString;
    const PString p;
    PString const q;
then p and q have the same type.  That is, the const does not
"penetrate" the typedef.

Writing
    const char* p;
is entirely different. The * attaches to the p, so p points to a
const char.

There is no special rule in the standard to cover this situation.
It just falls out of the declaration grammar, and is the same in C
and C++.

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 9 Jan 1999 17:41:09 GMT, Jeff Greif <jmg@spam-me-not.trivida.com> wrote:

>It appears that at least one compiler treats the type const PString,
>defined by
>typedef char* PString;
>as char const *, hence differently from the type CPString, defined as
>typedef const char* CPString;
>
>Is this correct according to the standard (I could not find relevant chapter
>and verse)?

Yes, this is correct.

1. The statement "const T" is equivalent to "T const"
2. 'const' protects whatever is to its left
3. Example:
      int const * *const pp;
         //   pp can't be changed (or reseated)
         //  *pp can   be changed
         // **pp can't be changed
4. So "const T" or "T const" just adds a top-level const
   (i ) if T is an object type, the object is const
   (ii) if T is a pointer type, the pointer only is made const
   (iii) if T is a reference type, the 'const' has no effect
5. Therefore
         const PString
      == PString const
      == char * const



>Here is an example showing the failure:

Not a failure.  The compiler can't assume that you want to const
qualify the pointed to object, because in general, this may not
be what you want.  So the compiler only const qualifies the top
level consts.

Interestingly, if you have a class X that has a field "char * x",
then in a constant member function of X, this data field has
type "char *const x".  So the stuff 'x' points to can always be
changed, even in a const member function!  This is physical
constness, as opposed to logical constness.  You can use it to
your advantage, but you also have to be careful.


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

typedef char * PString;

does not exist in the standard. It just exists in VC++.

Jeff Greif wrote:

> It appears that at least one compiler treats the type const PString,
> defined by
> typedef char* PString;
> as char const *, hence differently from the type CPString, defined as
> typedef const char* CPString;
>
> Is this correct according to the standard (I could not find relevant chapter
> and verse)?
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
> It's required by the standard.
>
> If T is the name of a type,
>     const T p;
> means the same as
>     T const p;
>
> If you write
>     typedef char* PString;
>     const PString p;
>     PString const q;
> then p and q have the same type.  That is, the const does not
> "penetrate" the typedef.
>
> Writing
>     const char* p;
> is entirely different. The * attaches to the p, so p points to a
> const char.
>
> There is no special rule in the standard to cover this situation.
> It just falls out of the declaration grammar, and is the same in C
> and C++.

Note that a similar situation:

typdef char Array[5];

const Array a;

does not quite do the same thing according to the standard.  This is
equivalent to:

const char a[5];

The reason for this is that a "constant array" doesn't make sense, but
an array of constants does.  This is a small trap, and can mislead the
unwary, since the following code is in error:

typedef char Array[5];
const Array a;
typedef char *CharPtr;
const CharPtr cp = a; // illegal

This is because cp is a 'char * const', while the use of the array name
a devolves to 'const char *'.

--
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <GDzl2.1132$fy2.109445209@dca1-nnrp1.news.digex.net>, Jeff
Greif <jmg@spam-me-not.trivida.com> writes
>typedef char* PString;
>typedef std::vector<const PString, std::allocator<const PString> > HCList;

const PString is equivalent to char * const  (this is one reason that
Dan Saks has been campaigning for some time for programmers to add cv
qualifications after the basic type name - that way you are less likely
to be bitten by this)

As toplevel const's must be initialised, I guess that is the reason the
compiler is spitting it back at you.

>
>HCList zork;
>*/
>
>/* This compiles */
>typedef const char* CPString;
>typedef std::vector<CPString, std::allocator<CPString> > CHCList;
>
>CHCList czork;
>

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Edward Diener <eddielee@abraxis.com> writes:

>typedef char * PString;

>does not exist in the standard. It just exists in VC++.

But any user of any C++ implementation can write the declaration
 typedef char * PString;
because the C++ standard does not predefine or reserve the name
PString.

Whether VC++ provides such a declaration in one of its headers
has no bearing on the orginal question.

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 10 Jan 99 16:10:11 GMT, Jonathan Biggar <jon@floorboard.com> wrote:

>Steve Clamage wrote:
>> It's required by the standard.
>>
>> If T is the name of a type,
>>     const T p;
>> means the same as
>>     T const p;
>>
>> If you write
>>     typedef char* PString;
>>     const PString p;
>>     PString const q;
>> then p and q have the same type.  That is, the const does not
>> "penetrate" the typedef.
...
>
>Note that a similar situation:
>
>typdef char Array[5];
>
>const Array a;
>
>does not quite do the same thing according to the standard.  This is
>equivalent to:
>
>const char a[5];


If you get that result, your compiler is in error. There is no such
special case for arrays.

An array name decays to a pointer to its first element in an
expression, and in a few other contexts, but not when used in a
typedef.

The type of Array above is "array of 5 chars", and the "const" in your
example applies (unnecessarily) to the "a", not to the array elements.

You can see this is the case by comparing typeid's.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
> >Note that a similar situation:
> >
> >typdef char Array[5];
> >
> >const Array    a;
> >
> >does not quite do the same thing according to the standard.  This is
> >equivalent to:
> >
> >const char a[5];
>
> If you get that result, your compiler is in error. There is no such
> special case for arrays.
>
> An array name decays to a pointer to its first element in an
> expression, and in a few other contexts, but not when used in a
> typedef.
>
> The type of Array above is "array of 5 chars", and the "const" in your
> example applies (unnecessarily) to the "a", not to the array elements.

Sorry, but I think you are wrong.  Check the example at the end of
paragraph 1 of section 8.3.4:

    typedef int A[5], AA[2][3];
    typedef const A CA;   // type is "array of 5 const int"

The text of the paragraph explicitly states that:

 Any type of the form "cv-qualifier-seq array of N T" is adjusted to
 "array of N cv-qualifier-seq T".

--
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

stephen.clamage@sun.com (Steve Clamage) writes:
>On 10 Jan 99 16:10:11 GMT, Jonathan Biggar <jon@floorboard.com> wrote:
>>
>>Note that a similar situation:
>>
>>typdef char Array[5];
>>
>>const Array a;
>>
>>does not quite do the same thing according to the standard.  This is
>>equivalent to:
>>
>>const char a[5];

>If you get that result, your compiler is in error. There is no such
>special case for arrays. ...

>The type of Array above is "array of 5 chars", and the "const" in your
>example applies (unnecessarily) to the "a", not to the array elements.

As several people pointed out to me, I got that one wrong.
Jonathan was correct.

I apologize for any confusion I may have caused.

The special case is for "const" applied to array types or objects,
including typedefs. The "const" always modifies the array element
type, and does not modify the top-level array object. In the case
of arrays of arrays, the const also modifies the subarray objects
in addition to the ultimate array elements. (Weird, huh?)

--
Steve Clamage, stephen.clamage@sun.com


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <369AA5AB.A855BC5F@floorboard.com>,
  Jonathan Biggar <jon@floorboard.com> wrote:
> > >typdef char Array[5];
> > >const Array    a;
[...] is equivalent to:
> > >const char a[5];
> >
> > If you get that result, your compiler is in error. There is no such
> > special case for arrays.
> > The type of Array above is "array of 5 chars", and the "const" in your
> > example applies (unnecessarily) to the "a", not to the array elements.
>
> Sorry, but I think you are wrong.  Check the example at the end of
> paragraph 1 of section 8.3.4:
>
>     typedef int A[5], AA[2][3];
>     typedef const A CA; // type is "array of 5 const int"
>
> The text of the paragraph explicitly states that:
>
>  Any type of the form "cv-qualifier-seq array of N T" is adjusted to
>  "array of N cv-qualifier-seq T".

Also, from section 3.9.3 p2: "All cv-qualifiers applied to an array
type affect the array element type, not the array type (8.3.4)."

---
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]