3. C++ 11 (benutzen?)

C++ 11 (benutzen?)

  • ?
     

    int iVal = 0;  // int C++11 besser: int iVal{0};

    Warum sollte das besser sein?

    0
  • S

    ????? schrieb:

    int iVal = 0;  // int C++11 besser: int iVal{0};

    Warum sollte das besser sein?

    Frage ich mich auch.

    immer schön auto verwenden beim Initialisieren

    Wieso das? Dann kann man ja gar nichts mehr lesen. Ich verwende für Skalare und Co. immer explizite Typangaben, um mir die Literalsuffixe zu sparen. IDEs können die Typen auch nur schwer deduzieren, daher muss man immer genau auf den initializer gucken, um den Typ zu bekommen. Das ist doch doof. Daher benutze ich auto relativ selten.

    0
  • S

    Für irgendwelche (map-) Iteratoren ist auto cool 😃

    0
  • ?

    Sone schrieb:

    Wieso das? Dann kann man ja gar nichts mehr lesen. Ich verwende für Skalare und Co. immer explizite Typangaben, um mir die Literalsuffixe zu sparen. IDEs können die Typen auch nur schwer deduzieren, daher muss man immer genau auf den initializer gucken, um den Typ zu bekommen. Das ist doch doof. Daher benutze ich auto relativ selten.

    Naja, ich machs halt so wie Herb es geraten hat. Wieso brauchst du die Suffixe? Klar f für float bruach ich auch mal aber die anderen brauch ich irgendwie nicht. Ich bin mit auto=int zufrienden:D

    0
  • K

    ????? schrieb:

    int iVal = 0;  // int C++11 besser: int iVal{0};

    Warum sollte das besser sein?

    Falsche Frage. Die Frage lautet: {} ist umstaendlicher zu Tippen und sieht absolut unnatuerlich aus. Welchen Mehrwert bietet es?
    Antwort: {} ist genau dasselbe in Himmelblau, = ist ein Token weniger und verwirrt Leute ohne C++11 Kenntnisse nicht.

    Ich selbst nehme generell Abstand von Uniform Initialization wann immer moeglich und halte das alles fuer grossen Bockmist. Gruende wurden in verschiedensten Threads schon mehrmals genannt.

    0
  • K

    ????? schrieb:

    int iVal = 0;  // int C++11 besser: int iVal{0};

    Warum sollte das besser sein?

    Die "narrowing conversions" hat C++ von C geerbt. Die neue Initialisierungssyntax muss sich daran aber nicht halten. Wenn Du versehentlich

    int iVal = 3.14;

    schreibst, wird der Compiler höchstens eine Warnung ausgeben, wobei er bei

    int iVal {3.14};

    meines Wissens nach einen Fehler bzgl. narrowing ausgeben muss. Es ist also ein bisschen typsicherer.

    Ich lass mich da gerne korrigieren. Diesen ganzen neuen "Initialisierungsmist" mit all seinen Sonderregeln konnte ich mir bisher nicht merken. Ich weiß z.B. auch gerade nicht, ob das Vorhandensein eines Gleichzeichens ein Unterschied bzgl narrowing macht:

    int iVal = {3.14}; // ?

    und wenn nicht, was ist dann mit Arrays, die sich so ja schon imer haben initialisieren lassen? K.A. ...

    0
  • K

    http://ideone.com/qUzbim

    0
  • K

    na supi. Und was war das, was ich bzgl "narrowing conversions" und der neuen Initialisierungssyntax im Kopf habe? Da war doch was ...

    Oder ist GCC 4.8 da einfach noch zu gnädig?

    0
  • K

    http://goo.gl/2Z58aO
    Der hier spuckt zumindest eine Warning aus. Ohne -Werror krieg ich aber keinen Compilerfehler hin.

    Edit: Sorry fuer den Link-Shortener, normalerweise mache ich sowas nicht, aber der Highlighter im Forum erkennt die URL sonst nicht.

    0
  • S

    Kellerautomat schrieb:

    Ich selbst nehme generell Abstand von Uniform Initialization wann immer moeglich und halte das alles fuer grossen Bockmist.

    Ich tendiere leider zu deiner Meinung. Mehr und mehr, auch wenn in aktuellen Projekten auch penibel durchgesetzt, sehe ich keinen wirklichen Sinn.
    Zumal es nicht konsequent durchgesetzt werden kann, wegen solchen "Sonderfällen" wie der Konstruktor von vector o.ä., irgendwie unschön.

    Es hat allerdings auch Vorteile. Einer davon ist bspw. der, dass die Auswertungsreihenfolge der initializer-clauses definiert ist (links rechts), für variadic templates eine gute Sache.

    @kk: Guck doch mal im Standard.

    if the initializer list has a single element of type E and either T is not a reference type or its referenced type is reference-related to E, the object or reference is initialized from that element; if a narrowing conversion (see below) is required to convert the element to T, the program is ill-formed.

    Das Beispiel dazu:

    int x1 {2};// OK
int x2 {2.0};// error: narrowing

    GCC 4.8 ist leider sehr gnädig.
    copy-list-initialization und direct-list-initialization sind übrigens für Skalare vollkommen gleich (werden nicht einmal separat behandelt).

    0
  • ?

    Also im "alten" Standard gibt es eigentlich mehr Sonderfälle, wie z.B. hier:

    int a(1);	// variable definition
	int b();	// function declaration
	int b(foo);	// variable definition or function declaration

    siehe http://www.stroustrup.com/C++11FAQ.html#uniform-init

    0
  • ?

    manni66: Deshalb benutzt man auch nicht "()", sondern "=".

    0
  • ?

    Michael E. logged out schrieb:

    manni66: Deshalb benutzt man auch nicht "()", sondern "=".

    Eben, das nennt man dann Sonderfälle.

    0
  • K

    Kellerautomat schrieb:

    http://goo.gl/2Z58aO
    Der hier spuckt zumindest eine Warning aus. Ohne -Werror krieg ich aber keinen Compilerfehler hin.

    Immerhin. Das ist schon mehr als sonst. 🙂

    0
Anmelden zum Antworten