Automatische dynamische Arrays
Sönke Müller-Lund
bisher bin ich stets davon ausgegangen, dass die Grￜￜe eines
automatischen Arrays zur Compilezeit konstant sein muss. Mit dem gcc
4.1.2 bekomme ich aber folgendes problemlos ï¿œbersetzt:
schnipp
#include <stddef.h>
extern void doSomething(int a[], size_t n);
void foo(size_t n) {
int a[n];
doSomething(a, n);
}
schnipp
War das schon immer so, oder ist das ein "frisches" Feature? Mein
betagtes "Programmieren in C" von K&R sagt darï¿œber nichts.
Grￜￜe
Sï¿œnke Mï¿œller-Lund
Claus Reibenstein
> bisher bin ich stets davon ausgegangen, dass die Grￜￜe eines
> automatischen Arrays zur Compilezeit konstant sein muss.
Das war bis 1999 auch der Fall. Mit dem damals verabschiedeten neuen
Standard (ISO/IEC 9899:1999) hat sich das geï¿œndert.
> War das schon immer so, oder ist das ein "frisches" Feature? Mein
> betagtes "Programmieren in C" von K&R sagt darï¿œber nichts.
K&R behandelte in der 2. Auflage auch nur ANSI-C von 1990 (ISO/IEC
9899:1990). Einen neueren K&R gibt es meines Wissens nicht.
Gruￜ. Claus
Marcel Müller
Sï¿œnke Mï¿œller-Lund wrote:
> bisher bin ich stets davon ausgegangen, dass die Grￜￜe eines
> automatischen Arrays zur Compilezeit konstant sein muss. Mit dem gcc
> 4.1.2 bekomme ich aber folgendes problemlos ï¿œbersetzt:
>
> void foo(size_t n) {
> int a[n];
>
> War das schon immer so, oder ist das ein "frisches" Feature?
wie schon gesagt, ist C99.
Im Prinzip ist das ein typisiertes alloca.
Marcel
Claus Reibenstein
> Im Prinzip ist das ein typisiertes alloca.
Du meinst malloc. Oder was meinst Du?
Gruￜ. Claus
Harald Wenninger
> Marcel Müller schrieb:
>> Im Prinzip ist das ein typisiertes alloca.
> Du meinst malloc. Oder was meinst Du?
Nein, er meint alloca.
Das ist eine (nicht standardisierte) Funktion auf manchen Unix-Systemen,
die Speicher dynamisch auf dem Stack alloziert. Der gcc auf Linux
beispielsweise realisiert (oder hat das zumindest mal so gemacht) Sachen
wie
int array[n];
mit einem Aufruf von alloca.
Gruß,
Harald
Thomas Koller
> Marcel M�ller schrieb:
>> Im Prinzip ist das ein typisiertes alloca.
>
> Du meinst malloc. Oder was meinst Du?
Nein, schon eher alloca.
Bei malloc handelst dir ja ein Speicherloch an, wenn du den Speicher
nicht mehr selbst freigibst, und du kannst das Objekt auch nach
Ende der Funktion in dem du es allokiert hast weiterverwenden.
Tom
Rainer Weikusat
>
>>> Im Prinzip ist das ein typisiertes alloca.
>> Du meinst malloc. Oder was meinst Du?
>
> Nein, er meint alloca.
> Das ist eine (nicht standardisierte) Funktion auf manchen
> Unix-Systemen,
Das ist ein Interface, dass es seit UNIX(*) 32V gibt, das ebenfalls
seitdem augenscheinlich eine gewisse Menge von Menschen gerne wieder
loswerden moechte, obwohl der Grund dafuer noch nie besonders klar
war und die Funktionalitaet selber mittlerweile in der C-Norm
angekommen ist. Unterstuetzt wird es wenigstens von Solaris, AIX,
HP-UX, *BSD und allen GNU-Implementierungen.
Insofern scheint 'das ist eine nicht standisierte Funktion, die es auf
manchen UNIX(*)-Systemen nicht gibt' (oder sogar 'auf manchen
mittlerweile weitgehend in Vergessenheit geratenen UNIX(*)-Systemen
nicht gab') der Wahrheit naeher zu kommen.
Marcel Müller
> Das ist ein Interface, dass es seit UNIX(*) 32V gibt, das ebenfalls
> seitdem augenscheinlich eine gewisse Menge von Menschen gerne wieder
> loswerden moechte, obwohl der Grund dafuer noch nie besonders klar
> war und die Funktionalitaet selber mittlerweile in der C-Norm
> angekommen ist. Unterstuetzt wird es wenigstens von Solaris, AIX,
> HP-UX, *BSD und allen GNU-Implementierungen.
Und auf allen mir bekannten DOS-artigen Systemen (DOS, OS/2, Win16, Win32)
> Insofern scheint 'das ist eine nicht standisierte Funktion, die es auf
> manchen UNIX(*)-Systemen nicht gibt' (oder sogar 'auf manchen
> mittlerweile weitgehend in Vergessenheit geratenen UNIX(*)-Systemen
> nicht gab') der Wahrheit naeher zu kommen.
:-) so in der Art. Es h�ngt aber letztlich nicht unbedingt vom OS ab,
sondern (auch) vom Compiler. Auf Plattformen mit Stack-Frames erzeugt es
oft nur eine Subtraktion vom Stack-Pointer. Ohne Stack-Frames geht es
auch, ist aber komplizierter.
Wissen sollte man das eher deshalb, weil die Allokation aus dem
Adressraum des Stacks heraus erfolgt, der gerade unter 32 Bit eine pro
Thread durchaus schnell endende Ressource ist.
Marcel