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

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

hustbaer

Nathan schrieb:

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.

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