vergesst C++ ...

Power Off

Talla schrieb:

Power Off schrieb:

Compilerbau gehört schon seit 1989 zu meinen Spezialgebieten.

Power Off schrieb:

Ich programmier zwar erst seit 1993,...

Hast du 4 Jahre lang theoretisch Compiler entwickelst ohne Programmieren zu können?!?

Was soll der Blödsinn?

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?

Ich programmiere seit 1993 in C++, seit 1986 in C, seit 1983 in Assembler und seit 1982 in BASIC.
Und das sind bei weitem nicht alle Sprachen die ich beherrsche. Da wären noch Pascal, FORTH, REXX, Perl, PHP, Ada 95, BCPL, hauptsächlich.

Ach ja: Und meine ersten Versuche im Compilerbau habe ich 1989 mit C und BCPL gemacht. Damals gab's ja noch gar keine C++ Compiler (jedenfalls keine erschwinglichen).

volkard

Power Off schrieb:

Komisch, bei mir geht's.

template < class T >
void* X<T>::operator new( size_t siz, void* blk ) {
   printf( "hello from new, blk be %p\n", blk );
   return blk;
}

nee, das brauch ich nicht.
ich will schon normale ints und so bauen. der andere paremeter muß als template gehen, der allokator.

teste mal das:

#include <iostream>
using namespace std;

struct Foo{
	Foo(){
		throw 1;
	}
};

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

int main()
{
	try{
		new(5) Foo;
	}
	catch(int e){
		cout<<"error: "<<e<<'\n';
	}
	return 0;
}

Power Off

Bei

try{
		new(5) Foo;
	}

rufst Du nirgends einen Destruktor auf.

Sovok

Power Off schrieb:

Bei
try{
		new(5) Foo;
	}
rufst Du nirgends einen Destruktor auf.

ohne scheiss?

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!

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

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.

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.

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

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 !