Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   const char* vs char const* (http://www.velocityreviews.com/forums/t961105-const-char-vs-char-const.html)

 engineer 05-28-2013 09:30 AM

const char* vs char const*

Hi,

Can someone give me an easy explanation as well as the difference between the following three statements.

const char* p
char const* m
char* const n

thanks
-Ahmed

 Öö Tiib 05-28-2013 10:30 AM

Re: const char* vs char const*

On Tuesday, 28 May 2013 12:30:39 UTC+3, engineer wrote:
> Can someone give me an easy explanation as well as the difference between
> the following three statements.
>
> const char* p
> char const* m
> char* const n

There are no difference between type of 'p' and 'm'. Both are mutable
pointers to immutable char. 'n' is immutable pointer to mutable char.

 Gerhard Fiedler 05-28-2013 11:31 AM

Re: const char* vs char const*

Öö Tiib wrote:

> On Tuesday, 28 May 2013 12:30:39 UTC+3, engineer wrote:
>> Can someone give me an easy explanation as well as the difference between
>> the following three statements.
>>
>> const char* p
>> char const* m
>> char* const n

>
> There are no difference between type of 'p' and 'm'. Both are mutable
> pointers to immutable char. 'n' is immutable pointer to mutable char.

In addition to what Öö wrote: Try to read the type declaration from
right to left, "translating" * with "pointer to", "const" with
"immutable" and considering that an "immutable char" is the same (in
this context) as a "char immutable".

Gerhard

 James Kanze 05-29-2013 10:03 PM

Re: const char* vs char const*

On Tuesday, May 28, 2013 10:30:39 AM UTC+1, engineer wrote:
> Can someone give me an easy explanation as well as the
> difference between the following three statements.

> const char* p
> char const* m
> char* const n

Just apply the general rule: const applies to whatever is
immediately to the left of it. If nothing is to the immediate
left of it, move it to the right until there is something.
Thus:

const char* p; // The same as char const* p (which would be preferable)
char const* m; // (non-const) pointer to const char.
char *const n; // Const pointer to (non-const) char.
char const* const* o; // Const pointer to const char.

In an ideal world, you'd never see the first declaration you
give, as it leads to a great deal of confusion when typedefs are
involved:

typedef char* CPtr;
CPtr const p1; // char *const p1
const CPtr p2; // char *const p2 !!!

--
James

 Jorgen Grahn 05-31-2013 08:33 AM

Re: const char* vs char const*

On Wed, 2013-05-29, James Kanze wrote:
> On Tuesday, May 28, 2013 10:30:39 AM UTC+1, engineer wrote:
>> Can someone give me an easy explanation as well as the
>> difference between the following three statements.

>
>> const char* p
>> char const* m
>> char* const n

>
> Just apply the general rule: const applies to whatever is
> immediately to the left of it. If nothing is to the immediate
> left of it, move it to the right until there is something.
> Thus:
>
> const char* p; // The same as char const* p (which would be preferable)
> char const* m; // (non-const) pointer to const char.
> char *const n; // Const pointer to (non-const) char.
> char const* const* o; // Const pointer to const char.
>
> In an ideal world, you'd never see the first declaration you
> give, as it leads to a great deal of confusion when typedefs are
> involved:
>
> typedef char* CPtr;
> CPtr const p1; // char *const p1
> const CPtr p2; // char *const p2 !!!

I think you're wrong here -- the const cannot "invade" the typedef, so
both p1 and p2 are constant pointers to non-const stuff, like you'd
expect.

Of course, many would say that in ideal world you don't see a lot of
typedef:ed pointers either. They are a source of confusion too.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

 Öö Tiib 05-31-2013 09:05 AM

Re: const char* vs char const*

On Friday, 31 May 2013 11:33:18 UTC+3, Jorgen Grahn wrote:
> Of course, many would say that in ideal world you don't see a lot of
> typedef:ed pointers either. They are a source of confusion too.

Can you describe the situation where those many would say that?

For example: All C++ standard library containers (and some non-containers)
have 'pointer' and 'const_pointer' member typedefs. Some non-containers
have such typedefs as well. Some people ignore these, some use.
Lack of such typedefs (in a weakly made custom container) may cause
inconvenience for people who expect such typedefs ... but what confusion?

 James Kanze 05-31-2013 02:16 PM

Re: const char* vs char const*

On Friday, May 31, 2013 9:33:18 AM UTC+1, Jorgen Grahn wrote:
> On Wed, 2013-05-29, James Kanze wrote:
> > On Tuesday, May 28, 2013 10:30:39 AM UTC+1, engineer wrote:
> >> Can someone give me an easy explanation as well as the
> >> difference between the following three statements.

> >> const char* p
> >> char const* m
> >> char* const n

> > Just apply the general rule: const applies to whatever is
> > immediately to the left of it. If nothing is to the immediate
> > left of it, move it to the right until there is something.
> > Thus:

> > const char* p; // The same as char const* p (which would be preferable)
> > char const* m; // (non-const) pointer to const char.
> > char *const n; // Const pointer to (non-const) char.
> > char const* const* o; // Const pointer to const char.

> > In an ideal world, you'd never see the first declaration you
> > give, as it leads to a great deal of confusion when typedefs are
> > involved:

> > typedef char* CPtr;
> > CPtr const p1; // char *const p1
> > const CPtr p2; // char *const p2 !!!

> I think you're wrong here -- the const cannot "invade" the typedef, so
> both p1 and p2 are constant pointers to non-const stuff, like you'd
> expect.

That's what I said, no?

> Of course, many would say that in ideal world you don't see a lot of
> typedef:ed pointers either. They are a source of confusion too.

I'm tempted to say "wishful thinking". I agree that typedef'ing
pointers is bad policy. But the same problems occur in more
complicated cases, where people are typedef'ing pointers to
member functions, or whatever. (Of course, I would argue that
even then, typedef's cause confusion. But given the syntax,
people do want to do it.)

--
James

 James Kanze 05-31-2013 02:19 PM

Re: const char* vs char const*

On Friday, May 31, 2013 10:05:28 AM UTC+1, Öö Tiib wrote:
> On Friday, 31 May 2013 11:33:18 UTC+3, Jorgen Grahn wrote:
> > Of course, many would say that in ideal world you don't see a lot of
> > typedef:ed pointers either. They are a source of confusion too.

> Can you describe the situation where those many would say that?

> For example: All C++ standard library containers (and some non-containers)
> have 'pointer' and 'const_pointer' member typedefs. Some non-containers
> have such typedefs as well. Some people ignore these, some use.
> Lack of such typedefs (in a weakly made custom container) may cause
> inconvenience for people who expect such typedefs ... but what confusion?

The situation is a bit different there. 'pointer' and
'const_pointer' are *not* necessarily T* and T const*. And the
typedef's are really only for use in template functions; you'd
never use them in cases where you knew the real type.

--
James

 Öö Tiib 05-31-2013 03:41 PM

Re: const char* vs char const*

On Friday, 31 May 2013 17:19:07 UTC+3, James Kanze wrote:
> On Friday, May 31, 2013 10:05:28 AM UTC+1, Öö Tiib wrote:
> > On Friday, 31 May 2013 11:33:18 UTC+3, Jorgen Grahn wrote:
> > > Of course, many would say that in ideal world you don't see a lot of
> > > typedef:ed pointers either. They are a source of confusion too.

>
> > Can you describe the situation where those many would say that?

>
> > For example: All C++ standard library containers (and some non-containers)
> > have 'pointer' and 'const_pointer' member typedefs. Some non-containers
> > have such typedefs as well. Some people ignore these, some use.
> > Lack of such typedefs (in a weakly made custom container) may cause
> > inconvenience for people who expect such typedefs ... but what confusion?

>
> The situation is a bit different there. 'pointer' and
> 'const_pointer' are *not* necessarily T* and T const*.

It is guaranteed to be something that works like pointer. It on most cases
is actually pointer (besides vector<bool> and when using some fancy
allocator).

> And the typedef's are really only for use in template functions;
> you'd never use them in cases where you knew the real type.

It does not always matter that you know the real type. For example
'Names' are typedefed 'std::vector<Name>'. Then it happens that you
need a pointer 'n' to element of 'Names' for whatever reason. The
purpose is cleaner (and maintenance easier) if you declare it as
'Names::pointer' instead of 'Name*' despite you know that these
are very same type.

 James Kanze 06-02-2013 01:40 PM

Re: const char* vs char const*

On Friday, May 31, 2013 4:41:29 PM UTC+1, Öö Tiib wrote:
> On Friday, 31 May 2013 17:19:07 UTC+3, James Kanze wrote:
> > On Friday, May 31, 2013 10:05:28 AM UTC+1, Öö Tiib wrote:
> > > On Friday, 31 May 2013 11:33:18 UTC+3, Jorgen Grahn wrote:
> > > > Of course, many would say that in ideal world you don't see a lot of
> > > > typedef:ed pointers either. They are a source of confusion too.

> > > Can you describe the situation where those many would say that?

> > > For example: All C++ standard library containers (and some non-containers)
> > > have 'pointer' and 'const_pointer' member typedefs. Some non-containers
> > > have such typedefs as well. Some people ignore these, some use.
> > > Lack of such typedefs (in a weakly made custom container) may cause
> > > inconvenience for people who expect such typedefs ... but what confusion?

> > The situation is a bit different there. 'pointer' and
> > 'const_pointer' are *not* necessarily T* and T const*.

> It is guaranteed to be something that works like pointer. It on most cases
> is actually pointer (besides vector<bool> and when using some fancy
> allocator).

The whole point of having the pointer typedef is that it may not
be a pointer. Or it may be some special type of pointer: all of
these typedef's were introduced to support things like __huge
(or whatever it was) on architectures where pointers could be
declared to have different sizes. Without allocators, the
typedef wouldn't be there.

> > And the typedef's are really only for use in template functions;
> > you'd never use them in cases where you knew the real type.

> It does not always matter that you know the real type. For example
> 'Names' are typedefed 'std::vector<Name>'. Then it happens that you
> need a pointer 'n' to element of 'Names' for whatever reason. The
> purpose is cleaner (and maintenance easier) if you declare it as
> 'Names::pointer' instead of 'Name*' despite you know that these
> are very same type.

The code is considerably more readable if you use Name*, rather
than Names::pointer (and if you use std::vector<Name>, rather
than Names). Maintainable is a point of view: using Names
and Names::pointer has the advantage of not requiring any other
changes (hopefully) if you do later change to use a custom
allocator. Otherwise, it's just obfuscation.

--
James

All times are GMT. The time now is 12:00 PM.