von Java nach C++
-
Es baut dir nicht nur die html Seiten, der gesamte Java Quelltext ist so kommentiert und das Javadoc kann auch direkt in deine IDE z.b. Eclipse integriert werden, dass es direkt angezeigt wird.
Geht auch mit C++ Eclipse und Doxygen.
-
Wenn man keine Argumente hat, lügt man halt um seine Lieblingssprache zu verteidigen.
Jo, C++ ist aber eine Programmiersprache mit vielen Tücken, welche ich jetzt so nicht bei Java gesehen habe (auch wenn ich mich schon lange nicht mehr mit Java programmiert haben).
Zeigerarithmetik, Mehrfachvererbung, Templates,... können einfach sein, müssen sie aber nicht. Schon die ganzen Späße mit Speicherlöchern, Resourcenfreigabe ist nicht zu verachten. Das sollte man schon einmal durchackern.
-
Wer behauptet, Memory-Leaks seien ein Problen und/oder kämen regelmäßig vor, der benutzt C++ falsch.
-
SoGehtEs schrieb:
krümelkacker schrieb:
SoGehtEs schrieb:
Und wenn du spass haben willst. http://yosefk.com/c++fqa/
Nicht mal für eine Belustigung reicht c++fqa aus. Im Wesentlichen beschränkt sich der Nutzen von c++fqa auf Leute, die C++ nicht wirklich kennen aber doch irgendwie bashen wollen, in dem sie darauf verlinken ... à la "Ich weiß zwar nicht, wovon ich rede, aber C++ ist scheisze, weil siehe c++fqa".
Wenn man keine Argumente hat, lügt man halt um seine Lieblingssprache zu verteidigen.
Bleibt dir natürlich frei, so zu denken. Aber so schwarz und weiß, wie du die Welt siehst, ist sie wahrscheinlich nicht. Recherchiere doch mal ein bisschen, was und warum andere Leute von C++FQA halten. Das muss man IMHO nicht alles wieder neu aufbrühen. Spontan finde ich z.B. das hier.
-
Wer behauptet, Memory-Leaks seien ein Problen und/oder kämen regelmäßig vor, der benutzt C++ falsch.
Klar.
Bloß für meinen Geschmack sollte man beim Wechsel von Java nach C++ auch Dinge wie Speicherlöcher anschauen, damit man auch die Gründe für RAII versteht und auch den Unterschied zur Garbage Collection versteht. Und damit man auch beim Zugriff auf C Libs keine bösen Überraschungen erlebt.
-
SoGehtEs schrieb:
9. Strings sind ein Graus in C++. Ich kann dir nicht wirklich einen guten empfehlen, wer std::string sagt, hat keine Ahnung von Internationalisierung.
Hmm. Was hat i18n mit dem verwendeten String-Datentypen zu tun? Ein std::string ist eine Kette von Bytes und damit eine Low-Level-Struktur. Was ich damit letztendlich anstelle, ist mir überlassen.
Warum sollte ich nicht auf Basis von std::string eine ordentliche Internationalisierungsinfrastruktur aufbauen können?
Finde die Frage gerade recht interessant. Wenn nötig, kann ein Mod das auch gerne in einen anderen Thread splitten.
-
Zur Javadoc-Diskussion:
Äußerst gelungen finde ich hier Godoc, das Dokumentationssystem der Programmiersprache Go. Es erstellt eine IMHO sehr gut lesbare Doku (im Gegensatz zu so manchem was ich schon von Javadoc gesehen habe) ohne dass man seinen Quellcode mit aufdringlichen Annotationen in einem bestimmten Format verschandeln muss.
Genutzt werden einfach an der richtigen Stelle plazierte Kommentare. Ausspucken kann es HTML (als Datei oder auf einem lokalen Webserver serviert), aber ist flexibel genug auch ein ernsthaft nutzbares Commandline-Tool zu füttern.
Die generierte HTML-Doku enthält Links, die einem bei Bedarf auch direkt die richtige Stelle des Quellcodes zeigen.
Beispiel
http://golang.org/pkg/os/
(für das Aussehen im Quellcode sind unten auch die Dateien des Packages aufgelistet; oder halt einfach auf einen Funktionsnamen klicken)Die komplette golang.org-Website läuft auf dem Godoc-Webserver, d.h. man kann auch zusätzlichen Content elegant in die Doku einbauen.
-
SoGehtEs schrieb:
9. Strings sind ein Graus in C++. Ich kann dir nicht wirklich einen guten empfehlen, wer std::string sagt, hat keine Ahnung von Internationalisierung.
Inwiefern sind Strings in Java denn besser?
-
badgerbadgerbadger schrieb:
SoGehtEs schrieb:
9. Strings sind ein Graus in C++. Ich kann dir nicht wirklich einen guten empfehlen, wer std::string sagt, hat keine Ahnung von Internationalisierung.
Hmm. Was hat i18n mit dem verwendeten String-Datentypen zu tun? Ein std::string ist eine Kette von Bytes und damit eine Low-Level-Struktur. Was ich damit letztendlich anstelle, ist mir überlassen.
Wer das glaubt kann auch einen std::vector nehmen. Woher weißt du viele Zeichen (nicht bytes) dein String hat, wenn du nur einen Haufen von Bytes ohne angabe des Encodings hast?
dot schrieb:
SoGehtEs schrieb:
9. Strings sind ein Graus in C++. Ich kann dir nicht wirklich einen guten empfehlen, wer std::string sagt, hat keine Ahnung von Internationalisierung.
Inwiefern sind Strings in Java denn besser?
Keine Ahnung was die genau machen, ich arbeite schon ewig nich tmehr mit Java, aber immerhin gibts da einen String den (fast) jede Library verwendet und man muss nicht ständig konvertieren wie in C++.
-
SoGehtEs schrieb:
Woher weißt du viele Zeichen (nicht bytes) dein String hat, wenn du nur einen Haufen von Bytes ohne angabe des Encodings hast?
Was nützt es mir, das zu wissen?
Encoding ist in (modernem) C++ immer UTF-8, nicht der UTF-16-Schrott.Und Java mit seinem
meinStringMitLangemNamen.codePointCount(0, meinStringMitLangemNamen.length())ist da auch nicht viel besser.SoGehtEs schrieb:
immerhin gibts da einen String den (fast) jede Library verwendet und man muss nicht ständig konvertieren wie in C++.
Für GUIs ist C++ vielleicht nicht die geeignetste Sprache (Java aber auch nicht). Im Backend kann std::string aber konsistent verwendet werden.
-
htgsdf schrieb:
Encoding ist in (modernem) C++ immer UTF-8
Hast du mal ein paar Links zu Opensource Code der utf-8 und std::string verwendet?
-
SoGehtEs schrieb:
dot schrieb:
SoGehtEs schrieb:
9. Strings sind ein Graus in C++. Ich kann dir nicht wirklich einen guten empfehlen, wer std::string sagt, hat keine Ahnung von Internationalisierung.
Inwiefern sind Strings in Java denn besser?
Keine Ahnung was die genau machen, ich arbeite schon ewig nich tmehr mit Java, aber immerhin gibts da einen String den (fast) jede Library verwendet und man muss nicht ständig konvertieren wie in C++.
Aha und inwiefern ist dieser String, "den (fast) jede Library verwendet und man nicht ständig konvertieren muss", besser für Internationalisierung als std::basic_string!?
-
Das Template std::basic_string kann man schön instanziieren:
std::basic_string<char> -> ASCII String
std::basic_string<wchar_t> -> Windows Unicode String
std::basic_string<TCHAR> -> Variabler String für Windows. Unicode Projekt -> Unicode String, ASCII Projekt -> ASCII String
std::basic_string<unsigned long> -> UTF32 String
...Nur für UTF8 ist std::basic_string nicht geeignet, was man dem std::basic_string aber nicht ankreiden kann.
-
seit wann? schrieb:
htgsdf schrieb:
Encoding ist in (modernem) C++ immer UTF-8
Hast du mal ein paar Links zu Opensource Code der utf-8 und std::string verwendet?
Hier mal ein Programm, das sehr viel mit Textverarbeitung zu tun hat: GNU Source-highlight
http://git.savannah.gnu.org/cgit/src-highlite.git/tree/src/source-highlight.cc@Bitte ein Bit: So sieht das richtig aus:
std::basic_string<char> -> UTF-8 String
std::basic_string<wchar_t> -> Blödsinn
std::basic_string<TCHAR> -> Blödsinn
std::basic_string<unsigned long> -> Völliger Blödsinn
std::basic_string<char32_t> -> Theoretisch UTF-32, de facto unnötig.
-
Bitte ein Bit schrieb:
Nur für UTF8 ist std::basic_string nicht geeignet, was man dem std::basic_string aber nicht ankreiden kann.
std::basic_string ist rein prinzipiell nicht mehr oder weniger schlecht für Unicode geeignet als der Java oder .NET String auch, man ist sich dieser Einschränkungen im Umfeld von C++ offenbar einfach nur wesentlich besser bewusst...
-
SoGehtEs schrieb:
Woher weißt du viele Zeichen (nicht bytes) dein String hat, wenn du nur einen Haufen von Bytes ohne angabe des Encodings hast?
Ich habe den Kram doch da rein getan, also weiß ich auch, welche Kodierung ich dabei verwendet habe. Vernünftigerweise natürlich UTF-8. Eine Funktion zu schreiben, die mir die Anzahl an Codepoints in einem UTF-8-String zurückgibt, ist trivial. Wo ist jetzt das Problem?
Wenn ich ständig wahlfreien Zugriff auf die Codepoints benötigen sollte, wandle ich eben bei Bedarf vorher zu UCS-4 in einem basic_string<uint32> o.ä. um.
@Bitte ein Bit: warum sollte basic_string<char> nicht für UTF-8 geeignet sein?
…
-
SoGehtEs schrieb:
Woher weißt du viele Zeichen (nicht bytes) dein String hat, wenn du nur einen Haufen von Bytes ohne angabe des Encodings hast?
Das weißt du auch in Java nicht. Überhaupt, die Frage wieviele "Zeichen" ein String hat ist rein Prinzipiell alles andere als einfach zu beantworten. Was genau verstehst du denn unter einem Zeichen? Ein Code Unit? Einen Code Point? Ein Grapheme? Einen Abstract Character?
-
Eine Funktion zu schreiben, die mir die Anzahl ...
Deswegen ist std::basic_string genauso gut wie std::vector, da die Standardfunktionalitaet von std::basic_string nicht benutzt werden kann. Eine simple Methode length muss selbst implementiert werden. std::basic_string ist ungeeignet und kann maximal als untergeordneter Container verwendet werden.
-
dot schrieb:
Aha und inwiefern ist dieser String, "den (fast) jede Library verwendet und man nicht ständig konvertieren muss", besser für Internationalisierung als std::basic_string!?
Der entscheidende Punkt bei Java ist die Standardbibliothek. Hier kriegt man von Anfang an eine erhebliche Infrastruktur fuer viele Dinge mitgeliefert. Das betrifft auch die Unterstuetzung der Internationalisierung. Javaentwickler nutzen praktisch immer java.lang.String, weil man weiss, dass es in der Standardbibliothek jede Menge Klassen, Methoden und so weiter gibt, die darauf ausgelegt sind. Externe Bibliotheken nutzen praktisch aus gleichem Grund die gleichen Strings. Wenn es in Java um Strings geht, ist java.lang.String deshalb die erste Wahl. Alles andere muss man erstmal rechtfertigen. Warum sollte man sich aus der massiven Unterstuetzung dieser Klasse ausklinken? Meistens findet man keinen Grund, der das rechtfertigen wuerde.
Ich habe keine Ahnung, wie die Situation diesbezueglich in C++ ist. C++ hat eine schlankere Standardbibliothek, so dass es vielleicht weniger offensichtlich ist, auf welcher Basis man seinen eigenen Code schreiben sollte. Ich vermute einfach mal, dass man deshalb haeufig externe Bibliotheken nutzt, die nicht unbedingt zu einander passen. Man wird also vermutlich mehr damit beschaeftigt sein, zwischen unterschiedlichen Bibliotheken zu vermitteln.
dot schrieb:
std::basic_string ist rein prinzipiell nicht mehr oder weniger schlecht für Unicode geeignet als der Java oder .NET String auch, man ist sich dieser Einschränkungen im Umfeld von C++ offenbar einfach nur wesentlich besser bewusst...
Wenn man sich gewisser Einschraenkungen nicht bewusst ist, dann meistens deshalb, weil sie im gegebenen Umfeld nicht relevant sind.
-
knivil schrieb:
Eine Funktion zu schreiben, die mir die Anzahl ...
Deswegen ist std::basic_string genauso gut wie std::vector, da die Standardfunktionalitaet von std::basic_string nicht benutzt werden kann. Eine simple Methode length muss selbst implementiert werden.
Ist doch Quatsch. Meist will ich doch gerade die Länge in Byte wissen. Was bringt mir denn die Anzahl der Codepoints? Was fange ich damit an? Siehe dot.
Die meisten anderen basic_string-Funktionen und Methoden kann ich doch prima mit UTF-8 verwenden. Ich seh' das Problem nicht.
