Kleine Umfarge: C++09 oder Ur-C++

Dravere

player424 schrieb:

Aber wozu braucht ihr eine Klasse für etwas, dass schon fest in der Sprache eingebaut ist (std::array)?

std::array und ein C-Array sind zwei grundverschiedene Sachen. Ein C-Array ist äusserst flüchtig und du endest im Nu mit einem Zeiger ohne Informationen über die Grösse des Arrays oder eine sinnvolle Möglichkeit das Array zu kopieren. std::array gibt dir wirklich ein Array mit konstanter Grösse, welches du auch als Array behandeln kannst. Grundsätzlich wird std::array das C Array vollständig ablösen können.

player424 schrieb:

Und was die Tuple-Klasse angeht: Mir fallen spontan nur wenige Beispiele ein, bei denen man so etwas brauchen könnte.

Immer wenn man etwas kurz gruppieren möchte. Das kann für viele Fälle sinnvoll sein, von Rückgabewerte bis hin zu Algorithmen, wo man temporär Dinge zusammenbinden muss. Das praktische ist, man muss nicht immer wieder eine eigene kleine Struktur basteln. Ist grundsätzlich ähnlich wie die Lambda-Ausdrücke, es erleichtert einem das Leben.

Grüssli

Gibts denn auch ne schöne möglichkeit darauf zu zu greifen? das std::get<n> konstruk ist irgendwie ziemlich... groß.

Der ganze STL Kram ist allgemein sehr klobig. Schau dir mal std::cout an. Damit etwas tabellarisch auszugeben ist genau so eleganz wie einen essay in den schnee zu pinkeln. Dagegen ist das C typische printf elegant und schlank.

Der ganze STL Kram ist allgemein sehr klobig.

Ist es klobig std::vector<MyClass> zu schreiben und dann ein dynamisches Array von Objekten der Klasse MyClass zu haben?

Schau dir mal std::cout an.

std::cout gehört nicht zu Standard Template Library...

Damit etwas tabellarisch auszugeben ist genau so eleganz wie einen essay in den schnee zu pinkeln. Dagegen ist das C typische printf elegant und schlank.

...und fehleranfällig.

mngbd

Wenn man keine Ahnung hat schrieb:

...und fehleranfällig.

Aber nur wenn man wild castet, das geht in C++ dann wohl auch schief. Wenn man das nicht tut, kann der Compiler die Typen genauso überprüfen wie überall sonst.

SeppJ

mngbd schrieb:

Wenn man keine Ahnung hat schrieb:

...und fehleranfällig.

Aber nur wenn man wild castet, das geht in C++ dann wohl auch schief. Wenn man das nicht tut, kann der Compiler die Typen genauso überprüfen wie überall sonst.

Dummerweise funktioniert das aber auch nur, weil es eine überschaubare Anzahl von zulässigen Datentypen für printf gibt. In einer Sprache wo eigene Datentypen ganz alltäglich sind, geht das Konzept nicht mehr auf.

mngbd schrieb:

Wenn man keine Ahnung hat schrieb:

...und fehleranfällig.

Aber nur wenn man wild castet, das geht in C++ dann wohl auch schief. Wenn man das nicht tut, kann der Compiler die Typen genauso überprüfen wie überall sonst.

Dann sag mir, wo du hier einen Cast siehst

char x = 12;

// ...

printf("%d", x);

Kompiliert, ist aber undefiniert.

Bashar

Das ist nicht undefiniert. Befass dich mal mit integer promotions.

DerKuchen

Dann versuchs mit

char x = 12;
printf("%s", x);

mngbd

DerKuchen schrieb:

Dann versuchs mit
char x = 12;
printf("%s", x);

Zumindest der gcc erkennt den Unsinn:

$ gcc -x c -std=c99 -Wall -
#include <stdio.h>

int main(void) {
  char x = 12;
  printf("%s", x);
} 
<stdin>: In Funktion »main«:
<stdin>:5: Warnung: format »%s« erwartet Typ »char *«, aber Argument 2 hat Typ »int«

Zumindest der gcc erkennt den Unsinn

Er erkennt ihn vielleicht, aber er verhindert ihn nicht.
Der aktuelle MS Compiler gibt übrigens (in der Standardeinstellung) keine Warnung aus.

mngbd

Erkenner schrieb:

Er erkennt ihn vielleicht, aber er verhindert ihn nicht.

Was soll er denn noch tun? Die Polizei rufen?

Erkenner schrieb:

Der aktuelle MS Compiler gibt übrigens (in der Standardeinstellung) keine Warnung aus.

Der gcc auch nicht, Archaismus. Vielleicht tut's der MS-Compiler ja, wenn man lieb zu ihm ist. Aber vielleicht auch nicht, MS kann ja C bekanntlich nicht so recht leiden.

Was soll er denn noch tun? Die Polizei rufen?

Nein, aber es geht hier um die Nachteile von printf() gegenüber den IOStreams. Letztere sind nämlich typsicher und würden ggf. in so einem Fall gar nicht kompilieren.

wxSkip

Jonas OSDever schrieb:

Ich bin nur der Meinung**,** dass manche neuen Sprachkonzepte schwierig zu handhaben sind und manchmal weniger bringen als sie kosten.

Was kosten sie denn? Dich eine Installation eines neuen Compilers? Mehr Lernaufwand, weil sie in Teilen der Standardbibliothek verwendet werden, die du sonst sowieso nicht benutzen könntest? Ich werde manche Teile des neuen Standards wahrscheinlich auch kaum gebrauchen, aber das ist für mich kein Problem - dafür können mir z.B. erweiterte Standardbibliothek, Variadic Templates, Initializer Lists, auto/decltype, UTF-Strings und static asserts neue Möglichkeiten eröffnen oder Schreibarbeit sparen.

krümelkacker

Erkenner schrieb:

Was soll er denn noch tun? Die Polizei rufen?

Nein, aber es geht hier um die Nachteile von printf() gegenüber den IOStreams. Letztere sind nämlich typsicher und würden ggf. in so einem Fall gar nicht kompilieren.

Ja und? Das kannst Du mit beim GCC mit -Wall -Wformat=2 -Werror auch haben. Klar, der C Standard fordert so ein Verhalten nicht ein. Aber das macht ja nichts. Wenn der GCC das anbietet, warum nicht bei der Entwicklung nutzen? Ich würde mich nicht als C Programmierer bezeichnen, aber bei aller Fairness muss man den C Programmierern -- zumindest denen, die einen Compiler einsetzen, der bei solchen Dingen gescheit warnen kann -- nicht mit "Typsicherheit" kommen. Diese "Typsicherheit" ist nicht viel besser als eine Compiler-Warnung.

Klasse Argument für printf()...

Meinst du IOStreams wurde aus Spaß in den Standard aufgenommen?

Das überzeugendste Argument für IOStreams hat aber SeppJ schon gegeben:

SeppJ schrieb:

Dummerweise funktioniert das aber auch nur, weil es eine überschaubare Anzahl von zulässigen Datentypen für printf gibt. In einer Sprache wo eigene Datentypen ganz alltäglich sind, geht das Konzept nicht mehr auf.

krümelkacker

Erkenner schrieb:

Klasse Argument für printf()...

Das ist kein Argument für printf. Du hast mich und mngbd anscheinend zum dritten Mal missverstanden. Ich sage nur, dass Du die Typsicherheit-Sache zu schwarz/weiß siehst. Die Möglichkeit eines bei prinft-Format-Fehlern warnenden Compilers kehrst Du komplett unter den Teppich. Das muss ich als C++ Programmierer mit einem Sinn für Fairness so feststellen.

Erkenner schrieb:

Meinst du IOStreams wurde aus Spaß in den Standard aufgenommen?

Nein, das meine ich nicht. Das habe ich auch nie behauptet.

kk

Ich sage nur, dass Du die Typsicherheit-Sache zu schwarz/weiß siehst. Die Möglichkeit eines bei prinft-Format-Fehlern warnenden Compilers kehrst Du komplett unter den Teppich.

Ja, du hast wahrscheinlich recht. Diejenigen, die heutzutage noch mit C arbeiten, sind sich dieser Problematik hoffentlich bewusst und beachten solche Warnungen auch.

Nur solchen ewig Gestrigen, wie diesem Kandidaten hier, traue ich das nicht wirklich zu. Man weiß ja im Internet nie mit wem man es zu tun hat - das könnte irgendein normaler Forentroll sein oder ein Lehrer, der seinen Schülern so etwas eintrichtert.

Naja, um zum Thema des Thread zurückzukommen: Sinnvolle Spracherweiterungen, ob an der Standardbibliothek (z.B. damals IOStreams ) oder am Sprachkern, sind immer willkommen. Einige der kommenden Neuerungen werden vor allem den Bibliotheksschreibern helfen, andere, wie z.B. die Move-Semantik, auch unmittelbar den "normalen" Nutzern. Insgesamt ist es ein stimmiges Paket, das ruhig mal etwas zügiger beschlossen werden könnte.

War es eigentlich immer so, dass die Compiler dem Standard voraus waren? Der GCC und selbst der MSVC Compiler beherrschen ja schon viele der wichtigsten Neuerungen von C++0x.