asking a question about pointer array.

[rakhshanda.malik]

i want to ask from you that how i can dynamically allocate memory to
double dimmensional arry ?please reply.

 

[Jonas]

i want to ask from you that how i can dynamically allocate memory to
double dimmensional arry ?please reply.

It's in the FAQ: http://c-faq.com/aryptr/dynmuldimary.html

 

[Martin Ambuhl]

i want to ask from you that how i can dynamically allocate memory to
double dimmensional arry ?please reply.

This is a FAQ. You should always check the FAQ for a newsgroup before
posting question. The one for <can be found in
several places, including <http://c-faq.com/>. The answer can be found
in question 6.16 "How can I dynamically allocate a multidimensional
array?", which can be found at <http://c-faq.com/aryptr/dynmuldimary.html>.

 

[Roland Pibinger]

It's in the FAQ: http://c-faq.com/aryptr/dynmuldimary.html

See also: http://home.netcom.com/~tjensen/ptr/pointers.htm

 

[Flash Gordon]

Roland Pibinger wrote, On 24/04/07 19:27:

See also: http://home.netcom.com/~tjensen/ptr/pointers.htm

This site still needs some work.

In the introduction of the PDF it assumes that PCs use 2 byte int and 4
byte long showing its age. It does note that these sizes need not be the
same on all machines, so not too bad, just dated. Note the HTML version
is more up to date.

It uses %p to print the result of sizeof which is wrong. For C89 it
should use %ul and cast the result to unsigned long.

It at least implies that due to the null pointer not necessarily being
all bits 0 you have to use the NULL macro when, in fact, an integer
constant expression evaluating to zero (most simply 0) is allowed and
the compiler is required to do any magic that is needed.

The author says he thinks of "the name of the array is the address of
the first element in the array" which, in my opinion, is dangerous
because of the difference in type and possible confusion when moving on
to multi-dimensional arrays.

In Chapter 4 it suggests some micro-optimisations in terms of using
pointers and pointer increment to avoid the additions involved in array
indexing. To be fair it says "this may not be true for a modern
optimising compiler" but these days I would say that the "optimisation"
should not even be suggested.

In Chapter 6, when talking about the differences between
char my_string[] = "Ted";
and
char *my_name = "Ted";
It fails to mention one very important difference. Namely that although
the string literal in the second case is not const, you are still not
allowed to modify it (it invokes undefined behaviour, i.e. it could case
the planet to be eaten by an enormous mutant stargoat).

At the end of Chapter 6 it says, "Because of the double de-referencing
required in the pointer version, the name of a 2 dimensional array is
often said to be equivalent to a pointer to a pointer..." While it is
true that this is often said, it is also very misleading because you
cannot pass a 2d array to a function expecting a pointer to a pointer
since they are not the same thing. In the next chapter it makes it a bit
clearer, but I think ending a chapter with something potentially
misleading is bad.

I would also suggest that talking about the old pre-ANSI C is just going
to make it harder for people learning. The chances of a learner coming
across a pre-ANSI compiler are pretty small.

To be fair, I did have to read more carefully than is often the case to
find things to comment on.

I've emailed this to the author of that site. This is meant to be
helpful criticism, not an "avoid that site" message.

 

[Richard Heathfield]

Flash Gordon said:

Roland Pibinger wrote, On 24/04/07 19:27:

This site still needs some work.

It uses %p to print the result of sizeof which is wrong. For C89 it
should use %ul and cast the result to unsigned long.

ITYM %lu

<snip>

 

[Flash Gordon]

Richard Heathfield wrote, On 24/04/07 22:37:

Flash Gordon said:



ITYM %lu

Thanks for the correction.

Not the only mistake. The site used %d for the result of sizeof which is
not as bad as using %p. Still wrong, just not as bad.