Das ist das Ende von C++!

[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

[kleine Frage]

Hat D eigentlich einen Garbage Collector?

[EchterCoder]

Wer braucht schon nen GC, ist doch was für Kinder.

[ten]

Schön zu sehen schrieb:

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

und wie immer wird eine hirnlose diskussion um stringklassen daraus

kleine Frage schrieb:

Hat D eigentlich einen Garbage Collector?

hat es, ist aber optional...
:xmas2:

[ggggggggggg]

Java hat einen GC, Java ist besser als C++ ==> eine gute PrograMMIERsprache braucht einen GC

[groovemaster]

Schön zu sehen schrieb:

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

Und das, obwohl es um D geht. Kann man das als gutes Omen bezeichnen? Hmmm...

Ich sehe, zumindest kurzfristig, keine Chance für D. Es wird halt ein Nischenprodukt für "Enthusiasten" bleiben. D bringt einfach nichts Neues, nichts was man nicht schon aus anderen Sprachen kennt. Es sind gegenüber C++ und Java Veränderungen im Detail. Ich schreibe bewusst mal nicht von Verbesserungen, weil man das teilweise so oder so sehen kann. Zudem hat D nicht die Supportbasis wie andere grosse Sprachen. Interessant wird sicherlich sein, inwiefern sich das ändern könnte. Ich habe da so meine Zweifel.
Positiv finde ich ja zumindest, dass der GC von D optional ist. GC bleibt für mich halt einfach ein Hack was Speichermanagement betrifft. Um mal das von TactX heraufbeschworene Thema anzuheizen.

@Artchi + TactX
Seid ihr eigentlich öfter im Heise Forum aktiv? Ich bin fast schon etwas schockiert. :xmas2: :p

[Gast]

groovemaster schrieb:

Positiv finde ich ja zumindest, dass der GC von D optional ist. GC bleibt für mich halt einfach ein Hack was Speichermanagement betrifft. Um mal das von TactX heraufbeschworene Thema anzuheizen.

Heraufbeschoren hab ich gar nichts. Ich habe lediglich das Unweigerliche etwas beschleunigt

groovemaster schrieb:

@Artchi + TactX
Seid ihr eigentlich öfter im Heise Forum aktiv? Ich bin fast schon etwas schockiert. :xmas2: :p

Nein, seit einer ganzen Weile halt ich mich davon größtenteils fern. Das wurde mir dort (ja, sogar _mir_) zu blöd.
Aber woher weisst du das eigentlich? :p

[groovemaster]

TactX schrieb:

Heraufbeschoren hab ich gar nichts. Ich habe lediglich das Unweigerliche etwas beschleunigt

So kann man das natürlich auch sehen.

TactX schrieb:

Aber woher weisst du das eigentlich? :p

Weil zu den Kommentaren auf Heise auch ein TactX gepostet hat. Ich habe einfach mal vermutet, dass der Nick nicht so oft verwendet wird.

[Gast]

<off-topic>

groovemaster schrieb:

TactX schrieb:

Aber woher weisst du das eigentlich? :p

Weil zu den Kommentaren auf Heise auch ein TactX gepostet hat. Ich habe einfach mal vermutet, dass der Nick nicht so oft verwendet wird.

Täusch dich da mal nicht. Ist mir schon fast zu oft über den Weg gelaufen. Google mal nach TactX und wundere dich wieviel man da findet: Firmen, andere mit dem Nick, Clans, ja sogar ganze Organisationen (siehe derzeitige Sig)

[groovemaster]

Und warst du es nun oder nicht?

[Gast]

Ja

</off-topic>

[Clw]

kleine Frage schrieb:

Hat D eigentlich einen Garbage Collector?

hat es, ist aber optional...
:xmas2:[/quote]
Na gut... so richtig optional ist der GC in D nicht, wenn man dafür in Kauf nehmen muss, die komplette Phobos-runtime-library nicht zu benutzen, denn die basiert darauf. Es gibt zwar die Möglichkeit Ares, Deimos (veraltet) oder bald Tango (nur angekündigt, closed-beta) zu benutzen, aber deren Status ist nicht wirklich zufriedenstellend.
Der GC lässt sich aber für kritische Stellen abstellen, jedoch nicht so einfach aus dem Programm entfernen.

[Gast]

TactX schrieb:

Ja

</off-topic>

[Simon2]

Optimizer schrieb:

...

Hi,

was ich meinte, war Folgendes:
z.B. Was erwartest Du von diesem Konstrukt:

class A {
private:
    Type a;
public:
//... restliches Zeug
    Type getA() { return a; }
};

// call: 
A a; // oder a = new A();
a.getA() = 1;

Ich erwarte entweder:
A Rückgabe einer Kopie (C++) oder
B Rückgabe einer Referenz (Java).
Funktioniert prima, wenn Type Klassentyp hat. In C++ bearbeite ich die (tmeporäre) Kopie, in Java auf der Referenz (also auf dem privaten a) - vollkommen in Ordnung, wenn es immer so ist.
Aber halt: Wenn Type ein eingebauter java-Typ ist, habe ich plötzlich eine Kopie in der Hand und weiß das nur, weil ich das in dem Buch nachgelesen habe. Ersetze ich string, int, ... durch meine myString-, MyInt-, ... -Klasse, verändert sich sofort das Verhalten ... so sehr ich mich auch an der Original-Implementation von string (z.B.) orientieren mag.
So etwas finde ich konzeptionell einfach sehr unschön.

Das soll jetzt keine "Java-Schelte" sein, es gibt auch IMO in C++ "Inkonsistenzen" mit primitiven Typen (z.B. bzgl. der Vererbung), so dass ich prinzipiell kein Freund von denen bin.

Ach ja: Und das Argument "Das haben die halt so gemacht" (bzgl "string") entkräftet irgendwie die Kritik "Das ist aber schlecht" nicht so recht, oder ? Der C++-Programmierer kann sich immerhin noch mit dem "Das ist nur irgendein Lib-Progger gewesen" rausreden ( ) aber in Java gehört dieses Verhalten zur Sprachdefinition ....

Gruß,

Simon2.

[groovemaster]

TactX schrieb:

Ja

Hehe. :p
Soll aber kein Vorwurf gewesen sein. Ist nur schön zu sehen, dass Moderatoren auch nur Menschen sind. :xmas2:

[Gast]

Simon2 schrieb:

Ich erwarte entweder:
A Rückgabe einer Kopie (C++) oder
B Rückgabe einer Referenz (Java).
Funktioniert prima, wenn Type Klassentyp hat. In C++ bearbeite ich die (tmeporäre) Kopie, in Java auf der Referenz (also auf dem privaten a) - vollkommen in Ordnung, wenn es immer so ist.
Aber halt: Wenn Type ein eingebauter java-Typ ist, habe ich plötzlich eine Kopie in der Hand und weiß das nur, weil ich das in dem Buch nachgelesen habe.

Java übergibt *immer* eine Kopie. Wenn natürlich nur ein Zeiger kopiert wird, ist das referenzierte Objekt wieder das selbe. Ist in C++ genauso. Was dich vielleicht stört ist, dass man ein Objekt gar nicht ohne Zeiger anfassen kann.

Ach ja: Und das Argument "Das haben die halt so gemacht" (bzgl "string") entkräftet irgendwie die Kritik "Das ist aber schlecht" nicht so recht, oder ?

"So gemacht" wurde, dass Strings unveränderlich sind, aber ich habe hier nirgendwo Kritik diesbzgl. gelesen.

[quote experte]

Simon2 schrieb:

Optimizer schrieb:

...

Sich auf ein Zitat beziehen, aus dem man alles gestrichen hat, ist wohl ungefähr so sinnvoll wie dieser Beitrag.