dynamische 1 dim. Klasse initialisieren

[dml]

Hi,

ich hab mal wieder ein Problem, dabei geht es aber eher um Grundwissen als um Qt.

Ich möchte ein dynamisches Array initialisieren

class x{
   QButtonGroup* revipetype[];
}

x::x{
   for( int i=0;i<dynamische variable;i++{
         recipetype[i] = new QButtonGroup;
  }
}

das klappt ja auch, bloß leider nur lokal

x::methode(){
    recipetype[0]->button(0)->text();
   // gibt zum Beispiel nix aus, aber beim construktor
}

Doch wie kann ich ein dynamisches Array global initialisieren?

Bedanke mich vielmals für Eure Hilfe!
gruß
dml

[dml]

juti das ist jetzt mal wieder ziemlicher Quatsch von mir,
ich werde es nochmal überarbeiten.

erst überlegen, dann schreiben.

[dml]

recipetype* QButtonGroup;

recipetype = new QButtonGroup[anz];

Noch früh am Morgen.
oder doch zu viel Alkohol gestern.

[RHBaum]

recipetype* QButtonGroup; // muss das nich QButtonGroup * recipetype heissen ?

recipetype = new QButtonGroup[anz];

Das ist C in C++ schreibweisse Quasi !

Du brauchst die Button-Zeiger am Stueck, also strikt hintereinanderliegend ???
Oder du hasst eine numerische bedeutung der "Position", also z.b. es ist genau definiert welches der 5. ButtonZeiger ist, udn du brauchst sehr schnellen zugriff drauf ?

dann ist besser:

std::vector<QButtonGroup *> myReceiveVector(anz); /// wir wissen wie gross das Array wird ! also ziehen wirs gleich mit der richtigen groesse auf 
for(int i = 0; i < anz; ++i) myReceiveVector.push_pack(new QButtonGroup);

Normal merkt man sich im Rest des Programs aber ned die "Positionen" sondern die zeiger direkt, und die dinger muessen ned am Stueck rumliegen, dann eignet sich sowas besser :

std::list<QButtonGroup *> myReceiveList; 
for(int i = 0; i < anz; ++i) myReceiveList.push_pack(new QButtonGroup);

Alternativ zu den stl-containern kann man auch die QT container nehmen, ich gewoehn mich aber ungern an standardfunktionalitaet aus 3.d Party Libs/Frameworks

Ciao ...

[dml]

Cool, vielen dank für Deine Antwort,

ich bin aber mit der Performance recht zufrieden und mit
recipetype = new QButtonGroup[anz]; funktioniert es eigentlich wunderbar.

Dennoch war Deine Antwort sehr Interessant für mich und werd den vector auch brauchen,
wenn ich mal Performance Probleme habe.

vielen dank!

[RHBaum]

wenn ich mal Performance Probleme habe.

wenn man die groesse vorher weiss, ist dyn. Array vs. vector eigentlich keine frage der Performance. Da sollte sich so gross nix mehr unnerscheiden.

Der vorteil den man von den containern bekommt, ist das einfacherere Exceptionhandling.

stell dir vor:

QWidget ** myArray = new QWidget * [anz]; 
//// irgend was wildes tun, wir nehmen mal ne einfache funktion foo() an; 
foo();
delete[] myArray;

jetzt stell dir vor, in foo kann nen Fehler auftreten, den deine Application abfangen kann / darf ....
nun bau mal das so um, das die exeption fangst, und auch sicherstellst, dass dein Array wieder "bereinigt" wird.

das iss ein vector oder ähnliches einfach pflegeleichter ....

Oft wird in Manuals als der Grosse Vorteil der container oder auto_ptr angepriessen, das man die Dinger ned mehr selber deallocieren muss, es also ned vergessen kann ... das ist aber nur der nebeneffekt (vergessliche Programmierer sind eh ne Gefahr), wichtiger iss die möglichkeit, restrikter aus dem block zwischen allocate und deallocte aussteigen zu koennen, ohne das Memory Leaks entstehen.

Wie gesagt, in c++ sollt man ein T * myArray = new T [x]; nur in sehr sehr seltenen faellen benutzen muessen, es gibt kaum eine entschuldigung da keinen Container zu verwenden.
Nicht zu verwechseln mit einem statischen array (groesse zur compilezeit bekannt).
ein T myStaticArry[100]; hat natürlich immer noch seine performante Daseinsberechtigung, da kommt nen vector ned hinterher.

weiterhin sollt man auch trainieren, die container richtig einzusetzen (vector vs. list vs. dequeue ...). Auch wenn bei dir momentan die Performance ned so wichtig ist, spaeter wird sie es vielleicht mal ! Und man sollt intuitiv schon beim entwerfen des codes den richtigen container nehmen. Schlimmer ist es, spaeter beim optimieren alle container ersetzen zu muessen, bzw ueberhaupt erst mal performance probleme zu haben, die von haus aus umgangen werden könnten.

Ciao ...