vergesst C++ ...

[volkard]

Power Off schrieb:

Bei

try{
		new(5) Foo;
	}

rufst Du nirgends einen Destruktor auf.

doch.
der operator new (der, den man nicht ändern kann, der echte operator, nicht eine funktion gleichen namens) wird aufgerufen. der ruft meine placement new auf. meine placement new besorgt speicher. dann ruft der operator new den ctor von Foo auf. der ctor wirft ne exception. der operator new bemerkt das und ruft meine placement delete auf, um den speicher, den meine placement new allokierte, wieder freizugeben.

als nicht-template sollte es klappen.

void* operator new(size_t size,int x){
    cout<<"new with "<<x<<'\n';
    static char buf[1000];
    return (void*)buf;
}
void operator delete(void* p,int x){
    cout<<"delete with "<<x<<'\n';
}

[Power Off]

volkard schrieb:

doch.
der operator new (der, den man nicht ändern kann, der echte operator, nicht eine funktion gleichen namens) wird aufgerufen. der ruft meine placement new auf. meine placement new besorgt speicher. dann ruft der operator new den ctor von Foo auf. der ctor wirft ne exception. der operator new bemerkt das und ruft meine placement delete auf, um den speicher, den meine placement new allokierte, wieder freizugeben.

ISO 14882:2003, chapter 5.3.4 New, section 17 schrieb:

If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed. [ Note: this is appropriate when the called allocation does not allocate memory; otherwise, it is likely to result in a memory leak. ]

Aber Du hattest Recht, an die Speicherfreigabe waehrend new habe ich gar nicht gedacht!

[O'Rakl]

@Power Off:

Nur aus Neugier:
Wo hast Du denn in BCPL programmiert ? Ist ja eine äußerst seltene Sprache,
der Vor-Vorgänger von C sozusagen.

[Power Off|_work]

In der Steinzeit.

[Talla]

Power Off schrieb:

Der Satz war komplett

Power Off schrieb:

Ich programmier zwar erst seit 1993, also bloß 12 Jahre in C++, aber bis jetzt hab ich noch keinen Compiler gesehen, der das Problem gelöst hätte.

Kannst Du nicht lesen?

Dann schreib das auch und setz nächstes mal des Komma richtig! So wie der Satz jetzt dasteht bezieht sich das bloß 12 Jahre in C++ nicht auf das seit 1993 programmieren.

[zustimm]

Talla schrieb:

Power Off schrieb:

Der Satz war komplett

Power Off schrieb:

Ich programmier zwar erst seit 1993, also bloß 12 Jahre in C++, aber bis jetzt hab ich noch keinen Compiler gesehen, der das Problem gelöst hätte.

Kannst Du nicht lesen?

Dann schreib das auch und setz nächstes mal des Komma richtig! So wie der Satz jetzt dasteht bezieht sich das bloß 12 Jahre in C++ nicht auf das seit 1993 programmieren.

FULL ACK

[--linuxuser--]

also ich kann nur sagen C ist eine einfach geniale sprache da kann man sagen was man will aber man sollte auch offen gegenueber anderen sprachen sein!

[maximAL]

...
ja, ich weiß, daß diese spielregel einen dicken bonus auf funktionale sprachen wirft, wo man mit ohne viel code wirklich große konzepte implementieren kann. wenn sie an erste stelle kommen, dann ist das verdient. wenn nicht, ist die unmittelbarkeit der main-stream-sprachen noch ausreichend, um bei extremen speed-tests zu gewinnen. (meine prophetische ader sagt: die funktionalen sind so viel geiler zu optimieren und die optimierer werden besser, daß sie noch zu meinen lebzeiten ein zwischenhoch erfahren bei solchen speed-tests und c++ und asm auf breiter front plätten).

[groovemaster]

O'Rakl schrieb:

Meinst Du wirklich ? Wenn man C++ ein bischen kann, ist es eher eine
Katastrophe, weil man dann ständig mit Compiler-Errors zu tun bekommt, die
nichts über die Fehlerursache sagen und kommentarlose Abstürze beim Testlauf.

Ich benutze hauptsächlich MSC und GCC und dort sind 95% aller Nicht-Template Fehler eindeutig. Und für den Rest kann man auch mal die Doku nachschlagen.
Was die kommentarlosen Abstürze betrifft, besorg dir einen aktuellen Compiler oder verwende Exceptions. Oder lern zu programmieren.

O'Rakl schrieb:

Um Spaß mit C++ zu haben, muß man es *richtig* können

Mittlerweile hast du ja mehrfach bewiesen, dass du nicht zu dieser Kategorie gehörst. Wie kommst du eigentlich darauf, Python mit C++ zu vergleichen? Nur weil du nicht fähig bist, C++ zu lernen, ist Python besser? Seltsame Logik.

O'Rakl schrieb:

, man muß wissen, wie
der Compiler intern funktioniert

Nö. Ich weiss nicht, wie mein Compiler intern funktioniert, habe aber trotzdem jede Menge Spass damit.

O'Rakl schrieb:

, man muß etliche Bibliotheken kennen, nur um
mal ein absturzsicheres Array benutzen zu können

Bitte? Programmierfehler müssen bestraft werden. Und wenn du keine machst, dann hast du auch ein absturzsicheres Array. Selbst VB bringt bei ungültigen Indizes Fehlermeldungen. Und was hast du gegen die Benutzung von Bibliotheken?

O'Rakl schrieb:

, man muß wissen, wieviel und
was der Compiler auf den Stack packt und anhanddessen auswählen, ob man Daten
const deklariert, um keinen Stacküberlauf zu riskieren, usw...

const deklarieren um Stacküberlauf zu verhindern, ja klar. Oh Herr, bitte lass Hirn regnen!

O'Rakl schrieb:

Die Ausdrucksmöglichkeiten an abstrakteren Konzepten als Bit, Byte und
Pointer von C++ sind im Vergleich mit Python nahezu
Null. Deshalb sind C++-Programme ja auch so lang.

Wie bereits mehrfach erwähnt wurde, du denkst zu viel C.

O'Rakl schrieb:

Für s="hello world\n" muss man schon eine Bibliothek bemühen.

Nö, musst du nicht. Wobei die eingebauten Strings (was ja eigentlich C Strings sind) durchaus überholt werden müssten, imo.

Power Off schrieb:

Vielleicht sollte man mal eine neue, C++ ähnliche, Sprache entwickeln, die alle Features hat, die man so braucht.

Tolle Idee, dass darauf noch niemand gekommen ist. Die Sprache könnte man ja zB D nennen.

Power Off schrieb:

C++ hat den Nachteil, daß es z.B. keine Initialisierung von Objekt-Arrays gibt.

Das stimmt so nicht ganz, zumindest wenn's nicht-dynamisch ist.

maximAL schrieb:

oh doch, genau darum geht es hier.

Nö. Entweder du hast den Thread nicht gelesen oder das Thema nicht verstanden. Niemand behauptet, dass C++ die beste Sprache ist wo gibt, und niemand behauptet, dass man mit C++ alles kinderleicht hinbekommt. Hier wird darüber diskutiert, ob man C++ aufgrund von Python vergessen sollte. Was ist also nicht legitim daran, dies zu verneinen?

Power Off schrieb:

Mit Array-Bounds-Checking meine ich Konstruktionen wie

int a[10]; // bounds checked

Mit einem specifier könnte man das Bounds-Checking ein-/ausschalten:

int __range_checked a[10];
int __range_unchecked a[10];

Ein Value-Range-Checking à la Ada wäre auch nicht schlecht:

int __range_checked(-3,5) a;

a = 4; // ok
a = 7; // exception

Das schöne an C++ ist, dass man sowas mit (Template-) Klassen wunderbar realisieren kann. Klar kann man monieren, dass sowas dann nicht eingebaut ist. Andere könnten darauf hin entgegnen, dass die C++ Basis so nicht noch mehr aufgebläht wird.

Power Off schrieb:

Diese Prüfungen sind für den Compiler leichter zu generieren (2-3 Assembler-Befehle) als eine manuell programmierte Prüfung in einer Template-Instanz.

Da hab ich so meine Zweifel, immerhin kann der Compiler auch nicht zaubern.

O'Rakl schrieb:

Daß C++ mächtig ist, ist eine Täuschung, der mancher langjährige C++-Programmierer aufsitzt -- er hat schließlich tausende Seiten an Referenz und
wirklich komplizierter Dokumentation zu C++ durchgearbeitet,
sodaß er zwangsläufig zum Schluß kommen muß, daß er nun, nach all den Jahren
der Mühsal, eine besonders mächtige Sprache beherrscht. Kompliziert ist es
ja wirklich.

So langsam fängst du an zu nerven.

O'Rakl schrieb:

Aber Komplixität ist kein Wert an sich. Im Gegenteil: Übermäßige
Komplexität in der Beschreibung einfachster Algorithmen weist eher einen
Mangel an Ausdrucksstärke nach.

Bist du echt (BWL-) Student? Sowas kann doch eigentlich nur von einem Theoretiker kommen. Was hat denn die "Beschreibung einfachster Algorithmen" mit einer Programmiersprache zu tun?

[maximAL]

groovemaster schrieb:

maximAL schrieb:

oh doch, genau darum geht es hier.

Nö. Entweder du hast den Thread nicht gelesen oder das Thema nicht verstanden. Niemand behauptet, dass C++ die beste Sprache ist wo gibt, und niemand behauptet, dass man mit C++ alles kinderleicht hinbekommt. Hier wird darüber diskutiert, ob man C++ aufgrund von Python vergessen sollte. Was ist also nicht legitim daran, dies zu verneinen?

auch wenn der threadstarter hier mit python trollt (was vom anwendungsgebiet sicherlich nicht vergleichbar ist), ändert das nichts daran, dass C++ hier über den grünen klee gelobt wird.
immer wieder die selbe beknackte argumentation - weil man alles mögliche mit diversen libs lösen kann, ist C++ natürlich genauso gut, wie andere sprachen, die derartige features nativ bieten - oder bei denen man entsprechende probleme erst gar nicht hat.
higher order functions? ach was! boost::lambda! function objects! alles genauso gut! garbage collector? ja, die gibts doch auch! etc. pp.
hauptsache man kann sich feature XYZ irgendwo auf die liste schreiben und dann sagen, dass doch sowieso alles geht. der faktor mensch wird dabei immer schön ausgeklammert, eine programmiersprache muss keineswegs einfach und intuitiv strukturiert sein, nönö! schliesslich sind wir ja richtige kerle und packen das alles! fehleranfällig? ach, wer fehler macht, ist nur zu blöd!
the right tool for the job - aber da C++ ja von low bis highlevel alles perfekt abdeckt, ist es auch immer das richtige werkzeug, gell?

ich will einmal hören, dass C++ einfach ne gute sprache für low level sachen ist - wenn man tatsächlich selbst den speicher verwalten will, wenn es einen wirklich interessiert, wie groß nun ein int ist oder man wirklich immer ganz genau wissen will oder muss welcher speicher/rechenzeit bedarf hinter irgendwas steckt.
aber nö, macht ruhig weiter.

irgendwann sterbt ihr mitsamt eurer sprache sowieso aus ;)[/sarkasmus]

[...]

Worin liegt der Unterschied ob eine Sprache diese Mittel von Haus aus mitbringt, oder Programmierer Bibliotheken mit dieser Funktionalität schreiben und jedem zur Verfügung stellen? Richtig bei letzterem kann man die Sprache selbst auf viel mehr Plattformen verwenden und für Plattformen die zB eine grafische Oberfläche haben eine entsprechende Bibliothek entwickeln. Ist btw. auch nen Grund weshalb C bis vor nen paar Jahren für alle plattformunabhängige Projekete verwendet wurde.

Manchmal hilft es auch, wenn man sich klar macht, dass es noch andere programmierbare Systeme gibt, als den Desktop PC mit 0815 Ausstattung.

[O'Rakl]

@groovemaster:

Genau das meinte ich mit "langjährige C++-Programmierer haben soviel
Mühe und Zeit in das Lesen tausednseitiger Sprachdokumentationen investiert, daß sie glauben müssen, nun auch eine besonders mächtige Sprache zu beherrschen."

C++ ist keine ausdrucksstarke Sprache.

(Zur Erinnerung: "ausdrucksstark" bedeutet, daß man eine Vielzahl von Konzepten
mit *wenig* Code beschreiben kann, nicht, daß die Quelltexte besonders viele
Ausdrücke enthalten)

[Sovok]

groovemaster schrieb:

O'Rakl schrieb:

Daß C++ mächtig ist, ist eine Täuschung, der mancher langjährige C++-Programmierer aufsitzt -- er hat schließlich tausende Seiten an Referenz und
wirklich komplizierter Dokumentation zu C++ durchgearbeitet,
sodaß er zwangsläufig zum Schluß kommen muß, daß er nun, nach all den Jahren
der Mühsal, eine besonders mächtige Sprache beherrscht. Kompliziert ist es
ja wirklich.

So langsam fängst du an zu nerven.

jep

@O'Rakl sowas hör ich vorallem von leuten die sich featurebeschreibungen durchlesen ohne sie zu verwenden und vergessen, dass hinter jedem feature auch eine sinnvolles anwendungsgebiet steckt

d.h. der richtige weg is erst mit ein paar wenigen features zu programmieren und dann etwas bestimmtes realisieren zu wollen wofür die bekannten features nich ausreichen
dann holt man sich die doku und kramt das neue feature raus das man zusätzlich brauch

falls es dir noch nich aufgefallen is... du kannst auch ein gültiges c/c++ unter verwendung von 0.1% der vorhandenen features schreiben

[Sovok]

O'Rakl schrieb:

@groovemaster:

Genau das meinte ich mit "langjährige C++-Programmierer haben soviel
Mühe und Zeit in das Lesen tausednseitiger Sprachdokumentationen investiert, daß sie glauben müssen, nun auch eine besonders mächtige Sprache zu beherrschen."

C++ ist keine ausdrucksstarke Sprache.

(Zur Erinnerung: "ausdrucksstark" bedeutet, daß man eine Vielzahl von Konzepten
mit *wenig* Code beschreiben kann, nicht, daß die Quelltexte besonders viele
Ausdrücke enthalten)

gut wenn du dir da so sicher bist dann bring mal 5 codebeispiele in denen
c++ schrecklich ausdrucksschwach is

[GPC]

Sovok schrieb:

d.h. der richtige weg is erst mit ein paar wenigen features zu programmieren und dann etwas bestimmtes realisieren zu wollen wofür die bekannten features nich ausreichen
dann holt man sich die doku und kramt das neue feature raus das man zusätzlich brauch

Eben, man kann eh nie alle Features einer Sprache kennen und/oder nützen. Braucht man auch gar nicht.

[O'Rakl]

<gut wenn du dir da so sicher bist dann bring mal 5 codebeispiele in denen
c++ schrecklich ausdrucksschwach is>

Ausdrucksschwäche ist keine lokale Eigenschaft, sondern eine globale.
Eine Sprache kann nur an sich ausdrucksstark sein oder eben nicht. Man kann
nicht die Nicht-Existenz von Features mit Codebeispielen beweisen, nur
deren Existenz.

Aber gut, ich gebe Dir dennoch einen Tip, wie Du Dich einem Verständnis des
Problems nähern kannst:
Leg' Deine C++-Referenz mal auf den Schreibtisch und dann sieh von vorne
auf das Buch. Was siehst Du ?
5 bis 10 cm Papier.

-- und nun überlege mal scharf, ob wir hier über eine ausdrucksstarke
Sprache reden, wenn soviel Papier notwendig ist, um überhaupt erst mal
an den Datentyp "string" oder "liste" (der zweiteinfachste zusammengesetzte Datentyp) zu gelangen.

(string und liste sind Dinge, die in ausdrucksstarken Sprachen wie Python irgendwo auf den ersten 10 Seiten vollständig beschrieben sind, allerdings in Tutorials für Nicht-Programmierer; Programmierern kann man das schon auf Seite 1 eines Python-Tuts erklären).

Ciao !

[GPC]

Leg' Deine C++-Referenz mal auf den Schreibtisch und dann sieh von vorne
auf das Buch. Was siehst Du ? 5 bis 10 cm Papier.

Du redest Blech, eine Referenz erklärt warum C++ dies und jenes so oder so macht, nichts anderes. Ich denke Python würde da auch einiges an Papier fressen.

Btw. Kannst/Willst du eigentlich nicht vernüftig zitieren?

[maximAL]

Sovok schrieb:

gut wenn du dir da so sicher bist dann bring mal 5 codebeispiele in denen
c++ schrecklich ausdrucksschwach is

ich bring mal eins:
tuple.
tja, wie kommt man denn in C++ zu tupeln? jedesmal ne extra struct bauen? unschön. oder templates! ja, da gibts doch auch was in boost...

tuple<int, int, double> add_multiply_divide(int a, int b) {
  return make_tuple(a+b, a*b, double(a)/double(b));
}

toll, nicht?
naja, das man die enthaltenen typen explizit angeben muss, ist natürlich nicht sooo elegant.
vielleicht ist es tatsächlich auch nicht so prall, das man sowas eigentlich grundlegendes erst aus einer "unabhängigen" lib ziehen muss, welche in kaum einem C++ buch erwähnung finden wird, die ein großteil der programmierer kaum kennt und die man in kaum einem source antreffen wird.

mir wärs nun wirklich zu blöd, noch weiter zu machen, denn mir ist eh klar, dass es im grunde keiner hören will.

[GPC]

Schon mal was von Typlisten gehört? Sind auch ganz nett. Wo gibt's die in Python?
Falls es sie gibt (keine Ahnung?!?) ist das sicherlich gut. Aber andersherum gefragt, wie oft brauch ich solche Teile im normalen Alltag? Sowohl in Python als auc h in C++?

[Power Off]

O'Rakl schrieb:

@Power Off:

Nur aus Neugier:
Wo hast Du denn in BCPL programmiert ? Ist ja eine äußerst seltene Sprache,
der Vor-Vorgänger von C sozusagen.

Ich hab 1989 damit angefangen, als ich das AmigaDOS Manual (von der AmigaOS "dos.library") gelesen habe.

Da stand bei der Dokumentation von AmigaDOS-Handlern:

AmigaDOS Manual schrieb:

This is normally written in BCPL.

Sonst nix. Da bin ich dann neugierig auf die Sprache geworden. Ich hatte den offiziellen Entwickler-Kit nicht, in dem ein BCPL Compiler enthalten war, also kaufte ich mir das Buch "BCPL - The Language and Its Compiler" von Martin Richards und Colin Whitby-Strevens.

Und dann war's um mich geschehen; denn als ich sah, wie einfach und genial BCPL im Vergleich zu C war, wollte ich einiges damit machen.

Ich hab dann in C Programme geschrieben, die genau so wie der BCPL Compiler funktionierten (der teilweise im Buch abgedruckt war), und so lernte ich Compilerbau.

Später fand ich dann das Original BCPL-Paket von Richards im Netz (kann man sich von Cambridge Universität, UK saugen), und schrieb als erstes einen INTCODE-Interpreter und später auch einen INTCODE-Assembler für 68030.

Der INTCODE-Interpreter war in ANSI C geschrieben und lief auf jedem Betriebssystem. Das war echt cool! Ein kleines Programm compilieren, und schon laufen alle BCPL-Programme auf einem neuen Targetsystem.

Da wurde mir klar, daß Richards wirklich der beste Spezialist für portable Compiler und Betriebssysteme war.

Übrigens: Die "dos.library" auf dem Amiga war eine Portierung von TRIPOS, einem Mini-Computer-Betriebssystem, das Richards mal entwickelt hatte. Als MetaComCo für Commodore die "dos.library" entwickeln sollte, habe sie einfach TRIPOS genommen.

Das hat sehr stark zur Erweiterbarkeit und Skalierbarkeit von AmigaOS beigetragen, auch wenn Commodore später (in AmigaOS 2.0) den TRIPOS-Code in C neu entwickelt hatte (lustig waren die damit verbundenen Programmfehler, die es vorher nicht gab, ich brauchte eine Weile, um mich an AmigaOS 2.x und 3.x zu gewöhnen). Aber ohne TRIPOS hatte es irgendwie etwas von seinem Reiz verloren, auch wenn die Funktionalität im Prinzip dieselbe war. Man konnte halt nicht mehr BCPL-Code ins OS einbetten!