Das ist das Ende von C++!

[nep]

Artchi schrieb:

nep schrieb:

Das ist in Java/C# eben nun mal einfach besser gelöst (oder anders ausgedrückt: produktiver). Da muss ich mich z.B. nicht um die verschiedensten String-Klassen kümmern.

Man sollte aber nicht verheimlichen, das es auch in Java mittlerweile drei String-Klassen gibt, weil nicht eine einzige alle Anforderungen auf einmal abdeckt. Mittlerweile sind drei dabei:

String
StringBuilder
StringBuffer

Je nachdem, was ich gerade braucht, muß ich mir eine Aussuchen. Das einzige was in Java wirklich kosistenter ist, ist das die parameter bei Methoden String erwarten

Naja das ist aber kein Vergleich zu C++. Es wird letztendlich ja trotzdem immer String benutzt. Nur wenn du halt nen großen String aus vielen Verkettungen zusammenbaust, dann benutzt du halt z.B. StringBuffer da das performanter ist als String(da dieser Immutable ist). Und daraus kannst ja dann sofort wieder einen String kriegen. Also das ist schon schön flüssig und einfach zu benutzen. Naja vielleicht ist das auch Ansichtssache.

Artchi schrieb:

Das erwarte ich von den großen C++-Frameworks auch. Leider machen die das nicht, um die User abhängig von ihren Klassen zu machen.

Ja, eben und das ist ja das Problem. Das bringt mir ja in der Praxis trotzdem nichts, wenn zwar C++ an sich dafür nichts kann, aber die Lib-Hersteller trotzdem alle ihr eigenes Süppchen kochen. Davon kann ich mir auch nichts kaufen.

[Gast]

rüdiger schrieb:

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.

Ich denke mal nicht, dass die Entwickler von D denken, die perfekte String-Klasse entworfen zu haben. Ich würde mal vermuten, dass sie besser als std::string ist, aber den eigentlichen Vorteil sehe ich darin, dass dafür ein Sprachmittel zur Verfügung steht.

Ich verstehe den Ansatz von C++, möglichst viel auf Bibliotheksebene zu machen um die Sprache davon unabhängig zu haben. C++ soll irgendwie alles geil können, man soll damit Programme schreiben können oder sich auch selber mit Makros, umfangreicher Operator-Überladung und eben nicht fertigem foreach und Strings in der Sprache unglaublich erweitern und anpassen können. Ich denke wir beide haben da eine grundverschiedene Meinung. Ich denke, auf Sprachebene sind viele Dinge besser realisierbar, du befürchtest anscheinend, dass darunter die Vielseitigkeit einer Sprache leidet. Ich halte extrem vielseitige Sprachen aber für schlecht.

Skriptsprachen existieren auch oft nur aus dem simplen Grund, weil auf Sprachebene alles besser integrierbar ist. Nimm als Beispiel JSP. Es ist halt nicht toll, wenn man eine Webseite machen will und dann von irgendwelchen Servlet-Klassen ständig ableitet und Code schreibt -> man entwickelt für diesen Zweck ne eigene Sprache. Sinnvoll. Du dagegen argumentierst, die Sprache solle möglichst wenig eingebaut haben, damit sie vielseitig ist. Was ich nicht für sinnvoll halte, da sie dann zwar alles kann, aber nichts gescheit. C++ kann kein gescheites foreach und keine gescheiten Strings.

Wenn du verschiedene Bibliotheken nutzt, die ihre eigenen String-Klassen mitbringen bist du immer irgendwie dabei, über char[] hin und her zu konvertieren. Oder bastel doch mal ein foreach. Es wird niemals genau so geil sein wie

foreach( int myInt in myIntList )
    sum += myInt;

Und mit foreach ist es das selbe wie mit String. Jeder bastelt sich sein eigenes...

... und würde die Sprache verkomplizieren.

Nein, die Grammatik der Sprache wäre gleich kompliziert und der Umgang mit der Sprache wäre ganz erheblich einfacher. Wie man wirklich gut an Sprachen sehen kann, die eingebaute Strings und foreach haben.

[Gast]

Artchi schrieb:

Man sollte aber nicht verheimlichen, das es auch in Java mittlerweile drei String-Klassen gibt, weil nicht eine einzige alle Anforderungen auf einmal abdeckt. Mittlerweile sind drei dabei:

String
StringBuilder
StringBuffer

Der Unterschied ist: Diese drei Klassen sind für einen jeweils eigenen Verwendungszweck geschaffen. Der Grund, warum es diese verschiedene Klassen gibt ist also, weil mal die eine geeigneter ist, mal die andere.

Der Grund, warum es für C++ dreihundert verschiedene String-Klassen gibt ist nicht so toll. Und das Ergebnis ist auch, dass es hundert Klassen gibt, die sich für den einen Zweck gut eignen, hundert, die sich für den anderen Zweck gut eignen.

[Artchi]

Optimizer schrieb:

Der Unterschied ist: Diese drei Klassen sind für einen jeweils eigenen Verwendungszweck geschaffen. Der Grund, warum es diese verschiedene Klassen gibt ist also, weil mal die eine geeigneter ist, mal die andere.

Ehm, und wo ist der Unterschied zu dem hier:

Optimizer schrieb:

Der Grund, warum es für C++ dreihundert verschiedene String-Klassen gibt ist nicht so toll. Und das Ergebnis ist auch, dass es hundert Klassen gibt, die sich für den einen Zweck gut eignen, hundert, die sich für den anderen Zweck gut eignen.

Du sagst es selber! Es gibt jeweils mehrere String-Klassen weil jede einen anderen Zweck erfüllt. Nur bei C++ ist das schlechter bei Java ist das i.O.? Oder sind nur 3 vs. 10 ein Unterschied? (hunderte sind es kaum, es gibt gerade mal eine Hand voll bedeutender String-Klassen im C++-Umfeld).

Ich liebe diesen C++-Flamewar.

[Jester]

Hast Du das jetzt ernsthaft nicht verstanden?

In C++ gibt es dermaßen viele Stringklassen, nicht weil die alle unterschiedliche Vorzüge bieten, sondern weil es lange keine gab und daher jede beschissene Library ihre eigene string-Klasse mitgebracht hat.

[Artchi]

Jester schrieb:

Hast Du das jetzt ernsthaft nicht verstanden?

In C++ gibt es dermaßen viele Stringklassen, nicht weil die alle unterschiedliche Vorzüge bieten, sondern weil es lange keine gab und daher jede beschissene Library ihre eigene string-Klasse mitgebracht hat.

Ist mir schon klar. NUr habe ich schon mal gesagt, das wir C++ler eine std::basic_string haben. Und? Kommen mir die Leute immer noch mit QString, wxString und CString an. Und wer sagt das es hunderte gibt? Es gibt nur eine Hand voll nennenswerter String-Klassen. Ich kann dir auch gerne viele XML-Libs im Java-Umfeld nennen. Warum sind die denn alle entstanden? Weil es erst ab Java 1.4 XML-Support gab? Ach, schau her! Das kann ich mit jeder Klasse/Lib aus dem Java-Umfeld machen, die erst später in den Java-Specs rein kamen, aber vorher schon von vielen anderen Leuten entworfen und implementiert wurden. In Java 1.4 gab es sogar einen Unicode-Bug in der XML-Lib. Wurde in Java 1.5 geändert, wodurch unsere damals ertellten XML-Dateien in Java 1.5 nicht mehr lesbar waren.

Was wäre das denn für eine Diskussionsgrundlage, wenn ich jetzt jedes Java-Defizit aufführe?

[KennerDesProblems]

Artchi schrieb:

Das kannst du vielleicht nicht wissen, aber die Win32-API ist eine C-API, nichts C++. Deshalb kann da schlecht eine String-Klasse benutzt werden. Aber ist ok. Das Beispiel habe ich nur aufgeführt, um zu zeigen, das eine API sehr wohl von einem Typ (in dem Fall char) auf einen aktuelleren/sinnvolleren Typ (in dem Fall wchar_t) umgestellt werden kann. Das C keine Klassen kennt, hat ja nichts mit C++ zu tun.

ich weiß

Langsam wird es lächerlich. Gibts doch endlich zu, dass C++ in Sachen standard library viel schlechter ist als Java.

Was hat den C++ für ne XML Unterstützung?

[Artchi]

KennerDesProblems schrieb:

Langsam wird es lächerlich. Gibts doch endlich zu, dass C++ in Sachen standard library viel schlechter ist als Java.

Ja, ich gebe hoch und heilig zu, das C++ in Sachen Standardlibrary der letzte Schrott in der Geschichte der Programmiersprachen ist.

Artchi

PS: endlich kann ich mich hier ausklinken.

[rüdiger]

Optimizer schrieb:

Ich denke mal nicht, dass die Entwickler von D denken, die perfekte String-Klasse entworfen zu haben. Ich würde mal vermuten, dass sie besser als std::string ist, aber den eigentlichen Vorteil sehe ich darin, dass dafür ein Sprachmittel zur Verfügung steht.

Ich verstehe den Ansatz von C++, möglichst viel auf Bibliotheksebene zu machen um die Sprache davon unabhängig zu haben. C++ soll irgendwie alles geil können, man soll damit Programme schreiben können oder sich auch selber mit Makros, umfangreicher Operator-Überladung und eben nicht fertigem foreach und Strings in der Sprache unglaublich erweitern und anpassen können. Ich denke wir beide haben da eine grundverschiedene Meinung. Ich denke, auf Sprachebene sind viele Dinge besser realisierbar, du befürchtest anscheinend, dass darunter die Vielseitigkeit einer Sprache leidet. Ich halte extrem vielseitige Sprachen aber für schlecht.

Die String-Klasse ist doch das beste Beispiel. Angenommen die wäre jetzt "hardgecodet", dann würde ich mich doch ziemlich ärgern, so eine String-Klasse hardgecodet zu haben. Wenn ich eben eine String-Klasse mit Multibyte-Support haben will, dann kann ich sie mir eben basteln und die Algorithmen der Standard-Library kommen damit trotzdem klar. Wäre std::string nun "fest verdrahtet", dann hätte ich ein großes Problem.

Skriptsprachen existieren auch oft nur aus dem simplen Grund, weil auf Sprachebene alles besser integrierbar ist. Nimm als Beispiel JSP. Es ist halt nicht toll, wenn man eine Webseite machen will und dann von irgendwelchen Servlet-Klassen ständig ableitet und Code schreibt -> man entwickelt für diesen Zweck ne eigene Sprache. Sinnvoll. Du dagegen argumentierst, die Sprache solle möglichst wenig eingebaut haben, damit sie vielseitig ist. Was ich nicht für sinnvoll halte, da sie dann zwar alles kann, aber nichts gescheit.

Ich kenne JSP nicht. Ich habe auch nichts gegen Spezial-Sprachen (nur dass die die ich kenne oft sehr schludrig sind, wie zB PHP). Nur finde ich eine vielseitige Programmiersprache nicht schlecht, weil ich so leichter Mängel der Sprache ausgleichen kann oder wenn sich meine Anforderungen ändern, dann kann ich mit der Programmiersprache reagieren.

C++ kann kein gescheites foreach und keine gescheiten Strings.

Warum kann C++ keine gescheiten Strings? Weil "abc".length(); nicht funktioniert? Welche Programmiersprache hat dann gescheite Strings? Ruby und mehr nicht? Und können Java und C++ auch keine gescheiten Integer, weil 10.sqrt() nicht funktioniert?

Wenn du verschiedene Bibliotheken nutzt, die ihre eigenen String-Klassen mitbringen bist du immer irgendwie dabei, über char[] hin und her zu konvertieren.

Die Bibliotheken, die eigene String-Klassen mitbringen haben ja in der Regel auch ein Kohärentes String-Design. Also muss ich nicht viel hin und her konvertieren und wenn, dann bietet mit C++ eben die Mittel um da entsprechend drauf zu reagieren.

Oder bastel doch mal ein foreach. Es wird niemals genau so geil sein wie

foreach( int myInt in myIntList )
    sum += myInt;

Und mit foreach ist es das selbe wie mit String. Jeder bastelt sich sein eigenes...

Ich kenne C# nicht genug, um zu wissen wie dort foreach gehandhabt wird. Aber was muss ich machen, damit meine Klasse auch in foreach benutzt werden kann?

... und würde die Sprache verkomplizieren.

Nein, die Grammatik der Sprache wäre gleich kompliziert und der Umgang mit der Sprache wäre ganz erheblich einfacher.

Ich habe ja auch nie behauptet, dass die Gramatik der Sprache wesentlich schwieriger wird.

[rüdiger]

KennerDesProblems schrieb:

Was hat den C++ für ne XML Unterstützung?

Eine sehr gute.

[nep]

Ich finde den Ansatz von C++ an sich ja eigentlich auch nicht schlecht, dass man erst mal nur die Sprache an sich und eine eher kleine Standardbibliothek hat. Wenn nun die ganzen Bibliotheken die es da draußen gibt den Standard so weit wie möglich ausnützen würden, dann wäre das eine richtig feine Sache. Zum Großteil ist es aber leider nicht so, also relativiert sich das ganze halt leider auch wieder.

Ich kenne C# nicht genug, um zu wissen wie dort foreach gehandhabt wird. Aber was muss ich machen, damit meine Klasse auch in foreach benutzt werden kann?

Ich kenn mich in C# zwar auch nicht wirklich aus, aber in Java ist das relativ einfach, da muss deine Klasse einfach das Interface Iterable implementieren, mehr nicht. Ich denke mal in C# wird es ähnlich sein.

[Tipp]

Don't feed the troll.

[daHa]

wie hier
http://www.digitalmars.com/d/comparison.html
zu sehen ist, ist D nicht nur das ende von C++ sondern auch von Java und C#
kann viel mehr und ist viel neuer

[Kenner der Sprachen]

Und Brainfuck ist das Ende von D.

[ten]

Artchi schrieb:

Ja, ich gebe hoch und heilig zu, das C++ in Sachen Standardlibrary der letzte Schrott in der Geschichte der Programmiersprachen ist.

na, endlich bringt's mal einer auf den punkt!

rüdiger schrieb:

KennerDesProblems schrieb:

Was hat den C++ für ne XML Unterstützung?

Eine sehr gute.

welche?

[Gast]

Was mir an D gefällt sind die Bezeichner für die einzelnen Datentypen. Kein unsigned long long sondern einfach nur ulong. Wobei ich die Bezeichner aus stdint.h (uint64_t) trotzdem besser finde.

[daHa]

Kenner der Sprachen schrieb:

Und Brainfuck ist das Ende von D.

brainfuck wurde von Ook! beendet

[ten]

TactX schrieb:

Was mir an D gefällt sind die Bezeichner für die einzelnen Datentypen. Kein unsigned long long sondern einfach nur ulong. Wobei ich die Bezeichner aus stdint.h (uint64_t) trotzdem besser finde.

geht noch besser: u64, u32, i8 usw...

[Gast]

rüdiger schrieb:

Optimizer schrieb:

Ich denke mal nicht, dass die Entwickler von D denken, die perfekte String-Klasse entworfen zu haben. Ich würde mal vermuten, dass sie besser als std::string ist, aber den eigentlichen Vorteil sehe ich darin, dass dafür ein Sprachmittel zur Verfügung steht.

Ich verstehe den Ansatz von C++, möglichst viel auf Bibliotheksebene zu machen um die Sprache davon unabhängig zu haben. C++ soll irgendwie alles geil können, man soll damit Programme schreiben können oder sich auch selber mit Makros, umfangreicher Operator-Überladung und eben nicht fertigem foreach und Strings in der Sprache unglaublich erweitern und anpassen können. Ich denke wir beide haben da eine grundverschiedene Meinung. Ich denke, auf Sprachebene sind viele Dinge besser realisierbar, du befürchtest anscheinend, dass darunter die Vielseitigkeit einer Sprache leidet. Ich halte extrem vielseitige Sprachen aber für schlecht.

Die String-Klasse ist doch das beste Beispiel. Angenommen die wäre jetzt "hardgecodet", dann würde ich mich doch ziemlich ärgern, so eine String-Klasse hardgecodet zu haben. Wenn ich eben eine String-Klasse mit Multibyte-Support haben will, dann kann ich sie mir eben basteln und die Algorithmen der Standard-Library kommen damit trotzdem klar. Wäre std::string nun "fest verdrahtet", dann hätte ich ein großes Problem.

Was für ein Problem hättest du denn genau? Ich sehe keines. Angenommen, du hast wirklich anfangs ohne Multibyte-Support geplant und änderst die Klasse nachträglich... was funktioniert dann nicht mehr genau wegen dem, dass "abc" eine Instanz deiner String-Klasse ist?

Skriptsprachen existieren auch oft nur aus dem simplen Grund, weil auf Sprachebene alles besser integrierbar ist. Nimm als Beispiel JSP. Es ist halt nicht toll, wenn man eine Webseite machen will und dann von irgendwelchen Servlet-Klassen ständig ableitet und Code schreibt -> man entwickelt für diesen Zweck ne eigene Sprache. Sinnvoll. Du dagegen argumentierst, die Sprache solle möglichst wenig eingebaut haben, damit sie vielseitig ist. Was ich nicht für sinnvoll halte, da sie dann zwar alles kann, aber nichts gescheit.

Ich kenne JSP nicht. Ich habe auch nichts gegen Spezial-Sprachen (nur dass die die ich kenne oft sehr schludrig sind, wie zB PHP). Nur finde ich eine vielseitige Programmiersprache nicht schlecht, weil ich so leichter Mängel der Sprache ausgleichen kann oder wenn sich meine Anforderungen ändern, dann kann ich mit der Programmiersprache reagieren.

Ja, ich denke auch, dass eine Programmiersprache schon ein bisschen vielseitig sein sollte. Kein extrem ist gut. Aber das Ziel mit einer Sprache fast alles gut machen zu können ist nicht haltbar. (btw. JSP ist in erster Linie HTML ähnlich, aber man kann eigene Tags entwerfen, die man selber wiederum in JSP oder in Java schreibt. Ist halt sehr sinnvoll für Webdesign, diese Sprache hat ein konkretes Anwendungsgebiet wo sie gut ist).

C++ kann kein gescheites foreach und keine gescheiten Strings.

Warum kann C++ keine gescheiten Strings? Weil "abc".length(); nicht funktioniert? Welche Programmiersprache hat dann gescheite Strings? Ruby und mehr nicht? Und können Java und C++ auch keine gescheiten Integer, weil 10.sqrt() nicht funktioniert?

Was ganz konkret dort geht ist ein Literal eines solchen Typs hinzuschreiben. In C++ ist es schon wieder mit einem Konstruktoraufruf verbunden, einer String-Variable ein String-Literal zuzuweisen. Dagegen zum Beispiel in Java ist "abc" eine Instanz von String, ohne Typumwandlung, ohne Konstruktion ohne alles lässt sie sich anderen String-Variablen zuweisen. In C++ wäre das äquivalent:

const char* myString = "abc";

Die Strings auf Sprachebene sind eben keine std::strings. Es hat halt Vorteile, Strings auf Sprachebene zu haben.

Was die Integer angeht: Man kann natürlich Literale hinschreiben. Literale sind grundsätzlich eigentlich Dinge, die man so nicht braucht. Trotzdem integriert man sie auf Sprachebene für besonders wichtige Typen. In den meisten Sprachen sind Strings wichtig.
Dass die Integer keine Methoden haben finde ich dagegen weniger schlimm. In C# sind Integer übrigens (zumindest scheinbar) auch Strukturen, die Methoden haben.

Oder bastel doch mal ein foreach. Es wird niemals genau so geil sein wie

foreach( int myInt in myIntList )
    sum += myInt;

Und mit foreach ist es das selbe wie mit String. Jeder bastelt sich sein eigenes...

Ich kenne C# nicht genug, um zu wissen wie dort foreach gehandhabt wird. Aber was muss ich machen, damit meine Klasse auch in foreach benutzt werden kann?

Du musst ein Interface implementieren und einen passenden Enumerator schreiben. In C# 2.0 gibt es ein Sprachmittel für Enumeratoren, so dass man diese Klasse nicht mehr selber definieren muss:

public class Stack<T> : IEnumerable<T> {
        public IEnumerator<T> GetEnumerator()
        {
            for (int i = top; --i >= 0; )
            {
                yield return values[i];
            }
        }

        // Dass man dies braucht ist ein Design-Fehler aus alten Tagen  :-(
        IEnumerator IEnumerable.GetEnumerator()
        {
            return GetEnumerator();
        }
}

... und würde die Sprache verkomplizieren.

Nein, die Grammatik der Sprache wäre gleich kompliziert und der Umgang mit der Sprache wäre ganz erheblich einfacher.

Ich habe ja auch nie behauptet, dass die Gramatik der Sprache wesentlich schwieriger wird.

Ok. Was meinst du, würde komplizierter werden?

[Gast]

Function Templates  	Yes  	No  	Yes  	No  	Yes

Ich möchte jetzt mal nicht auf den Begriff Template rumreiten. Versteht jemand, was die Seite genau damit meint, was Java haben soll und C# nicht?