www.mikrocontroller.net

Forum: Compiler & IDEs Arrays in Klassen


Autor: blue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe mal wieder ein kleines Problem undzwar mit Arrays.

Ich will eine Klasse schreiben, die ein Array besitzt. Die Größe dieses 
Arrays soll aber abhängig von der initialisierung der Klasse sein. Ich 
hatte mir das ganze so vorgestellt:
 class t{
          public:
             int i[];

             t(int j){
                   i[j];
             }
        }

aber so funktioniert das leider nicht. Kennt wer ne alternative wie ich 
das hinbekommen könnte?

viele grüße blue

Autor: dito (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arrays müssen immer statisch initialisiert werden, d.h. die Größe muss 
zur Übersetzungszeit bekannt sein. Um zur Laufzeit Speicher anzufordern 
musst du malloc() verwenden.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dito schrieb:
> Arrays müssen immer statisch initialisiert werden, d.h. die Größe muss
> zur Übersetzungszeit bekannt sein. Um zur Laufzeit Speicher anzufordern
> musst du malloc() verwenden.

@blue

Lass malloc mal links liegen. In C++ macht man das anders.

Schau dir in deinem C++ Buch den Abschnitt über die STL an, und da 
wiederrum über std::vector
Wenn du einen neueren Compiler hast, kannst du auch mal nachsehen, ob er 
std::tr1::array unterstützt.

Autor: Lukas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du könntest ein dynamisches Array, einen std::vector, oder Templates 
verwenden.

Dynamisch zb so:

class T {
  public:
    int * arr;
    int size;

    T(int s) size(s) {
      arr = new int[s];       //malloc() geht auch c++ sieht aber new 
vor
    }

    ~T() { //destruktor notwendig damit kein memory leak entsteht
      delete [] arr;
    }
};

Persönlich würde ich (wenn es nicht Speicherkritisch oder 
Performancekritisch zugeht) einen std::vector (oder std::list) 
verwenden, allein wegen des Komforts...

Lukas

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, aber vielleicht arr und size dann doch private oder protected 
zumindest.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... und einen op= und einen Copy Constructor.

Und genau wegen all diesen Dingen, die man noch braucht um ein Klasse 
bei Verwendung von dynamischer Allokierung sicher zu machen, ist es viel 
einfacher diese Allokierung einem Spezialobjekt zu überlassen, zb. 
std::vector

Dann braucht man weder Dtor, noch op=, noch CCtor.
Und fehlerfrei im Falle, dass die erste Schätzung der Anzahl der 
Elemente zu klein war, ist es als Zugabe auch noch.

Und Performance ist kein Thema.
Wenn man std::vector halbwegs intelligent einsetzt, hat man keine 
Performance Einbusen im Vergleich zu einem selbst angelegtem Array.

Autor: blue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die schnellen Antworten.

Ich hatte aber vergessen zu sagen, dass das ganze für avr gedacht ist. 
Da gibt es leider keine STL. Werd aber mal Lukas Vorschlag probieren.

Danke nochmals.

viele Grüße blue

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@KHB:
Aber halt nur, wenn einer der Standardcontainer auch passt.
Je nachdem, was man braucht.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
blue schrieb:
> Danke für die schnellen Antworten.
>
> Ich hatte aber vergessen zu sagen, dass das ganze für avr gedacht ist.

Welchen?

> Da gibt es leider keine STL. Werd aber mal Lukas Vorschlag probieren.

Auf einem µC mit arg begrenztem Speicher willst du dynamische 
Speicherallokierung vermeiden, wie der Teufel das Weihwasser.

Was machst du, wenn der Speicher zur Neige geht?
Du kannst nicht einfach "Out of Memory" hinschreiben und zum 
Betriebssystem zurückkehren!

a) hast du kein Betriebssystem
b) Steuerungen müssen unter allen Umständen weiterlaufen.
   So etwas wie einen "Out of Memory" darf es nicht geben!

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
blue schrieb:
> Ich hatte aber vergessen zu sagen, dass das ganze für avr gedacht ist.

Ob man da aber mit copy-ctor, operator= etc. spielen will, sei mal
dahingestellt.
Wenn man weiß, was man macht, ist es i. Ordnung.
Aber im Allgemeinen sind die Warnungen nicht von der Hand
zu weisen:

Karl heinz Buchegger schrieb:
> .. und einen op= und einen Copy Constructor.
>
> Und genau wegen all diesen Dingen, die man noch braucht um ein Klasse
> bei Verwendung von dynamischer Allokierung sicher zu machen,...

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Was machst du, wenn der Speicher zur Neige geht?

Hoffentlich keine Ausnahme werfen :-)

Autor: blue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nutze einen Roboter mit einem AT90CAN128.

Das Ganze wird als Tupel für ein DBMS gebraucht. Und für spezielle 
Funktionen brauch ich eine klare Struktur meiner Daten. Und da 
gespeicherte Tupel unterschiedlich viele Attribute haben können, muss 
ich die Größe des Arrays meinem Datensatz anpassen. Ohne Array wird das 
ganze (inkl. der zu Programmierenden Funktion) um einiges Komplizierter. 
Die Menge der Tupel im Hauptspeicher soll ja garnicht so groß werden und 
die Tupel (also auch das Array) werden später wieder frei.

Betriebssystem: soll garkeins haben, um Speicher zu sparen.

viele Grüße blue

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
blue schrieb:
> die Tupel (also auch das Array) werden später wieder frei.

Aber auch dann kann es passieren, daß der Speicher zwar frei
ist, aber irgendwann zu fragmentiert, um etwas neues anlegen zu
können.

Mit etwas Verstand könnte man sich notfalls eine eigene
Speicherverwaltung überlegen.
Die Fehlerbehandlung wird auf jeden Fall spannend.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
blue schrieb:
> Ich nutze einen Roboter mit einem AT90CAN128.

d.h 4KB SRAM

> Und da
> gespeicherte Tupel unterschiedlich viele Attribute haben können,

gibt es eine Obergrenze?
Wenn es eine gibt, dann nutze sie.
Lege alles statisch für diese Obergrenze aus.

> muss
> ich die Größe des Arrays meinem Datensatz anpassen. Ohne Array wird das
> ganze (inkl. der zu Programmierenden Funktion) um einiges Komplizierter.
> Die Menge der Tupel im Hauptspeicher soll ja garnicht so groß werden und
> die Tupel (also auch das Array) werden später wieder frei.

Dir ist klar, dass das einfache Zusammenzählen der Speicherallokierungen 
für den Komplettverbrauch eine Milchmädchenrechnung ist, die ganz 
schnell nach hinten losgehen kann? Stichwort: Speicherfragmentierung

Du kannst zb

 4K frei haben

 1K allokieren
 2K allokieren
 1K allokieren

jetzt gibst du die beiden 1K Blöcke wieder frei. Nach Adam Riese sind 2K 
allokiert und 2K frei. Und trotzdem gibt dir malloc einen NULL Pointer 
wenn du 1.5K anforderst.
Warum?
Weil zwar 2k frei sind, das stimmt schon, aber nicht in einem Stück! Die 
2K liegen in Form von 2 jeweils 1K großen Blöcken vor. In keinen von 
beiden passen aber deine 1.5K hinein.

(Zahlen jetzt frei erfunden um das Problem zu zeigen. Du wirst kleinere 
Zahlen haben. Dafür hast du aber auch mehr im Speicher und nicht die 
ganzen 4K für dich alleine)

Autor: Lukas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das dem Problem nicht entgegensteht würde ich einfach verkettete 
Listen nehmen, oder spricht da was dagegen?

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Und trotzdem gibt dir malloc einen NULL POinter
> wenn du 1.5K anforderst.

Selbst bei 1K bekommt er einen null Pointer, da die Speicherverwaltung 
schon den Rest gefressen hat.

@ TE: Was genau meinst Du mit
Tupel für ein DBMS gebraucht. DBMS ist für mich database management 
System. Und ein Tpel eine Menge von (n) Elementen/Werten.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas schrieb:
> Wenn das dem Problem nicht entgegensteht würde ich einfach verkettete
> Listen nehmen, oder spricht da was dagegen?

mehr Speicheroverhead.
Gefahr für Fragmentierung größer

Vorteile:
mehrere kleinere Speicheranforderungen anstatt einer großen.
Dadurch ist die Gefahr einer Fragmentierung zum Opfer zu fallen 
geringer.


Ein grundätzlicher Nachteil dynamischer ALlokierung auf einem AVR mit 
wenig Speicher (und 4K sind wenig) wurde noch gar nicht angesprochen.

Bei rein statischer Allokierung muss man ein Auge darauf haben, dass 
einem der Stack nicht in die Daten hineinwächst.
Kommt dynamische Allokierung mit ins Spiel gilt dann auch die Umkehrung: 
Man muss ein Auge darauf haben, dass einem der Heap nicht in den Stack 
hineinwächst, wachsende Daten also nicht den Stack korrupten.
Wenn man von malloc eine NULL bekommt, ist es schon längst zu spät. Dann 
hat man schon längst den Stack niedergebügelt.

Alles in allem gute Gründe, möglichst alles statisch festzunageln und 
auf Obergrenzen zu dimensionieren, selbst wenn dann in Einzelfällen 
Speicher nicht benutzt wird. Aber so hat man dann wenigstens fixe 
Kennzahlen: Bis hierher und nicht weiter.

Autor: blue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab mich oben falsch ausgedrückt,

das Ganze ist wie gesagt für ein DBMS. Unterschiedliche Anwendungen 
dieses DBMS haben je nach verwendetem Systemkonfiguarationen wenige 
verschiedene Tupelarten mit unterschiedlichen Längen. Die dann aber sich 
nicht ständig Ändern. Also feste Größen pro Datenbank, die sich aber von 
Anwendung zu Anwendung ändern.

Dank euch werde ich als Empfehlung für die Anwendungsprogrammierung klar 
herausstellen, das immer nur eine feste Anzahl an Tupeln deklariert 
werden sollte, die dann nicht!! freigegeben werden, sondern immer wieder 
mit neuen Werten bestückt werden. Vielleicht mach ich das auch über eine 
Schnittstelle, die dann die Tupel verwaltet/ initialisiert. (Achtung 
keine Speicherverwaltung)

Die Möglichkeit mit einer festen Obergrenze ist leider nicht so 
praktikabel, da sich diese von Anwendung zu Anwendung ändert und 
eigendlich nicht im Code des DBMS geändert werden soll.

Danke für eure Hilfe, damit habt ihr mich auch auf die potentielle 
Fehlerquelle Tupel hingewiesen. (an anderer Stelle habe ich genau das 
Problem erst behoben und hier vergesse ichs ;-))

viele grüße blue

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.