Ist es sinnvoll heute noch C++ anzufangen?

[*john 0]

+fricky schrieb:

welcher destruktor? sowas gibts nicht in Java.

So etwas gibt es Java schon, nennt sich bloß finalize() und wird halt probabilistisch aufgerufen, womit die Methode nutzlos ist. Irgend wie ist das auch so eine Designleiche, die irgend wann mal in der Frühphase des Sprachdesign reingeruscht ist und nun überflüssig ist.

[audacia]

Metalag00 schrieb:

Das würde ich so nicht sagen. Mit dem neuen C++0x Standard bzw. Boost wird C++ in vielen Bereichen ordentlich aufgepeppt, so dass es locker mit Java, C# usw. mithalten kann.

Wenige der Neuerungen im neuen Standard zielen auf Konkurrenzfähigkeit mit Java und C# ab.

~john schrieb:

finalize() [...] wird halt probabilistisch aufgerufen, womit die Methode nutzlos ist. Irgend wie ist das auch so eine Designleiche, die irgend wann mal in der Frühphase des Sprachdesign reingeruscht ist und nun überflüssig ist.

Das sehe ich ebenso - aber genau deshalb ist die Gleichsetzung von Destruktoren und finalize() Unfug. Den üblichen Aufgaben eines Destruktors in C++ - der Freigabe von Ressourcen, davon eine der Speicher ist, dessen Verwaltung in GC-Umgebungen eben nicht mehr dem Programmierer aufgebürdet ist - kommt die dispose()-Methode am nächsten.

(Es sei natürlich denn, man stößt auf eine der Lücken in der Abstraktion - dann darf man sich mit manueller Referenzzählung oder mit Weak und Phantom References herumschlagen :p).

[+fricky]

Wikinger75 schrieb:

bei C++ wird der stan**** per ISO-Norm vorgeschrieben und ich weiß echt nit warum ihr da einen nachteil drin sieht...

vieles ist darin garnicht erwähnt, den compiler-herstellern überlassen, oder endet in undefiniertem verhalten. nimm nur mal so grundlegende dinge wie einfachsten datentypen. ein popeliger 'int' kann hier 16 bit breits sein, wo anders isser 32 bit breit und wieder wo anders 73 bits, usw. wer dass nicht weiss und annimmt, ints wären immer 32 bits breit, kann schon mal pech haben.

[+fricky]

~john schrieb:

+fricky schrieb:

welcher destruktor? sowas gibts nicht in Java.

So etwas gibt es Java schon, nennt sich bloß finalize() und wird halt probabilistisch aufgerufen, womit die Methode nutzlos ist.

sie wird immer aufgerufen, wenn der GC das objekt löscht (ausser bei JVM-implementationen ohne GC), nicht mit 'ner wahrscheinlichkeit von 70...80% oder so, sondern immer. du kannst nur den zeitpunkt nicht vorhersehen, d.h. solange es nicht passiert, ist das objekt noch am leben. deswegen sollte man 'finalize()' auch nicht als destruktor missbrauchen. aber in Java so wie in C++ zu programmieren, ist generell eine schlechte idee.

[audacia]

+fricky schrieb:

sie wird immer aufgerufen, wenn der GC das objekt löscht (ausser bei JVM-implementationen ohne GC), nicht mit 'ner wahrscheinlichkeit von 70...80% oder so, sondern immer.

Es sei natürlich denn, das System verfügt über hinreichend viel Speicher, daß der GC gar nicht in Aktion tritt, sondern sämtlicher Speicher bei der Terminierung der Anwendung freigegeben wird - denn gerade in dieser Situation ist Speicherverwaltung mit GC deutlich effizienter als die manuelle Variante. Da dieser Fall nicht ganz ungewöhnlich ist, dürfte das Phänomen keineswegs auf "JVM-Implementationen ohne GC" beschränkt sein.

[+fricky]

audacia schrieb:

+fricky schrieb:

sie wird immer aufgerufen, wenn der GC das objekt löscht (ausser bei JVM-implementationen ohne GC), nicht mit 'ner wahrscheinlichkeit von 70...80% oder so, sondern immer.

Es sei natürlich denn, das System verfügt über hinreichend viel Speicher, daß der GC gar nicht in Aktion tritt, sondern sämtlicher Speicher bei der Terminierung der Anwendung freigegeben wird - denn gerade in dieser Situation ist Speicherverwaltung mit GC deutlich effizienter als die manuelle Variante. Da dieser Fall nicht ganz ungewöhnlich ist, dürfte das Phänomen keineswegs auf "JVM-Implementationen ohne GC" beschränkt sein.

ok, in dem fall werden die finalize()'s kurz vor'm ende des programms aufgerufen, aber sie kommen dran, wenn auch in dem fall der nutzen eher zweifelhaft ist. aber ganz sinnlos sind finalizer nicht, wie ~john uns weismachen will. ich könnte mir z.b. vorstellen, wenn man 'ne rückmeldung braucht, dass ein objekt automatisch aus einer WeakHashmap rausgeflogen ist, wäre finalize() der richtige punkt, um das mitzukriegen.

[Leprechaun]

Lennard_ schrieb:

Die Frage betrifft mich selbst nicht, aber ich werde immer wieder von Leuten gefragt, wie man am besten Programmieren lernen und irgendwie kennen die meisten Leute C++ und denken es sei die "beste" Programmiersprache. Ich weiss nicht so recht, was ich den Leuten da raten soll.

Es gibt keine "beste" Programmiersprache. Frag sie, was sie programmieren möchten und nenne dann die Sprache, die auf dem Gebiet am häufigsten Verwendung findet. Sag ihnen auch, wenn sie unbedingt C++ lernen wollen, daß sie ein harter, steiniger Weg erwartet.

[audacia]

+fricky schrieb:

ok, in dem fall werden die finalize()'s kurz vor'm ende des programms aufgerufen, aber sie kommen dran

Ist das wirklich so? Müssen Finalizer aufgerufen werden? Wenn ich mich recht erinnere, darf die JVM das nach Belieben auch unterlassen.

[Zeus]

http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19147 schrieb:

... Java virtual machine will invoke the finalizer of that object

[täschder]

public class Test {

	static class Foo{
		protected void finalize() {
			System.out.println("Finalisiert"); 
		}

		public void bar() {
			System.out.println("Bar");

		}
	}

	public static void main(String[] args) {
		Foo foo = new Foo();
		foo.bar();
	}	
}

Gibt bei mir immer nur "Bar" aus.

[audacia]

Zeus schrieb:

http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19147 schrieb:

... Java virtual machine will invoke the finalizer of that object

Falsch zitiert. Korrekt ist es so:
[

Before the storage for an object is reclaimed by the garbage collector, the Java virtual machine will invoke the finalizer of that object.

](http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19147)Das klärt nicht, ob der GC überhaupt laufen muß. Und in dieser Frage kenne ich andere Statements:

[

http://java.sun.com/developer/TechTips/2000/tt0124.html schrieb:

Garbage collection might not ever run. If garbage collection runs at all, and an object is no longer referenced, then that object's finalize will run.

](http://java.sun.com/developer/TechTips/2000/tt0124.html)

[Zeus]

Also war's ne rhetorische Frage

[tntnet]

Metalag00 schrieb:

Das würde ich so nicht sagen. Mit dem neuen C++0x Standard bzw. Boost wird C++ in vielen Bereichen ordentlich aufgepeppt, so dass es locker mit Java, C# usw. mithalten kann. Und viele Dinge, die C++ gerne als Nachteil ausgelegt werden, haben auch eine Kehrseite. Sprachen wie Java oder C# bieten nicht die gleiche Flexibilität wie C++ an. Einiges ist in C++ vielleicht nicht out-of-the-box enthalten, aber man kann alles nachrüsten durch Bibliotheken, wenn man es braucht, man MUSS es aber nicht. Das ist ein großer Vorteil von C++.

Du sprichst eins der Dinge an, was ich an C++ so liebe. Es ist einfach flexibel und für alles geeignet. Die Grenzen werden nicht von irgendwelchen Abstraktionsschichten gegeben sondern von der verfügbaren Technik. Will ich ein ausführbares Programm ohne Runtime erzeugen, dann ist das mit C++ möglich (ja ich kann auch auf die Standardlibrary verzichten, wenn es notwendig ist). Es gibt praktisch nichts, was in C++ nicht möglich ist, was technisch machbar ist. Und dennoch habe ich eine komfortable Sprache, mit der ich einfach auch große Lösungen realisieren kann.

Das soll nicht gegen Java sein. Java hat auch seine Daseinsberechtigung (wäre schön, so etwas mal von einem Java-Anhänger über C++ zu hören). Wie erwähnt gibt es ja zahlreiche Anwendungen, die in Java geschrieben wurden. Vielfalt ist gut. Und für jeden Anwendungszweck kann man die Sprache wählen, die am besten passt.

Ich persönlich finde C++ einfach für alles geeignet und sehe daher keinen Grund irgendetwas anderes zu verwenden, aber das kann jeder für sich (bzw. der Vorgesetzte ) entscheiden.

[+fricky]

Metalag00 schrieb:

Lennard_ schrieb:

In den low-level Anwendungsgebieten wird beinahe ausschließlich auf C gesetzt und nicht auf C++. Der Linux Kernel ist ja komplett in C geschrieben, der Großteil des Windows Kernels ebenfalls und die allermeisten Treiber werden auch in C programmiert. Es scheint mir auch so, daß viele Systemprogrammierer eine Abneigung gegen C++ haben und die Sprache keinen sinnvollen Mehrwert auf diesem Gebiet bringt.

Das stimmt so nicht. Man findet zwar noch häufig C in diesem Bereich, aber auch hier zeichnet sich eindeutig ein Trend in Richtung C++ ab. In schätzungsweise 10 Jahren wird all das, was du auflistet, auch in C++ programmiert werden.

*räusper*, c++ gibt's seit ~30 jahren. wieso sollte c++ plötzlich, nach 40 jahren, C verdrängen? das hätte doch schon viel früher passieren müssen, wenn c++ das potential dazu hätte.

Metalag00 schrieb:

Das Problem ist, dass es gerade in diesem Bereich viele Entwickler gibt, die nicht bereit sind neue Dinge zu lernen und deshalb an ihrem veralteten C festhalten. Mit einer neuen Generation von Entwicklern wird sich das ändern.

das 'problem' ist in dem bereich ist, dass entwickler ständig neues lernen müssen. da bleibt überhaupt nicht die zeit, sich mit esoterischen sprachen auseinanderzusetzen und man verspürt auch kaum lust, projekte unter einsatz von C++ gegen die wand zu fahren. C ist alt aber nicht veraltet. und 'alt' heisst nicht automatisch 'schlecht'.

[explosion]

mikey schrieb:

Es ist sinnvoll, C++ "anzufangen", wenn es für Deine Zwecke geeignet ist. Der Zweck heiligt die Mittel heißt es ja so schön.

der einzig sinnvolle beitrag in diesem thread

[*john 0]

audacia schrieb:

Das sehe ich ebenso - aber genau deshalb ist die Gleichsetzung von Destruktoren und finalize() Unfug.

Da dispose im Gegensatz zu finalize explizit aufzurufen ist, wäre finalize das Gegestück zu einem Destruktor, und dispose zu einer beliebigen Cleanup Funktion, wenn es da nicht diesen Designfehler gäbe. Effektiv fehlt Java ein echter Destruktor.

audacia schrieb:

Den üblichen Aufgaben eines Destruktors in C++ - der Freigabe von Ressourcen, davon eine der Speicher ist, dessen Verwaltung in GC-Umgebungen eben nicht mehr dem Programmierer aufgebürdet ist - kommt die dispose()-Methode am nächsten.

Das ist eben nicht der Fall! Mangels passendem deterministischen Destruktor in Java muß man anders Programme formulieren. RAII geht nicht und man muß immer von Hand finally Blöcke einführen, in der dann wieder explizit die dispose Methoden der Objekte aufgerufen werden müssen. Das ist ein anderer Stil Programme zu formulieren, mir gefällt er nicht.

[audacia]

~john schrieb:

Da dispose im Gegensatz zu finalize explizit aufzurufen ist, wäre finalize das Gegestück zu einem Destruktor, und dispose zu einer beliebigen Cleanup Funktion, wenn es da nicht diesen Designfehler gäbe.

Nein. Die Intention eines Destruktors ähnelt in Java fast in allen Fällen der Intention von dispose(), nicht der von finalize(). finalize() deckt ein paar Randprobleme ab (die man offenbar mit Phantom References auberer lösen kann); wer finalize() als Destruktor mißbraucht, macht einen Designfehler.

~john schrieb:

audacia schrieb:

Den üblichen Aufgaben eines Destruktors in C++ - der Freigabe von Ressourcen, davon eine der Speicher ist, dessen Verwaltung in GC-Umgebungen eben nicht mehr dem Programmierer aufgebürdet ist - kommt die dispose()-Methode am nächsten.

Das ist eben nicht der Fall! Mangels passendem deterministischen Destruktor in Java muß man anders Programme formulieren. RAII geht nicht und man muß immer von Hand finally Blöcke einführen, in der dann wieder explizit die dispose Methoden der Objekte aufgerufen werden müssen.

Ich verstehe dich nicht.

Mein Statement: Dem üblichen Zweck von Destruktoren kommt in Java dispose() am nächsten.
Deine Antwort: Nein, eben nicht, denn in Java gebe es keine Destruktoren, und man müsse stattdessen dispose() benutzen.

Was willst du mir sagen?

[+fricky]

~john schrieb:

Da dispose im Gegensatz zu finalize explizit aufzurufen ist, wäre finalize das Gegestück zu einem Destruktor

das ist er eben nicht! so'n c++-artiger destruktor wird sofort aufgerufen, wenn der scope verlassen, oder das objekt mit delete (oder delete[], warum auch immer c++ hier unterscheiden muss) gekillt wird. im gegensatz dazu wird finalize() erst aufgerufen, wenn der GC sich entschließt, speicher eines unreferenzierten objekts freizugeben. und genau aus dem grund darfste finalize() keinesfalls als destruktor missbrauchen, sondern höchstens als indikator, dass ein objekt endgültig in die ewigen jagdgründe eingegangen ist.

~john schrieb:

Effektiv fehlt Java ein echter Destruktor.

mit allen konsequenzen, so wie in C++? das lassen wir mal besser bleiben.

~john schrieb:

Mangels passendem deterministischen Destruktor in Java muß man anders Programme formulieren. RAII geht nicht und man muß immer von Hand finally Blöcke einführen, in der dann wieder explizit die dispose Methoden der Objekte aufgerufen werden müssen.

RAII ist zu 99% eine reine C++ technik, ein hilfsmittel, das eingesetzt wird, hauptsächlich um manuelle speicherverwaltung halbwegs erträglich zu machen. würdest du einer sprache mit GC RAII aufdrücken, dann würdest du sie in die programmierer-steinzeit zurückbefördern. ich glaube, das würden die meisten benutzer einer solchen sprache dir nicht verzeihen.

[Tyrdal]

RAII ist zu 99% eine reine C++ technik, ein hilfsmittel, das eingesetzt wird, hauptsächlich um manuelle speicherverwaltung halbwegs erträglich zu machen.

Nein, es ist eine Technik um Resourcenverwaltung handhabbar zu machen. Speicher ist nur eine Resource von vielen. Wenn du aber unbedingt einen GC haben willst dann kannste den in C++ dazulinken und gut ist, in Sprachen ohne Destruktur ist das Aufräumen von Nichtspeicherresourcen dagen ordentlich mühsam und meist nicht so einfach nachzurüsten.

[audacia]

+fricky schrieb:

RAII ist zu 99% eine reine C++ technik, ein hilfsmittel, das eingesetzt wird, hauptsächlich um manuelle speicherverwaltung halbwegs erträglich zu machen. würdest du einer sprache mit GC RAII aufdrücken, dann würdest du sie in die programmierer-steinzeit zurückbefördern. ich glaube, das würden die meisten benutzer einer solchen sprache dir nicht verzeihen.

Die C#-Benutzer scheinen zumindest mit dem using-Statement nicht unzufrieden zu sein, und daß in Delphi nun typsichere Smart-Pointer möglich sind, wird auch eher positiv aufgenommen

Tyrdal schrieb:

RAII ist zu 99% eine reine C++ technik, ein hilfsmittel, das eingesetzt wird, hauptsächlich um manuelle speicherverwaltung halbwegs erträglich zu machen.

Nein, es ist eine Technik um Resourcenverwaltung handhabbar zu machen. Speicher ist nur eine Resource von vielen.

So ist es. Ohne RAII muß man ständig try-finally benutzen, ganz egal, ob für einen Speicherblock, einen Graphikkontext oder einen Dateistream.