What does it mean int (*a)[10]

[Quick Function]

What does it mean:

int (*a)[10];

 

[Dave]

What does it mean:

int (*a)[10];

a is a pointer to an array of 10 ints. So, for example, a++ will increase a
by the size of 10 ints (40 bytes on most platforms, but I can't speak for
yours).

 

[Rob Williscroft]

Quick Function wrote in
in comp.lang.c++:

What does it mean:

int (*a)[10];

'a' points to an array of 10 intergers:

#include <iostream>

int main()
{
int array[ 10 ];
int (*a)[10] = &array;

for ( int i = 0; i < 10; ++i ) (*a) = i;

for ( int i = 0; i < 10; ++i ) std::cerr << array << '\n';
}



Rob.

 

[Gernot Frisch]

int (*a)[10];

'a' points to an array of 10 intergers:

At least eleven? [0...10]

 

[Mabden]

int (*a)[10];

'a' points to an array of 10 intergers:

At least eleven? [0...10]

Nope. 0..9

 

[pvsp]

for ( int i = 0; i < 10; ++i ) std::cerr << array << '\n';
}



Rob.

sorry, it isn't on topic;
what is difference between cerr and cout ??
thanks,

 

[Richard Herring]

int (*a)[10];


'a' points to an array of 10 intergers:

At least eleven? [0...10]

Nope. 0..9

10.5 : you can point at [10] but not access it.

;-)

 

[Karl Heinz Buchegger]

for ( int i = 0; i < 10; ++i ) std::cerr << array << '\n';
}



Rob.

sorry, it isn't on topic;
what is difference between cerr and cout ??
thanks,

cerr is the error output stream
cout is the output stream

On some operating systems it is possible to redirect
output to eg a file. This is handy because then
the program by itself doesn't need to deal with files, but
yet can be used to produce a file (by redirecting
its output into a file). But then it is also possible
to redirect the error stream into a different file, such
that you can easily seperate the real output from the
error messages in different files.

cout is also usually buffered while cerr is not.

 

[Rob Williscroft]

pvsp wrote in in
comp.lang.c++:

for ( int i = 0; i < 10; ++i ) std::cerr << array << '\n';
}



Rob.

sorry, it isn't on topic;
what is difference between cerr and cout ??
thanks,

They are different streams which on most systems go to the same place,
i.e. the "console".

However std::cerr, differs from std::cout in that every time a '\n' char
is sent to it, it calls flush(), so the output should be immediatly
visible (or writen to the file if its been redirected).

For std::cout you need to call flush() (std::cout.flush()) or
alternativly use std::endl (std::cout << std::endl) which sends
a '\n' char and then calls flush() all by itself.

Rob.

 

[Gernot Frisch]

int (*a)[10];


'a' points to an array of 10 intergers:

At least eleven? [0...10]

Nope. 0..9

10.5 : you can point at [10] but not access it.

In a release version you can even access it. I'd suggest read asscess
only

 

[Karl Heinz Buchegger]

int (*a)[10];


'a' points to an array of 10 intergers:

At least eleven? [0...10]

Nope. 0..9

10.5 : you can point at [10] but not access it.

In a release version you can even access it.

You can, but it is undefined behaviour. Just the same
as you would access [11], [12], [13], [14], etc ...

 

[Gernot Frisch]

In a release version you can even access it.

You can, but it is undefined behaviour. Just the same
as you would access [11], [12], [13], [14], etc ...

That's why I'd only try reading - it if at all... )

 

[Karl Heinz Buchegger]

In a release version you can even access it.

You can, but it is undefined behaviour. Just the same
as you would access [11], [12], [13], [14], etc ...

That's why I'd only try reading - it if at all... )

No 'if at all'.
Even reading is illegal

 

[Rob Williscroft]

Gernot Frisch wrote in in comp.lang.c++:

In a release version you can even access it.

You can, but it is undefined behaviour. Just the same
as you would access [11], [12], [13], [14], etc ...

That's why I'd only try reading - it if at all... )

Reading is accessing, reading is UB, don't read (aka access) an object
beyond the end of an array (or any other container for that matter).

If your compiler lets you "Get Away With It(tm)" today it may not
tomorrow, its UB anything can, and by Murphy's Law will, happen.

Rob.

 

[Richard Herring]

In a release version you can even access it.

You can, but it is undefined behaviour. Just the same
as you would access [11], [12], [13], [14], etc ...

That's why I'd only try reading - it if at all... )

Reading is still access and therefore UB.

 

[Ron Natalie]

However std::cerr, differs from std::cout in that every time a '\n' char
is sent to it, it calls flush(), so the output should be immediatly
visible (or writen to the file if its been redirected).,

Actually, cerr has unitbuf set. Every output operation is flushed.
There is no "linebuffering" mode defined in C++ although some
non-unibuf stream implementations work that way on terminals.

 

[Rob Williscroft]

Ron Natalie wrote in in comp.lang.c++:

Actually, cerr has unitbuf set. Every output operation is flushed.
There is no "linebuffering" mode defined in C++ although some
non-unibuf stream implementations work that way on terminals.

Thanks, this is a detail I should have remembered, its been said here
enough times .

Rob.