Das ist das Ende von C++!

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

[Du Nervst]

Ich wollte schon was schreiben, aber dann dachte ich mir, dass das sicher ein anderer macht. Und...

Optimizer schrieb:

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.

Warum befolgst du meinen Rat den nicht, ich wollte dir doch nur helfen.

[Knuddlbaer]

Das hast Du aber zu Simon2 , nicht zu Optimizer geschrieben.

[Du Nervst]

Gut erkannt.

[rüdiger]

Phoemuex schrieb:

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?

Sicherlich Lisp (ich sehe Scheme einfach mal als ein Lisp-Derivat an). Gibt aber sicherlich mehr Programmiersprachen, die sich so verhalten. Das Paradigma spielt dabei keine Rolle, weil man es mit einer universellen Programmiersprache nachahmen kann.

Optimizer schrieb:

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.

(ich kürze mal die Quotes weg, damit das Post nicht so lang wird.)

Das Problem mit den Strings tritt eigentlich überall auf, wo man mit anderen Programmiersprachen, anderen Systemen, anderen GUIs, Binär-Daten etc. kommunizieren muss. Die WinAPI nimmt vielleicht das veraltete UCS-2, während ich unter Linux UTF-8 oder UCS-4 mache etc. Sicher, wenn man nur in einer Programmiersprache bleibt, mit dem Programmiersprache eigenem GUI-System und ohne Binär-Daten. Dann geht sich das schon aus. Aber die meisten größeren Anwendungen haben doch entweder eine GUI, die die meisten Leute dann ihrem System angepasst haben wollen oder müssen irgend wo Binär-Daten anfassen usw.

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.

Warum sollte der Compiler den Konstruktor nicht wegoptimieren können? Selbst wenn, gibt es glaube ich schlimmere Dinge, als das. Das man für Literale keine Methoden aufrufen kann ist ja deswegen nicht inkonsistent, weil es sich eben nicht um Objekte handelt. Ich finde es eher inkonsistent, wenn man für einige privilegierte Klassen besondere Wege einführt um Objekte anzulegen...

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.

Wie gesagt, es gibt auch Sprachen bei denen man ein foreach anders implementieren kann, als über besondere Interfaces. Was ich konsistenter finde, als bestimmten Interfaces und Klassen eine höhere Wertigkeit in der Sprache einzuräumen, als anderen Sprachen.

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.

Und warum ist dann 10 keine Instanz von java.lang.Integer? (bzw. const java.lang.Integer oder kann man etwa so etwas machen "abc".erase(1);?)

[entwikkler]

jeder weiss doch, dass C++ scheisse ist. Alle wichtigen Sachen wurden in Brainfuck geschrieben.

[Carmack]

Die vom Standard bereitgestellte Templatebilbiothek für BF ist aber noch etwas mager.

[Gast]

rüdiger schrieb:

Optimizer schrieb:

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.

(ich kürze mal die Quotes weg, damit das Post nicht so lang wird.)

Das Problem mit den Strings tritt eigentlich überall auf, wo man mit anderen Programmiersprachen, anderen Systemen, anderen GUIs, Binär-Daten etc. kommunizieren muss. Die WinAPI nimmt vielleicht das veraltete UCS-2, während ich unter Linux UTF-8 oder UCS-4 mache etc. Sicher, wenn man nur in einer Programmiersprache bleibt, mit dem Programmiersprache eigenem GUI-System und ohne Binär-Daten. Dann geht sich das schon aus. Aber die meisten größeren Anwendungen haben doch entweder eine GUI, die die meisten Leute dann ihrem System angepasst haben wollen oder müssen irgend wo Binär-Daten anfassen usw.

Natürlich brauchst du Strings oft als Binärdaten, klar. Die Libs wollen Strings vielleicht nicht alle in der gleichen Kodierung, oder der String benutzt intern UTF-32, ich würde aber gerne als UTF-8 in eine Datei schreiben...
Dieses Problem hat man realistischerweise immer wieder. Ganz abstrakt brauchen wir also immer etwas, was unsere Strings zu Bytes macht. Sowas in der Art:

byte[] encode(String, Encoding)

Den Punkt, den ich jetzt nicht verstehe ist, wo du den Zusammenhang zu eingebauten Strings siehst. Wo glaubst du, behindern mich dabei eingebaute Strings oder begünstigen mich dabei nicht eingebaute Strings?

Das man für Literale keine Methoden aufrufen kann ist ja deswegen nicht inkonsistent, weil es sich eben nicht um Objekte handelt.

Doch, es handelt sich logisch gesehen ganz konkret um Instanzen vom entsprechenden Typ. 5 ist eine Instanz von int und wenn int Methoden hat, muss ich sie an der 5 aufrufen können. Ich sage jetzt aber nicht, dass das mit den String-Literalen in C++ unlogisch wäre. Das hat dort seine Richtigkeit, weil "abc" eine Instanz von const char* ist und das Ding hat keine Methoden. Ich halte es nur für eine schlechte Wahl, das es dort so gemacht ist.

Ich finde es eher inkonsistent, wenn man für einige privilegierte Klassen besondere Wege einführt um Objekte anzulegen...

Naja, es ist wie mit const char* in C++ nichts anderes. Es ist ja genauso ne seltsame Sache, dass ich "abc" schreibe und der Compiler allokiert für mich 4 Bytes und schreibt das da rein. Aber du hast damit zu Leben gelernt und wahrscheinlich findest du es inzwischen ganz praktisch.

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.

Wie gesagt, es gibt auch Sprachen bei denen man ein foreach anders implementieren kann, als über besondere Interfaces. Was ich konsistenter finde, als bestimmten Interfaces und Klassen eine höhere Wertigkeit in der Sprache einzuräumen, als anderen Sprachen.

Es ist in C#, einer objektorientierten Programmiersprache, der übliche Weg, Schnittstellen zu definieren. In C++ ist ein üblicher Weg, Template-Funktionen zu schreiben, die von ihren Typparametern ein bestimmtes Verhalten und eine bestimmte Schnittstelle einfach erwarten. Wenn es in C++ ein eingebautes foreach gäbe, sähe es wahrscheinlich so aus, dass es von dem Typ ein begin() und end() erwartet. Damit hast du Methoden mit diesen Namen eine höhere Wertigkeit in der Sprache eingeräumt. Irgendeine formale Schnittstelle brauchst du für sowas halt, weil der Compiler nicht die Intelligenz hat, zu erkennen, dass du gerade nen Container schreibst und wie er funktioniert. Oder man macht es halt so wie es in C++ aktuell ist: Man freut sich darüber, dass man gar nichts hat. Das ist aber eine Einstellung die ich nur bedingt nachvollziehen kann.

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.

Und warum ist dann 10 keine Instanz von java.lang.Integer? (bzw. const java.lang.Integer

Weil 10 eine Instanz von int ist, nicht von Integer. Dieses Literal verhält sich auch in jeder Hinsicht wie eine Instanz von int. java.lang.Integer benutzt man eigentlich nur, wenn man muss, das Ding ist keineswegs der Standardfall. Du kritisierst wahrscheinlich, dass die primitiven Typen sich nicht wie eigene Klassen verhalten. Das ist ein Grundproblem von Java, das man einfach in Kauf genommen hat, damit die Performance nicht völlig hinüber geht. Man hat einen Graben, auf der einen Seite primitive Typen, auf der anderen Klassen. Die primitiven sind die absoluten Grundbausteine, die einfach da sind, damit man irgendwas hat. Steht jetzt IMHO aber eher nicht im Zusammenhang mit in die Sprache integrierten Strings.

oder kann man etwa so etwas machen "abc".erase(1);?

Nein, ein java.lang.String, von dem "abc" eine Instanz ist, hat keine Methoden, die eine Veränderung erlauben. Die Klasse ist schlichtweg so geschrieben. Es gibt ein privates byte[], das im Konstruktor gefüllt wird und die Methoden nach außen erlauben keine Änderungen. Das macht man sich auch bei Substrings zu Nutze, ein Substring referenziert das selbe Array wie der ursprüngliche String, nur in einem kleineren Bereich. Ist einfach ne Design-Entscheidung. Wenn man Strings veränderbar hätte, hätte man vielleicht konsequenterweise auch String-Literale veränderbar machen müssen. Ist wahrscheinlich gut, dass es nicht so ist.

[mick]

Carmack schrieb:

Die vom Standard bereitgestellte Templatebilbiothek für BF ist aber noch etwas mager.

hab mir mal eine geschrieben... nein schmarrn

[Schön zu sehen]

Der monatlich Java vs. C++ Flamewar ist wieder entbrannt.

[Gast]

Schön zu sehen schrieb:

Der monatlich Java vs. C++ Flamewar ist wieder entbrannt.

Naja, noch fehlt die Diskussion über GC/nicht GC