bitte um etwas Nachsicht, bin noch nicht soweit mit Cpp. Also, das Programm ist natürlich total sinnfrei, taste mich gerade an Containter ran (die Iteratoren Sache verwirrt noch etwas).

Bitte um Verbesserung, bzw. was alles falsch ist. Es geht hauptsächlich um die "Insert" Sache. Das funktioniert zwar, aber das muss ja nichts heißen
Danke!

#include <iostream>
#include <vector> 

void vect_dyn2(void){

const int EX =110;
enum{YES='y', NO='n'};

std::cout<<"\n\nWelcome to some Experiments :-) \n";	

std::vector<double> myData;

double value=0;

while (value != EX){
	std::cout<<"Enter:";
	std::cin>>value;
	myData.push_back(value) ;
}

myData.pop_back() ;

for(int show : myData){
	std::cout<<show<<std::endl;
}

char check=' ';
double  spec=7.0;

for(std::vector<double>::iterator it=myData.begin(); it!= myData.end();it++){

	std::cout<<"Element Value : "<<*it<<std::endl;

    std::cout<<"insert? y/n";
    std::cin>>check;

    if(check == YES && (it+1 != myData.end()) ){
    	std::cout<<"\n\tInserted!!\n";    	
    	it=myData.insert(it+1,spec ) ;
    	spec+=100.0;
    }  else{
    	     std::cout<<"\nInsert not possible or requested\n";
       }

}  

 for(int show : myData){
	std::cout<<show<<std::endl;
}

}//END vect_dyn2

enum{YES='y', NO='n'}; // erinnert mich an Jürgen Wolfs Buch?

Nö, hatte das früher mit #define YES usw gemacht, wurde aber letztens darauf hingewiesen das man in c++ das nicht so machen soll, und eher z.B. Enums hernehmen.

Mich wundert am meisten, das kein Kommentar zu der Insert geschichte??

++it ist schneller

Ohne Optimierung vielleicht. Ne, nicht mal dann.

enum{YES='y', NO='n'};

Hier wären char -Konstanten angebrachter.

double value=0;

while (value != EX){
    std::cout<<"Enter:";
    std::cin>>value;
    myData.push_back(value) ;
}

myData.pop_back() ;

Nicht so schön. Lieber zuerst den Wert überprüfen, einfügen falls erwünscht, sonst die Schleife abbrechen.

for (double value; std::cin >> value && value != EX;) // Werner-Style
    myData.push_back(value) ;

(Ausgabe mal ausgelassen, schien unnötig und schadet der zweizeiler-keit )

Warum verwendest du endl wenn nur ein Zeilenumbruch gewünscht ist? Warum nicht einfach '\n' ?

(it+1 != myData.end())

Man kann auch etwas vor end() einfügen - es scheint als ob du das (oder die Einfüge-Semantiken i.A.) nicht wusstest.

Zudem definierst du die Konstante NO , verwendest sie aber gar nicht.

PS: Bitte den Code formatieren bevor du ihn postest (das sollte er eigentlich ohnehin sein!).
Tja, formatiert ist er schon irgendwie.

PS: Bitte den Code formatieren bevor du ihn postest (das sollte er eigentlich ohnehin sein!).
Tja, formatiert ist er schon irgendwie.

Auf der Suche nach "Style" bin ich irgendwann bei "passt schon" hägengeblieben.
Ich wäre für jede Anregung eines Profis dankbar!!

Das mit dem Iterator stimmt so?

Man kann auch etwas vor end() einfügen - es scheint als ob du das (oder die Einfüge-Semantiken i.A.) nicht wusstest.

Da hast du Recht, das muss ich (unter anderem) nochmal überarbeiten. Die Einfüge-Semantik im Allgemeinen... Wie meinst du das genau?

Auf der Suche nach "Style" bin ich irgendwann bei "passt schon" hägengeblieben.
Ich wäre für jede Anregung eines Profis dankbar!!

Hauptaufreger ist wohl diese Stelle:

if(check == YES && (it+1 != myData.end()) ){
        std::cout<<"\n\tInserted!!\n";     
        it=myData.insert(it+1,spec ) ;
        spec+=100.0;
    }  else{
             std::cout<<"\nInsert not possible or requested\n";
       }

Das ist schlecht, da die Logik des if-else-Konstrukts nicht gut sichtbar ist. Besser:

if(check == YES && (it+1 != myData.end())){
    std::cout<<"\n\tInserted!!\n";     
    it=myData.insert(it+1,spec ) ;
    spec+=100.0;
  } 
  else{
    std::cout<<"\nInsert not possible or requested\n";
  }

Ich persönlich hasse die '{' am Zeilenende und würde es so machen:

if(check == YES && (it+1 != myData.end()))
    {
      std::cout<<"\n\tInserted!!\n";     
      it=myData.insert(it+1,spec ) ;
      spec+=100.0;
    } 
  else
    {
      std::cout<<"\nInsert not possible or requested\n";
    }

Dann gehen wir nochmal den Code selbst durch und setzen ein paar Leerzeichen und entfernen ein paar an anderer Stelle:

if(check == YES && (it + 1 != myData.end()))
    {
      std::cout << "\n\tInserted!!\n";     
      it = myData.insert(it + 1, spec);
      spec += 100.0;
    } 
  else
    {
      std::cout << "\nInsert not possible or requested\n";
    }

(Wo wir schon dabei sind: Multiple exclamation marks are a sure sign of a diseased mind)

Allgemein:
http://en.wikipedia.org/wiki/Indent_style
Wichtig ist jedenfalls, dass die logische Blockstruktur des Codes gut sichtbar ist. Ebenso macht man das bis hinunter auf die Ebene der Ausdrücke. Zwischen Ausdrücken und den Operatoren, die sie verbinden, kommt ein Leerzeichen, um die logische Trennung hervorzuheben:
http://en.wikipedia.org/wiki/Programming_style#Spaces

(Wo wir schon dabei sind: Multiple exclamation marks are a sure sign of a diseased mind)

I guess, that´s right, why else should i start trying to program c++ :-)))

void vect_dyn2(void){ // du brauchst hier kein void in die Klammern schreiben

Müssen wahrscheinlich nicht, aber falsch ist es auch nicht.

void vect_dyn2(void){ // du brauchst hier kein void in die Klammern schreiben

Müssen wahrscheinlich nicht, aber falsch ist es auch nicht.

Es ist sehr ungewöhnlich. Die anderen stolpern beim Lesen drüber. Die denken sich, daß Du echt die falschen Bücher liest. Und ich lese mir dann schon die Sachfrage gar nicht durch, da ich regelmäßig die Erfahrung mache, daß Proggern, die so weit auf Abwegen sind, nicht sehr zu helfen ist.

Es ist sehr ungewöhnlich. Die anderen stolpern beim Lesen drüber. Die denken sich, daß Du echt die falschen Bücher liest. Und ich lese mir dann schon die Sachfrage gar nicht durch, da ich regelmäßig die Erfahrung mache, daß Proggern, die so weit auf Abwegen sind, nicht sehr zu helfen ist.

Geht mir bei vielen anderen Dingen ähnlich.

int mach_was();

festgelegt habe, es müsse int mach_was(void) heißen.
Also ich hab mir das dann so angewohnt, funktionen ohne Parameter mit foo(void) zu machen. Sollte ich mir das wieder abgewöhnen? Prinzipiell ist es ja egal, oder?

Wie meinst du das genau?

Ein Element wird immer vor dem Iterator eingefügt der der insert -Methode übergeben wurde. Das geht einher mit rechtsoffenen Intervallen.

Das mit dem Iterator stimmt so?

Ja, aber ich würde es so

for (auto it=myData.begin(); it != myData.end(); ++it)

schreiben. Das mit dem Präfix-Inkrement ist Konsistenz - und auto spart seit C++11 viel Schreibarbeit.

Vielleicht würde ich myData.end() zwischenspeichern falls das eine performance-kritische Schleife ist. Range-based for Schleifen machen das automatisch.

for (auto d : myData)

Offenbar brauchst du aber den Iterator in der Schleife, daher ist das hier nicht einsetzbar.

Ich muss dazu sagen, das ich hier im Forum, Abteilung 'C' zurecht gewiesen wurde (hört sich jetzt härter an als es war )dass ich funktionen mit

int mach_was();

festgelegt habe, es müsse int mach_was(void) heißen.

Richtig, das ist auch gut so.
Denn in C gibt es ein Feature, dass so eine Dekleration für sämtliche Argumente passt, d.h. ebenfalls für int mach_was(int) oder int mach_was(float, float) ( http://ideone.com/WReK4S ).
In C++ gibt es das nicht, weswegen das void überflüssig ist. Einen wirklichen Grund das wegzulassen, außer, dass es alle machen, hab ich aber auch nicht.

Ich muss dazu sagen, das ich hier im Forum, Abteilung 'C' zurecht gewiesen wurde

C hat doch gar nichts mit C++ zu tun. Lerne nicht beide Sprachen gleichzeitig.

C hat doch gar nichts mit C++ zu tun. Lerne nicht beide Sprachen gleichzeitig.

Mach ich nicht gleichzeitig. C hab ich für mich "soweit abgeschloßen" (ich bin natürlich Welten von Euch Profis entfernt, für mich ist es aber auch nur ein Hobby, mein Geld verdien ich zwar auch mit Programmieren, aber komplett andere Schiene.), das es für meine Bedürfniße reicht, jetzt will ich hald in C++ "reinschnuppern" bzw. mir da einen Grundstock erarbeiten.

Denn in C gibt es ein Feature, dass so eine Dekleration für sämtliche Argumente passt, d.h. ebenfalls für int mach_was(int) oder int mach_was(float, float) ( http://ideone.com/WReK4S ).
In C++ gibt es das nicht, weswegen das void überflüssig ist. Einen wirklichen Grund das wegzulassen, außer, dass es alle machen, hab ich aber auch nicht.

Jetzt wo du es sagst, stimmt, da war mal was.

Variante 1 :

if ( x == y ){
    bla bla;
}

oder
Variante 2 :

if (x == y){
    bla bla;
}

abgesehen von den Klammern, wills jetzt nicht übertreiben mit den Leerzeichen?

Noch was zum Stil:

Variante 1 :

if ( x == y ){
    bla bla;
}

oder
Variante 2 :

if (x == y){
    bla bla;
}

abgesehen von den Klammern, wills jetzt nicht übertreiben mit den Leerzeichen?

Ich empfehle, fast alle nutzlosen Leerzeichen wegzumachen. Es ist UNMÖGLICH, einen einigermaßen konsistenten Stil mit Leerzeichen hinzukriegen.

for (auto it=myData.begin(); it != myData.end(); ++it)

Da sieht mans Elende doch schon. != kriegt Leerzeichen aber = nicht. Die Leerzeichenschmücker (leider noch in der deutlichen Überzahl) bemerken diese Unschönheiten scheinbar gar nicht, aber mir kommts Kotzen. () kriegen Leerzeichen drum bei Schleifen aber nicht bei Funktionsaufrufen? Wo ist da der Sinn? Das alles ist eine Sammlung von aberwitzig vielen persönlichen Sonderregelungen.

Also ganz einfach

for(auto it=myData.begin();it!=myData.end();++it)

und dafür die Schriftart um 2-5 Punkte größer einstellen.

Wobei mich an stört, wenn die öffnenden und schließenden Klammern nicht in einer Spalte stehen.

cpp_beginner_offl schrieb:

Noch was zum Stil:

Variante 1 :

if ( x == y ){
    bla bla;
}

oder
Variante 2 :

if (x == y){
    bla bla;
}

abgesehen von den Klammern, wills jetzt nicht übertreiben mit den Leerzeichen?

Ich empfehle, fast alle nutzlosen Leerzeichen wegzumachen. Es ist UNMÖGLICH, einen einigermaßen konsistenten Stil mit Leerzeichen hinzukriegen.

for (auto it=myData.begin(); it != myData.end(); ++it)

Da sieht mans Elende doch schon. != kriegt Leerzeichen aber = nicht. Die Leerzeichenschmücker (leider noch in der deutlichen Überzahl) bemerken diese Unschönheiten scheinbar gar nicht, aber mir kommts Kotzen.

Ehm, wenn dann ist man auch konsequent:

for (auto it = myData.begin(); it != myData.end(); ++it)

Leerzeichen kommen nach Trennern wie , ; (wie im Deutschen) und vor und hinter binären Operatoren.
Nach und vor Klammern kommen keine Leerzeichen, außer bei if, while, for,... da kommt ein Leerzeichen nach dem Keyword.
Das ist dann auch konsequent.

Von den beiden: Variante 2.

Wobei mich an stört, wenn die öffnenden und schließenden Klammern nicht in einer Spalte stehen.

Mich stört, wenn die schließende Klammer nicht unter dem ersten Zeichen von if/while/for… steht, also Dein Vorschlag

if(...)
  {
    tuwas1();
    tuwas2();
  }
else
  {
    anderes();
  }

von der ersten Seite geht gar nicht.

Sehr spät bin ich umgestiegen von

if(...)
{
    tuwas1();
    tuwas2();
}
else
{
    anderes();
}

nach

if(...){
  tuwas1();
  tuwas2();
}
else
  anderes();

, weil mir die Klammern eher die Übersicht nehmen, als was zu bringen. Ich wünschte mir, allein die Einrückung würde steuern.

if(...)
  tuwas1();
  tuwas2();
else
  anderes();

~(Dann geht natürlich wieder einiges an der Schriftgröße!)~

Macht wohl jeder wie er will . Für mich definitv v2 ! ( Auch wenn bei umfangreicheren Bedingungen mal 4 )))) zusammenkommen )

Leerzeichen kommen nach Trennern wie , ; (wie im Deutschen) und vor und hinter binären Operatoren.
Nach und vor Klammern kommen keine Leerzeichen, außer bei if, while, for,... da kommt ein Leerzeichen nach dem Keyword.
Das ist dann auch konsequent.

+1

Wobei ich es lustig finde dass darüber noch diskutiert wird. Ich hab' den Eindruck dass das schon ein quasi-Standard ist. Man sieht nicht viel Code in Open-Source Projekten der was Leerzeichen angeht anders formatiert wäre.
Ist auch die Standardeinstellung von Visual Studio. Bei anderen IDEs nehme ich an dass die Standardeinstellungen auch so sind, aber ausprobiert hab' ich es nicht.

Sehr spät bin ich umgestiegen von

if(...)
{
    tuwas1();
    tuwas2();
}
else
{
    anderes();
}

Ist imho die übersichtlichste Sache.

UltraEdit macht das sehr schön mit gepunkteten Linien von Block zu Block.

'{' am Zeilenende geht gar nicht. Völlig unübersichtlich.

Und - Klammern müssen schon sein wenn man nicht von Basic kommt. (asm ist wieder ne andere Baustelle)

volkard schrieb:

Sehr spät bin ich umgestiegen von

if(...)
{
    tuwas1();
    tuwas2();
}
else
{
    anderes();
}

Ist imho die übersichtlichste Sache.

So sehe ich das auch. Der einzige Nachteil dieser Variante (dass es mehr Zeilen braucht und daher u.U. gewisse Dinge nicht mehr auf den Monitor passen sodass man dauernd scrollen muss) wird durch neuere IDEs, bei denen man Codeblöcke reduzieren / einklappen kann, ausgebügelt.