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

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.

hustbaer

Nathan schrieb:

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

Das kann für mich jetzt zwei Sachen heissen:

Segfaults wegen falscher Zeiger die überhaupt nie auf ne "richtige" Adresse hatten. Das wäre noch verzeihbar, Flüchtigkeitsfehler wenn man vergessen hat was mit 0 zu initialisieren oder so.
Segfaults wegen falscher Zeiger die mal "richtige" Zeiger waren. Nur das Heap-Segment an der Stelle wurde halt schon freigegeben, und deswegen kracht es dann. Das würde heissen dass du dich selbst belügst, denn genau das *ist* use-after-free. Und wenn du so nen Segfault bekommst, dann gab es davor vermutlich schon hunderte "use-after-free" Vorfälle die einfach nur unbemerkt geblieben sind.

Nathan

Falsche Pointer Arithmetik.
Typverlust via void* und dann falsches Casten.
Das sind die Fehler,

volkard

Unfassbar, wie frech und dominant sich IBV als blutiger Anfänger über welche setzt, die seiner Meinung nach einen Monat weniger wissen. Ein würdiger Nachfolger für TGGC und Prof84.

Wenn man keine Ahnung hat, einfach mal die Klappe halten!

Außerdem im konkreten Fall dieses Forum verlassen. Bei solchen Laberkästen im Staff werden Euch früher oder später alle technisch versierten Mods abspringen.

tntnet

Nathan schrieb:

Falsche Pointer Arithmetik.

Typverlust via void* und dann falsches Casten.
Das sind die Fehler,

Du verwendest Pointerartithmetik? Und Casten via void*? Was verstehst Du denn unter modernen C++

Ethon

Nathan schrieb:

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.

Boah ist das eine nervige Laberbacke. Der ist bei Microsoft gut aufgehoben.

tntnet schrieb:

Nathan schrieb:

Falsche Pointer Arithmetik.

Typverlust via void* und dann falsches Casten.
Das sind die Fehler,

Du verwendest Pointerartithmetik? Und Casten via void*? Was verstehst Du denn unter modernen C++

Ja, ich verwende Pointerarithmetik und Casten.
Allerdings extrem abgekapselt. Und es ist notwendig. Die Pointerarithmetik in einem Stack-Allocator und das void* im Callstack meiner Skriptsprache.
Die Lösung ist zwar nicht sonderlich elegant, dafür extrem schnell. Und das ist kein Problem, weil das falsche Casten wird in der Zukunft automatisiert.

Ethon schrieb:

Boah ist das eine nervige Laberbacke. Der ist bei Microsoft gut aufgehoben.

Ist doch wahr was der sagt. Java hat keinen besonderen Lernwert und so viele schlechte Designs, dass gute Programmierer nicht produktiv arbeiten können, weil sie sich ständig darüber am Aufregen sind. Das fängt mit GC an, geht mit dem dämlichen "alles ist ein Pointer" weiter und endet mit mangelnden guten Möglichkeiten zur generischen Programmierung.

volkard

NathanOff schrieb:

tntnet schrieb:

…
Was verstehst Du denn unter modernen C++

…
Und das ist kein Problem, weil das falsche Casten wird in der Zukunft automatisiert.
…

Automatisch falsch zu casten ist in der Tat ein sehr moderner Ansatz.
Halt uns auf dem Laufenden!

Ethon

NathanOff schrieb:

Ethon schrieb:

Boah ist das eine nervige Laberbacke. Der ist bei Microsoft gut aufgehoben.

Ist doch wahr was der sagt. Java hat keinen besonderen Lernwert und so viele schlechte Designs, dass gute Programmierer nicht produktiv arbeiten können, weil sie sich ständig darüber am Aufregen sind. Das fängt mit GC an, geht mit dem dämlichen "alles ist ein Pointer" weiter und endet mit mangelnden guten Möglichkeiten zur generischen Programmierung.

Welchen Lernwert willst du denn? Java hat nur langweilige, ausgereifte Features - deswegen benutzt man es ja.
Bei uns beschwert sich niemand über Java als Tool weil es funktioniert und macht was es soll.
Können sich Gartenzwerge wie der STL noch so viel darüber aufregen, es interessiert keinen der zahlreichen Anwender.

Und ich bin C++ Fanboy. Aber warum sollte ich für ein Sprache Partei ergreifen? Sind doch alles nur Tools. Wenn ich über etwas schimpfen möchte dann vlt PHP weil die Sprache einfach komplett verhunzt ist. Aber Java? Man bekommt was man erwartet.

Das fängt mit GC an,

Der ist super.

geht mit dem dämlichen "alles ist ein Pointer" weiter

Es gibt Value-Typen. Zwar nur primitive, ab Java 9/10 aber auch zusammengesetzte. Sehe auch nicht inwiefern mich Referenztypen bei der Arbeit stören sollten.

und endet mit mangelnden guten Möglichkeiten zur generischen Programmierung.

Beispiel, bei dem es limitieren oder stören würde? Mir nicht bekannt.

Columbo

Boah ist das eine nervige Laberbacke. Der ist bei Microsoft gut aufgehoben.

volkard schrieb:

Unfassbar, wie frech und dominant sich IBV als blutiger Anfänger über welche setzt, die seiner Meinung nach einen Monat weniger wissen. Ein würdiger Nachfolger für TGGC und Prof84.

Wenn man keine Ahnung hat, einfach mal die Klappe halten!

Außerdem im konkreten Fall dieses Forum verlassen. Bei solchen Laberkästen im Staff werden Euch früher oder später alle technisch versierten Mods abspringen.

Ich war auch ziemlich gereizt. Normalerweise antworte ich auf diese Weise nicht.
Ich bin in C++ zwar nicht versiert, aber ich habe mich genügend umgeschaut, was Sprachen, Technologien und Infrastruktur (d. h. Tools für die Sprachen wie IDEs, Buildtools (sbt ftw)) angeht, so dass ich mir eine Meinung bilden konnte.

Meine Sicht auf C++ ist differenziert und nicht so Schwarz-Weiß wie das einige vll. interpretiert haben. Selbst, wenn rust 1.0 rauskommt, werde viele Unternehmen lange auf C++ setzen. Zum einen, um ihre Software weiter zu pflegen, zum anderen, wegen den vorhandenen Libs und Tools und weil es hier schon Know How gibt.

Falls jemand denkt, ich würde Java in den Himmel loben, der irrt. Es gibt Dinge in Java, die sind wirklich kaputt (ich meine damit nicht den GC :p ). Z. B. Type Erasure. Letzteres führt dazu, dass man nicht zur Laufzeit ermitteln kann, um welches Generic es sich hier handelt, da die Information beim Compilieren eliminiert wird und an entsprechenden Stellen einfach ein Cast gemacht wird. Dieses Laster führt dazu, dass man in Scala pattern matching nur begrenzt durchführen kann. Folgendes ist z. B. nicht möglich:

foo match {
   case MyObject[Int] => Do something
}

Dass es sich um ein Int-Generic handelt, ist hier nicht mehr feststellbar, wohl aber, dass es sich um eine MyObject-Instanz handeln könnte.
Dieser Aspekt wird in Java wohl immer kaputt bleiben, um die Kompatibilität nicht zu brechen, was Scala eben auch zu spüren bekommt. Apropo Scala: Schon erstaunlich, dass so eine kleine Bude wie typesafe Java auf der linken Spur auf derselben(!) Plattform so schnell überholt hat. Bis Java 8 wollte ich mich deswegen gar nicht mehr intensiv mit Java befassen, aber seit Java wieder einigermaßen modern ist, finde ich die Sprache wieder interessant.

Um meinen Willen zum Frieden zu demonstrieren, verschenke ich hier einen One Plus Invite. Das Angebot gilt nur für registrierte Benutzer, die in diesem Thread gepostet haben (eine Ausnahme mache ich bei Mods und Admins). Außerdem muss versichert werden, dass mit dem Invite bzw. mit dem gekaufen One Plus One kein Gewinn gemacht wird. Das Angebot gilt auch nur für zwei Tage, da die Invites ebenfalls zeitlich begrenzt sind.
Wer nicht weiß, was ein One Plus ist:

https://oneplus.net/

@Volki: Hast du nicht ein Uralt-Handy? Wird's nicht mal langsam Zeit?

L. G.,
IBV

Columbo

@IBV: Bitte nicht Werbung posten. Sonst muss ich dich melden.

Arcoth schrieb:

@IBV: Bitte nicht Werbung posten. Sonst muss ich dich melden.

Falls das ein anderer Mod bestätigen kann, entferne ich die Stelle entsprechend. Es war eigentlich nur gut gemeint und ich verdiene auch nichts dran.

volkard

IBV schrieb:

@Volki: Hast du nicht ein Uralt-Handy? Wird's nicht mal langsam Zeit?

In der Tat.

Nee, ich schau mir den Markt erst noch ein Weilchen an.

Columbo

IBV schrieb:

Es war eigentlich nur gut gemeint und ich verdiene auch nichts dran.

Es geht schon in Ordnung. Aber sogar Kruemelkacker hat sich als Werber herausgestellt, da muss man stets vorsichtig sein da Leute eine Weile lang kompetent daherkommen koennen und dann den Account fuer andere Zwecke verwenden.

Edit: Es hat sich nunmal merkwuerdig angehoert. Da wurde ich ganz misstrauisch, musste verstehen.

Ethon

IBV schrieb:

Dass es sich um ein Int-Generic handelt, ist hier nicht mehr feststellbar, wohl aber, dass es sich um eine MyObject-Instanz handeln könnte.
Dieser Aspekt wird in Java wohl immer kaputt bleiben, um die Kompatibilität nicht zu brechen, was Scala eben auch zu spüren bekommt. Apropo Scala: Schon erstaunlich, dass so eine kleine Bude wie typesafe Java auf der linken Spur auf derselben(!) Plattform so schnell überholt hat. Bis Java 8 wollte ich mich deswegen gar nicht mehr intensiv mit Java befassen, aber seit Java

Naja, nicht so das Problem, man kann ja in Generics das Klassenobjekt per Getter verfügbar machen. Damit kann man dann auch zur Laufzeit an den Typ kommen. Zwar eher hackish aber ein praktikabler Workaround.
Sprachen ohne Kompromisse gibt es leider nicht.

Ethon schrieb:

IBV schrieb:

Dass es sich um ein Int-Generic handelt, ist hier nicht mehr feststellbar, wohl aber, dass es sich um eine MyObject-Instanz handeln könnte.

Naja, nicht so das Problem, man kann ja in Generics das Klassenobjekt per Getter verfügbar machen. Damit kann man dann auch zur Laufzeit an den Typ kommen. Zwar eher hackish aber ein praktikabler Workaround.
Sprachen ohne Kompromisse gibt es leider nicht.

Das funktioniert sogar. Nur, dass ich in Scala keinen Getter anlegen muss.

case class MyObject[T](genType: String)

val foo = MyObject[Int]("Int")

foo match {
   case MyObject("Int") => println("Funktioniert!")
   case _ => println("Funktioniert nicht!")
}

L. G.,
IBV

hustbaer

Nathan schrieb:

Falsche Pointer Arithmetik.

Typverlust via void* und dann falsches Casten.
Das sind die Fehler,

OK.
So lange es nicht (2) ist, ist ja alles OK
An Pointer Arithmetik hatte ich nicht gedacht, weil ich die nie brauche. Und an falsche Casts nicht, weil ich ... naja, so-gut-wie nie falsch gecastet habe

Nathan

volkard schrieb:

NathanOff schrieb:

tntnet schrieb:

…
Was verstehst Du denn unter modernen C++

…
Und das ist kein Problem, weil das falsche Casten wird in der Zukunft automatisiert.
…

Automatisch falsch zu casten ist in der Tat ein sehr moderner Ansatz.
Halt uns auf dem Laufenden!

Ja, ungünstig formuliert.

hustbaer schrieb:

Nathan schrieb:

Falsche Pointer Arithmetik.

Typverlust via void* und dann falsches Casten.
Das sind die Fehler,

OK.
So lange es nicht (2) ist, ist ja alles OK
An Pointer Arithmetik hatte ich nicht gedacht, weil ich die nie brauche. Und an falsche Casts nicht, weil ich ... naja, so-gut-wie nie falsch gecastet habe

Es ist dummerweise notwendig. Ich speichere einen Memoryblock, darin sind Pointer gespeichert, in einem rekursiven Template werden sie nun der Reihe nach genommen und gecastet. Hat man die Typargumente falsch, crashts.

Ethon schrieb:

Welchen Lernwert willst du denn? Java hat nur langweilige, ausgereifte Features - deswegen benutzt man es ja.
Bei uns beschwert sich niemand über Java als Tool weil es funktioniert und macht was es soll.
Können sich Gartenzwerge wie der STL noch so viel darüber aufregen, es interessiert keinen der zahlreichen Anwender.

STL meint vermutlich: Welchen Mehrwert hat es Java gegenüber anderen Sprachen zu verwenden? Wieso kann ich nicht bspw. C++ nehmen?

Das fängt mit GC an,

Der ist super.

Super ein Problem langsamer, aufwendiger, unvollständiger und unzuverlässiger zu lösen als bpsw. RAII, ja. RAII ist vielseitiger, schneller und es kann alles was GC auch kann (ABA-Problem kann man via std::shared_ptr lösen). Wieso also GC?

geht mit dem dämlichen "alles ist ein Pointer" weiter

Es gibt Value-Typen. Zwar nur primitive, ab Java 9/10 aber auch zusammengesetzte. Sehe auch nicht inwiefern mich Referenztypen bei der Arbeit stören sollten.

Ich weiß nicht genau, wie Java das macht, aber man hat Cachemisses, Overhead durch Derefernzierung, auch wenn es unnötig ist. Minecraft bspw. hat an Performance eingebüßt, als Positionen durch eine Klasse represäntiert werden anstatt wie vorher drei Ints zu übergeben. Die zusammengesetzten würden das vielleicht lösen, aber trotzdem. Das ist nur um das "alles ist virtual by Default" zu unterstützen um problemlos alle Typen gegen andere austauschen zu können. C++ Lösung mit Templates ist da imo eleganter.

und endet mit mangelnden guten Möglichkeiten zur generischen Programmierung.

Beispiel, bei dem es limitieren oder stören würde? Mir nicht bekannt.

Ein wesentlicher Bestandteil meines Codes manipuliert Typelisten und betreibt Templatemetaprogramming. Die ganze STL ist auf Templates ausgelegt, anstatt dieses Interfacegedöns. Templates sind wesentlich besser, insbesondere mit Concepts, da sie beschreiben, was ein Typ haben muss, ohne das der Typ das explicit implementieren muss. Das ist nützlich, wenn der Typ gar nichts von dem Interface/Concept weiß.