Was ist denn mal ne WIRKLICH gute String-Klasse?
-
Wenn man z.B. den Operator '&' verwendet, ist sofort offensichtlich, was gemeint ist:
Nein. Das ist imo eine Gewöhnungssache. Ich finde das '&' z.B. total unintuitiv, da es für mich ein bitweise-und repräsentiert. Ich hätte z.B. jetzt behauptet, dass '+' der beste Operator für Konkatenation von Strings ist (in Abwesenheit eines ausgefüllter-Kreis-Operators). Das liegt aber wohl daran, dass ich a) hauptsächlich mit Sprachen arbeite, die diesen Operator dafür verwenden und b) in der Uni bereits das ein oder andere mal + als Konkatenations-Op für Wörter verwendet habe.
-
Optimizer schrieb:
His extensions and modifications to C++ (also know as C++ ++ --), were the first steps towards the development of an independent language that would fit the project objectives. He named the language "Oak" [...]
Oak wurde später noch weiterentwickelt und zu Java unbenannt - aus Lizenzrechtlichen Gründen, soweit ich weiß.
Quelle: http://ei.cs.vt.edu/~wwwbtb/book/chap1/java_hist.htmlIch dachte immer Weiterentwicklungen fügen etwas innovatives hinzu statt es zu entfernen.
Insofern halte ich "Weiterentwicklung" für das falsche Wort. Naja, was soll's
-
Ich dachte immer Weiterentwicklungen fügen etwas innovatives hinzu statt es zu entfernen.
hehe
-
Helium schrieb:
Guck dir mal Mr.Ns Beispiel an:
template<class T, class Ch, class A> std::basic_string<Ch, std::char_traits<Ch>, A> operator+(T const &a, std::basic_string<Ch, std::char_traits<Ch>, A> const &b) { ostringstream s; s << a << b; return s.str(); }
Hmm, mir ist nicht ganz klar, wieso man einerseits die Funktion so konstruiert, dass sie zwar jeder Spezialisierung von basic_string klarkommt, andererseits aber wieder in einen normalen handelsüblichen ostringstream schreiben will.
-
Wenn du ein & haben willst dann nimm Mr.Ns Beispiel und ersetze 'operator+' durch 'operator&'. Fertig.
His extensions and modifications to C++
Ich kann C++ auch solange modifizieren, bis es ein Basic ist.
Java ist eine weiterentwicklung von C++ und hat das Prinzip der Objektorientierung weiter vertieft bzw. zwingt den Programmierer schon fast dazu, OO zu programmieren.
Das ist schlecht. Ich werde nur äußerst ungerne zu etwas gezwungen. Und grade dass ich auch (zumindest ein wenig) funktional programmieren kann liebe ich so an C++, wogegen mich der prozedurale Teil einfach nicht interessiert.
Du findest es toll zu etwas gezwungen zu werden? Masochistisch veranlagt, wie?
-
Wenn du mehr Freiheiten willst, dann verwende doch einfach C. C++ schränkt dich unnötig ein.
-
Optimizer schrieb:
Wenn du mehr Freiheiten willst, dann verwende doch einfach C. C++ schränkt dich unnötig ein.
Begründe mal bitte
-
z.B. musst du Prototypen von Funktionen schreiben.
Nein, lass es mich anders formulieren:
C++ ZWINGT dich dazu, Prototypen bzw. Funktionsdefinitionen vor dem ersten Aufruf zu schreiben.C++ does not allow implicit function declarations. It is invalid to call a function that does not have a previous declaration in scope.
Ich bin jetzt grad zu faul, nach mehr Einschränkungen zu suchen. Java ist sogar noch mehr eingeschränkt:
- jeglicher Code muss in Klassen stehen.
- eine variable eines Blocks darf nicht genau so heißen wie eine Variable, die es schon vorher (außerhalb dieses Blocks) gibt.
- Zahlenwerte können nicht bool-Werten zugewiesen werden.
- usw.[Ironie]
Die Entwickler haben sich dabei natürlich überhaupt nichts gedacht und das sind alles nur unnötige Einschränkungen. Da die Sprachen immer eingeschränkter werden, bleiben halt dann manche Leute, die mehr Freiheiten wollen, am besten bei den Vorgängersprachen.
[/Ironie]
-
LOL
-
Optimizer schrieb:
z.B. musst du Prototypen von Funktionen schreiben.
Nein, lass es mich anders formulieren:
C++ ZWINGT dich dazu, Prototypen bzw. Funktionsdefinitionen vor dem ersten Aufruf zu schreiben.Ich weiß nicht so genau was Du meinst ?! Also in Java wirst Du sicherlich auch alles bekanntmachen müssen bevor Du es nutzt. Wenn Du Prototyp im sinne von
void foo(); meinst:
void bar() { } void foo() { bar(); } int main() { foo(); }
Gezwungen wirst Du da nu nich ?!
-
Du musst in Java keine Prototypen schreiben. Du musst in Java nicht mal eine Klasse erst definieren, um sie verwenden zu können:
class A { B objekt } class B { int bla; }
geht bei mir zumindest nicht!
in Java ist das kein Problem, da steht sowieso jede Klasse in einer eigenen Datei.Das stört mich bei C++ ziemlich, dass man alles in der richtigen Reihenfolge deklarieren muss. Dadurch kann ich auch oft Methoden nicht innerhalb der Klasse definieren und muss in die Klasse wieder ne Deklaration setzen.
P.S.: in Java gibt es kein int main(), das war jetzt wohl kein Java-Code?
-
Optimizer schrieb:
Du musst in Java keine Prototypen schreiben. Du musst in Java nicht mal eine Klasse erst definieren, um sie verwenden zu können:
class A { B objekt } class B { int bla; }
geht bei mir zumindest nicht!
in Java ist das kein Problem, da steht sowieso jede Klasse in einer eigenen Datei.Wo ist da deine Klasse nicht definiert? Du hast doch 'class B {blabla}'
geschrieben, also hast du die Klasse damit definiert.Das stört mich bei C++ ziemlich, dass man alles in der richtigen Reihenfolge deklarieren muss. Dadurch kann ich auch oft Methoden nicht innerhalb der Klasse definieren und muss in die Klasse wieder ne Deklaration setzen.
Versteh ich net. Du deklarierst deine Methoden in deiner Klasse, ist doch ne
voellig normale Sache.P.S.: in Java gibt es kein int main(), das war jetzt wohl kein Java-Code?
Ich glaube dort heisst die Funktion 'static int main()'
mfg
v R
-
Ne Java Code wars nich. Ich hab mit Java noch nix am hut, deswegen frag ich ja nu so viel nach.
Du musst doch in der Unit in der Klasse A verwendet wird irgendein Bezug in Klasse B erzeugen, und wenns ein Include ist?
-
Wenn du mehr Freiheiten willst, dann verwende doch einfach C. C++ schränkt dich unnötig ein.
hä? Schonmal versucht in C funktional zu Programmieren? Erst durch die Templates ergeben sich Möglichkeiten sowas umzusetzen. Und OOP in C ist eher ein Krapf, als Programmieren. Das ist ziemlich behindernd.
Und ich brauche keinen tollen [Ironie]-Tags, um deinen Sarkasmus zu erkennen. Ich sehe das als Beleidigung.
Das stört mich bei C++ ziemlich, dass man alles in der richtigen Reihenfolge deklarieren muss. Dadurch kann ich auch oft Methoden nicht innerhalb der Klasse definieren und muss in die Klasse wieder ne Deklaration setzen.
Allgemein stimm ich dir zu. Nur grade dein letztes Beispiel ist der einzige Fall in C++, wo genau das nicht gilt. Innerhalb der Klasse verhält sich das scoping quasi genau wie in Java.
-
Helium schrieb:
Allgemein stimm ich dir zu. Nur grade dein letztes Beispiel ist der einzige Fall in C++, wo genau das nicht gilt. Innerhalb der Klasse verhält sich das scoping quasi genau wie in Java.
// mein letztes Beispiel? Meinst du das? class SomeTests { Test myTest1; Test myTest2; }; class Test { int x; }; int main() { SomeTests harhar; return 27; }
Ich enttäusche dich nur ungern, aber... das wird nicht compiliert. Wenn ich die Klasse Test zuerst definiere, geht es.
virtuell Realisticer schrieb:
Wo ist da deine Klasse nicht definiert? Du hast doch 'class B {blabla}'
geschrieben, also hast du die Klasse damit definiert.Ja hab ich. Und nein es geht nicht. Siehe oben.
virtuell Realisticer schrieb:
Versteh ich net. Du deklarierst deine Methoden in deiner Klasse, ist doch ne
voellig normale Sache.Ja das ist leider normal. In Java kann (muss sogar) man die Methoden direkt in die Klassendefinition schreiben (also definieren).
@Knuddlbaer: Ich weiß leider nicht, was du meinst.
Also in Java steht der ganze Code in Klassen. Und jede Klasse steht in einer eigenen Datei. Wenn man damit erstmal gearbeitet hat, wird man diese Einschränkung begrüßen.
Die main()-Funktion steht auch in einer Klasse. Damit man darauf überhaupt zugreifen kann, ist sie alspublic static void main(String[] args)
definiert.
Ein Vorteil dieser Einschränkungen ist z.B. dass es keine globalen Variablen (sonder nur noch static) geben kann.Weiß eigentlich jemand, ob C# zur Spieleentwicklung taugt? C# ist nämlich eigentlich die selbe Sprache wie Java (darf man das überhaupt so dreist kopieren?).
-
Optimizer schrieb:
Ein Vorteil dieser Einschränkungen ist z.B. dass es keine globalen Variablen (sonder nur noch static) geben kann.
und voll in die Falle rein. Was hilft dir das? du versteckst quasi dann alle globalen Daten hinter ner Fassade. Bis auf reduzierende namespace pollution sehe ich nur semantische verluste
-
du versteckst quasi dann alle globalen Daten hinter ner Fassade.
Nein, ich räume sie auf. Man sollte auch in C++ keine globalen Variablen verwenden, sondern sie in Klassen einsortieren.
-
Optimizer schrieb:
Man sollte auch in C++ keine globalen Variablen verwenden, sondern sie in Klassen einsortieren.
und dadurch wirds dann besser
-
Optimizer schrieb:
Ja das ist leider normal. In Java kann (muss sogar) man die Methoden direkt in die Klassendefinition schreiben (also definieren).
@Knuddlbaer: Ich weiß leider nicht, was du meinst.
Also in Java steht der ganze Code in Klassen. Und jede Klasse steht in einer eigenen Datei. Wenn man damit erstmal gearbeitet hat, wird man diese Einschränkung begrüßen.Also in C++ wird oder zumindest sollte man jede Klasse in eine extra Datei schreiben.
Und auch in C++ kannst du deine Methoden direkt in der Klasse definieren. Das sollte eigentlich kein Problem darstellen.
-
PuppetMaster2k schrieb:
Optimizer schrieb:
Ja das ist leider normal. In Java kann (muss sogar) man die Methoden direkt in die Klassendefinition schreiben (also definieren).
@Knuddlbaer: Ich weiß leider nicht, was du meinst.
Also in Java steht der ganze Code in Klassen. Und jede Klasse steht in einer eigenen Datei. Wenn man damit erstmal gearbeitet hat, wird man diese Einschränkung begrüßen.Also in C++ wird oder zumindest sollte man jede Klasse in eine extra Datei schreiben.
Und auch in C++ kannst du deine Methoden direkt in der Klasse definieren. Das sollte eigentlich kein Problem darstellen.Sie sind aber dann inline und man sollte nur kleine Funktionen 'inlinen'.
Was ist so schlimm daran, Deklaration von Implementation zu trennen? Dadurch wird der gesamte
Aufbau doch gleich wieder uebersichtlichermfg
v R