3. Sprachmittel, die ihr nie benutzt

Sprachmittel, die ihr nie benutzt

  • C

    Nexus schrieb:

    CStoll schrieb:

    globale Variablen ein (letztere aus Prinzip und wegen der dadurch möglichen Nebeneffekte).

    Konstanten habe ich manchmal, vor allem in .cpp-Dateien. Ich weiss nicht, ob du zu den Leuten gehörst, für die Konstanten keine Variablen sind 😉

    globale Konstanten halte ich für unproblematisch, Variablen (in dem Sinn, daß sich ihr Wert ändern kann) führen schnell zu Spagetti-Code und endlosen Debugging-Sitzungen, weil du nicht einschränken kannst, wo sie tatsächlich genutzt und verändert werden (häufig an einer Stelle, die mit dem eigentlichen Problem gar nichts zu tun haben sollte).

    0
  • N

    asdsad schrieb:

    Objekt * tmp = const_cast<Objekt *>(GetConstMember());
delete tmp; // Futsch ist der const Member

    Wer ohne zu denken delete auf Zeiger anwendet, nimmt die Probleme geradezu in Kauf. Als Bibliotheksentwickler kann man doch nicht auf solche Leute Rücksicht nehmen. Übrigens brauchst du dafür nicht mal const_cast .

    asdsad schrieb:

    Wenn man einen [] hat der einmal ein eine const memberfunktion und einmal zuordnung ist muss man zwangsläufig duplizieren oder const_casten.

    Lustig, jetzt habe ich tatsächlich gerade eine Codestelle entdeckt, wo ich etwa 5 Zeilen Code dupliziere, allerdings kein Operator. Könnte ich mir echt const_cast überlegen 🙂

    CStoll schrieb:

    globale [...] Variablen [...] führen schnell zu Spagetti-Code und endlosen Debugging-Sitzungen

    Völlig einverstanden 😉

    0
  • 3

    Nexus schrieb:

    • Exception-Spezifikationen Ebenfalls nicht.
    • variable Argumentlisten Nur für Meta-Programming.
    • Speicherklassen-Schlüsselwörter register und auto Ebenfalls nicht.
    • protected -Vererbung Ebenfalls nicht.
    • Pointer-to-Member (nicht Memberfunktionszeiger) Ebenfalls nicht.
    • Function-Style- und C-Casts Ebenfalls nicht.
    • Bitfelder Extrem selten. Wenn ich mal bools packen möchte und Namen dazu haben will.
    • Digraphen, Trigraphen, alternative Schlüsselwörter ( and etc.) Ebenfalls nicht.
    • export Ebenfalls nicht.

    Sehr selten:

    • virtuelle Vererbung Gar nicht.
    • eigene new - und delete -Operatoren Ebenfalls selten.
    • Funktionstemplate-Spezialisierung Das sagt mir jetzt nichts. Vermutlich erkenne ich's soofort, wenn ich's sehe.
    • const_cast , dynamic_cast const_cast noch nie, danymic_cast sehr selten.
    • union Gelegentlich.
    • goto Nie.
    • volatile Annähernd nie.
    • Arrays Für const char [], die zur Compilezeit bekannt sind. Ansonsten nicht.*
    0

  • Wurde die Symmetrie des eingebauten Indexing Operators schon genannt?

    Also dass pointer[index] einfach zu *(pointer+index) wird, und man es daher auch als index[pointer] schreiben kann?

    Das ist nämlich auch was was ich nie verwende.

    0
  • C

    Interessanter wird es doch bei der Frage: Auf was könntet ihr verzichten? Also bei mir wären da nur Trigraphen, register, auto. Wobei auto von C++11 wohl eh eine neue Bedeutung bekommt.

    0
  • V

    hustbaer schrieb:

    Wurde die Symmetrie des eingebauten Indexing Operators schon genannt?

    Es ist eher die Symmetrie des eingebauten Plus-Operators.

    0
  • A

    Sprachmittel, die ich nie einsetze:

    • Exception-Spezifikationen
    • variable Argumentlisten
    • Speicherklassen-Schlüsselwörter register und auto
    • protected -Vererbung
    • Pointer-to-Member (nicht Memberfunktionszeiger)
    • Bitfelder
    • Digraphen, Trigraphen, alternative Schlüsselwörter ( and etc.)
    • export
    • eigene new - und delete -Operatoren
    • union
    • goto
    • volatile
    • Arrays
    • C-String

    Sprachmittel, die ich selten einsetze:

    • Globale Variablen (und wenn auch nur für Objekt-Registrierung an anderen Klassen, oder Konstanten).
    • #define (Nur für Headerguards und bedingte Compilierung, niemals für Konstanten und Funktionsersatz)
    • delete (In der Regel ziehe ich Smartpointer wie scoped_ptr/unique_ptr & Co vor).
    0

  • volkard schrieb:

    hustbaer schrieb:

    Wurde die Symmetrie des eingebauten Indexing Operators schon genannt?

    Es ist eher die Symmetrie des eingebauten Plus-Operators.

    Hihi, OK.
    Dann eben dass der Indexing-Operator auf *(a+b) abgebildet wird.
    Und Symmetrie ist sicher auch der falsche Ausdruck, aber ich glaube ihr versteht was ich meine.

    0
  • B

    hustbaer schrieb:

    volkard schrieb:

    hustbaer schrieb:

    Wurde die Symmetrie des eingebauten Indexing Operators schon genannt?

    Es ist eher die Symmetrie des eingebauten Plus-Operators.

    Hihi, OK.
    Dann eben dass der Indexing-Operator auf *(a+b) abgebildet wird.

    Das ist soweit eigentlich OK, es ist wirklich die Kommutativität von +, die nicht immer sinnvoll ist.

    0
  • N

    Bashar schrieb:

    Das ist soweit eigentlich OK, es ist wirklich die Kommutativität von +, die nicht immer sinnvoll ist.

    Wo sonst? Und findest du die Nicht-Kommutativität bei std::string sinnvoll?

    0
  • V

    Nexus schrieb:

    Bashar schrieb:

    Das ist soweit eigentlich OK, es ist wirklich die Kommutativität von +, die nicht immer sinnvoll ist.

    Wo sonst? Und findest du die Nicht-Kommutativität bei std::string sinnvoll?

    Da war die Wahl de Zeichens '+' eine unglückliche Wahl.

    0
  • B

    Nexus schrieb:

    Bashar schrieb:

    Das ist soweit eigentlich OK, es ist wirklich die Kommutativität von +, die nicht immer sinnvoll ist.

    Wo sonst? Und findest du die Nicht-Kommutativität bei std::string sinnvoll?

    Ja klar, warum nicht?

    0
  • A

    volkard schrieb:

    Nexus schrieb:

    Wo sonst? Und findest du die Nicht-Kommutativität bei std::string sinnvoll?

    Da war die Wahl de Zeichens '+' eine unglückliche Wahl.

    Das ist Geschmackssache, ich finde es jedenfalls durchaus intuitiv bei der Anwendung.

    0
  • V

    asc schrieb:

    Das ist Geschmackssache, ich finde es jedenfalls durchaus intuitiv bei der Anwendung.

    Ich finde . und & auch nicht schlecht, in Basic-Dialekten, wo + und & gehen, bevorzuge ich &.

    0
  • Mod

    Hier auch mal mein Senf, falls es jemandem interessiert:
    Sprachmittel, die ich nie einsetze:

    • Exception-Spezifikationen
    • variable Argumentlisten
    • Speicherklassen-Schlüsselwörter register und auto (in seiner alten Bedeutung)
    • Pointer-to-Member (nicht Memberfunktionszeiger) (nur mal versehentlich, als ich einem Compilerfehler begegnet bin)
    • Function-Style- und C-Casts
    • Bitfelder
    • Digraphen, Trigraphen (man beachte, dass ich die alternativen Schlüsselwörter ausdrücklich benutze!)
    • export
    • eigene new - und delete -Operatoren
    • dynamic_cast
    • union
    • goto , Labels
    • volatile
    • Inline-Assembler
    • wchar_t , wide Strings & Co.
    • Lokale Klassen (d.h. Klassen in Funktionen, nicht Klassen in Klassen)
    • operator->* , operator~
    • Überladung von: operator->* , operator& , operator~ , operator+ (unär), logische Verknüpfungsoperatoren.
    • Präprozessordirektiven: #line, #error, Nulldirektive 😃 , im Standard vordefinierte Makros (die sind total nutzlos!)

    Sehr selten:

    • virtuelle Vererbung
    • Funktionstemplate-Spezialisierung
    • const_cast
    • Arrays
    • switch Ja, kaum zu glauben, aber es kommt einfach nie vor, außer bei Hausaufgaben im Forum.
    • mutable
    • explicit Auch kaum zu glauben. Aber meine Konstruktoren haben irgendwie immer entweder 2+-Argumente oder sollen tatsächlich implizit sein.
    • float, short, signed char, long double
    • continue
    • Überladung von: operator, , operator- (unär)

    Das ist meine Liste nach Durchgehen der Beiträge hier im Thread und Lesen der Überschriften im Standard bis Kapitel 17 (wo die Sprachbibliothek losgeht).

    0
  • K

    Ich kann im Wesentlichen Nexus zustimmen. Kleine Unterschiede/Ergänzungen:

    - Pointer-to-Member: Kommen hin- und wieder mal vor in Verbindung mit bind.
    - Spezialisierung von Funktions-Templates: Nie.
    - volatile: Nie.
    - Polymorphe Basisklassen sind immer abstrakt bei mir.

    0
  • N

    SeppJ, du hast noch einiges aufgezählt, das ich auch nie verwende. Z.B. Inline-Assembler, funktionslokale Klassen (deren Schicksal ist mit Lambdas eh besiegelt) und #line . Operatoren und Typen verwende ich auch nicht alle. Und die Nulldirektive kannte ich gar nicht, muss ich von nun an öfter einsetzen 🤡

    Aber wenn ich den C++-Standard kürzen müsste, würde ich wahrscheinlich mit all den alternativen Schreibweisen anfangen (besonders Di/Trigraphen benutzt eh niemand, und für die Schlüsselwörter reichen auch Makros :p). Exception-Spezifikationen sind wenigstens bald deprecated, export wird ganz entfernt. Bei VarArgs oder register wirds wohl wegen C-Kompatibilität noch ewig dauern, falls die überhaupt jemals rausfliegen. Der Rest sollte okay sein, auch wenn ich persönlich nicht Gebrauch davon mache.

    0
  • Mod

    Nexus schrieb:

    Und die Nulldirektive kannte ich gar nicht, muss ich von nun an öfter einsetzen 🤡

    Ja, die war mir auch neu, ich bin nur im Standard drüber gestolpert und musst erst einmal lesen, was das überhaupt ist.

    0
  • ?

    Nexus schrieb:

    Exception-Spezifikationen sind wenigstens bald deprecated, export wird ganz entfernt.

    Good point. Aber wieso ist im neuen Standard noexcept drin? Tut es nicht genau das selbe?

    0
  • N

    exceptthis schrieb:

    Good point. Aber wieso ist im neuen Standard noexcept drin? Tut es nicht genau das selbe?

    Nein, noexcept ist schon sinnvoll, um Funktionen mit Nothrow-Garantie kennzuzeichnen.

    Es gab hier schon ein paar Threads dazu, da könntest du Genaueres darüber finden. Z.B. ab hier (ist etwas viel Noise, beachte vor allem die Beiträge von krümelkacker und Shade Of Mine).

    0
Anmelden zum Antworten