Problem mit Aufruf von templates in einer Funktion

Zeus

Rafzahn schrieb:

Nicht zu vergessen, daß in Java die Destruktoren wegfallen. Hab noch nicht so viel Erfahrung mit cpp aber ich denk mal da kann man einen richtig dicken Bock schießen. Heißt keine Memoryleaks dank Garbage-Collection. Man muß nicht eine Zeile Code fürs aufräumen aufbringen. Als würde Mama für einen aufräumen während man selbst die Füße hoch legt Natürlich auf Kosten der Geschwindigkeit. Aber ich glaube das kann man hinnehmen.

Ein Taxi ist auch besser als ein eigenes Auto

Rafzahn

Zeus schrieb:

Rafzahn schrieb:

Nicht zu vergessen, daß in Java die Destruktoren wegfallen. Hab noch nicht so viel Erfahrung mit cpp aber ich denk mal da kann man einen richtig dicken Bock schießen. Heißt keine Memoryleaks dank Garbage-Collection. Man muß nicht eine Zeile Code fürs aufräumen aufbringen. Als würde Mama für einen aufräumen während man selbst die Füße hoch legt Natürlich auf Kosten der Geschwindigkeit. Aber ich glaube das kann man hinnehmen.

Ein Taxi ist auch besser als ein eigenes Auto

Da will ich nicht widersprechen und das Taxi kostet in dem Fall nichtmal was

XSpille

Rafzahn schrieb:

Man muß nicht eine Zeile Code fürs aufräumen aufbringen.

Ich liebe diese Einstellung

Java macht ja allea selbstständig

Lass du mal schön wenn du z. B. irgendetwas schließt dein Object in
in irgendwelchen Listenern hängen...

Es räumt sich ja alles von alleine auf
Das Objekt wird ja (eigentlich) nicht mehr gebraucht

Ich will nicht wissen wie viele Java-N00bs sowas einfach nicht berücksichtigen.
Ein C++-Progger kennt solche Gefahren (spätestens nach leidigen Speicherzugriffsfehlern).

EDIT: Mich würd ja mal das Verhältnis zwischen Gebrauch von addListener und
removeListener eines (durchschnittlichen) Java-Programmierers interessieren

volkard

Rafzahn schrieb:

Nicht zu vergessen, daß in Java die Destruktoren wegfallen.

Aber in Java wird nur der Speicher automatisch verwaltet. Alle anderen Ressourcen, die stark beschränkt sind wie Datenbankverbindungen, oder kollidieren können wie offene Schreibdateien muß man per Hand verwalten.

Hab noch nicht so viel Erfahrung mit cpp aber ich denk mal da kann man einen richtig dicken Bock schießen.

In C++ geschehen eigentlich auch keine Speicherlöcher. Ok, man muß ein wenig üben dafür.

Heißt keine Memoryleaks dank Garbage-Collection. Man muß nicht eine Zeile Code fürs aufräumen aufbringen.

Fürs Aufräumen des Speichers.

Als würde Mama für einen aufräumen während man selbst die Füße hoch legt Natürlich auf Kosten der Geschwindigkeit. Aber ich glaube das kann man hinnehmen.

Ja, die soll mal egal sein.

Aber diese Art der Sicherheit halte ich für ein Anfängerproblem.

Ist man Profi, gilt wohl: Beide Sprachen sind sicher. In C++ sichert man per RAII http://de.wikipedia.org/wiki/Ressourcenbelegung_ist_Initialisierung und in Java? Ich weiß nicht genau. So? http://accu.org/index.php/journals/236
Hmm, das fände ich recht lästig.

XSpille

volkard schrieb:

drakon schrieb:

Michael E. schrieb:

Rafzahn schrieb:

Was die Objektorientierung angeht ist Java um einiges komfortabler.

Warum?

Weil es eingeschränkter ist.

Wenn man nicht autofahren kann, ist das Fahrrad komfortabler.

Genauso ist es...
Warum hat Java keine Mehrfachvererbung?
Wenn man mit etwas nicht umgehen kann, braucht man es ja nicht zu verwenden!!!

unskilled

Plus die allseits gelobte Plattformunabhänigkeit

Unabhängig würd ichs nicht nennen - immerhin muss erst mal ne vm für das system bestehen und auch noch installiert werden.

Da ist C++ in meinen Augen weitaus Unabhängiger - ist wohl aber auch bedingt durch die wesentlich kleinere Standard-Bibliothek.
Wenn man dann Allerdings boost noch mit dazurechnet, hat c++ vrmtl nciht mehr (abgesehen von der weiterhin fehlenden GUI) das nachsehen.

In C++ muss man auch keine Einzige Zeile fürs Aufräumen schreiben, wenn man sich das nicht zutraut. Wenn man shared_ptr nimmt hat man Quasi das gleiche - auch "nur" auf Kosten der Performance.

Ich kenn mich auch nicht gut mit Java aus, aber der einzige Vorteil, der mir einfällt, sind die Checked Exceptions oder wie sich das schimpft(Java guckt, welche Exceptions geschmissen werden können, man aber nirgendwo auffängt), was aber leider fast jeden Java-Deppen dazu bringt, einen großen try/catch(...)-block um das ganze zu machen und es dann einfach gut sein lässt.

bb

Zeus

unskilled schrieb:

Ich kenn mich auch nicht gut mit Java aus, aber der einzige Vorteil, der mir einfällt, sind die Checked Exceptions oder wie sich das schimpft(Java guckt, welche Exceptions geschmissen werden können, man aber nirgendwo auffängt), was aber leider fast jeden Java-Deppen dazu bringt, einen großen try/catch(...)-block um das ganze zu machen und es dann einfach gut sein lässt.

bb

Dann hast du sie wohl noch nicht verstanden, mann muss Sie fangen oder in der Methodensiganture vermerken, dass sie geworfen wird.

XSpille

unskilled schrieb:

In C++ muss man auch keine Einzige Zeile fürs Aufräumen schreiben, wenn man sich das nicht zutraut. Wenn man shared_ptr nimmt hat man Quasi das gleiche - auch "nur" auf Kosten der Performance.

Naja... Kreise vernachlässigen wir mal

unskilled schrieb:

Ich kenn mich auch nicht gut mit Java aus, aber der einzige Vorteil, der mir einfällt, sind die Checked Exceptions oder wie sich das schimpft(Java guckt, welche Exceptions geschmissen werden können, man aber nirgendwo auffängt), was aber leider fast jeden Java-Deppen dazu bringt, einen großen try/catch(...)-block um das ganze zu machen und es dann einfach gut sein lässt.

Macht man das etwa nicht so?

Ich erinner mich an einen Kommentar in im Java-Code:

catch(WhichExcpetionEver e){
// Oh... I don't know what to do now...
}

Zeus

Dann lieber:

catch(Exception ex) {
   // There is an Exeception... Bye!
}

pfui wir sind im C++ Forum nicht im Java Forum :p

XSpille

Jetzt hätte ich doch fast meine Lieblings-Java-Gewohnheit vergessen.

class MyObject implements ObjectInterface{
	public void doSomething(){
		throw new UnsupportedOperationException();
	}
}

Ja nee...
Is klar...

Schön dass Java nur dynamische Vererbung (oder wie sich das auch schimpft) unterstützt

Bei Templates hat man so einen Mist nicht nötig.
Schnittstellen vorgaukeln, die nicht vorhanden sind...

volkard

unskilled schrieb:

aber der einzige Vorteil, der mir einfällt, sind die Checked Exceptions

Sie werden kontrovers diskutiert.
http://www.mindview.net/Etc/Discussions/CheckedExceptions

unskilled

Dann hast du sie wohl noch nicht verstanden, mann muss Sie fangen oder in der Methodensiganture vermerken, dass sie geworfen wird.

ahja - genau das hab ich doch geschrieben (ok, in die fkt-signatur aufnehmen hab ich weggelassen, weil die main-fkt imho keine werfen darf und man somit dort dann spätestens alles auffangen muss)

volkard schrieb:

Sie werden kontrovers diskutiert.

Wieder was dazu gelernt - danke
mal gucken, ob ich noch genug lange weile habe, das komplett durchzulesen^^

bb

Nexus

@Rafzahn: Du legst Halbwissen an den Tag, das leider sehr verbreitet ist und auch dazu führt, dass C++ in gewissen Kreisen ein relativ schlechtes Image hat. Da gibt es einiges klarzustellen, deshalb mag meine Antwort vielleicht etwas einseitig erscheinen.

Rafzahn schrieb:

Nicht zu vergessen, daß in Java die Destruktoren wegfallen.

Was aber nicht nur Vorteil ist. In Java hat man das Problem, dass Ressourcen (ausser Speicher) explizit freigegeben werden müssen (z.B. close() bei Dateien aufrufen). In C++ kann dieses Problem mit RAII umgangen werden. Java hat zwar Finalizers, die aber begrenzt für automatisches Aufräumen tauglich sind, weil sie vielleicht zu einer unbestimmten Zeit aufgerufen werden. Insofern kannst du in Java relativ leicht Resource Leaks erzeugen – das einzige, was du dagegen tun kannst, ist manuelle Freigabe.

Rafzahn schrieb:

Heißt keine Memoryleaks dank Garbage-Collection.

Die hat man in C++ nicht, wenn man richtig programmiert. Und das geht sehr gut, ohne den Code voller expliziter delete s zu haben. RAII und Smart-Pointer wären entsprechende Stichwörter. Dass man sich in C++ mit manueller Speicherverwaltung herumschlagen muss, ist ein weit verbreiteter Irrtum. In C vielleicht, aber auf C++ bezogen ist diese Aussage einfach falsch.

Rafzahn schrieb:

Man muß nicht eine Zeile Code fürs aufräumen aufbringen.

In idiomatischem C++ auch nicht, siehe oben.

unskilled schrieb:

In C++ muss man auch keine Einzige Zeile fürs Aufräumen schreiben, wenn man sich das nicht zutraut. Wenn man shared_ptr nimmt hat man Quasi das gleiche - auch "nur" auf Kosten der Performance.

Und dann nimmt man noch scoped_ptr für lokale Anforderungen und hat automatische Freigabe sogar ohne Performancekosten.

Rafzahn schrieb:

Plus die allseits gelobte Plattformunabhänigkeit.

C++ ist ebenfalls plattformunabhängig, jedoch muss der Code neu kompiliert werden. Allerdings ist er dann auch gerade für die jeweilige Plattform optimiert.

Das Ganze soll nicht heissen, dass Java keine Vorteile gegenüber C++ hat. Aber du hast ein paar Beispiele gewählt, die sich gut widerlegen lassen (und in denen C++ teilweise sogar fortschrittlicher ist).

Übrigens, mit OOP haben die aufgezählten Punkte rein gar nichts zu tun (weil du deine Aussage "Objektorientierung ist in Java konfortabler" mit ihnen begründet hast). Davon abgesehen sollte dir bewusst sein, dass Code nicht automatisch besser ist, je mehr OOP (im Java-Sinn) er verwendet. Gewisse Zusammenhänge kann man schlecht damit ausdrücken. Denke z.B. an die nachträglich eingeführten Generics oder die immer noch fehlenden freien Funktionen und Operatorüberladung, welche sehr wohl ihren Beitrag zur objektorientierten Programmierung leisten könnten. Meist ist es zudem die Kombination unterschiedlicher Paradigmen, die dem Programmierer mächtige Werkzeuge verleiht.

Michael E.

Rafzahn schrieb:

Nicht zu vergessen, daß in Java die Destruktoren wegfallen. Hab noch nicht so viel Erfahrung mit cpp aber ich denk mal da kann man einen richtig dicken Bock schießen. Heißt keine Memoryleaks dank Garbage-Collection. Man muß nicht eine Zeile Code fürs aufräumen aufbringen. Als würde Mama für einen aufräumen während man selbst die Füße hoch legt Natürlich auf Kosten der Geschwindigkeit. Aber ich glaube das kann man hinnehmen.

Plus die allseits gelobte Plattformunabhänigkeit.

Ich will nochmal unterstreichen, was Nexus gesagt hat. Man kann jeden einzelnen Punkt von dir anfechten und diskutieren, aber vor allem haben sie nichts mit deiner ursprünglichen Aussage über OOP zu tun.