Nach C kommt D ...

Zitat von gue

Zitat von master blue

cool.
du warst beim BH gell

Aber NUR dir.

Was ist les -und wartbarer?

Code:

std::map < std::string, std::pair < std::string, SomeStruct > > somemap;

for (std::map < std::string, std::pair < std::string, SomeStruct > > ::iterator it = somemap.begin(); it != somemap.end(); ++it) {
  ....
}

oder

Code:

typedef std::map < std::string, std::pair < std::string, SomeStruct > > SomeStructMap;

SomeStructMap somemap;

for (SomeStructMap::iterator it = somemap.begin(); it != somemap.end(); ++it) {
  ...
}

Nein, ich will solche Würschte NICHT schreiben. Ich nehme typedef. Und nein, das ist kein exotischer Fall, er passiert laufend, wenn man die STL intensiv einsetzt. Daher verwendet man SEHR OFT typedef in C++. Ich hab in meinem Code viele STL-Container, und ohne typedef wäre der Code um Welten unleserlicher. Btw. wird es in C++0x Type Deduction hauptsächlich dafür geben; dann wäre typedef hier unnötig. Also würde es so lauten:

Code:

std::map < std::string, std::pair < std::string, SomeStruct > > somemap;

for (auto it = somemap.begin(); it != somemap.end(); ++it) {
  ...
}

Natürlich, wenn man mehrere Maps/Vektoren/wasauchimmer desselben typs erzeugt, empfiehlt sich auch da ein Typedef.

Zitat

Dann zumindest in einen speziellen Namespace. Wie gesagt finde ich es besser, wenn es spezielle Klassen gibt, in die die Funktionalität gepackt ist, z.B. java.lang.Math; Ansonsten sollte die Funktionalität vom Objekt erfüllt werden (Beispiel str.toLowerCase() statt toLowerCase(str); - das habe ich mit OO-Ansatz gemeint).

Es *gibt* Funktionen, die in keiner strengen Bindung zu einer Klasse existieren (std::find ist ein guter Beispiel dafür). Für solche Funktionen verwendet man auch normalerweise Namespaces. In D schreibst du die Funktionen in Packages, und hast etwas ähnliches.

Im Übrigen will ich wissen, wie du sonst Lambda-Funktionen zusammenbringen willst..

Zitat

Die Standardrepräsentation von Strings in C ist ein 0-terminiertes Char-Array. Dass Arrays an Bibliotheksfunktionen by-reference (char *) übergeben werden ist wohl klar. Aber bitte, da du ja der C-Gott schlechthin zu sein scheinst und ich davon keine Ahnung habe, bin ich eh schon ruhig

Das 0-terminierte Array ist eine Konvention, und wird nicht von der Sprache forciert - genau das ist das Problem. In D hast du Arrays, die auch als solche bekannt sind; in C wissen Stringfunktionen nichts von Arrays, sie kennen nur einen Pointer zu einen Speicherbereich mit einem nullterminierten Array - zumindest nehmen sie an, es ist ein nullterminiertes Array, wenns keiner ist, gibts keine Chance, das rauszufinden (ausser einem Programmabsturz mit nachfolgenden tollen Debugsessions). Der Unterschied liegt in dem Informationsgehalt; wenn eine Funktion *weiss*, was ein Array ist, weiss sie auch über die Arraygrenzen Bescheid. Man kann in C auch einfach bis ins unendliche den char* pointer inkrementieren (passiert tatsächlich wenn es keinen Nullterminator gibt). Deswegen verwendet man in C++ auch std::string und nicht char*, std::vector und keine malloc/realloc-Konstrukte.

Zitat

Auch in C könnte die Laufzeitumgebung Buffer-overflows erkennen, wenn [] als Operator auf ein bestimmtes Array behandelt wird. Aufgrund der "Lässigkeit" von C wird das aber nicht gemacht.

Der [] operator ist in C eine Dereferenzierung eines Pointers mit Offset, mehr nicht. p[1]; ist äquivalent zu *(p + 1); in C++ ist das natürlich anders, weil man DORT (und nicht in C) * und [] überladen kann. []-Checks würden wahrscheinlich eine nicht unerhebliche Menge an C-Code unbrauchbar machen, weil speziell in der Pointerarithmetik sehr viel getrickst wird.

Zitat

Unterschied: unittest ist ein Sprachschlüsselwort. Will man nun etwas neues hinzufügen, muss die Sprache und somit der Compiler geändert werden. In Java hatte man das z.B. mit dem transient Schlüsselwort, das mittlerweile durch eine Annotation ersetzt wurde. Annotationen machen natürlich nur mit Reflection einen Sinn (siehe Frys_Assassin's Post).

Reflection vermisse ich in D tatsächlich. Es ist aber wahrscheinlich eher eine Versäumnis in der Standardbibliothek, da die Sprache selber die nötigen Symboltabellen zu haben scheint. Wenn es drinnen ist, können wir über Annotationen reden.