was hat new für vorteile

Nexus

[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.

camper

Nexus schrieb:

[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.

Die wohl wichtigsten Vorteile von Dynamischen Speicherverwaltung ist
wohl das du frei über den Speicher walten kannst.(Stell es dir so vor du Spielst Gott^^)

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

T0bi

Ich besitze nen 22Zoll Wildscreen das ist also platz für ne Menge "Pausen". Und meiner Seits finde ich es einfach nur gequetscht, wenn leute alle sohne "Pausen schreiben", z.B: for(int i=0;i<2;i++) wie sieht, denn das aus? Ist ja wie in einer Deutscharbeit: keinen bock auf Silbentrennung, also wird alles noch in eine Zeile gedrückt....

Gruß Tobi.

Nexus

Okay, ich kann dir zwar weitgehend zustimmen. Über die Zeit habe ich mir auch meinen eigenen Stil (neben schönen Einrückungen, Zeilenabstände etc.) angewöhnt:

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

Als den eigentlichen Hauptvorteil von

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.

Simon2

TheorienErfinder schrieb:

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.

Konrad Rudolph

T0bi schrieb:

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.

camper

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?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

camper schrieb:

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.