int a[ 10 ]; // Allokiert Speicher für 10 Ingeger

Dynamisch:

int *b = new int[ 10 ]; // Zeiger, der auf einen Speiecherbereich ziegt
                    // wo Platz für 10Integer allokiert wurde

Vorteil hier ist, dass man auch noch später hätte festlegen können wieviel Platz man gerne hätte. Nachteil, man muss eigenständig den Speicher wieder frei geben.

Gruß Tobi.

hi,
warum sollte ich z.b. ein array so anlegen:
int *omg = new int[];
und nicht einfach
int omg[];
was hat das für vorteile?

Größe kann zur Laufzeit bestimmt werden (geht besser mit std::vector).
Der Stack kann nicht überlaufen (geht besser mit std::vector).

während ein normales array bis zum schluss des programmes bleibt

Du meinst bis zum Schluss des Sichtbarkeitsbereiches, in dem es deklariert wurde. Du musst es eben nicht global deklarieren.

ok danke ist das auch schneller wie ein normales array?
denn ein dynamisches kann man ja schon eher löschen und den platz freigeben,
während ein normales array bis zum schluss des programmes bleibt

Ähhh ...
1.) das Allozieren per new dauert deutlich länger als auf dem Stack (was Du "normales Array" nennst)
2.) im Zugriff kann ein Stack-Array einen schneller sein (wenn der Compiler bestimmte Optimierungen vornimmt)
3.) Ein "Vorteil" eines mit new angelegten Arrays bzgl. der Lebens ist gerade anders herum: Es kann Blockenden überleben:

int* f1() {
   int arr[10];
   return arr;
} // ab hier "lebt" arr nicht mehr und deswegen zeigt der zurückgegebene Zeiger ins "Nirvana"

int* f2() {
   return new arr[10];
} // der allokierte Speicher lebt weiter

ACHTUNG: Ich warne dringend vor den Gefahren dieser "Erzeugersemantik" ... ist nur ein Beispiel.

Anders herum wird ein Schuh draus: new ist komplizierter, (deswegen) fehleranfälliger und langsamer. Deshalb sollte man es nur in speziellen Fällen verwenden.
Besser ist es sowieso in 99% der Fälle, gleich vorgefertigte Container (vector, list, ....) zu nehmen.

Gruß,

Simon2.

P.S.: "schneller wie" geht gar nicht !!

Will du dein gesamten daten vorher in main statisch allokieren? Und im rest deine programm verwenden?

man arbeitet ja hauptsächlich in main

Nein. Wenn man anständig programmieren will, lagert man seinen Code in Funktionen und Klassen aus.

Bei kleinen Konsolenprogrammen mag ja main() noch reichen, aber bei grösseren Projekten ist es ratsam bzw. sogar notwendig, den Code zu strukturieren.

Undynamisch:

int a[ 10 ]; // Allokiert Speicher für 10 Ingeger

Dynamisch:

int *b = new int[ 10 ]; // Zeiger, der auf einen Speiecherbereich ziegt
                    // wo Platz für 10Integer allokiert wurde

Vorteil hier ist, dass man auch noch später hätte festlegen können wieviel Platz man gerne hätte. Nachteil, man muss eigenständig den Speicher wieder frei geben.

Gruß Tobi.

Bei den klammern schreibt man ohne pausen!:

int a[ 10 ]; // Allokiert Speicher für 10 Ingeger

Bitte denk dran, oder du hast ne andere version (zb. C)

Bei den klammern schreibt man ohne pausen!:

int a[ 10 ]; // Allokiert Speicher für 10 Ingeger

Bitte denk dran, oder du hast ne andere version (zb. C)

1. Mit Pausen meinst du wohl Leerzeichen.
2. Es ist wohl jedem selber überlassen, wie er das macht. Ich finds ehrlich gesagt auch nicht schön, aber von der Syntax her ist es zulässig.
3. C ist nicht eine andere Version von C++, sondern eine eigene Programmiersprache.

[NOVA] Max schrieb:

Bei den klammern schreibt man ohne pausen!:

int a[ 10 ]; // Allokiert Speicher für 10 Ingeger

Bitte denk dran, oder du hast ne andere version (zb. C)

1. Mit Pausen meinst du wohl Leerzeichen.
2. Es ist wohl jedem selber überlassen, wie er das macht. Ich finds ehrlich gesagt auch nicht schön, aber von der Syntax her ist es zulässig.
3. C ist nicht eine andere Version von C++, sondern eine eigene Programmiersprache.

Die Bildschirme werden immer breiter, die Quelltexte immer länger und die Augen immer schlechter - da kann man ruhig etwas Ausgleich durch horizontale Leerfelder schaffen.

Du kannst bestimmen wann wie viel Speicher erzeugt wird und wann er wieder
freigeben wird.Wie man so schön sagt auf große Macht folgt große Verantwortung^^
Also du musst dich selbständig um das wieder Freigeben des Zugewiesenen Speichers kümmern.Da der Speicher ja net auf dem Stack liegt und automatisch freigeben wird sobald der Speicher seine Gültigkeit verliert.Er befindet sich auf dem Heap und über den musst du walten und Herrschen.

Aber besser ist wohl einfach mal zu lesen:
Dynamische Speicherzuweisung
STACK
HEAP

Gruß Tobi.

for (short i = 0; i < 35; i++) // Abstände zwischen Operatoren und ; Trennzeichen
{                              // Klammer hier, nicht oben (das hasse ich)
   if (2*i + 3 <= 15)          // Jeweils abstand zwischen
      DoSomething(Argument, Parameter, Wert); // nach , bei Funktionen auch schön Abstand
   if ((4*i - i*i < 5  &&  i > 1)  // Abstand der Operatorenrangfolge angepasst
    || (i == 14))              // leicht unschön, aber besser als auf einer Zeile
   {
      DoSomething();
   }

   // logisch eher separater Teil, deshalb Zeilenabstand
   float Float1, Float2;       // Mache ich bei gleichen Variabeln (ohne Initialisierung)
   float *FloatPtr;            // Zeiger separat, * direkt vor Variable
   Array[i] = 77 % i;          // bei Indexklammern keinen Abstand, sieht für mich hässlich aus
   Var++;                      // Inkrement- und Dekrementoperatoren auch direkt daran
   Var += 0;                   // schöne Abstände bei anderen Operatoren
}

int &operator += (...);        // auch schöne Abstände :)

Wie ihr seht, bin ich sehr stolz auf meine Abstände
Ich finde es unübersichtlich, wenn immer mehrere Anweisungen pro Zeile stehen, keine Leerzeichen zwischen Operatoren/Trennzeichen stehen, oder auch wenn sehr lange Codeblöcke (ohne logisch sinnvolle Zeilenabständen) vorkommen. Unkommentierter Code ist auch mühsam, manchmal sind eine Seite breite Trennkommentare ganz nützlich.

Aber jedem das Seine

new

würde ich darin sehen, dass Konstruktoren oftmals implizit aufgerufen werden. Eventuell unangenehm könnte sein, dass new bei mehrdimensionalen Arrays, die zur Laufzeit wachsen sollen, nicht mit realloc() zusammenarbeitet, weil die Daten kreuz und quer im Speicher verstreut liegen. Ähnliches gilt auch für std::vector und sämtliche Derivate davon. Wenn es unwichtig ist, wo genau die Daten im Speicher untergebracht wurden, (weil man z.B. ohnehin nicht vorhat, exzessiv mit Bitoperationen auf Speicherblöcken zu arbeiten), ist new aber wohl vorteilhaft. Andernfalls lieber die malloc()-Familie.

Als den eigentlichen Hauptvorteil von new würde ich darin sehen, dass Konstruktoren oftmals implizit aufgerufen werden....

Was ist den daran

myClass* m = new myClass(1, "Hallo", &otherO, 12.34f);

"explizierter" als an

myClass m(1, "Hallo", &otherO, 12.34f);

??

TheorienErfinder schrieb:

...Eventuell unangenehm könnte sein, dass new bei mehrdimensionalen Arrays, die zur Laufzeit wachsen sollen, nicht mit realloc() zusammenarbeitet...Andernfalls lieber die malloc()-Familie.

Hier geht's Dir also um "Speicheroptimierung" ....
Einerseits geht's in diesem Thread eigentlich nicht um den Unterschied "new<->..alloc()" und andererseits sehe ich da sogar einen starken Vorteil bei new und STL-Containern , dass man ihm ein eigenes Speichermanagement "unterschieben" kann (Stichworte "new-Überladung" und "Allokatoren").
Und das Ganze auch noch:
- für den Benutzer unsichtbar (d.h. ich habe einen "Fachspezi", der ganz sich der Programmierung der Fachlichkeit widmen und einen "TechnikSpezi", der aus der Speicherverwaltung das Optimum herausholen kann)
und
- Nach einem konsistenten und einheitlichen Konzept. D.h.: Ich muss mir nicht aus dem allgemeinen Code rauspopeln, wie denn jetzt eigentlich die Speicheroptimierung funktioniert, sondern kann mir ganz gezielt die news und die Allokatoren ansehen....

Gruß,

Simon2.

Ich besitze nen 22Zoll Wildscreen das ist also platz für ne Menge "Pausen".

Dann mach's wenigstens richtig.

int a[ 10 ];

ist albern. Wieso ist nach der öffnenden und vor der schließenden Klammer ein Leerzeichen, vor der öffnenden und nach der schließenden aber nicht?

Ich gebe Dir grundsätzlich recht, bin aber dafür, soweit wie möglich die „übliche“ Typographie zu befolgen, alles andere ist nur irreführend. Und üblich ist, innerhalb der Klammern keine Leerzeichen zu lassen, dafür aber davor.

Ich gebe Dir grundsätzlich recht, bin aber dafür, soweit wie möglich die „übliche“ Typographie zu befolgen, alles andere ist nur irreführend. Und üblich ist, innerhalb der Klammern keine Leerzeichen zu lassen, dafür aber davor.

Wer legt denn fest, was üblich ist?Wenn wir uns überhaupt einig sind, dass white space sinnvoll und nützlich ist, folgt doch sofort, dass es für das Weglassen desselben zusätzliche Gründe sprechen müssen. Ich sehe keine besonderen Grund, innerhalb der eckigen Klammern die Leerzeichen wegzulassen, vor den Klammern kann man sich dagegen so etwas denken: durch das Weglassen des Leerzeichens vor der Klammern wird die Affinität zum links stehenden Bezeichner deutlich. Natürlich ist das nur meine ganz persönliche Vorgehnsweise - aber ich kann deinen Ausführungen hinsichtlich des"Üblichen" so nicht folgen. Größtenteils ist es sowieso nur Gewohnheit: es gibt sicher keinen besonderen Grund, vor dem Semikolon keinen Leerraum zu lassen - andererseits lässt man in natürlicher Sprache auch keinen Platz vor dem Satzende. Und ein Semikolon hat ja eine ganz ähnliche Funktion wie der Punkt am Ende eines Satzes.

Konrad Rudolph schrieb:

Ich gebe Dir grundsätzlich recht, bin aber dafür, soweit wie möglich die „übliche“ Typographie zu befolgen, alles andere ist nur irreführend. Und üblich ist, innerhalb der Klammern keine Leerzeichen zu lassen, dafür aber davor.

Wer legt denn fest, was üblich ist?

Die Allgemeinheit? Bzw. im Fall von Typographie halt die Regeln der jeweiligen Sprache. Und die sind im Englischen, ähnlich wie im Deutschen so, dass innerhalb von Klammern keine Leerzeichen stehen. Übrigens auch bei mathematischen Textsatzprogrammen.

Wenn wir uns überhaupt einig sind, dass white space sinnvoll und nützlich ist, folgt doch sofort, dass es für das Weglassen desselben zusätzliche Gründe sprechen müssen.

Nicht unbedingt. Ich finde überflüssige Leerzeichen und -zeilen genauso störend wie zu wenige. Wobei eigentlich nicht die Menge ein Problem ist sondern eher die Asymmetrie. Von daher spricht aus meiner Sicht auch nichts gegen Leerzeichen innerhalb der Klammern. Nützlich finde ich sie allerdings auch nicht, da ich durch fast lebenslange Übung daran gewöhnt bin, Klammern im Text entsprechend einzuordnen.

Größtenteils ist es sowieso nur Gewohnheit: es gibt sicher keinen besonderen Grund, vor dem Semikolon keinen Leerraum zu lassen - andererseits lässt man in natürlicher Sprache auch keinen Platz vor dem Satzende.

Eben.

Abgesehen davon will ich meine Kritik an T0bi mal stufenweise zurücknehmen. Es gibt m.E. nichts ätzenderes als fehlende Leerzeichen. Beim Korrigieren von Code aus Übungesaufgaben ist das schon ziemlich anstrengend.