By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,918 Members | 2,279 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,918 IT Pros & Developers. It's quick & easy.

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

P: n/a
What does it mean:

int (*a)[10];
Jul 22 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a

"Quick Function" <qu******@yahoo.com> wrote in message
news:21**************************@posting.google.c om...
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).
Jul 22 '05 #2

P: n/a
Quick Function wrote in
news:21**************************@posting.google.c om 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] = i;

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

Rob.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #3

P: n/a

int (*a)[10];


'a' points to an array of 10 intergers:


At least eleven? [0...10]
Jul 22 '05 #4

P: n/a
"Gernot Frisch" <Me@Privacy.net> wrote in message
news:2n************@uni-berlin.de...

int (*a)[10];


'a' points to an array of 10 intergers:


At least eleven? [0...10]


Nope. 0..9
Jul 22 '05 #5

P: n/a
>
for ( int i = 0; i < 10; ++i ) std::cerr << array[i] << '\n';
}

Rob.

sorry, it isn't on topic;
what is difference between cerr and cout ??
thanks,
Jul 22 '05 #6

P: n/a
In message <x_****************@newssvr29.news.prodigy.com>, Mabden
<mabden@sbc_global.net> writes
"Gernot Frisch" <Me@Privacy.net> wrote in message
news:2n************@uni-berlin.de...

> > 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.

;-)

--
Richard Herring
Jul 22 '05 #7

P: n/a
pvsp wrote:

for ( int i = 0; i < 10; ++i ) std::cerr << array[i] << '\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.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #8

P: n/a
pvsp wrote in news:11**************************@posting.google.c om in
comp.lang.c++:

for ( int i = 0; i < 10; ++i ) std::cerr << array[i] << '\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.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #9

P: n/a

"Richard Herring" <ju**@[127.0.0.1]> schrieb im Newsbeitrag
news:rA**************@baesystems.com...
In message <x_****************@newssvr29.news.prodigy.com>, Mabden
<mabden@sbc_global.net> writes
"Gernot Frisch" <Me@Privacy.net> wrote in message
news:2n************@uni-berlin.de...


> > 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 ;)

Jul 22 '05 #10

P: n/a
Gernot Frisch wrote:

"Richard Herring" <ju**@[127.0.0.1]> schrieb im Newsbeitrag
news:rA**************@baesystems.com...
In message <x_****************@newssvr29.news.prodigy.com>, Mabden
<mabden@sbc_global.net> writes
"Gernot Frisch" <Me@Privacy.net> wrote in message
news:2n************@uni-berlin.de...
>
>
> > > 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 ...
I'd suggest read asscess
only ;)

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #11

P: n/a
> > 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... :))
Jul 22 '05 #12

P: n/a
Gernot Frisch wrote:
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 :-)

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #13

P: n/a
Gernot Frisch wrote in news:2n************@uni-berlin.de 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.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #14

P: n/a
In message <2n************@uni-berlin.de>, Gernot Frisch
<Me@Privacy.net> writes
> 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.
--
Richard Herring
Jul 22 '05 #15

P: n/a

"Rob Williscroft" <rt*@freenet.co.uk> wrote in message
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.

Jul 22 '05 #16

P: n/a
Ron Natalie wrote in news:41**********************@news.newshosting.com
in comp.lang.c++:

"Rob Williscroft" <rt*@freenet.co.uk> wrote in message
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.


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

Rob.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.