Re: These are identical, right? char const* and const char*

From: Hattuari (susudata_at_setidava.kushan.aa)
Date: 03/22/04 

Date: Sun, 21 Mar 2004 19:47:28 -0500

Leor Zolman wrote:

> On Sun, 21 Mar 2004 16:14:36 -0500, Hattuari <susudata@setidava.kushan.aa>
> wrote:

>>The answere was on page 96 of TC++PL, SE. Is there any semantic
>>difference between the two forms?
>
> None. There are a slew of type specifiers that can appear adjacently in
> any
> order without affecting the semantics. Some orderings tend to be used
> more than others; you won't see too many programs written with lines like:
> int unsigned i = 20u;
> but it is perfectly legal.

This is something Java quashed early on. A bit of personal experience might
explain my opinion on this matter. When I was young, I learned that it
didn't matter which order I did certain mathematical calculations. I
thought that was an interesting proposition, do I established the habit of
not doing my calculations in any order other than following rules of
precedence. Not until I was in my 30s did I realize this had been a
mistake. I should have established a uniform system of working left to
right if precedence didn't override the rule.

And a specific incident comes to mind as well. I was working with a very
brillian man who had a PhD in Computer Science from Cal. Berkely. I was
designing a user interface and showed it to him. I explained that they
could do it this way, or that way, or ... He asked why. My response was
that it gave the user flexibility. Again he asked why. I couldn't answer.
Then he said all I was accomplishing was to make my job and the user's job
more confusing.

"If it is suffixed by u or U, its type is the first of these types in which
its value can be represented: unsigned int, unsigned long int. If it is
suffixed by l or L, its type is the first of these types in which its value
can be represented: long int, unsigned long int. If it is suffixed by ul,
lu, uL, Lu, Ul, lU, UL, or LU, its type is unsigned long int."

And my opinion is Dr. Jim was right!

> Dan Saks has been on a fairly lonely crusade
> pushing for cvr-qualifiers such as "const" to appear to the /right/ of the
> type they're modifying, so that the declarations can be read "naturally"
> from right-to-left:
>
> char const* c1; // c1 is a pointer to const char
>
> (Bjarne makes that very point at the bottom of page 96).
>
> Occasionally one even sees Dan's style in use ;-) (Dan is a buddy of mine
> and I kid him about this all the time, not because it isn't a good idea,
> but because it seems to me that getting folks to change old habits like
> that without offering a "bigger" payoff is a losing battle...)

And I understand there is a bounty on my head put up by veteran Mathematica
users because I persuaded wri to change the functionality of of the alt and
ctrl keys so it matched the other tools on my Linux desktop, as well as the
standard of Microsoft desktop. And I still have a hard time adjusting to
what I asked for.

What would Dan say about imposing specific ordering on all cv-qualifier and
type specifiers, etc? Please note very carefully that I was not fool
enough to actually articulate that reasonable proposal as a genuine
proposal.
 
> So did you have any questions about the code below?

No. I was just representative of the experimentation I had done to
demonstrate what the declarations seemed to mean. 

-- 
p->m == (*p).m == p[0].m

Relevant Pages

  • Re: conditional operator
    ... int main ... In C99, it's no longer strictly necessary for main, but it would be for most other functions that return a value, so it's a good idea to make a habit of it. ... this is described in terms of precedence of operators; so you would say that conditional operator has a higher precedence than the assignment operator. ...
    (comp.lang.c)
  • Re: These are identical, right? char const* and const char*
    ... There are a slew of type specifiers that can appear adjacently in ... Some orderings tend to be used ... One thing I actually like about teaching Java is that when anyone asks why ... unsigned int, ...
    (comp.lang.cpp)
  • Re: Why not auto?
    ... >> int only for functions, not for objects, but I might be mistaken. ... >> just took a quick look through the C90 standard and didn't find ... Each list of type specifiers shall be one of the following sets ... the type signed int may ...
    (comp.lang.c)
  • Re: What is the right interpretation?
    ... The type "long int" followed by the type long ... I want to be clear that I'm not claiming that this is the only possible algorithm, or even the best algorithm, merely that any conforming implementation of C must interpret type specifiers in the same way that this algorithm does. ...
    (comp.std.c)
  • Re: is order urgent doubt
    ... jacob navia wrote, On 03/06/08 21:24: ... (delimited by commas, when there is ... more than one set on a line); the type specifiers may occur in any order, ... And why is not long int, ...
    (comp.lang.c)