Cade Roux (cade@ix.netcom.com) wrote:
: In <jzipnick-2104951023280001@jzipnick.vip.best.com> jzipnick@best.com
: (Jay Zipnick) writes:
: >
: >The following code compiles with six compilers, but intentionally does
: not
: >compile with an upgrade to one of the compilers due to a change in the
: >draft ANSI standard. Can someone explain why this change was made!
: >-----
: >class foo;
: >
: >void f1(int* arr);    // compiles OK
: >void f2(int  arr[]);  // compiles OK
: >void f3(foo* arr);    // compiles OK
: >void f4(foo  arr[]);  // doesn't compile with *new* version of one
: compiler!!
: >-----

: <snip'ed a lot of stuff>

: >
: >*Bottom line* This seems like a step backward. I don't know why it was
: >done. It breaks code. It will cause less than optimal work arounds.
: Can
: >someone who knows why this was done please explain the rationale.

: It's legal C - it saves declaring somthing as a fixed length argument
: array, and looks more like an array - when it's actually passed as a
: pointer, right?

: Something funny's up - which compiler are you having trouble with it
: on?

It may be legal C (not sure) but he is right that it is not
legal C++.  The draft does not allow a function param to be
a pointer or reference to an incomplete type.  So the problem
should not be able to be fixed by changing [] to *.

Why?  Can't say at the moment.

-- Joshua Allen

In <jzipnick-2104951023280001@jzipnick.vip.best.com> jzipnick@best.com
(Jay Zipnick) writes:
>
>The following code compiles with six compilers, but intentionally does
not
>compile with an upgrade to one of the compilers due to a change in the
>draft ANSI standard. Can someone explain why this change was made!
>-----
>class foo;
>
>void f1(int* arr);    // compiles OK
>void f2(int  arr[]);  // compiles OK
>void f3(foo* arr);    // compiles OK
>void f4(foo  arr[]);  // doesn't compile with *new* version of one
compiler!!
>-----

<snip'ed a lot of stuff>

>
>*Bottom line* This seems like a step backward. I don't know why it was
>done. It breaks code. It will cause less than optimal work arounds.
Can
>someone who knows why this was done please explain the rationale.

It's legal C - it saves declaring somthing as a fixed length argument
array, and looks more like an array - when it's actually passed as a
pointer, right?

Something funny's up - which compiler are you having trouble with it
on?

--
| Cade Roux
| New Orleans, LA -- 73733.1014@compuserve.com -- cade@ix.netcom.com

The following code compiles with six compilers, but intentionally does not
compile with an upgrade to one of the compilers due to a change in the
draft ANSI standard. Can someone explain why this change was made!
-----
class foo;

void f1(int* arr);    // compiles OK
void f2(int  arr[]);  // compiles OK
void f3(foo* arr);    // compiles OK
void f4(foo  arr[]);  // doesn't compile with *new* version of one compiler!!
-----

According to the compiler architect it shouldn't compile:

     "void f4(foo  arr[]);" is illegal because foo is incomplete. This is
     not really clear in the ARM but [ANSI C++ draft 01 Feb 1995 8.3.4
     Arrays] says:

     "In a declaration T D where D has the form "D1 [ const-expr(opt) ]"
     ... . T shall not be a reference type, an incomplete type, ...".

This is a surprise. It also seems like it is a step backward:

*1* It will break a lot of code (it broke mine)!

*2* It may lead to making hidden implementation details public (the
situation I ran into):

in .h file:
-----
class SystemMap;    // forward class declaration of "hidden" class

class xyz
    {
    public:  // details omitted
    private:
        int ProcessMap(SystemMap map[]);  // <--Now illegal: new ANSI rules!
    };

in .c file:
-----
// intentionally private implementation detail
// *not* in .h file for all to see!
class SystemMap
    {  // details omitted
    };

int  xyz::ProcessMap(SystemMap map[]) { ... }
-----
This scenario, where a private function will take an array of some type
that is intentionally forward declared instead of being included in the
public interface is not too uncommon. Yet this type of code is now
allegedly illegal under [ANSI C++ draft 01 Feb 1995 8.3.4 Arrays].

A wrapper class can be made to work around this, but that is rather
tedious and inefficient.

*3* Alternatively I can switch to pointer syntax:
    //ProcessMap(SystemMap map[]);    // Now illegal under new ANSI rules!
    ProcessMap(SystemMap* map);       // legal, but less clear

but doing this violates a number of style guidelines, including the one I
follow:

"Use [] instead of * for arrays in argument lists, because it is clearer."

*Bottom line* This seems like a step backward. I don't know why it was
done. It breaks code. It will cause less than optimal work arounds. Can
someone who knows why this was done please explain the rationale.