Java: Immer noch keine echten Templates?



  • Ich glaube die Diskussion über Destruktoren sollten wir bleiben lassen...

    @gomberl:
    Ich verstehe nur immer noch nicht, warum ein
    a.add(b); bzw.
    x=Foo.add(a,b);
    besser ist als
    a+=b; bzw.
    x=a+b;

    Ich weiss bei einem add() genausowenig über die Aktion wie bei einem operator+



  • Das Destruktor-Konzept würde für Java einfach keinen Sinn machen, weil man dann vorschreiben müsste, wann ein Destruktor aufgerufen wird.
    Wenn sich ein Programmierer dann acuh sowas verlässt, kümmert er sich indirekt schon wieder um die Speicherverwaltung und die soll ja in Java automatisch stattfinden.
    Man soll sich um nichts kümmern müssen, das ist einfach eine andere Philosophie. Man überlässt die Speicherverwaltung komplett der VM, die das sowieso viel besser macht, als man es von Hand coden würde.
    Daraus ergeben sich auch ein paar Nachteile, da hat Shade nicht ganz unrecht. Aber in C++ ist es IMO trotzdem leichter, ganz allgemein ein paar Sachen zu vergessen, in Java muss man sich nicht um so viel kümmern.

    Operatoren: Ich vermisse Operator-Überladung in Java auch. Es ist theoretisch nicht notwändig und auch gerade aufgrund der Referenz-Semantik ein bisschen problematisch bei == und !=. Da finde ich den Graben zwischen == und equals() schon gut, den sollte man auch nicht ändern können.
    Aber ein + und - überladen, wär schon was feines manchmal.



  • gomberl schrieb:

    Alles liegt im speicher.
    Datenbankverbindungen auch.

    Aber der Unterschied zwischen Speicher und DB Verbindung ist dir klar?
    Das eine ist ne kritische Resource (DB) das andere eine Resource die nahezu unendlich vorhanden ist.

    Mir geht es um das triggering des destructors.
    und der ist AFAIK getriggered wenn der scope verlassen wird oder wenn ich ein delete mache.
    das heisst mache ich kein delete auf etwas das am heap erzeugt wurde so habe ich ein memory leak und eine nicht schliessende verbindung. punktum. und das ist moeglich in C++, ganz einfach. WIE ich jetzt gegen sowas vorbeugen kann war nicht gegenstand der diskussion.

    Doch.
    C++ bringt nunmal wenig in die Sprache integrierte 'Features' mit.
    Nur aus diesen Features lassen sich eben Sachen basteln: wie zB das RAII Idiom.
    Und deshalb gibt es in einem guten C++ Programm keine Resource Leaks - weil eben alles über Destruktoren zerstört wird (auch dynamisch allokierter Speicher).

    Das man auch die Möglichkeit hat, dieses Feature nicht zu nutzen ist doch kein Nachteil der Sprache.



  • shade: in dem fall weisst du genausoviel da hast du recht
    die (vom mir bereits erfahrene problematik) liegt darin das das einlesen laenger dauert - bzw man fehler leichter uebersieht.IMHO. IME (in my experience)

    ich finde einfach das methodenaufrufe besser lesbar sind und man sich auch mehr darunter vorstellen kann (speziell wenn die namen gut gewaehlt sind)

    bei add und + ist kein unterschied (das sagt beides nicht viel wenn die objekte nicht gerade irgendwelche mathematischen oder graphischen dinge sind)

    ich persoenlich habe das operator ueberladen sehr gerne genutzt bis zu dieser erfahrung.
    seither benutze ich es nicht mehr. methodenaufrufe sind genausogut

    meine meinung

    gomberl



  • a = (b + c) * (d + e);
    
    a.assign(b.add(c).mul(d.add(e));
    

    LOL



  • Aber der Unterschied zwischen Speicher und DB Verbindung ist dir klar?
    Das eine ist ne kritische Resource (DB) das andere eine Resource die nahezu unendlich vorhanden ist.

    das ist mir schon klar.
    Ich weiss auch auf was du hinaus willst, aber das aendert meine ansicht nicht das ein .close() benutzt werden sollte.
    eine kritische resource gehoert dezidiert geoeffnet und dezidiert geschlossen. IMHO.

    C++ bringt nunmal wenig in die Sprache integrierte 'Features' mit.
    Nur aus diesen Features lassen sich eben Sachen basteln: wie zB das RAII Idiom.
    Und deshalb gibt es in einem guten C++ Programm keine Resource Leaks - weil eben alles über Destruktoren zerstört wird (auch dynamisch allokierter Speicher).

    Das man auch die Möglichkeit hat, dieses Feature nicht zu nutzen ist doch kein Nachteil der Sprache.

    ueber RAII hab ich 2 mal gelesen in meinem leben, dementsprechend kann ich nix dazu sagen. 😉
    ich will hier auch C++ nicht schlecht machen.
    Ich weiss auch das es in einem guten C++ prorgramm keine resource leaks gibt, habe auch schon so etwas geschrieben, man glaubt es kaum.

    Frage: wieviele "gute" C++ programme kennst du. Ich sage gerade 20 prozent sind gut geschrieben, weil eben sehr viel zeitdruck auf den personen lastet und man nicht alles machen kann. man hat auch organisatorische aufgaben und dann kommen noch altlasten hinzu.
    Fuer alles weiter koennen wir einen thread ueber software quality management aufmachen. Auch verweise ich auf den Chaos Report. Jedes jahre wieder eine freude zu sehen wieviele IT projekte in die hose gehen.

    Das man auch die Möglichkeit hat, dieses Feature nicht zu nutzen ist doch kein Nachteil der Sprache.

    das hab ich auch nie behauptet. ich habe nur behauptet das "C++ nicht die eierlegende wollmilchsau ist" -> "In C++ unmoeglich"

    In C++ ist viel mehr moeglich. auf der positiven wie auch auf der negativen seite. Und das ist auch gut so.



  • @me_:

    und jetzt erklaerst du mir was

    a = (b + c) * (d + e);

    bedeutet wenn

    a .. Klasse_Flugzeug
    b .. Klasse_Auto
    c .. Klasse_Sprit
    d .. Klasse_WasWeissIchNoch
    e .. Klasse_KeineAhnung

    ist

    ach ja - dasselbe problem hast du in java auch
    aber dort wuerdest du wohl fuer b + c sagen b.betanke(c)



  • gomberl schrieb:

    @me_:

    und jetzt erklaerst du mir was

    a = (b + c) * (d + e);

    bedeutet wenn

    a .. Klasse_Flugzeug
    b .. Klasse_Auto
    c .. Klasse_Sprit
    d .. Klasse_WasWeissIchNoch
    e .. Klasse_KeineAhnung

    ist

    ach ja - dasselbe problem hast du in java auch
    aber dort wuerdest du wohl fuer b + c sagen b.betanke(c)

    Wenn du Operatoren dort einsetzt wo sie niemand verwenden würde ist das deine Sache,
    Operatorenüberladung ist dazu da dir das Leben leichter zu machen nicht schwerer.
    Niemand würd die aktion auftanken über einen Operator lösen, sondern über eine
    Methode.



  • aber dort wuerdest du wohl fuer b + c sagen b.betanke(c)

    Nie und nimmer! Man kann antürlich auch schwachsinnige Seiteneffekte implementieren aber wenn man von einem halbwegs normalen Design ausgeht, dann wird 'b + c' 'b' nicht verändern.

    Das man auch die Möglichkeit hat, dieses Feature nicht zu nutzen ist doch kein Nachteil der Sprache.

    das hab ich auch nie behauptet. ich habe nur behauptet das "C++ nicht die eierlegende wollmilchsau ist" -> "In C++ unmoeglich"

    Du hast den Zusammenhang nicht ganz verstanden. Wenn du die entsprechenden Features nicht nutzt ist es natürlich möglich. Solltest du aber die dir angebotenen Features nutzen, so ist es unmöglich!


  • Mod

    SirLant schrieb:

    Wenn du Operatoren dort einsetzt wo sie niemand verwenden würde ist das deine Sache,
    Operatorenüberladung ist dazu da dir das Leben leichter zu machen nicht schwerer.
    Niemand würd die aktion auftanken über einen Operator lösen, sondern über eine
    Methode.

    AFAIK hat man sich dazu entschlossen, Operatorenüberladung nicht in Java zu realisieren, weil man gesehen hat, dass es zu oft mißbraucht wird. Der Code wird dadurch also oft schlechter lesbar, wartbar,...!



  • das sagst du und ich glaube dir das du das auch so machen wuerdest.

    nur bist du leider nicht jedermann der in einem programmierteam sitzt.

    ich habe in verschiedenen teams gearbeitet und da kommt immer viel mist heraus



  • Jungs ... ihr geht OT. Die Überschrift lautet "Java: Immer noch keine echten Templates?"



  • AFAIK hat man sich dazu entschlossen, Operatorenüberladung nicht in Java zu realisieren, weil man gesehen hat, dass es zu oft mißbraucht wird. Der Code wird dadurch also oft schlechter lesbar, wartbar,...!

    Obwohl ich noch nie was offizielles von den Java-Designern dazu gehört hab, glaub ich eher, daß das nicht eingebaut wurde um keine Verwirrung zwischen Objekt-Referenz und referenziertem Objekt zu verursachen. Die Operatoren op= und op== haben nun mal ne Bedeutung für die Referenz selber und wenn man jetzt den op= zB überladen könnte, wär das wohl sehr verwirrend, ihm plötzlich die Bedeutung kopiere Objekt, statt kopiere Referenz zu verpassen.
    Darum müsste man diese beiden ops vom Überladen wohl ausschließen. Wenn man op= jetzt aber ausschließt, wär es irgendwie merkwürdig += , -=, *= usw. überladbar zu haben. Also sollte das dann möglich sein?

    Irgendwie würde man sich daher für meinen Geschmack sehr viele Unstimmigkeiten einhandeln, darum hat man das Überalden wohl weggelassen..



  • @CengizS: Oh, natürlich.
    ...
    Ja, Java hat immernoch keine echten Templates und wird meiner Meinung nach auch nie welche bekommen. Fertig.


  • Mod

    1. Wodurch sind "echte Templates" definiert? Ist hier C++ das Maß aller Dinge? Warum eigentlich?

    2. In Java wurden nicht "Templates", sondern "Generics" realisiert. Man hat wohl mit Absicht einen anderen Begriff gewählt, weil es hier keine Äquivalenz gibt. Es gibt nur Überschneidungen bezüglich des Nutzens.



  • 1. Wodurch sind "echte Templates" definiert? Ist hier C++ das Maß aller Dinge? Warum eigentlich?

    Gut, nehmen wir D als Bezug :p

    C++ hat den Begriff Template numal geprägt. Deswegen sind "echte Templates" nunmal dass, was Templates in C++ sind.



  • Gomberl du kannst aber nicht etwas schlecht heißen nur weil es manche Missbrauchen.
    Ich kann in Java ja auch i.add(5) schreiben und in Wahrheit zieht es 5 ab, mal als
    ganz extremes Beispsiel.
    Und in nem Programmiererteam, sollte man sich auf gewisse Dinge einigen, z.B. dass
    man Operatoren nicht für alles einsetzt, sondern nur dort wo es sinn hat.

    Und das was oben angesprochen wurde, wegen der Datenbankverbindung, wenn ich das
    in den Destruktor schreibe, dann habe ich eine Garantie, dass die Verbindung
    beendet wird, wenn das Objekt den Scope verlässt. Es sei denn ich arbeite mit
    heapbasierten Objekten, dort kann ich jedoch Smartpointer verwenden und ich habe
    wieder die Garantie, dass das Objekt gelöscht wird, wenn der Smartpointer den
    Scope verlässt.



  • @Helium: Du scheinst ein echtes Problem mit Java und deiner Umgebung zu haben. Wenn es wirklich so schwer für dich ist wirklich anständig eine Diskussion zu führen dann lass es bitte und störe die anderen nicht dabei. Fertig. PUNKT... du weisst was ich meine.



  • CengizS schrieb:

    Jungs ... ihr geht OT. Die Überschrift lautet "Java: Immer noch keine echten Templates?"

    Lass mal. Der Topic war eh nur da, um einen Flamewar anzufangen.



  • obwohl so richtig ist da kein flamewar draus geworden


Anmelden zum Antworten