Das ist das Ende von C++!

Clw

Der Punkt ist einfach, dass diese Sachen zur D-Grammatik gehören. Warum kam die STL, die eigentlich grundlegende Dinge liefert erst später zu der C++ Spezifikation?

C++ ist (wie eigentlich alle Sprachen) historisch gewachsen. Und dass string und vector und foobar nicht zur "D-Grammatik" gehören ist doch eigentlich wurscht.

Artchi

Clw schrieb:

Der Punkt ist einfach, dass diese Sachen zur D-Grammatik gehören. Warum kam die STL, die eigentlich grundlegende Dinge liefert erst später zu der C++ Spezifikation?

Stimmt doch garnicht! Es gibt bisher nur EINE C++ Spezifikation, aus dem Jahr 1998. Und da ist die Standardlib samt std::basic_string und std::vector enthalten. Die beiden Sachen sind definitiv von ANFANG an in der ISO-Norm drin.

Informiert euch erstmal. Kein Compiler kann sich ernsthaft ISO-C++ konform nennen, wenn keine String-Klasse dabei ist. Bzw. kein C++-Programmierer wird einen Compiler benutzen, wo er keine Standardlib für hat. Und ob String in der Core-Language oder als Lib dabei ist, ist völlig irrelevant für die Zweckerfüllung.

Artchi

Clw schrieb:

Ich habe vorher C++ programmiert und ich bin echt froh, dass ich jetzt von dieser Sprache weg bin: Ich habe C++ mit Visual Studio benutzt, und nie wirklich gewusst, was ich mache, denn die IDE erstellt alles von selbst, ohne dass ich wusste was sie macht, bzw. warum (warum z.B. kann man in einer C++-Konsolenanwendung die stdafx.h nicht löschen? ...).

Tja, und was hat die IDE mit C++ zu tun? Nichts! Du hättest ja auch Notepad und den Commandline-Compiler von MSVC benutzen können.

Und stdafx.h kann man in den Projekteinstellungen ABSCHALTEN. Bzw. wenn du das Projekt neu erstellst/anlegst, kannst du es gleich abwählen. Hast dir bloss den Projekt-Wizard nicht richtig angeschaut, dann wäre dir der Punkt aufgefallen.

Soviel zu deinen Kompetenz bzgl. C++. Dann lass bitte auch Aussagen darüber, ob ISO-C++ Strings hat.

Artchi

thordk schrieb:

so, nu hat die seite mal geladen.

bezüglich resize-able arrays und strings: stimmt doch, was da steht. das unterstützt c++ nicht ohne stl. d wohl schon, is doch nett.

Und? Die Standardlib (ihr mit eurer STL immer, das ist was ganz anderes!) ist FESTER Bestandteil der ISO-C++ Spezifikation. Also hat C++ offiziell Strings und sich dynamisch ändernde Arrays (vector). Bleibt mal fair! Das String kein KEYWORD ist, stimmt. Aber mehr auch nicht.

thordk

string gehört zur standard lib, aber vector zur stl. aber is doch wurscht, wo der krams zugehört: es bleibt halt ne lib

geht nur darum, dass es auch c++ compiler gibt, die diese beiden features nicht bieten, weil sie eben ein zusatz sind, kein integraler bestandteil. in D isses anders. dass in java alles über libs geliefert wird, stört ja auch keine sau.

und? noch lang kein grund, hier den fanatiker zu spielen

thordk schrieb:

geht nur darum, dass es auch c++ compiler gibt, die diese beiden features nicht bieten, weil sie eben ein zusatz sind, kein integraler bestandteil. in D isses anders.

Dir ist schon klar, dass eine Stringklasse bei manchen Implementierungen schlicht albern wäre? Eben deswegen gibt es ja die Unterscheidung zwischen "freestanding" und "hosted" environments.

Artchi schrieb:

Clw schrieb:

Der Punkt ist einfach, dass diese Sachen zur D-Grammatik gehören. Warum kam die STL, die eigentlich grundlegende Dinge liefert erst später zu der C++ Spezifikation?

Stimmt doch garnicht! Es gibt bisher nur EINE C++ Spezifikation, aus dem Jahr 1998. Und da ist die Standardlib samt std::basic_string und std::vector enthalten. Die beiden Sachen sind definitiv von ANFANG an in der ISO-Norm drin.

Informiert euch erstmal. Kein Compiler kann sich ernsthaft ISO-C++ konform nennen, wenn keine String-Klasse dabei ist. Bzw. kein C++-Programmierer wird einen Compiler benutzen, wo er keine Standardlib für hat. Und ob String in der Core-Language oder als Lib dabei ist, ist völlig irrelevant für die Zweckerfüllung.

Darum geht es doch nicht. Der Unterschied zu D ist, dass in C++ die Standard C++-String Klasse nicht als Sprachmittel zur Verfügung steht. Wenn du schreibst "Blubb", dann ist das ein char*.

Im Vergleich dazu ist in D, Java, C# und anderen Sprachen, die Strings auf Sprachebene integrieren, ein String-Literal wirklich vom Typ String. Zum Beispiel ist dadurch sowas wie "blubblubb".ToUpper() möglich. Klar, kann man darüber streiten, wie gigantisch der Vorteil ist. Auf Sprachebene erreicht man halt eine bessere Integration. Während es für C++ zahllose String-Klassen gibt und keine so richtig in der Praxis Standard ist, hast du in D die Situation, dass jeder die eine String-Klasse benutzt, schon allein indem er ein Literal hinschreibt.

Das ist es, worum es hier geht und nicht, ob bei C++ von Anfang an std::string dabei war.

thordk

TactX schrieb:

thordk schrieb:

geht nur darum, dass es auch c++ compiler gibt, die diese beiden features nicht bieten, weil sie eben ein zusatz sind, kein integraler bestandteil. in D isses anders.

Dir ist schon klar, dass eine Stringklasse bei manchen Implementierungen schlicht albern wäre? Eben deswegen gibt es ja die Unterscheidung zwischen "freestanding" und "hosted" environments.

naja, die unterscheidung gibs aber auch nur, weil es bisschen bekloppt wär, für jedes x-beliebige embedded system o.ä. den vollen lib funktionsumfang anzubieten (garantieren zu müssen), was meist nichtmal möglich wäre.

aber was trägt das zur diskussion bei? c++ bietet dies nur an, da so keine dedizierten c compiler herhalten müssen und man bestimmte möglichkeiten von c++ ausnutzen kann, sofern anwendbar. hier trifft wieder das "historisch gewachsen" zu.

will D denselben ansatz liefern? ich denke nicht. ne sprache, die ausgerechnet mit automatischer GC wirbt, wird wohl nicht für freestanding entwicklung konzipiert worden sein.

äpfel und birnen

Zeus

Artchi schrieb:

Ja, also die Idee von D ist ja nicht schlecht. Auch wenn ich wieder ein paar Sachen aus C++ vermisse. ...

Was vermisst du denn?

Ich muss sagen ich bin nach dem ersten ansehen sehr positiv überrascht. D bietet mir Sachen die ich in C++ immer vermisst hab . Natürlich wird D C++ in nächster Zeit nicht verdrängen, aber das Potenzial hat die Sprache ganz klar.

rüdiger

Optimizer schrieb:

Darum geht es doch nicht. Der Unterschied zu D ist, dass in C++ die Standard C++-String Klasse nicht als Sprachmittel zur Verfügung steht. Wenn du schreibst "Blubb", dann ist das ein char*.

Im Vergleich dazu ist in D, Java, C# und anderen Sprachen, die Strings auf Sprachebene integrieren, ein String-Literal wirklich vom Typ String. Zum Beispiel ist dadurch sowas wie "blubblubb".ToUpper() möglich. Klar, kann man darüber streiten, wie gigantisch der Vorteil ist. Auf Sprachebene erreicht man halt eine bessere Integration. Während es für C++ zahllose String-Klassen gibt und keine so richtig in der Praxis Standard ist, hast du in D die Situation, dass jeder die eine String-Klasse benutzt, schon allein indem er ein Literal hinschreibt.

Wenn man "foo" zu einem Objekt einer Klasse String macht, dann muss man aber einige "besondere" Klassen einführen. Das Widerspricht eben dem C++-Ansatz und würde die Sprache verkomplizieren. Ich meine eine Freestanding-Implementierung, die kein std::basic_string anbietet, macht dies ja aus einem gewissen Grund. Da macht es natürlich kein Sinn, das man sagt "Nö, eine Freestanding-Implementierung" darf das nicht.

Außerdem gibt es ja unterschiedliche String-Klassen, weil es eben nicht so leicht ist eine String-Klasse zu entwerfen. Die std::basic_string-Klasse ist ja alles andere als perfekt. Warum glauben gerade die D-Leute, die perfekte String-Klasse entworfen zu haben? (Wobei ich dazu sagen muss, das viele Probleme einer String-Klasse wohl für US-Amerikaner eh ziemlich abstrakt wirken dürften, mit denen sich jemand in Deutschland oder gar China rumprökeln muss.)

Der gleiche Grund ist es ja auch, warum man in C++ kein foreach hat, weil man damit eben die Trennung zwischen Sprache und Bibliothek aufheben müsste und ich halte viele Verbesserungen an C++ für sinnvoll. Aber sicher keine, die die Bibliothek mit der Sprache verwurschteln.

Zeus

Vielleicht habenn Sie genug Erfahrung gesammelt mit C++ Compiler bauen *g*

import std.stdio;

class Int{
	private int i;
}

void main() {
	Int i = new Int();
	i.i = 2;
	writef(i.i);
}

hmmmm 3 mal dürft ihr raten, was der Code macht.

Artchi

thordk schrieb:

string gehört zur standard lib, aber vector zur stl. aber is doch wurscht, wo der krams zugehört: es bleibt halt ne lib

Nö, ist nicht wurscht. Weil die Stdlib einen vector hat. Du scheinst nicht zu wissen, was die Stdlib und was die STL ist. Die STL ist eine bestimmte Implementierung, die von bestimmten Leuten entwickelt wird. (zu letzt bei SGI) Die Stdlib dagegen ist eine Spec in der ISO-C++-Norm, die string und vector enthält. Dadurch das die STL von jemandem in eigener Verantwortung entwickelt wird und nicht nach der Stdlib richtet, ist sie sogar zur Stdlib INKOMPATIBEL bzw. nicht mehr 100% kompatibel.

Fälschlicherweise sagt aber nur der Volksmund zur Stdlib "STL". Es ist halt nur tolerriert, aber richtiger wird es dadurch nicht.

thordk schrieb:

geht nur darum, dass es auch c++ compiler gibt, die diese beiden features nicht bieten, weil sie eben ein zusatz sind, kein integraler bestandteil.

Ein bestimmter C++ Compiler ist nicht C++. Du verwechselst hier ein PRODUKT mit einer Spec. Nur weil vielleicht ein von zehn Compilern keine vollständige Stdlib beiliegt, heißt das nicht, das C++ unvollständig ist. Versuche mal in deinen Kopf den Unterschied zwischen einer Spezifikation (ISO-C++) und einer Implementierung (Produkt) zu bekommen.
Wenn die EU für Autos die Euro4-Abgasnorm (Spezifikation) vorschreibt, und ein chinesischer Hersteller es nicht schafft Euro4 zu implementieren, kannst du auch nicht einfach sagen "Die Euro4 gibt es nicht, weil ein paar Hersteller kein Euro4 komplett in ihrem Auto X und Auto Y haben." Haha, sehr witzig.

thordk schrieb:

in D isses anders.

Es ist in dem einen D-Compiler ein string dabei, richtig. Aber was ist wenn ich morgen einen D-Compiler entwickle, und zeitlich nicht schaffe string einzubauen? Und sage: ihr könnt meinen D-Compiler benutzen! Hat dann D keinen Buildin-string mehr? Nach deiner Auffassung wäre das so.

thordk schrieb:

und? noch lang kein grund, hier den fanatiker zu spielen

Nö, ich informiere und stelle hier nur ein paar Unwahrheiten wieder richtig.

Artchi

Optimizer schrieb:

Darum geht es doch nicht. Der Unterschied zu D ist, dass in C++ die Standard C++-String Klasse nicht als Sprachmittel zur Verfügung steht. Wenn du schreibst "Blubb", dann ist das ein char*.

Ich streite ja nicht ab, das C++ in der Core-Language kein String hat. Aber ich streite ab, das C++ keinen Standard-String hat! Weil das ISO-C++-Dokument eindeutig std::basic_string und zwei typedefs enthält.

Optimizer schrieb:

Während es für C++ zahllose String-Klassen gibt und keine so richtig in der Praxis Standard ist, hast du in D die Situation, dass jeder die eine String-Klasse benutzt, schon allein indem er ein Literal hinschreibt.

Gerade du, der hier nun ein alter Hase im Forum ist, hätte ich eher zugetraut, das ihm bewusst ist, warum es soviele String-Klassen gibt. Schade.

Die vielen String-Klassen von Qt, MFC, wx usw. sind doch vor 1998 entstanden. Deshalb hat doch jeder seinen eigenen String gebastelt, weil es keine C++-Norm gab und man nicht davon ausgehen konnte, das es eine String-Klasse beim Compiler gab.

Aber z.B. std::wstring erfüllt mind. UCS2 bzw. UTF-16. Wenn jemand heute eine neue Lib entwickelt, wird er wohl kaum wstring umgehen.

[quote="Artchi"]
[quote="Optimizer"]Während es für C++ zahllose String-Klassen gibt und keine so richtig in der Praxis Standard ist, hast du in D die Situation, dass jeder die eine String-Klasse benutzt, schon allein indem er ein Literal hinschreibt.[/quote]
Gerade du, der hier nun ein alter Hase im Forum ist, hätte ich eher zugetraut, das ihm bewusst ist, warum es soviele String-Klassen gibt. Schade.

Die vielen String-Klassen von Qt, MFC, wx usw. sind doch vor 1998 entstanden. Deshalb hat doch jeder seinen eigenen String gebastelt, weil es keine C++-Norm gab und man nicht davon ausgehen konnte, das es eine String-Klasse beim Compiler gab.
[/quote]
Na und, das ändert nichts daran, dass das unheimlich nervt. Außerdem sind die std::(w)strings schon sehr mager, wenn man sie mit dem Java String vergleicht.

Artchi schrieb:

Optimizer schrieb:

Während es für C++ zahllose String-Klassen gibt und keine so richtig in der Praxis Standard ist, hast du in D die Situation, dass jeder die eine String-Klasse benutzt, schon allein indem er ein Literal hinschreibt.

Gerade du, der hier nun ein alter Hase im Forum ist, hätte ich eher zugetraut, das ihm bewusst ist, warum es soviele String-Klassen gibt. Schade.

Die vielen String-Klassen von Qt, MFC, wx usw. sind doch vor 1998 entstanden. Deshalb hat doch jeder seinen eigenen String gebastelt, weil es keine C++-Norm gab und man nicht davon ausgehen konnte, das es eine String-Klasse beim Compiler gab.

Na und, das ändert nichts daran, dass das unheimlich nervt. Außerdem sind die std::(w)strings schon sehr mager, wenn man sie mit dem Java String vergleicht.

Die smilies weg, nicht die BBCodes

Artchi

Was nervt dich? Die Standard-Strings? Oder die vielen Strings aus anderen Libs? Benutze dann halt eine Lib, die Standard-Strings verwendet. Dann nervt es nicht mehr. Wenn mich an einem Auto was grundlägend nervt, kauf ich das Auto nicht.

Die Boost-Leute schaffen es komischerweise in ihrer gesamtheit die Standard-Strings zu benutzen. Wenn Qt, WX u.a. es nicht schaffen auf Standard-Strings zu switchen, kann ISO-C++ nichts dafür. Beschwert euch doch bei den Urhebern von Qt, WX usw. Sollen sie halt endlich umbauen. Aber natürlich macht Qt das nicht, weil dann würden sie einen Abhängigkeitsgrund weniger haben.

MS hat ihre gesamte Win32-API auf const wchar_t* umgebaut. Kann ich problemlos std::wstring benutzen und wenn ich mal einen Parameter an Win32 übergebe, mache ich einfach c_str(), fertig. Es geht, wenn der API-Urheber es nur will.

Artchi schrieb:

Was nervt dich? Die Standard-Strings? Oder die vielen Strings aus anderen Libs?

Eigentlich beides.

Benutze dann halt eine Lib, die Standard-Strings verwendet. Dann nervt es nicht mehr. Wenn mich an einem Auto was grundlägend nervt, kauf ich das Auto nicht.

Manche Arbeitgeber woll nicht, dass man dauernd neue Libs einschleppt.

MS hat ihre gesamte Win32-API auf const wchar_t* umgebaut. Kann ich problemlos std::wstring benutzen und wenn ich mal einen Parameter an Win32 übergebe, mache ich einfach c_str(), fertig. Es geht, wenn der API-Urheber es nur will.

Das finde ich ja auch so toll, das man den "guten" std::string wieder zum "bösen" char* macht.
Sogar die STL ist so inkonsequent

basic_fstream (const char *__s, ios_base::openmode __mode=ios_base::in|ios_base::out)

TOLL!!!

Gregor

Artchi schrieb:

Wenn Qt, WX u.a. es nicht schaffen auf Standard-Strings zu switchen, kann ISO-C++ nichts dafür.

Ich denke nicht, dass man die Infrastruktur rund um eine Sprache bei der Betrachtung der Sprache ignorieren sollte. Das geht an der Realität vorbei. Es ist eine bewusste Entscheidung, bei C++ nur eine relativ kleine Standardbibliothek zu haben und das ist ein zentrales Problem von C++. Genau das führt dazu, dass derartige Inhomogenitäten bei der Verwendung üblicher Werkzeuge entstehen.

Du meinst, ISO-C++ ist nicht an solchen Inhomogenitäten schuld? Ok, so kann man das natürlich sehen. Wenn man den eigenen Verantwortungsbereich derart stark einschränkt, dass man sich für fast gar nichts zuständig fühlt, kann man auch an fast gar nichts schuld sein. Ich sehe eine umfassende Standardbibliothek aber durchaus als etwas an, für das der Standard verantwortlich sein sollte.

BTW: Genau aus dem gleichen Grund wird D nie irgendeine Relevanz bekommen: Da fehlt einfach eine umfassende Standardbibliothek.