Re: Guru-nizing printing of types

[Alastair Houghton <ajh8 at doc dot ic dot ac dot uk>]

Gabriel Dos Reis wrote:
> 
> Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:
> 
> | On Tue, 16 Nov 1999, Carlo Wood wrote:
> | > Allow me to quote from
> | > http://sourceware.cygnus.com/libstdc++/17_intro/C++STYLE
> | > ...
> | >
> | > Notable areas of divergence from what may be previous local practice
> | > (particularly for GNU C) include:
> | >
> | > 01. Pointers and references
> | >   char* p = "flop";
> | >   char& c = *p;
> | >      -NOT-
> | >   char *p = "flop";  // wrong
> | >   char &c = *p;      // wrong
> |
> | Personally I don't really agree with this. Just consider
> |   int *j, k;
> |   int* m, n;
> | where in the first line it is clear that k is *not* a pointer, while
> | the second is misleading in that n appears to be a pointer.
> 
> Well, this is the classic one.  One declaration per line is an
> accepted established pratice.

One declaration per line is all very well, but when you've
got lots of variables to declare it makes the program
a lot longer and more difficult to read.

I agree with Gerald. I think that whoever started this fad
of putting the '*' and '&' characters on the type (to which
they are *not* attached) rather than the variable name was
being silly. If people really want this sort of thing,
they could always use Pascal instead ;-).

Besides, if you read "char *p" as meaning that "the thing
pointed to by p is a char" (and in general, the expression
"*p" as "the thing pointed to by p"), the meaning is
always clear. The same goes for "char &c", meaning that
"the thing referred to by c is a char" - though of course
the expression "&c" means "the address of c" in this case.

Microsoft use the newer style all over the place, and as
a result they have several bugs in their function
declarations, where people have put const (or other modifiers)
in the wrong place (e.g. "char* const" instead of "const char *" -
though their problems are more contrived due to the large number
of preprocessor macros and user-defined types involved).

I don't think it's good practice to space code in a way
that is contradictory to the compiler's interpretation
of it. No matter who advocates it.

> | In any case, all of us seem to agree that this should be controlled by
> | a command-line option, the question being ``What is the default?''...
> 
> I suggested the default be the proposed change when the driver is
> invoked as 'g++'.

This could be a contentious issue; personally I'd rather
the proposed change *wasn't* the default (I like it the
way it is). But obviously it's weight of opinion that
counts in the end (and the bloody minded amongst us are
always free to hack our specs files ;-)).

____________________________________________________________
Alastair Houghton                              ajh8@ic.ac.uk
(ISE 4)                             Imperial College, London