1) Is incomplete type specification related to C++ only?

see the following snippet.

[root@protos tmp]# cat test.c
#include <stdio.h>

int foo[3] = {0, 1, 2};

int main(void)
{
     int i;
     extern int foo[];

     for (i = 0; i < 3; i++)
     {
         printf("%d\n", foo[i]);
     }

     return 0;

using namespace std;

int foo[3] = {0, 1, 2};

int main(void)
{
     int i;
     extern int foo[];

     for (i = 0; i < 3; i++)
     {
         cout << foo[i] << endl;
     }

     return EXIT_SUCCESS;

As you can see, extern int foo[] succeeds in test.c, but throws an
error in test.cpp. Does that mean 'incomplete type error' is
related to C++ only?

2) Why the compiler can't find the size information?

See the code.

[root@protos tmp]# cat test.cpp
#include <iostream>

using namespace std;

int foo[3] = {0, 1, 2};

int main(void)
{
     int i;
     extern int foo[];

     for (i = 0; i < 3; i++)
     {
         cout << foo[i] << endl;
     }

     return EXIT_SUCCESS;

Here, I know that extern in foo[] is invalid due to C++
specification. IMHO, however, everyone knows that extern int foo[]
actually means the in foo[3] array defined globally. That means
that the size information is known when we see extern int foo[].

Let me think from the perspective of a compiler. 'int foo[3]' precedes
'extern int foo[]' in the code. So, it is manifest that any compiler
will see the int foo[3] definition before it sees the 'extern int
foo[]'.
That means that the extern int foo[] is complete; it's size information

is known in advance. If the lines of my reasoning is true, why does the

compiler raise an error?

3) Why is the size information needed?

Let's think about the code in item 2. In the code, the size of foo
array is 3. And I also hardcoded the size of array, 3, in the for
loop: i < 3. That means the size information is not needed because
C/C++ programmers are responsible for the specifying correct size
information like the aforementioned code.

C/C++ does not perform boundary check like JAVA or C#, but the C++
specification requires that the size information should be informed to
the compiler. Why the specification postulate that the unneeded
information should be provided?

Regards,
Minkoo Seo.

On the other hand, every version of g++ I tried gave the same
error message.  From what I understand, g++ underwent a major
rewrite between versions 2.95.3 and 3.0.  Enough of a rewrite to
suppose that if the behavior is the same in both 2.95.2 and in
more recent versions, it is intentional.  And on checking the
standard (§8.3.4/1), there is a sentence: "The type
'derived-declarator-type-list array of N of T,' is a different
type from the type 'derived-declarator-type-list array of
unknown bound of T.'"  In addition, in §3.9/7, it says "The
declared type of an array object might be an array of unknown
size and therefore be incomplete at one point in a translation
unit and complete later on; the array types at those two points
('array of unknown boudn of T' and 'array of N T') are different
types."

On the other hand, there is no doubt that:

     extern int foo[] ;
     //  ...
     int foo[ 3 ] ;

is legal.  The only difference here is in the order in which the
compilers see the declarations.

Traditionnally, and I believe that this is probably the intent
as well, compilers have maintained a list of the information
concerning the variable as they went along.  If the total
information included the dimension data, the type was complete;
if not, it wasn't.  Regretfully, the actual wording of the
standard says that the type may be completed *later*, not that
it may be completed *elsewhere*.  Interestingly enough, the C
standard shares the same problem (§6.2.5/22): "An array type of
unknown size is an incomplete type.  It is completed, for an
identifier of that type, but specifying the size *in* *a*
*later* declaration."  Taken (too ?) literally, there is a
problem in the C code as well.

My immediate reaction is that this is just a case of sloppy
wording, and that the real intention must be that once a type is
complete, it remains complete, even if later declarations would
only be of an incomplete type.  But I have to admit that the
reason that this is "obvious" to me is 25 years of experience
with C and C++ compilers, and not any words I can find in the
standard.

     [...]

  -- once the type is complete, it remains complete, even through
     a declaration which would be for an incomplete type, and

  -- once the type is complete, it can no longer be declared
     incomplete, since this would have the effect of changing a
     complete type into an incomplete type, a transformation for
     which the standard makes no provisions.

Personally, only the first interpretation makes any real sense
to me.  But apparently, the authors of g++ disagree, and have
implemented the second.  Interestingly enough, in this case,
they also disagree with the authors of gcc, although the rule is
pretty much the same in the two languages.  Still, the wording
seems ambiguous enough to me that I think a DR would be in
order.

--
James Kanze                                           GABI Software
Conseils en informatique orientée objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[...]

What I am trying to make clear here is the intention of
incomplete type. AFAIK, there are two kinds of incomplete
type that can occur.

1) struct a; // or class a;
2) int array_name[];

The meaning of incomplete type is quite clear when we talk about
the first one, 'struct a', because that's a kind of definition
which lacks the actual definition.

However, incompleteness with regard to the second one,
int array_name[], does not make sense to me. The reason why the
second one is incomplete is that the size of the array is unknown.

As I mentioned previously, however, compilers do not need to know the
'size' of an array in C/C++, because keeping size information is
entirely up to programmers.

Why the second type of declaration was sentenced to be incomplete
in the standard?

Regards,
Minkoo Seo

If you put "extern int foo[3] = {0, 1, 2};" into another file, then
g++ had no problem. If there is a problem of g++, I think the problem
is the interpretation of "extern".

g++ looks for the foo[] definition within the file and reports the
type mismatch between foo[] and foo[3]. If g++ left the look-up to the
linker, then g++ would not have any problem. I do not know what the
Standard says about this.

[...]

[...]

extern int foo[]; // OK
int foo[]={1,2,3};
extern int foo[]; // OK

void bar(){
  extern int foo[]; // g++: ERROR -- SHOULD BE OK

Regards,
Vladimir Marko

1) extern int foo[3] = {0, 1, 2};
is a definition of foo and not just a declaration. In effect the
'extern' is largely ignored.

2) That does not help if you are using sizeof or a template that needs
the complete type. (or I do not think it does)
--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

int foo[3];
int main(){
   extern int foo[];
   sizeof(foo);

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

1)
Does it conform to standard to say that 'the type of int array_name[]
is different from int array_name[3]'?

AFAIK, incomplete type like int array_name[] become completed after
a compiler sees the definition int array_name[3]. I also believe
that such a completing process render [] and [3] everything but a
*disparate types*.

2)
As to the original question of the first posting:

int array_name[3];

int main()
{
   extern int array_name[];
    ...

But, opposed to my reasoning, g++ raise an error when above code
is compiled. What's the things that I don't understand here?

Regards,
Minkoo Seo

I understand the following currently working g++&#12288;code would
brake. It seems that the code is strange and a surprise to me, but if
such codes as below are useful, I should give up my idea.

#include <iostream>

using namespace std;

class C {
   int i;

      cout << sizeof(c) << endl;

      return EXIT_SUCCESS;

And this seems to really be the case with g++: if you inverse
the order of the definitions of main and foo in his function,
g++ compiles it.

    int foo[3] ;
    extern int foo[] ;

causes no problems in g++ either.  The problem only occurs if
the extern is in a function (a nested scope).  And of course, if
you write "struct A;" in a function, you have declared a new,
function local type, and have not named the previously completed
type defined at namespace scope.

(I know what I intuitively want it to be, which is pretty much
what you seem to think it should be.  But what I intuitively
want, and what the standard says, are often two different
things.)

--
James Kanze                                           GABI Software
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

(Note that in the case of g++, scope makes a difference:

    int foo[ 3 ];
    extern int foo[] ;

is perfectly legal, but putting the second declaration in a
function makes it illegal.  Which makes me suspect that making
it illegal is an accidental bug in g++, and not intentional.)

Seriously: put your extern's and incomplete types at namespace
scope in a header file.  Make sure that the header is included
before any definition, and you shouldn't have any problems.  As
for understanding... since it's not at all clear what the
standard really says, the only solution is to join the committee
and help define it.

--
James Kanze                                           GABI Software
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

That is, I think, part of the problem.  When you say "struct C",
you name a type.  A single, unique type (at least in the
relevant scope).  Whether that type is complete or not is only a
question of what the compiler knows about that type.  When you
say "int a[]", you do not name a type.  You are dealing with a
derived type, which doesn't have a simple name.  And there are
an infinite number of different concrete types which may be used
for the definition.  Which causes problems for things like
function overload resolution and template instantiation, where
you need to know the exact type, even if you don't need to know
anything about it.

--
James Kanze                                           GABI Software
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Beyond that, of course, you are right in that the three types of
incomplete types are incomplete in different ways, which results
in different constraints.  In this case, the most important
difference (and the one which is causing the problems), is that
the incomplete type 'struct a' is a placeholder for exactly one
type.  We may not have all of the information concerning that
type, but we do know how to 'name' it (e.g. as in name
mangling).  In the case of 'int a[]', the "incomplete type" is
in fact a placeholder for a set of types, and a priori, we don't
know how to name it.  Except that in certain uses, we have to be
able to name it:

    template< typename T > vod f( T& a ) ;
    extern int a[] ;

    f( a ) ;        //  legal, but how to instantiate f?

I presume that this is the motivation for saying that the
incomplete type in this case is a distinct type.

Given your initial code:

    int foo[ 3 ] = { 0, 1, 2 } ;

    int
    main()
    {
        extern int foo[] ;
        cout << typeid( foo ).name() << std::endl ;
        return 0 ;
    }

I see three possible interpretations: it's an error, the type of
foo in the typeid is an array[unknown] of int, and the type
of foo in the typeid is an array[3] of int.  Intuitively, I
would expect that latter -- of the three compilers I have at
hand (Sun CC, g++ and VC++), g++ treats it as an error, and the
other two accept it, and treat it as array[unknown] of int.

If I modify the code to be C (using sizeof, instead of typeid),
I get an error from gcc, a warning from Sun cc, and the
generated code outputs 0, and VC++ accepts it fine, and outputs
12.  Intuitively, I would go with the behavior of VC++ for C,
but the standard does seem a bit vague as to what is to be
expected.

The problem, in my mind, is more why it doesn't behave like the
other incomplete types; I suspect that it has to do with the
fact than an incomplete class has a name, which gives the type
itself scope.  And any attempt to declare the type in a
different scope actually declares a new type -- there's no way
to apply the extern modifier to the name of a class.

Having said that, I think you're right in that we have three
distinct things (arrays of unspecified dimension, class forward
declarations, and void), and calling them all the same thing (an
incomplete type) only leads to confusion.

--
James Kanze                                           GABI Software
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

There are obviously reasons for this, linked at least partially
to the strange beast that arrays are in C++.  The consequence,
however, is that the two cases need to be handled differently in
many contexts.  Consider, for example, the following:

    #include <iostream>
    #include <ostream>

    template< typename T >
    void f( T const* )
    {
        static int i = 0 ;
        std::cout << ++ i ;
    }

    //      incomplete types.
    struct S ;
    extern int a[] ;

    void
    f1()
    {
        f( (S*)0 ) ;
        f( a ) ;
    }

    //      complete the types.
    struct S
    {
        int s1 ;
        int s2 ;
    } ;
    int a[ 3 ] ;

    void
    f2()
    {
        f( (S*)0 ) ;
        f( a ) ;
    }

    int
    main()
    {
        f1() ;
        f2() ;
        return 0 ;
        std::cout << std::endl ;
        return 0 ;
    }

According to the standard, this code should output 1121 -- in
f1, a has the incomplete type int[], and in f2, it has the
complete type int[3].  At least, that is the only reasonable
interpretation I can give to §3.9/7: "The declared type of an
array object might be an array of unknown size and therefore be
incomplete at one point in a translation unit and complete later
on; the array types at those two points are different types."
But I may have missed something; both Sun CC and g++ output 1122
(presumably using the same template instantiation for the
incomplete array in f1 and the complete type in f2).

About all I really feel confident in saying at this point is: 1)
the issue is relatively complex, and 2) the standard is far from
clear about it.  (And in consequence of 2, 3) compilers differ
considerably concerning these points.)

    struct S ;
    extern int a1[] ;
    extern S   a2[ 5 ] ;

Both arrays have incomplete types.  You can, however, index into
the first, but not into the second.

You and I both know that this is because an array converts into
a pointer to the first element, resulting in an int* -- a
complete type -- in one case, and an S* in the other, and that
pointer arithmetic is not allowed on an incomplete type.  And
that indexation is defined in terms of pointer arithmetic.  But
surely you can see that the issue can be confusing to a
beginner.

--
James Kanze                                           GABI Software
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vladimir Marko

3.5/6:

     The name of a function declared in block scope, and the name
     of an object declared by a block scope extern declaration,
     have linkage. If there is a visible declaration of an entity
     with linkage having the same name and type, ignoring entities
     declared outside the innermost enclosing namespace scope, the
     block scope declaration declares that same entity and receives
     the linkage of the previous declaration. If there is more than
     one such matching entity, the program is ill-formed. Otherwise,
     if no matching entity is found, the block scope entity receives
     external linkage.

So, let's have a look on this snippet:

int foo[]={1,2,3};  // (1)

void bar(){
   extern int foo[];  // (2)
   foo[2];  // (3)
   sizeof(foo); // (4)

g++ is wrong to refuse (2) anyway, but the PR's subject may
be wrong.

Regards,
Vladimir Marko

#include <iostream>
#include <istream>
int a[] = {4,5,6};

int main(){
        int a[] = {1,2,3,4};
        {
                extern int a[];
                std::cout << a[2];
        }
        std::cout << a[2];

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

Vladimir Marko

At least, I'm happy that at least one compiler agrees with my
reading of the standard:-).

--
James Kanze                                           GABI Software
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

--
James Kanze                                           GABI Software
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

--
James Kanze                                           GABI Software
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34