Sprachmittel, die ihr nie benutzt

satanfreze

Wenn ich pur C++ programmiere, dann verwende ich selten...

- char* btw. char[] (stattdessen die string-Klasse)
- defines
- structs
- protected Vererbung

Da fallen mir noch ein dutzend mehr Dinge ein.

Nexus

CStoll schrieb:

Funktionszeiger

Brauche ich oft – meist um sie gleich in eine std::function zu stecken, aber von Zeit zu Zeit werden sie auch direkt abgespeichert.

CStoll schrieb:

#define (außer für Include-Guards)

Habe ich auch ab und zu. Nicht nur für Konfiguration und bedingte Kompilierung, sondern auch, um Boilerplate-Code wie Traits-Spezialisierungen anwenderfreundlich zu machen.

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

satanfreze schrieb:

- char* btw. char[]

Benutze ich für Stringliterale.

satanfreze schrieb:

- structs

Habe ich andauernd für Funktoren und kleine Hilfsklassen.

Nexus schrieb:

Brauche ich schon ab und zu. Ich sehe auch nichts, was dagegen spricht, wenn der Zeiger keinen Besitz überträgt.

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

dynamic_cast <-- ist irgendwie dazwischengerutscht

Nexus schrieb:

Und bei mir sind solche Operatoren wohl meist trivial genug gewesen, um Code zu duplizieren...

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

CStoll

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

Nexus

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

314159265358979

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

hustbaer

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.

cooky451

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.

volkard

hustbaer schrieb:

Wurde die Symmetrie des eingebauten Indexing Operators schon genannt?

Es ist eher die Symmetrie des eingebauten Plus-Operators.

asc

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

hustbaer

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.

Bashar

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.

Nexus

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?

volkard

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.

Bashar

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?

asc

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.

volkard

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

SeppJ

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

krümelkacker

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.

Nexus

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.