char to string: Wie ich mir in den Fuß geschossen habe

MfG, ich werde mir die Mühe machen, dir einmal zu antworten. In Zukunft werde ich das nicht mehr tun, weil deine Ahnungslosigkeit (ich bin es auch, aber nicht sooo) ziemlich anstrengend ist und du implizit gegenteiliges behauptest.

Was ich mit Qualität der Compiler meine: Dass eben schon viele Fehler vorweg vermieden werden. D. h., Fehler werden zuverlässig erkannt und sind erst gar nicht kompilierbar. Logikfehler meine ich damit natürlich nicht.

Explizites Compilieren: Wenn du auf den Run-Button drückst. Implizites Compilieren: Es geschieht im Hintergrund. Java-IDEs machen das, sobald du eine Java-Datei speicherst.

gcc-Version: 4.8

Du weißt nicht, was Operatoren-Überladung ist? Das erlaubt z. B., dass ich Schokolade und Autoreifen verheirate. Das macht in dem Fall vll. nicht viel Sinn, aber bei char und string schon. Wie gesagt: string macht genau das beim Zuweisungsoperator:

char c = 'a';
string b;
b = c; // Funkioniert, weil hier der Operator = von string überladen wurde!

http://www.cplusplus.com/reference/string/string/operator=/
Man könnte theoretisch auch folgenden Operator definieren:

string& operator= (int i);

Und intern wird ein to_string() angewendet. Genau das hatte ich vermutet, weil gcc keine Warnung ausgab.

Hoffe, du hast nun ein paar Fragezeichen weniger im Kopf.

L. G.,
IBV

IBV schrieb:

MfG, ich werde mir die Mühe machen, dir einmal zu antworten. In Zukunft werde ich das nicht mehr tun, weil deine Ahnungslosigkeit (ich bin es auch, aber nicht sooo) ziemlich anstrengend ist und du implizit gegenteiliges behauptest.

Was ich mit Qualität der Compiler meine: Dass eben schon viele Fehler vorweg vermieden werden. D. h., Fehler werden zuverlässig erkannt und sind erst gar nicht kompilierbar. Logikfehler meine ich damit natürlich nicht.

Explizites Compilieren: Wenn du auf den Run-Button drückst. Implizites Compilieren: Es geschieht im Hintergrund. Java-IDEs machen das, sobald du eine Java-Datei speicherst.

gcc-Version: 4.8

Du weißt nicht, was Operatoren-Überladung ist? Das erlaubt z. B., dass ich Schokolade und Autoreifen verheirate. Das macht in dem Fall vll. nicht viel Sinn, aber bei char und string schon. Wie gesagt: string macht genau das beim Zuweisungsoperator:
char c = 'a';
string b;
b = c; // Funkioniert, weil hier der Operator = von string überladen wurde!
http://www.cplusplus.com/reference/string/string/operator=/
Man könnte theoretisch auch folgenden Operator definieren:
string& operator= (int i);
Und intern wird ein to_string() angewendet. Genau das hatte ich vermutet, weil gcc keine Warnung ausgab.

Hoffe, du hast nun ein paar Fragezeichen weniger im Kopf.

L. G.,
IBV

wie du meinst...
ahnungslosigkeit? wie kommst du darauf? nur weil ich mal nachgefragt hatte?
eine frage ist kein zeichen für ahnungslosigkeit... (soweit ich weiß...)
dann werde ich dich auch nicht weiter beanspruchen, nicht das es noch anstrengender wird ...

ok compiler-qualität hätte mir schon gereicht...
war mir nicht ganz sicher was du meinst...

expliziertes compilieren kenne ich nicht...
ich mache auch kein java...
bitte um verzeihung ich wollte in diesem zusammenhang eig einfach was dazu lernen...

ich weiß was operatoren-überladung ist ...
gibt hier im forum auch ne schöne mehr teilige erklärung dazu ...

ps. c++ ist aber kein "mist" .. auch wenn es manchmal probleme macht bzw. verständnis vorraussetzt... was java nicht macht ...

das wars von mir, dann schön abend noch...

@ IBV hast du vll mal einen link oder sowas zu diesem "explizierten" kompilieren...
ich kann dazu nix finden...
würde mich mal interessieren wie das funktioniert... (eig das nicht explizite speziell...)

lg

Because of the IDE's Compile on Save feature, you do not have to manually compile your project in order to run it in the IDE. When you save a Java source file, the IDE automatically compiles it.

https://netbeans.org/kb/docs/java/quickstart.html

When you save a Java file, Eclipse will automatically compile the file also, so that you don't need to compile it later when you want to run it.

http://oak.cs.ucla.edu/cs144/projects/eclipse/windows.html

IBV schrieb:

Because of the IDE's Compile on Save feature, you do not have to manually compile your project in order to run it in the IDE. When you save a Java source file, the IDE automatically compiles it.

https://netbeans.org/kb/docs/java/quickstart.html

When you save a Java file, Eclipse will automatically compile the file also, so that you don't need to compile it later when you want to run it.

http://oak.cs.ucla.edu/cs144/projects/eclipse/windows.html

vielen dank ...
schönen abend noch, sry falls ich i.wie genervt habe, war nicht meine absicht, wollte was lernen und evt. helfen.
lg MfG

Swordfish

IBV schrieb:

Also, dass C++ Compiler erst mit clang einigermaßen an die Qualität von Java, rust etc. rankommen ist traurig, da C++ deutlich älter ist.

Dir ist aber schon klar, daß der C++-Standard um einiges komplexer ist als deine Gegenbeispiele?

@Mfg: Mich hat vor allem gestört, dass jemand, der noch weniger Ahnung hat als ich, mir Ahnungslosigkeit vorgeworfen hat und als ich mich erklärte, hast du alte Punkte, die ich eigentlich schon aufgeklärt hatte, wiederholt bzw. hast um den heißen Brei geredet (ohne konstruktives Ergebnis). Genau das macht die Sache anstrengend.

Btw: Man kann in Java auch nicht ohne tiefes Verständnis gut programmieren und der GC ist in den meisten Fällen kein Problem, sondern Problemlöser.

Btw2: Eine neue Version von Chrome wurde released:

[$1500][406868] High CVE-2014-7900: Use-after-free in pdfium. Credit to Atte Kettunen from OUSPG.
[$1000][414504] High CVE-2014-7902: Use-after-free in pdfium. Credit to cloudfuzzer.
[$3000][414525] High CVE-2014-7903: Buffer overflow in pdfium. Credit to cloudfuzzer.
[$2000][418161] High CVE-2014-7904: Buffer overflow in Skia. Credit to Atte Kettunen from OUSPG.
[$500][423030] High CVE-2014-7906: Use-after-free in pepper plugins. Credit to Chen Zhang (demi6od) of the NSFOCUS Security Team.
[$7500][423703] High CVE-2014-0574: Double-free in Flash. Credit to biloulehibou.
[$5000][424453] High CVE-2014-7907: Use-after-free in blink. Credit to Chen Zhang (demi6od) of the NSFOCUS Security Team.
[$500][391001] Medium CVE-2014-7909: Uninitialized memory read in Skia. Credit to miaubiz.

http://googlechromereleases.blogspot.de/2014/11/stable-channel-update_18.html

Nein, ich will damit nicht sagen, dass es eine gute Idee ist in Java einen Browser zu schreiben, sondern, dass immer noch Menschen programmieren und egal wie gut du bist, du wirst immer klassische Fehler machen und wenn sie bei dir selten vorkommen, bist du entweder tatsächlich verdammt gut oder deine Programmieranforderungen provozieren obige Fehler nicht.

Swordfish schrieb:

Dir ist aber schon klar, daß der C++-Standard um einiges komplexer ist als deine Gegenbeispiele?

Was willst du damit sagen? Spricht das für C++ oder dagegen?
C++ ist teilweise zu recht komplex, weil mächtiger, teilweise ist es aber auch komplexer als es eigentlich nötig wäre, das spricht wiederum gegen C++.

L. G.,
IBV

Eine C++ IDE kann viele Fehler doch gar nicht anzeigen, da zu dem Zeitpunkt des Eingabe und Speichern nicht kompiliert wird, da ist keine VM im Hintergrund mit JIT. Um sowas zu können müsste IDE am laufenden Band kompilieren und einen vollständigen C++-Compiler eingebaut haben.

Da vergisst, dass C++ eine echte native Programmiersprache ist. Du programmiert da wirklich dein OS und die CPU etc. mit und nicht nur eine weichgespülte VM mit Zufalls-GC und keiner echten Ressourcenverwaltung, da RAII nicht wirklich konsequent unterstützt werden kann.

C++ ist halt LEGO für Erwachsene, da kann ein Kind schon mal überfordert sein und es in die Ecke schmeißen.

@ThinkAboutIt: Jede Wette, dass du auch so ein Kandidat mit wenig Ahnung bist! Du hast meine Kritikpunkte nicht mal im Ansatz verstanden!

Swordfish

IBV schrieb:

Swordfish schrieb:

Dir ist aber schon klar, daß der C++-Standard um einiges komplexer ist als deine Gegenbeispiele?

Was willst du damit sagen? Spricht das für C++ oder dagegen?
C++ ist teilweise zu recht komplex, weil mächtiger, teilweise ist es aber auch komplexer als es eigentlich nötig wäre, das spricht wiederum gegen C++.

Komplexität spricht so ohne weiteres weder dafür noch dagegen. Es ist so. Lern bitte argumentieren.

IBV schrieb:

Btw: Man kann in Java auch nicht ohne tiefes Verständnis gut programmieren und der GC ist in den meisten Fällen kein Problem, sondern Problemlöser.

Dass du wenig Verständnis für die Programmierung hast, attestierst du dir gerade selbst mit solch einer Aussage. Gerade dass Java dir soviel abnimmt, kann dir am Ende des Projektes ganz übel mitspielen. Wenn der GC nämlich in sehr ungünstigen Momenten zuschlägt, da du die ganze Projektphase die Speicherverwaltung komplett ignoriert hast, weil du nie gelernt hast mit RAM umzugehen und dann im Produktivbetrieb fliegt dir alles um die Ohren und ein Jahr harter Teamarbeit ist vielleicht für die Katz.

Mit C++ kann man sich in den Fuß schießen, mit Java kann man sich am Ende das Genick brechen.

Sage mal, kann es sein, dass du nur so ein kleiner C++-Basher bist, der noch mitten in der Pubertät steckt?

Swordfish schrieb:

Komplexität spricht so ohne weiteres weder dafür noch dagegen. Es ist so. Lern bitte argumentieren.

Das ist Quatsch. Wenn ich zwei Dinge mit der gleichen Funktionalität habe, egal, ob es sich um ein Programm, Code, um eine Sprache, um ein Auto oder sonst etwas handelt, dann spricht das zum einen für das weniger komplexe Etwas, zum anderen gegen das komplexere. Und ja: Beide sind komplex bzw. weniger komplex.

Swordfish

Aha. Java und rust bieten also die selbe Funktionalität wie C++. qed.

@JavaGC: *Lach* Ist dir eigentlich klar, dass ich den Spieß umdrehen kann und mit ganz ähnlichen Argumenten gegen C++ wettern kann? Schau dir mal den Chrome-Changelog an, den du wirklich perfekt ignoriert oder im Kopfe klein geredet hast.

Es gibt ein paar Fälle, wo Java nicht geeignet ist, was ich sogar erst eine Seite zuvor unterstrichen habe. Aber diese ach so schlimme GC-Sprache funktioniert in der produktiven Welt erstaunlich gut. Selbst auf Smartphones, was du vor einigen Jahren bestimmt vehement bestritten hättest!

Swordfish schrieb:

Aha. Java und rust bieten also die selbe Funktionalität wie C++. qed.

Gehe zurück zu los und lies nochmal! qed.

Nathan

IBV schrieb:

@JavaGC: *Lach* Ist dir eigentlich klar, dass ich den Spieß umdrehen kann und mit ganz ähnlichen Argumenten gegen C++ wettern kann? Schau dir mal den Chrome-Changelog an, den du wirklich perfekt ignoriert oder im Kopfe klein geredet hast.

*sigh*
Wer Use-after-free und double-free Fehler hat, verwendet kein modernes C++, sondern macht manuelle Speicherverwaltung, wie das halt bei Legacycode üblich ist. Mit modernem C++ kann man die vermeiden, da können sie unmöglich* auftreten.

Es gibt ein paar Fälle, wo Java nicht geeignet ist, was ich sogar erst eine Seite zuvor unterstrichen habe. Aber diese ach so schlimme GC-Sprache funktioniert in der produktiven Welt erstaunlich gut.

Ich zitiere einfach mal Stephan T. Lavavej:

STL http://nuwen.net/gcc.html#whynotjava schrieb:

**Why Not Java
**
Second, Java. Java is a terrible programming language developed by incompetent programmers. It is not an undue exaggeration to say that everything Java does is wrong. There is nothing interesting that can be learned from Java, except how such an awful programming language can become so popular. Java is said to increase programmer productivity, but this is a half-truth. Java increases the productivity of incompetent programmers; it harms the productivity of excellent programmers. Since 90% of programmers are incompetent, the overall effect is that Java increases programmer productivity. I submit that this is the exact opposite of a good thing. Do not waste time with Java; let the incompetent programmers revel in their miserable language while you embrace the wonder that is C++.

Why is Java a terrible programming language? Alex Stepanov can explain it better than I can.

"I spent several months programming in Java. Contrary to its author's prediction, it did not grow on me. I did not find any new insights - for the first time in my life programming in a new language did not bring me new insights. It keeps all the stuff that I never use in C++ - inheritance, virtuals - OO gook - and removes the stuff that I find useful. It might be successful... but it has no intellectual value whatsoever" - Alexander Stepanov

Java takes almost all of the useful and powerful things in C++ and C and discards them. This includes: [...]
And for losing all of that, what do we get in return? Garbage collection, a fundamentally flawed approach to resource management. (FIXME: Jumplink to RAII.) Stay away from Java if you value your sanity.

Selbst auf Smartphones, was du vor einigen Jahren bestimmt vehement bestritten hättest!

Saying that Java is good because it works on all platforms is like saying anal sex is good because it works on all genders.

*Disclaimer, weil absolute Aussage.

Das wird mir zu unsachlich.

http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

Tschö mit "ö"!

IBV schrieb:

Aber diese ach so schlimme GC-Sprache funktioniert in der produktiven Welt erstaunlich gut. Selbst auf Smartphones, was du vor einigen Jahren bestimmt vehement bestritten hättest!

Wut, wut, wut??? :o

Klick.
Ich fasse kurz zusammen: Die haben einen Haufen Methoden in ihrer App gehabt, und das hat den statischen Buffer platzen lassen. Also haben sie dran rumgehackt, und von der Beschreibung bekomme ich schlechte Träume:

Instead, we needed to inject our secondary dex files directly into the system class loader. This isn't normally possible, but we examined the Android source code and used Java reflection to directly modify some of its internal structures. We were certainly glad and grateful that Android is open source — otherwise, this change wouldn't have been possible.

Wenn ich jemanden in C eine solche Arbeit hätte machen sehen, hätte ich ihm den Code um die Ohren geschlagen. Als Code-Reviewer lese ich manchmal auch Java-Code. Der ist meistens scheiße. Keine Ahnung, ob das daran liegt, dass die Leute, die den Code hacken, scheiße sind, oder weil die Sprache scheiße ist. Da mache ich kein Urteil, in C kannst du auch Scheiße bauen.

Übrigens: Linus hat recht.

Nathan schrieb:

Wer Use-after-free und double-free Fehler hat, verwendet kein modernes C++, sondern macht manuelle Speicherverwaltung, wie das halt bei Legacycode üblich ist. Mit modernem C++ kann man die vermeiden, da können sie unmöglich* auftreten.

Redest du jetzt von der Sprache an sich, oder von den vielen Frameworks? Da gab's schon einige Use-After-Free-Probleme. Sind wahrscheinlich alle nicht mit modernem C++ programmiert worden.

Nathan

dachschaden schrieb:

Nathan schrieb:

Wer Use-after-free und double-free Fehler hat, verwendet kein modernes C++, sondern macht manuelle Speicherverwaltung, wie das halt bei Legacycode üblich ist. Mit modernem C++ kann man die vermeiden, da können sie unmöglich* auftreten.

Redest du jetzt von der Sprache an sich, oder von den vielen Frameworks? Da gab's schon einige Use-After-Free-Probleme. Sind wahrscheinlich alle nicht mit modernem C++ programmiert worden.

Von der Sprache an sich. Ich verwende konsequent RAII und hatte noch nie double-free oder user-after-free. Nur Segfaults wegen falscher Pointer.

volkard

Nathan schrieb:

Ich verwende konsequent RAII und hatte noch nie double-free oder user-after-free. Nur Segfaults wegen falscher Pointer.

Jupp. Das erinnert mich an meine Metapher mit den naturblonden Chinesen in Bielefeld.
http://www.c-plusplus.net/forum/158841-42

Es hat keinen Taug, C-Probleme für größere Programme zu nehmen und sie C++ vorzuwerfen. Sie sind vollständig behoben. quote=2006 und da wars schon 10 Jahre lang sonnenklar.

Allein bleiben übrig der Lernwiderstand dank noch existierender schlechter Bücher und der Haß der Javauntergeher.

Rust/Go und Konsorten gehen den richtigen Weg, einen Nachfolger von C++ vorzubereiten mit abgeschnittenen alten Zöpfen. Bisher sieht man lange keine Sonne, weil die Vereinfachungssprachen nicht sehen, daß das Proggern an sich saukompliziert ist und man keinen runden Deckel auf einen viereckigen Topf tun sollte.

edit: Ich lasse den Versuch nicht gelten, daß Java zugegeben turingvollständig ist aber so lahm ist, daß man das Halteproblem damit löst durch faktische Ununterscheidbarkeit.