Re: Static data?
Re: Static data?
- Subject: Re: Static data?
- From: Tobias Sargeant <email@hidden>
- Date: Wed, 7 Jul 2004 10:05:06 +1000
Message: 12
Cc: XCode XCode <email@hidden>, Pavol Markovic
<email@hidden>, "<email@hidden>"
<email@hidden>
From: Allan Odgaard <email@hidden>
Subject: Re: Static data?
Date: Tue, 6 Jul 2004 22:56:53 +0200
To: Markus Hitter <email@hidden>
On 6. Jul 2004, at 22:24, Markus Hitter wrote:
There are cases where this transformation cannot happen, like:
long data[1024][1024];
->
data = ...?
From the C-FAQ (<http://www.faqs.org/faqs/C-faq/faq/>) 6.16:
[...]
But this is not the same thing. It has a different memory layout (which
may be important if you manipulate image data or similar), it looses
the extra type info about array sizes (which could be deduced using
sizeof() or template functions) and it require extra code to deal with
alloc/free of each row plus probably worse cache performance and memory
fragmentation (overhead). So while this might be used in some
circumstances, it's not a general "transformation" from static to
dynamic data of n dimensional arrays (as it could easily break programs
relying on sizeof(), the continuos memory layout, or programs which use
template functions to work on the array data).
How about this then?
typedef int Array[1024][1024];
void foo(Array x) {
}
int main(int argc, char **argv) {
Array *array = (Array *)malloc(sizeof(Array));
foo(*array);
}
But the simple truth of the matter is that multidimensional arrays
in C are hairy beasts to use. If you're using templates, then I
presume you're writing C++. In that case, you should look at the
excellent Boost and Blitz++ libraries.
http://www.boost.org/libs/multi_array/doc/user.html
http://www.oonumerics.org/blitz/
And as for cache performance, allocating a large static array -
especially one has a row size that's a power of two times
the size of a cache line - and then only using part of it is about
as bad as you can get.
I do not know what you mean with "even more likely" -- but for the
coder it's certainly better just to have the OS refuse to load the
program if it makes memory requirements which it cannot fulfill, rather
than the need to check every single trivial allocation (for which there
would perhaps anyway be no graceful way to handle an allocation fault).
And for the user, it's certainly better to see a meaningful error
message than have an application silently quit on startup.
And again, if you're using C++, I believe the default semantics of
new is to correctly allocate memory or throw an exception. If you
*want* all your dynamic allocations to just turn your app into heat
and light straight away, just use new & don't catch the exception.
Toby.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.