Das ist das Ende von C++!

[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?

[Zeus]

Naja bei den Vergleich scheind DM mit Falschinformation zu glänzen.
In C++ kann ne Klasse ein Referenttype oder Werttype sein, oder?

[rüdiger]

Optimizer schrieb:

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?

Das Problem ist, das ich es nicht ändern kann. Das kann nur der Hersteller der Implementierung oder gar des Standards. Das sind ja nicht nur Sachen wie Multibyte, sondern auch die Breite der Zeichen bei Fixed-Byte-Sachen etc.

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

Ich denke, dass es universelle Programmiersprachen gibt, die alles gut können. C++ gehört da aber nicht zu.

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.

Da sehe ich noch keinen Vorteil. In C++ ist

std::string myString = "abc";

doch auch möglich.

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.

Und warum sollte ein Integer-Literal kein Objekt sein, aber ein String-Literal? Das finde ich sehr inkonsistent.

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();
        }
}

Da verbindet man dann wieder die Sprache zu sehr mit irgend welchen Interfaces und Methoden.

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

Die Sprache an sich, weil ich nun Klassen habe, die fest verdrahtet sind, von denen ich auf besondere Weise Objekte erzeugen kann etc.

[Clw]

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.

Die gibts auch in D in der Standardlibrary:
http://www.digitalmars.com/d/phobos/std_stdint.html

Optimizer schrieb:

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?

Zugegeben, die Seite ist ein wenig reißerisch, aber im Kern sind die Aussagen bezüglich D wahr.

Zeus schrieb:

Naja bei den Vergleich scheind DM mit Falschinformation zu glänzen.
In C++ kann ne Klasse ein Referenttype oder Werttype sein, oder?

Klassen sind in C++ immer Werttypen, soweit ich weiß. In D sind Klassen immer Referenztypen, mit allen Folgen, es ist aber trotzdem möglich Klassen auf dem Stack zu erstellen, diese haben dann aber einige Einschränkungen, bieten aber die Sicherheit, dass der Destruktor aufgerufen wird.

[Phoemuex]

rüdiger schrieb:

Ich denke, dass es universelle Programmiersprachen gibt, die alles gut können. C++ gehört da aber nicht zu.

Welche denn? Assembler? Java? LISP? Prolog?

Funktional, logisch, Objektorientiert?

[Zeus]

Clw schrieb:

Zeus schrieb:

Naja bei den Vergleich scheind DM mit Falschinformation zu glänzen.
In C++ kann ne Klasse ein Referenttype oder Werttype sein, oder?

Klassen sind in C++ immer Werttypen, soweit ich weiß. In D sind Klassen immer Referenztypen, mit allen Folgen, es ist aber trotzdem möglich Klassen auf dem Stack zu erstellen, diese haben dann aber einige Einschränkungen, bieten aber die Sicherheit, dass der Destruktor aufgerufen wird.

Wertetypen liegen auf dem Stack, Referenztypen auf dem Heap und in C++ hassu die Freiheit Objekte auf den Stack oder auf dem Heap zu erzeugen. Wenn ich falsch liege, sagt es mir.
Jep Scope Classen heisst das.

[Knuddlbaer]

Ich weiß nicht so recht was die Diskussionen sollen.

Niemand wird seine angefangene Projekte in D neu Implementieren weil die Sprache D nach (glaubt man Heise.de) 7 Jahren in der Version 1 vorliegt.
(Changelog lässt sich derzeit nicht gescheit einsehen, erster Eintrag vom Okt 2002)

Wenn ich mir dann die Vergleiche hier ansehe:
http://www.digitalmars.com/d/htomodule.html

fühle ich mich schon veralbert.

Besonders die vergleiche mit
__declspec(dllimport) int __stdcall foo(int a);
export extern (Windows) int foo(int a);

stören mich da, __declspec etc. hat nun mal nichts mit der Sprache C zu tun.

Einige der Vergleiche dürften sich, hätte man C++ angesetzt, erledigt haben.

Wenn wir aber schon teils auf Compilerspezifische bzw. OS spezifische Dinge zum hervorheben von D verwenden, dann hätte ich gerne D mit C++/CLI im vergleich oder C++ mit boost.

(Ah mist, die Seiten gehen kaum von D gerade, schlechte Basis für mich

Mir werden dann Delegates geboten,
es steht ein GC zur Vergügung,
es gibt typof
für interne Typen wie z.B. int kann ich einfach ToString aufrufen
mir stehen Properties zur Verfügung
static con und destruktor
etc.

Insgesammt sehe ich nur eine Menge Werbung, Sachen die schöner gelöst sind, sachen die schlechter gelöst sind. Aber nichts, was mir meine Arbeit auf anhieb deutlich einfacher machen würde oder die eingesetzten Werkzeuge mit einem Schlag ersetzen könnte.

Im Moment müsste ich auch sehr umdenken:

Templates cannot be used to add non-static members or functions to classes. For example: 

class Foo
{
    template TBar(T)
    {
	T xx;			// Error
	int func(T) { ... }	// Error

	static T yy;				// Ok
	static int func(T t, int y) { ... } 	// Ok
    }
}

Auch schaut

alias TFoo!(char, int, int) foo4; // instantiates #4

für mich nicht nach Template aus sondern nach Funktion irgendwas.

Bei

struct TFoo(int x) { }
static assert(is(TFoo!(3) == TFoo!(2 + 1)));   // 3 and 2+1 are both 3 of type int
static assert(!is(TFoo!(3) == TFoo!(3u)));     // 3u and 3 are different types

muss ich schon aufmerksam lesen, das mir das ! nicht verloren geht und aus dem Template nicht ein Funktionsaufruf wird.

Insgesammt sehe ich D mit interesse entgegen, aber ich sehe nichts ausschlaggebendes, was massig Leute von C++ zu D wandern lässt.

Für jede Sprache gibt es sinvolle Anwendungen, ich sehe hier aber kein Potential
andere Sprachen zu verdrängen. Die anderen Sprachen schlafen auch nicht und das Geld in der Marktwirtshaft wird auch nicht mit dem reinen Sprachumfang bzw. reinen Standard gemacht.

Ich finde den Hype verfrüht und die Diskussion C (C++) vs D genauso sinnfrei wie SpracheX vs SpracheY.

Lassen wir D doch einfach mal eine Zeit "wirken" und schauen mal was die Praxis zu D sagt. Da wird sich die Vorfreude sicherlich etwas gelegt haben und ein paar Ansichten anderst sein.

[Gast]

Lass mich doch bitte aus Zitaten raus wo ich gar nix gesagt habe

[Zeus]

Ops Sry

Knuddlbaer schrieb:

Niemand wird seine angefangene Projekte in D neu Implementieren weil die Sprache D nach (glaubt man Heise.de) 7 Jahren in der Version 1 vorliegt.
(Changelog lässt sich derzeit nicht gescheit einsehen, erster Eintrag vom Okt 2002)

Nein die Sprache ist 7 Jahre in Entwicklung gewessen. Die 1.0 gibst seid 2.Jan.

[Gast]

rüdiger schrieb:

Optimizer schrieb:

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?

Das Problem ist, das ich es nicht ändern kann. Das kann nur der Hersteller der Implementierung oder gar des Standards. Das sind ja nicht nur Sachen wie Multibyte, sondern auch die Breite der Zeichen bei Fixed-Byte-Sachen etc.

Ich verstehe nicht, wo du da das Problem siehst. An deinem Source ändert sich doch deswegen nichts. Kein Mensch muss es ändern. Es wird für 99% der Fälle geil sein und für das 1% nehme ich doch nicht den anderen 99% bequeme Sachen weg. Es hat sich überall bewährt, String-Literale in die Sprache einzubauen, ich verstehe gar nicht warum irgendwer für sich die Strings in einer Sprache grundlegend ändern sollte. Warum ist zum Beispiel die Breite der Zeichen in nem Fixed-Byte-Charset wichtig? Das ist vielleicht wichtig, wenn ich den String byteweise irgendwohin (Datei) schreibe. Es darf natürlich keinesfalls so affig sein wie in der STL mit filestream << "blubb", ohne dass man irgendein Encoding angeben kann. Aber amsonsten ist es doch in meinen Programmcode völlig transparent, wenn irgendwas an Strings geändert wird.

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.

Da sehe ich noch keinen Vorteil. In C++ ist

std::string myString = "abc";

doch auch möglich.

Das ist doch ineffizient. Kein Compiler optimiert dir die Konstruktion weg, wenn du so ne Zuweisung machst. Dann kannst du keine Methoden an dem Literal aufrufen. Wieso kann ich an einer Variable schon Methoden aufrufen und am Literal nicht? Weil sie in C++ nicht vom selben Typ sind. Literale sind dort const char* und deine Variablen std::string, CString oder sonstwas. Das ist inkonsistent, unperformant, hässlich, unnötig.

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.

Und warum sollte ein Integer-Literal kein Objekt sein, aber ein String-Literal? Das finde ich sehr inkonsistent.

Mit Literal sein hat das nicht direkt was zu tun. In Java ist ein int keine Instanz einer Klasse, weder als Literal noch als Variable. Literale sind also an sich völlig konsistent. Ich kann Literal und Variable auch die gleiche Art benutzen. Ein Literal ist einfach nur eine Instanz eines Typs, genau wie eine Variable. In C# sind wie gesagt Integer auch eine Struktur. Und siehe da, man kann konsequenterweise an Literalen und an Variablen Methoden aufrufen.

int i = 5;
i.GetHashCode();
5.GetHashCode();

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();
        }
}

Da verbindet man dann wieder die Sprache zu sehr mit irgend welchen Interfaces und Methoden.

Ja, ein Interface, dass bei allen Implementierungen dieser Sprache vorhanden sein muss. Ich verstehe nicht, warum das schlimm sein soll. Es ist wohl ein ziemlich einfacher Weg in den Genuss von Sprachfeatures wie foreach zu kommen.

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

Die Sprache an sich, weil ich nun Klassen habe, die fest verdrahtet sind, von denen ich auf besondere Weise Objekte erzeugen kann etc.

Da ist eigentlich nichts besonders. Wenn du in Java ein String-Literal schreibst, erzeugt der Compiler (oder die VM, das ist jetzt nicht wichtig) beim Laden des Moduls eine Instanz von java.lang.String. Das Literal ist eine Referenz auf diese Instanz. Es wäre besonders, wenn man das Literal nicht wie jedes Objekt handhaben könnte, aber das ist zum Glück nicht der Fall.

[daHa]

jeder marktschreier der sein neues produkt anpreist erzaehlt gut eingefaerbten bloedsinn wenn er sein produkt mit den bisher dagewesenen vergleicht, hat ja sun und ms zb nicth anders gemacht

D schaut fuer mich aus wie die scriptsprache die mir abgeht und daher nicht uninteressant, das ichs kompilieren muss/kann seh ich eher als vorteil.

gscheites einfaches hinundher mit c++ und D kann durchaus recht brauchbar sein

[Simon2]

Hi,

nur eine kleine Fußnote zum Thema "eingebaute und Klassentypen": Ich finde die Existenz "eingebauter Typen" eher lästig und führt zu Inkonsistenzen.
Statt zu beklagen, dass in C++ string kein eingebauter Typ ist, sollte man eher beklagen, dass es überhaupt "primitive Typen" gibt (und ganz großer Mist ist so ein Zwitter wie string in Java) - ich finde, alle Typen sollten sich identisch verhalten und nicht mal so und mal so (ableitbar, auf Stack wie auf Heap ablegbar, keine "impliziten Kopien" oder immutables, global/static/const/..., const-initialisierbar, ...).
WENN ich also einen Trend begrüßenswert fände, wäre das eine Ausdünnung eingebauter Typen statt einer Ausweitung.
Ansonsten schießt man sich mit allen generischen Konstrukten in den Fuß...

Gruß,

Simon2.

[Gast]

(und ganz großer Mist ist so ein Zwitter wie string in Java)

An java.lang.String ist nichts zwittrig. Es ist eine standardkonforme Java-Klasse, deren Sourcecode du dir gerne selber ansehen und compilieren kannst.

Man kann von ihr nicht ableiten, weil sie final ist.
Man kann Instanzen davon nur auf dem Heap anlegen, weil das bei allen Java-Klassen so ist.
Strings sind unveränderlich, weil die Klasse so geschrieben worden ist. Das liegt im Ermessen des Autors der Klasse und es kann gar nicht sein, dass du jetzt verlangen musst, dass sie auch nicht-const sein können muss.

Vielleicht verstehst du Java auch einfach nicht genug und hast deshalb Theorien aufgestellt, die dieses scheinbar komische Verhalten von String für dich erklären.

WENN ich also einen Trend begrüßenswert fände, wäre das eine Ausdünnung eingebauter Typen statt einer Ausweitung.

Ja und das begründest du damit, dass in die Sprache integrierte Typen sich angeblich komisch verhalten. Sowas mag niemand, keiner mag eine Sonderbehandlung für eingebaute Typen. Bei so einfachen Sachen wie int ist es halt schwierig, das alles schön und objektorientiert zu machen, wenn man keine noch kleineren Bestandteile hat, um damit int aufzubauen. Aber wenn wie bei java.lang.String keine Sonderbehandlung gegeben ist, dann ist es recht angenehm. Der Compiler macht nichts, was ich als Programmierer nicht auch machen könnte, sowohl beim foreach als auch beim String. Er nimmt mir einfach nur Arbeit ab, nur zu.

[Clw]

Zeus schrieb:

Clw schrieb:

Zeus schrieb:

Naja bei den Vergleich scheind DM mit Falschinformation zu glänzen.
In C++ kann ne Klasse ein Referenttype oder Werttype sein, oder?

Klassen sind in C++ immer Werttypen, soweit ich weiß. In D sind Klassen immer Referenztypen, mit allen Folgen, es ist aber trotzdem möglich Klassen auf dem Stack zu erstellen, diese haben dann aber einige Einschränkungen, bieten aber die Sicherheit, dass der Destruktor aufgerufen wird.

Wertetypen liegen auf dem Stack, Referenztypen auf dem Heap und in C++ hassu die Freiheit Objekte auf den Stack oder auf dem Heap zu erzeugen. Wenn ich falsch liege, sagt es mir.
Jep Scope Classen heisst das.

Ich konnte jetzt zwar keine exakte Definition für value- und reference-types finden, aber eigentlich ist für mich ein Merkmal eines value-types, dass er bei einer Funktion (ohne Optimierung) ohne Pointer übergeben wird, und genau das passiert in C++ mit einer Klasse, solange man keinen Pointer als Argument nimmt.