Dynamisches Ändern der Größe von Arrays

[Bert (Gast)]

Hallo,

das Problem: zur Laufzeit soll die Größe eines Arrays geändert werden 
können.

Der Compiler meint aber dazu, dass ein Array eine konstante Länge haben 
muss.

Ein "alloc" und Co. kann ich nicht verwenden, da nicht unterstützt.

Gibts noch weitere Möglichkeiten?

Das Array sitzt in einer Funktion der die Array-Länge bei Aufruf 
zugewiesen wird.

[Uhu U. (uhu)]

Nein.

Beim Einsatz auf kleinen µC wäre das auch keine gute Idee, da auf diesem 
Weg mit einem Schlag alle Sicherheitsprobleme, die mit dynamischer 
Speicherverwaltung verbunden sind, in die Anwendung eingebaut würden.

Es bleibt nur, die maximal benötige Größe zu bestimmen und den Speicher 
fest zu reservieren.

[Rolf Magnus (Gast)]

> Der Compiler meint aber dazu, dass ein Array eine konstante Länge haben
> muss.

Da hat er recht, der Compiler.

> Das Array sitzt in einer Funktion der die Array-Länge bei Aufruf
> zugewiesen wird.

Und warum muß die zur Laufzeit geändert werden?

[Stefan (Gast)]

Vielleicht einfach die maximale Größe reservieren. Damit müsste er ja im 
worst case auch umgehen könnne. Also sollte das Programm damit laufen, 
auch wenn es sich erst mal nach Verschwendung anhört (ich denke es wird 
bestimmt ein globales Array?).

[hulou (Gast)]

nimm malloc und free

[Uhu U. (uhu)]

Bert:

> Ein "alloc" und Co. kann ich nicht verwenden, da nicht unterstützt.

[Michael Z (Gast)]

Für einfache Variablen oder Instanzen kann man sich malloc und free 
selber per makro implementieren. Was fehlt, ist eine Unterstützung für 
generische Parameter & signaturen.

Einfach mal hier oder beim englischen Forum suchen, da gibt es Tricks 
dazu.

[Andreas K. (a-k)]

Einzelne Umgebungen (lies: GCC-basierend) unterstützen eine dynamische 
Allokation auf dem Stack. Nennt sich alloca(). In diesem Fall ist es 
einfach und die Nebenwirkungen sind überschaubar.

[Uhu U. (uhu)]

> Für einfache Variablen oder Instanzen kann man sich malloc und free
> selber per makro implementieren.

Das ist reine Augenwischerei:

Macros werden noch vor der eigentlichen Übersetzung vom Preprozesser 
abgearbeitet. Daraus folgt: Es handelt sich um reine 
Textersetzungsoperationen; Macroparameter werden textuell im Macrorumpf 
substituiert.

Ein Macro kann keine Heapverwaltung implementieren. Was man mit einem 
Macro malloc erreichen kann, das kann man auch direkt dort hinschreiben, 
wo der Macro expandiert würde: eine Variablendefinition.

free als Macro? das geht ganz einfach nicht...

[Patrick D. (oldbug)]

Was spricht denn gegen

void
foo(int len)
{
    char array[len];
    /* something very usefull */
}

...wenn sonst keine dynamische Speicherverwaltung verfügbar ist?
Sicher gibt's gerade dabei Stolperstellen, aber bis er darauf gekommen 
ist, dass es zu 99% auch ohne geht, sollte das doch weiterhelfen!?

[Andreas K. (a-k)]

Dagegen spricht erstens, dass dies erst mit C99 möglich ist, mit C89 
noch nicht. Und viele Compiler im Controller-Umfeld tun sich mit C99 
etwas schwer.

Zweitens wird Bert wohl genau dies probiert haben, der Meldung nach zu 
schliessen.

[Bert (Gast)]

genau,

und ich werde es daher als maximale Größe auslegen und fertig.

[Patrick D. (oldbug)]

Andreas Kaiser wrote:
> Dagegen spricht erstens, dass dies erst mit C99 möglich ist, mit C89
> noch nicht. Und viele Compiler im Controller-Umfeld tun sich mit C99
> etwas schwer.
>

Aha, ich muss also in einem GCC-Forum davon ausgehen, dass es sich um 
einen Compiler handelt, der die Features eines GCC-Compilers nicht 
unterstützt?

> Zweitens wird Bert wohl genau dies probiert haben, der Meldung nach zu
> schliessen.

Hat Dir das die Glaskugel verraten?
Meine hat mir gesagt, dass er eben 'static' vor 'char' verwendet hat ;-)

void
foo(int len)
{
  static char array[len];
}

main.c: In function 'foo':
main.c:15: error: storage size of 'array' isn't constant

Danke an Bert, dass er das aufgeklärt hat!

[Andreas K. (a-k)]

> Aha, ich muss also in einem GCC-Forum davon ausgehen, dass es sich um
> einen Compiler handelt, der die Features eines GCC-Compilers nicht
> unterstützt?

Sein Text:

> Ein "alloc" und Co. kann ich nicht verwenden, da nicht unterstützt.

sprach gegen GCC. Denn GCC kann alloca und die avr-libc hat malloc/free.

[Patrick D. (oldbug)]

Andreas Kaiser wrote:
>> Aha, ich muss also in einem GCC-Forum davon ausgehen, dass es sich um
>> einen Compiler handelt, der die Features eines GCC-Compilers nicht
>> unterstützt?
>
> Sein Text:
>
>> Ein "alloc" und Co. kann ich nicht verwenden, da nicht unterstützt.
>
> sprach gegen GCC. Denn GCC kann alloca und die avr-libc hat malloc/free.

Das spricht lediglich gegen die verwendete libc, aber sei's d'rum.

[Rolf Magnus (Gast)]

> Denn GCC kann alloca

Wenn die libc es unterstützt.

> und die avr-libc hat malloc/free.

avr? Wo steht denn was von avr?

[Andreas K. (a-k)]

>> Denn GCC kann alloca
>
> Wenn die libc es unterstützt.

Wenn du ein
 #define alloca(size) __builtin_alloca(size)
als libc ansiehst, ja. Bis auf den Namen ist die Funktionalität von 
alloca() bei GCC allerdings ziemlich zwangsläufig Sache des Compilers, 
nicht der Library. Auch bei manchen anderen Compilern.

[Andreas K. (a-k)]

Rolf Magnus wrote:

> avr? Wo steht denn was von avr?

Ok. Gibt es ein leidlich gängiges GCC Paket ohne malloc?

[Jörg W. (dl8dtl) (Moderator)]

Andreas Kaiser wrote:

> Bis auf den Namen ist die Funktionalität von
> alloca() bei GCC allerdings ziemlich zwangsläufig Sache des Compilers,
> nicht der Library. Auch bei manchen anderen Compilern.

Das ist eigentlich zwangsläufig der Fall.  Die Bibliothek hat ja keinen
Einfluss auf den Funktionsepilog, den der Compiler generiert, genau
der muss aber bei alloc() das Aufräumen organisieren.  Das kann also
nur im Compiler passieren.

[Andreas K. (a-k)]

> Das ist eigentlich zwangsläufig der Fall.  Die Bibliothek hat ja keinen
> Einfluss auf den Funktionsepilog, den der Compiler generiert, genau
> der muss aber bei alloc() das Aufräumen organisieren.  Das kann also
> nur im Compiler passieren.

Wenn ein Compiler stets mit getrenntem Stack- und Frame-Pointer 
arbeitet, geht es auch ohne Compiler-Support. So war alloca() 
ursprünglich entstanden. Nur ist das mittlerweile aus der Mode gekommen.

Walter Bright (Digital Mars) beispielsweise implementiert alloca() als 
Lib-Funktion, scheint es aber im Compiler doch irgendwie zu kennen, denn 
es erzwingt den vollen Stack-Frame.