c++ type system

[Looney]

template
<
typename T,
unsigned int size

>

void DoStuff1(
T (& array)[size]
)
{}

template
<
typename T,
unsigned int size

>

void DoStuff2(
T (* array_p)[size]
)
{}

struct Pod
{
int data[10];
};

int main ()
{
Pod pod;
DoStuff1(pod.data); // does not compile why ??
DoStuff2(&pod.data); // this one is fine in comparison to the
above
}

I am just confused as how come a function parameter taking a reference
to an array leads to the data array decaying into a pointer (so type
info is lost and code does not compile), where as the function which
is taking a call parameter of a pointer to an array can compile and
keep on holding the type info.

[Looney]

On Jul 10, 11:01*am, Looney <[e-mail]:

template
<
* * * * typename T,
* * * * unsigned int size

void DoStuff1(
* * * * T (& array)[size]
)
{}

template
<
* * * * typename T,
* * * * unsigned int size

void DoStuff2(
* * * * T (* array_p)[size]
)
{}

struct Pod
{
* * * * int data[10];

};

int main ()
{
* * Pod pod;
* * DoStuff1(pod.data); // does not compile why ??
* * DoStuff2(&pod.data); // this one is fine in comparison to the
above

}

I am just confused as how come a function parameter taking a reference
to an array leads to the data array decaying into a pointer (so type
info is lost and code does not compile), where as the function which
is taking a call parameter of a pointer to an array can compile and
keep on holding the type info.

I do suspect it is due the implicit conversion applied to the array
object to make the reference to the array.
is n't it ?

[Looney]

//---------------------------------------------------------------------------

#include <vcl.h>
#include <windows.h>
#pragma hdrstop

//---------------------------------------------------------------------------

template
<
typename T,
unsigned int size

>

void DoStuff1(
T (& array)[size]
)
{}

template
<
typename T,
unsigned int size

>

void DoStuff2(
T (* array_p)[size]
)
{}

struct Pod
{
int data[10];
};
#pragma argsused
WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow)
{
Pod pod;

int (& arrayref)[10] = pod.data;
DoStuff1(arrayref); // fine it compiles

DoStuff1(pod.data); // does not compile

DoStuff2(&pod.data);// fine it compiles

return 0;
}
//---------------------------------------------------------------------------

[Thomas J. Gritzan]

Looney wrote:

//---------------------------------------------------------------------------

#include <vcl.h>
#include <windows.h>
#pragma hdrstop

[...]

I removed the Borland-specific stuff and shortened the example to:

//---------------------
template <typename T, unsigned int size>
void DoStuff1( T (& array)[size] )
{}

struct Pod
{
int data[10];
};

int main()
{
Pod pod;
DoStuff1(pod.data); // does not compile
return 0;
}
//---------------------

This doesn't compile with the Borland compiler, the error message is:

E2285 Could not find a match for 'DoStuff1<T,size>(int *)'

However, it compiles with GCC and Comeau, and using the array directly
without the struct it compiles with the Borland compiler, too:

int data[10];
DoStuff1(data); // compiles.

I guess it is a compiler error.

--
Thomas

[Looney]

On Jul 10, 12:00*pm, "Thomas J. Gritzan" <[e-mail]>
wrote:

Looney wrote:

//---------------------------------------------------------------------------

#include <vcl.h>
#include <windows.h>
#pragma hdrstop

[...]

I removed the Borland-specific stuff and shortened the example to:

//---------------------
template <typename T, unsigned int size>
void DoStuff1( T (& array)[size] )
{}

struct Pod
{
* * * * int data[10];

};

int main()
{
* * * * Pod pod;
* * * * DoStuff1(pod.data); // does not compile
* * * * return 0;}

//---------------------

This doesn't compile with the Borland compiler, the error message is:

E2285 Could not find a match for 'DoStuff1<T,size>(int *)'

However, it compiles with GCC and Comeau, and using the array directly
without the struct it compiles with the Borland compiler, too:

int data[10];
DoStuff1(data); *// compiles.

I guess it is a compiler error.

--
Thomas

Thanks for summing all of it up much more clearly & precisely.
It does seem bit odd and does indeed look like a compiler error.