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



  • 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


  • Mod

    @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. 🙄



  • 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.


  • Mod

    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.



  • 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



  • Nathan schrieb:

    1. Falsche Pointer Arithmetik.
    2. 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 🙂



  • 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:

    1. Falsche Pointer Arithmetik.
    2. 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ß.



  • Nathan schrieb:

    hustbaer schrieb:

    Nathan schrieb:

    1. Falsche Pointer Arithmetik.
    2. 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.

    Da kann ich mir jetzt auch net mehr vorstellen als vor dieser Zusatzinfo 😉


Anmelden zum Antworten