C++Talk.NET

Le Chaud Lapin · Guest

Hi All,

I mentioned in a concurrent post that I am testing Microsoft's new
Visual C++ express compiler on a large code base. I got thousands of
errors on code I thought was mostly "pure" C++, as it compiled without
complaint with Visual C++ 7.1. The errors are my fault - looking at
top of page 394, TCPPPL 3rd Ed., it states (more or less), that you
cannot, for example, do things like this:

struct Outer
{
struct Inner
{
} ;
} ;

using Outer::Inner;

Inner i; // not allowed to pull out typename from Outer. must use
explicty qualification:

Outer::Inner i;

One of the other comformance improvements that the new compiler made
was to force explicit attachment of an ampersand (&) to the name of a
member function, if what was meant is to specify the address of the
member function.

Instead of this:

insert (SERVICE_CODE_FILE_BIND,
file_bind);
insert (SERVICE_CODE_FILE_COPY,
file_copy);
insert (SERVICE_CODE_FILE_DESTROY,
file_destroy);
insert (SERVICE_CODE_FILE_FREE,
file_free);

One must write this:

insert (SERVICE_CODE_FILE_BIND,
&file_bind);
insert (SERVICE_CODE_FILE_COPY,
&file_copy);
insert (SERVICE_CODE_FILE_DESTROY,
&file_destroy);
insert (SERVICE_CODE_FILE_FREE,
&file_free);

It's always been my opinion that the second form is better because it
supports more "regular thinking" than the first form. If one intends
to say "the address of the function", even though there appears to be
no use for the name of the function alone in the language, then that
should be what one writes. if I had designed the syntax, I would have
forced inclusion of the ampersand from the outset, because the first
method constitutes a breach in regular thought. It's a somewhat minor
breach, but a breach nevertheless. In any case, it's not minor any
more. I have 260 lines of code that say so.

There is one other important area where this "breach of regular
thinking" is made: arrays.

void foo (char *);

char x[128];

foo (x); // works but represents breach of regular thinking
foo (&x[0]); // more verbose, but concurs with regular thought,
therefore less mental tax

I would not have allowed the first form to mean what it currently
means. IMO, if there is any big, out-in-your-face flaw in C, it's the
help that the compiler gives to you with arrays. How hard is it to
write &x[0]? Only a few more characters, and the benefit from the
consistency is invaluable, especially to beginners. Also, as
programmers, we might have benefited from the semantic distinction that
would have remained:

typedef char Cipher_Block[128];

Cipher_Block x, y;

x = y; // no memcpy necessary. one can almost assume optimality from
compiler.

void bar (Cipher_Block block) // copies the entire block to function,
knows that it must be exactly 128 chars or will issue error

void bar (Cipher_Block &block) // block passed by reference. still must
be 128 chars

You get the idea: subscription to regularity for regularity's sake
will often yield small but benefiical fruit and will almost always have
less mental tax. I do ntot think that no apparent immediate benefit
for maintaining semantic distinction (and gaining optimization in
keystrokes as a result of blurring the distinction) is a good excuse to
deviate from this principle.

-Le Chaud Lapin-

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Alf P. Steinbach · Guest

* Le Chaud Lapin:

Falk Tannhäuser · Guest

Le Chaud Lapin wrote:

Le Chaud Lapin · Guest

Alf P. Steinbach wrote:

Alf P. Steinbach · Guest

* Le Chaud Lapin:

Le Chaud Lapin · Guest

Alf P. Steinbach wrote:

kanze · Guest

Le Chaud Lapin wrote: