Erst C oder gleich C++ ???

[rüdiger]

audacia schrieb:

Shade Of Mine schrieb:

aber wo ist name() jetzt undurchdacht? es ist die human readable form einer typeinfo.

Hätte man "human-readable" standardisiert, wäre es plötzlich viel nützlicher, meinst du nicht? Wem nützt die gegenwärtige Variante? Außerdem ist std::type_info::name() eigentlich nur beim C++Builder "human-readable"; bei MSVC gibt es, wenn ich mich recht erinnere, offenbar der Optimierung dienende "Verschönerungen", und GCC gibt einfach die vollständig dekorierte Variante zurück.

Da sehe ich nicht das Problem. Es gibt im C++-Standard einige Dinge die der Implementierung überlassen werden. Aber wenn ich type_info::name() benutze, dann ist das entweder beim debuggen oder um eh platformspezifische Hacks zu bauen (wie zB Introspection, in dem man die Infos aus den Symbolen der sharedlib liest).

[~fricky]

volkard schrieb:

~fricky schrieb:

aber gibt es irgendeine problemstellung, von der man sagen kann: 'dafür C++ die einzig richtige wahl', wofür weder java noch C, noch python, noch php, noch sonstwas geeignet wären?

tausch "c++" durch irgend eine sprache deiner wahl aus und dein argument paßt auch. seltsam.

wieso? viele sprachen haben gewisse alleinstellungsmerkmale und sind daher nicht beliebig austauschbar. um mal einige zu nennen:
PHP - man kann dynamische webseiten, ohne viele vorkenntnisse, in rekordzeit entwickeln.
Java - bringt eine riesige, plattformunabhängige infrastruktur mit
C# - 'besseres' Java für windows-rechner
C - schlank, schnell, sehr gut geeignet für maschinennahe programmierung, microcontroller, etc.
ADA - low-level, sehr gute typsicherheit, laufzeitchecks d.h. extreme stabilität in einem.
^^usw. usw, um nur (sehr unvollständig) einige zu nennen.
aber wohin gehört c++? gibt es eine lücke, die c++ füllen kann?

Shade Of Mine schrieb:

nicht durchdacht meine ich im sinne von:
wozu braucht man das?

wenn du schon so fragst: wieso gibt es delete und delete[]?

[asc]

Shade Of Mine schrieb:

Ich will dass mir eine Sprache die Tools gibt um die Probleme die ich habe ideal zu lösen. Wenn sie mir nur Hämmer gibt, tu ich mir beim Schraubendrehen schwer - deshalb mag ich es, wenn ich einen ganzen Werkzeugkoffer bekomme.

Oder kurz gesagt: Für jede Aufgabe sollte man das passende Werkzeug verwenden. In manchen Fällen ist dies eine Scriptsprache, in anderen C++...

Wobei ich hoffe das meine gefühlten Hauptmankos an C++ sich tatsächlich mit C++09 und dem danach folgenden TR (TR2?) erledigen... (Und wer C++ garnicht mag soll es halt nicht einsetzen).

cu André

[Shade Of Mine]

audacia schrieb:

Hätte man "human-readable" standardisiert, wäre es plötzlich viel nützlicher, meinst du nicht? Wem nützt die gegenwärtige Variante? Außerdem ist std::type_info::name() eigentlich nur beim C++Builder "human-readable"; bei MSVC gibt es, wenn ich mich recht erinnere, offenbar der Optimierung dienende "Verschönerungen", und GCC gibt einfach die vollständig dekorierte Variante zurück.

Ich sehe das Problem nicht.
Ja, es könnte besser sein - da widerspricht dir ja niemand. aber ist type_info::name() nicht verwendbar? Es ist praktisch zur Ausgabe. Nicht mehr nicht weniger.

Ich würde es toll finden wenn es reflection gäbe, keine frage.

Jedenfalls fallen sämtliche Features, die man leicht und ohne Zusatzaufwand auf der Grundlage des Vorhandenen hätte implementieren können (siehe meine type_info-Beispiele), für mich ebenso unter "undurchdacht".

es wurde einfach keine restriktionen an die implementierung gegeben.
klar macht es das feature weniger nützlich.
aber weniger nützlich != undurchdacht

Dann sage mir bitte: wozu in aller verbliebenen Götter Namen muß man einen Integer werfen können?

Warum darf ich keinen werfen. Das würde mich mal interessieren.

Weil es keinen Sinn macht? Weil es unschön ist?

ich will aber einen int werfen als error code. unheimlich praktisch weil ich plötzlich keine allokationen brauche für das objekt.

Auch die Sache mit den Default-Kopierkonstruktoren ist mehr als unschön. Barry Kelly hat das, finde ich, recht schön dargelegt.

Der Artikel ist ja mal ziemlicher Käse.
Warum genau sind closures in C++ unmöglich?

Default CopyCtor ist etwas sehr sinnvolles: es erlaubt nämlich code ersparnis - man muss die großen 3 nur implementieren wenn man sie braucht. das erspart eine menge arbeit bei hilfsklassen wie zB eine list node.

und datenstrukturen aus c sind generell so leichter zu verwenden.

[Shade Of Mine]

~fricky schrieb:

Shade Of Mine schrieb:

nicht durchdacht meine ich im sinne von:
wozu braucht man das?

wenn du schon so fragst: wieso gibt es delete und delete[]?

aus performance gründen

[asc]

~fricky schrieb:

^^usw. usw, um nur (sehr unvollständig) einige zu nennen.
aber wohin gehört c++? gibt es eine lücke, die c++ füllen kann?

C++ : Wie C sehr schnell, und auch für maschinennahe Programmierung geeignet. Bietet zusätzlich die Möglichkeiten der generischen Programmierung (bei gleichzeitiger Typsicherheit) und der direkten Unterstützung von OO-Konzepten.

Ich finde das C++ in jede Nische passt, die C erfüllt, wenn man gleichzeitig noch Funktionalitäten von Hochsprachen haben will. Sprich: In allen Projekten wo C möglich wäre, die Komplexität des Programmes aber mehr Abstraktion und Wartbarkeit erfordert (Meiner Meinung nach auch mehr Stabilität).

cu André

[Bulli]

namespace invader schrieb:

C++ ist unnötig kompliziert, weil zu viele Paradigmen hineingequetscht wurden und dann auch noch versucht wurde, zu C kompatibel zu bleiben.

Ich halte das für eine dumme Idee. Sprachen sollten ein oder wenige zusammenpassende Paradigmen konsequent umsetzen und besser dafür sorgen, dass die Anbindung an andere Sprachen problemlos möglich ist.

Dann benutze doch einfach eine andere Sprache als C++. Oder wo ist der Haken?

[dfgdfgdfg]

asc schrieb:

C++ : [...] Bietet zusätzlich die Möglichkeiten der generischen Programmierung (bei gleichzeitiger Typsicherheit) und der direkten Unterstützung von OO-Konzepten.

cu André

Wow! Applaus! Soll jetzt jeder Luftsprünge machen?
Das was du da tolles für C++ vorstellst, ist das selbstverstöndlichste auf der welt.

C++ ruht sich auf Lohrbeeren aus, die schon seit ~30 jahren als etwas selbstverstäünliches in highlevelsprachen sind.

[~fricky]

Shade Of Mine schrieb:

~fricky schrieb:

Shade Of Mine schrieb:

nicht durchdacht meine ich im sinne von:
wozu braucht man das?

wenn du schon so fragst: wieso gibt es delete und delete[]?

aus performance gründen

das verstehe ich nicht. in dem allozierten block ist doch schon die information gespeichert, wie gross er ist. ein zusätzliches delete[] müsste es doch gar nicht geben.

asc schrieb:

~fricky schrieb:

^^usw. usw, um nur (sehr unvollständig) einige zu nennen.
aber wohin gehört c++? gibt es eine lücke, die c++ füllen kann?

C++ : Wie C sehr schnell, und auch für maschinennahe Programmierung geeignet.

trotzdem wird C++ in solchen bereichen eher selten verwendet, sondern stattdessen C. warum? aus unwissenheit, traditionsbewusstsein oder aus gutem grund?

[Walli]

Tradition wuerde ich tippen. Und weil man gut C++ koennen muss um zu wissen wo die Overheads stecken koennten. Auch die Verfuegbarkeit der Compiler koennte eine Rolle spielen.

[hellihjb]

wieso gibt es delete und delete[]?

aus performance gründen

das verstehe ich nicht. in dem allozierten block ist doch schon die information gespeichert, wie gross er ist. ein zusätzliches delete[] müsste es doch gar nicht geben.

delete[] fuehrt den Destruktor jedes einzelnden Elementes aus.
Das kann erwuenscht sein oder auch nicht - haelst Du fuer ueberfluessig?

[audacia]

Shade Of Mine schrieb:

~fricky schrieb:

wenn du schon so fragst: wieso gibt es delete und delete[]?

aus performance gründen

Unfug. Der Allokator muß ohnehin Metainformationen über den Speicherblock unterbringen. Ob da jetzt auch noch eine Array-Dimension mitgespeichert wird, dadurch aber jeder Menge Laufzeitfehler vorgebeugt wird, macht doch nun keinen Unterschied in der Performance?
(@fricky: da zwischen Allokation und Konstruktion unterschieden wird, muß schon zusätzliche Information untergebracht werden. Aber trotzdem: vier Bytes im Tausch gegen eine vermeidbare Fehlerquelle!)

Shade Of Mine schrieb:

Warum darf ich keinen werfen. Das würde mich mal interessieren.

Weil es keinen Sinn macht? Weil es unschön ist?

ich will aber einen int werfen als error code. unheimlich praktisch weil ich plötzlich keine allokationen brauche für das objekt.

Du weichst deiner eigenen Frage aus
Sage mir doch: wozu braucht man das?
Für das vermeiden von Allokationen aka Premature Optimization jedenfalls nicht. Du kannst auch ein std::exception-Derivat implementieren, das für what() ein Literal zurückgibt und auf dem Stack alloziert wird. Keinerlei Allokation vonnöten, dafür alle Vorteile der Polymorphie beim Exception-Handling vorhanden.

Shade Of Mine schrieb:

es wurde einfach keine restriktionen an die implementierung gegeben.
klar macht es das feature weniger nützlich.
aber weniger nützlich != undurchdacht

"This problem is hard. Let's make it an option and the user can decide!"

In obigem Falle mit std::type_info ist es aber so, daß die Features ohne Mehraufwand gewesen wären: niemand hätte VMTs vergrößern müssen, weil das Nötige eh schon drinsteht. Niemand, der die Funktionalität nicht benötigt, hat größere Executables. Nur die RTL-Programmierer haben ein paar zusätzliche Funktionen zu implementieren, die sich im Wesentlichen aus den Bestandteilen der Implementation von dynamic_cast<> zusammensetzen lassen.
Aufgrund des Fehlens solcher Features halte ich std::type_info schlicht für "undurchdacht".

Artchi schrieb:

Dann benutze doch einfach eine andere Sprache als C++. Oder wo ist der Haken?

Als Argument kein Stück besser als IYWTPICPPTPICPP

Edit: Typographie und Eile

[~fricky]

hellihjb schrieb:

delete[] fuehrt den Destruktor jedes einzelnden Elementes aus.
Das kann erwuenscht sein oder auch nicht - haelst Du fuer ueberfluessig?

nein, ich frage mich nur, warum delete nicht selbst erkennen kann, ob es für ein einzelobjekt oder ein array von objekten ausgeführt wird.

[Gast]

~fricky schrieb:

trotzdem wird C++ in solchen bereichen eher selten verwendet, sondern stattdessen C. warum? aus unwissenheit, traditionsbewusstsein oder aus gutem grund?

Wenn man schon mit C arbeitet braucht es halt gute Gründe auf C++ umzusteigen. Offensichtlich reichen diese nicht immer aus.

[audacia]

Achja, ich vergaß:

Shade Of Mine schrieb:

Auch die Sache mit den Default-Kopierkonstruktoren ist mehr als unschön. Barry Kelly hat das, finde ich, recht schön dargelegt.

Der Artikel ist ja mal ziemlicher Käse.

Hoppla, du bist aber schnell mit abwertenden Urteilen bei der Hand

Shade Of Mine schrieb:

Warum genau sind closures in C++ unmöglich?

Sind sie nicht. Aber ohne GC darfst du die Speicherverwaltung selbst übernehmen.
Schau dir als Beispiel die Closures in Delphi 2009 an, die nicht mit GC, sondern mit Referenzzählung implementiert sind (übrigens hauptsächlich von obengenanntem Barry Kelly, der also vielleicht etwas besser als du darüber Bescheid weiß, welche Komplikationen sich dabei ergeben). So richtig funktional und ohne die Beachtung der Speicherverwaltung kann man Closures eigentlich vor allem im Zusammenhang mit Interfaces benutzen - die auch referenzgezählt werden. Referenzzählung ist eine GC-Variante.

Shade Of Mine schrieb:

Default CopyCtor ist etwas sehr sinnvolles: es erlaubt nämlich code ersparnis - man muss die großen 3 nur implementieren wenn man sie braucht. das erspart eine menge arbeit bei hilfsklassen wie zB eine list node.

und datenstrukturen aus c sind generell so leichter zu verwenden.

Hast du den Artikel überhaupt gelesen? Es geht doch nicht darum, auf Kopierkonstruktoren zu verzichten.

[Shade Of Mine]

audacia schrieb:

Shade Of Mine schrieb:

Warum genau sind closures in C++ unmöglich?

Sind sie nicht. Aber ohne GC darfst du die Speicherverwaltung selbst übernehmen.
Schau dir als Beispiel die Closures in Delphi 2009 an, die nicht mit GC, sondern mit Referenzzählung implementiert sind (übrigens hauptsächlich von obengenanntem Barry Kelly, der also vielleicht etwas besser als du darüber Bescheid weiß, welche Komplikationen sich dabei ergeben). So richtig funktional und ohne die Beachtung der Speicherverwaltung kann man Closures eigentlich vor allem im Zusammenhang mit Interfaces benutzen - die auch referenzgezählt werden. Referenzzählung ist eine GC-Variante.

Ich kenne nur die closures in c++ und die haben eigentlich kein ref counting dabei...

Hast du den Artikel überhaupt gelesen? Es geht doch nicht darum, auf Kopierkonstruktoren zu verzichten.

Sicher, aber ich dachte dir geht es um default cctors...

der artikel ist doof - sag einfach was du daraus meinst. mag nicht den ganzen artikel zerpflücken müssen.

@~fricky:
nein, es muss nicht gespeichert werden wie groß der bereich ist. meistens wird es dass, aber es wäre mögich es auch ohne zu implementieren.

aber selbst wenn es gespeichert wird: delete[] speichert noch mit wie viele objekte hier liegen. das ist eine zusatz information die delete nicht braucht -> du sparst performance

[~fricky]

Tim schrieb:

~fricky schrieb:

trotzdem wird C++ in solchen bereichen eher selten verwendet, sondern stattdessen C. warum? aus unwissenheit, traditionsbewusstsein oder aus gutem grund?

Wenn man schon mit C arbeitet braucht es halt gute Gründe auf C++ umzusteigen. Offensichtlich reichen diese nicht immer aus.

oder man ist sich der gefahren bewusst. tatsächlich hab' ich mehr als einmal erlebt, dass jemand, durch den (blauäugigen) einsatz von c++ in einem embedded system, fürchterlich auf die nase gefallen ist.

Shade Of Mine schrieb:

@~fricky:
nein, es muss nicht gespeichert werden wie groß der bereich ist. meistens wird es dass, aber es wäre mögich es auch ohne zu implementieren.

wie das? delete muss doch wissen, ob es sich um einen einzelnen 'char', oder ein objekt mit 99 members handelt, um die richtige speichermenge wieder freizugeben.

Shade Of Mine schrieb:

delete[] speichert noch mit wie viele objekte hier liegen. das ist eine zusatz information die delete nicht braucht -> du sparst performance

ja, ein lesezugriff und eine bedingte verzweigung, vielleicht 10...20 taktzyklen oder so. die ersparniss ist minimal, dafür hätte man aber eine üble fehlerquelle ausgeschaltet, nämlich das vertauschen von delete[] mit delete.

[asc]

dfgdfgdfg schrieb:

asc schrieb:

C++ : [...] Bietet zusätzlich die Möglichkeiten der generischen Programmierung (bei gleichzeitiger Typsicherheit) und der direkten Unterstützung von OO-Konzepten.

cu André

Wow! Applaus! Soll jetzt jeder Luftsprünge machen?
Das was du da tolles für C++ vorstellst, ist das selbstverstöndlichste auf der welt.

Interessanterweise ist die generische Programmierung in den "Mainstream"-Sprachen erst mit C++ wirklich eingekehrt. Als selbstverständlich würde ich das also nicht nennen (Generics & Co in Sprachen wie Java/C# kamen erst danach)

dfgdfgdfg schrieb:

C++ ruht sich auf Lohrbeeren aus, die schon seit ~30 jahren als etwas selbstverstäünliches in highlevelsprachen sind.

So? Ich wusste noch gar nicht das Templates in C++ 30 Jahre alt sind (Den darauf beziehe ich mich u.a.). Dir ist hoffentlich bewusst das die Sprache C++ im Wandel ist, C++98, TR1 (C++03), C++09 seien hier nur genannt.

[Tachyon]

~fricky schrieb:

...sabbel...

Ist klar, weil einem so wenig unsichere Konstrukte in C++ einfallen, muss eben delete herhalten.
Mir fallen da jede Menge Dinge in C ein, die unsicher sind. Das fängt schon beim printf/scanf an, geht über das gesamte Bastelei mit Strings und Arrays bis hin zu so tollen Sachen wie die wenigen Standardalgorithmen die absolut 0 Typsicherheit bieten.
Man muss eben wissen, was man tut. Das gilt, wer hätte das gedacht, auch für C++, Ada und alle möglichen anderen Sprachen.
In C braucht es Disziplin um was Ordentliches zu Stande zu bringen. In C++ muss man sich von alten Strukturen lösen und auf C++-Konstrukte umsatteln. Das fällt Anachronisten (und C++ ist heute nicht mehr das, was es war als es besagte Anachronisten offensichtlich ausprobiert haben) oft schwer, und deshalb kommt oft Schrott dabei raus.
Ich weiß nicht wie andere Leute C++ programmieren (bei fricky habe ich allerdings so eine grobe Vorstellung), aber bei mir deckt der Compiler bereits die meisten Fehler auf. Die Fehler die noch da sind, sind meist eher Logikfehler. Und die hätte man in jeder Sprache.

Um auf die Frage des TOs zurückzukommen:
Wenn es um die Wahl zwischen C und C++ geht und sonst keine Sprachen in Frage kommen, würde ich mit C++ beginnen, und mir auch ein richtiges C++-Buch dazu kaufen (und keines das mit C in Klassen, C++ mit Visual Studio oder sonstigem Quark beginnt). Dann ist C++ auch einfacher als C.

[Shade Of Mine]

~fricky schrieb:

dafür hätte man aber eine üble fehlerquelle ausgeschaltet, nämlich das vertauschen von delete[] mit delete.

ist das wirklich ein fehler der oft vorkommt?
bei anfängern vielleicht, aber ich hab das eigentlich noch nie in einem produktiv code gesehen.