Ist es sinnvoll heute noch C++ anzufangen?

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

[knivil]

Also Java vs. C++:
Hier jemand sehr bekanntes der gewissen Sachen wie Operatorueberladung, Stack und "Generics" fuer Java fordert: Growing a language

[+fricky]

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.

sagen wir mal: es wird auch dafür benutzt. aber wie begegnet man mit RAII dem problem, wenn ein nicht-trivialer destruktor scheitert (was in der realität oft vorkommen kann, angenommen es gelingt nicht, eine TCP-verbindung zu schliessen, es kommt eine negative rückmeldung bei irgendeiner aktion, oder sowas)?

knivil schrieb:

Also Java vs. C++:
Hier jemand sehr bekanntes der gewissen Sachen wie Operatorueberladung, Stack und "Generics" fuer Java fordert:

der typ ist mathematiker. kein wunder also, dass er sowas wie op-überladung liebt, damit er sich operatoren für klassen für matrizen, polarkoordinaten, komplexe zahlen u.ä. basteln kann. Java ist aber eigentlich nicht auf mathe spezialisiert, sondern soll eine einfache sprache sein, die jeder leicht lernen und schnell was nützliches damit machen kann.

[tntnet]

+fricky schrieb:

der typ ist mathematiker. kein wunder also, dass er sowas wie op-überladung liebt, damit er sich operatoren für klassen für matrizen, polarkoordinaten, komplexe zahlen u.ä. basteln kann. Java ist aber eigentlich nicht auf mathe spezialisiert, sondern soll eine einfache sprache sein, die jeder leicht lernen und schnell was nützliches damit machen kann.

Endlich mal ein wahres Wort von Dir. Java ist nicht für alles geeignet. Es ist eine Anfängersprache mit eingeschränkten Funktionsumfang. Dagegen ist C++ eine universelle Programmiersprache, womit Profis ihre Arbeit erledigen können.

[knivil]

Bloed, dass dieser jemand fuer Sun an Java arbeitete. Auch ist Operatorueberladung nicht der einzige Knackpunkt. Es nur fuer Matheliebhaber als sinnvoll zu erachten, ist etwas ... kurzsichtig. Auch die riesige Klassenbibliothek wuerde er gern gern vom Rest trennen.

Java ist aber eigentlich nicht auf mathe spezialisiert,

Braucht es auch gar nicht, C++ ist auch nicht auf Mathe spezialisiert.

soll eine einfache sprache sein, die jeder leicht lernen und schnell was nützliches damit machen kann.

Da man Java nur mit Klassenbibliothek bekommt, zaehle ich sie mal zur Sprache hinzu. Daher ist Java keine einfache Sprache mehr.

[mngbd]

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

Und was ist so schlimm daran?
Python z. B. hat dafür ein eigenes Syntax-Element eingeführt, die Implementation verhält sich unter der Haube ähnlich wie ein Konstruktor/Destruktor-Paar, und das ohne daß die Sprache Destruktoren kennen würde.

[JustAnotherNoob]

Was so ziemlich genau dem angesprochenem using Statement in C# entspricht, oder sehe ich das falsch?

[LordJaxom]

mngbd schrieb:

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

Und was ist so schlimm daran?

try oben, finally unten?

Man hat das gleiche Problem, was in Sprachen wie C oft genug dazu führt, dass allokierte Ressourcen nicht (immer) freigegeben werden. Die Anforderung der Ressource und die Freigabe der Ressource sind räumlich voneinander getrennt, damit kann bei Anpassung des einen die Anpassung des anderen leicht vergessen werden.

Wenn doch der finally-Block wenigstens oben stehen würde..

FileStream fs = new FileStream(...);
finally { fs.close(); }
try {
    ...
} catch (...) {
}

[mngbd]

try oben, finally unten?

Ja, das ist schlecht.
Ich sehe da aber nur ein syntaktisches Problem, und deshalb keinen Grund, die Interpretation der Sprache zu verändern.
In Lisp würde ich mit einem Makro auskommen, neue Semantik könnte ich mir sparen.

[audacia]

mngbd schrieb:

In Lisp würde ich mit einem Makro auskommen, neue Semantik könnte ich mir sparen.

Das ist wunderbar, hilft aber in Java und C# herzlich wenig

In C++ mit typeof / decltype geht es übrigens auch mit einem Makro:

UCL_SAFEGUARD (MyListView->Items, object->BeginUpdate (), object->EndUpdate ());