vergesst C++ ...

[Power Off]

volkard schrieb:

datenbank natürlich. aber der standard sollte nur plain-text-formate definieren und die datenbanken sache der compilerbauer sein lassen.

Ja.

Was cool wäre, wäre eine integrierte Datenbank à la OS/400's TIMI (Datenbank und virtuelle Maschine in einem).

Überhaupt wäre es nicht schlecht, wenn man C++ und virtuelle Maschinen wieder in einem Satz nennen könnte, da hat sich ja seit BCPL nicht so viel getan. Micrsoft hat den Fehler gemacht, eine spezielle C++ Variante (Managed C++) für die CLR zu entwickeln.

C++ könnte man auch so erweitern, daß ein Standard-Datenbank-Interface definiert wird, das nicht auf calls basiert. Oder doch als Library. Wäre aber zumindest cool, und würde C++ wieder etwas Auftrieb geben!

volkard schrieb:

das ist das problem. wenn die sprachen mächtiger als c++ werden, werden sie auch unlesbarer. deswegen wäre meine idee, c++ nur ein wenig aufzupeppen. aber nicht mit sachen, die man mit wenigen tausend zeilen code auch selber in c++ bauen kann, ohne beim anwenden nachher komfort zu verlieren. ich wünsche mir zum beispiel ein ordentliches foreach (wie in visual basic *g*).

Vielleicht ginge es doch, lesbare Erweiterungen für C++ zu machen.

Aber wenn man den Namensraum nicht erweitern darf (also immer "_" oder "__" voranstellen muß), dann ist das zwar prinzipiell kompatibler, aber die Spracherweiterungen werden dann nie benutzt, weil sie im Source so komisch aussehen (könnte man natürlich durch ein Include-File oder eine Compiler-Option einfach lösen).

Aber "foreach" habe ich mir auch schon oft gewünscht!

Man könnte es natürlich auch so machen:

#include <vector>

using std::vector;

#define foreach(type,obj) for ( type::iterator __iter = (obj).begin(); __iter != (obj).end(); __iter++ ) 
#define foreach_c(type,obj) for ( type::const_iterator __iter = (obj).begin(): __iter != (obj).end(); __iter++ )

typedef vector<int> IntVector;

IntVector a;
a.push_back( 10 );
a.push_back( 20 );
a.push_back( 30 );

foreach ( IntVector, a ) {
   // ...
}

[volkard]

Power Off schrieb:

#define foreach(type,obj) for ( type::iterator __iter = (obj).begin(); __iter != (obj).end(); __iter++ )

mit dem typeof-operator vom gcc kann man sogar fast leben.
optimal wäre das auto-keyword.

und ich trenne mich erstmal vom gcc, weil der bug mit dem nichtaufgerufenen template-placement-delete mir zu fies ist.

[ness]

volkard schrieb:

und ich trenne mich erstmal vom gcc, weil der bug mit dem nichtaufgerufenen template-placement-delete mir zu fies ist.

Ich habe zwar eine ungefähre vorstellung, was du meinst, aber das ist mal eine kreation... Echt, dass darauf nicht schon längst jemand gestoßen ist

[Power Off]

volkard schrieb:

und ich trenne mich erstmal vom gcc, weil der bug mit dem nichtaufgerufenen template-placement-delete mir zu fies ist.

Komisch, bei mir geht's. Ich hab GCC 3.3.5 20050117 (prerelease) (SUSE Linux), also der, der bei SUSE Linux 9.3 dabei ist.

Hier mein Testprogramm:

#include <stdio.h>

char objbuf[1024];

template < class T >
class X {
   T dat;
   public:
   X( void );
   virtual ~X( void );
   void* operator new( size_t siz, void* blk );
   void operator delete( void* blk );
};

template < class T >
X<T>::X( void ) {
   printf( "hello from ctor\n" );
}

template < class T >
X<T>::~X( void ) { 
   printf( "hello from dtor\n" );
}

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

template < class T >
void X<T>::operator delete( void* blk ) {
   printf( "hello from delete, blk = %p\n", blk );
}

typedef X<int> XX;

int main( int argc, char** argv ) {

   {
      XX* xx = new(objbuf) XX();

      delete xx;
   }

   return 0;
}

Die Ausgabe davon ist:

hello from new, blk be 0x8049a20
hello from ctor
hello from dtor
hello from delete, blk = 0x8049a20

Allerdings hab ich's mit dem "g++" Frontend compiliert, mit "cc" kam ein Fehler beim Linken.

[DrGreenthumb]

[quote="volkard"]

Power Off schrieb:

Ugh, LISP!! Das ist doch nicht mehr lesbar, oder? (sorry, kenne LISP nicht besonders gut, aber ich wollte es mir schon lange mal richtig angucken, ich hab mal einige Sachen in der Richtung überflogen, war aber nicht besonders begeistert.)

das ist das problem. wenn die sprachen mächtiger als c++ werden, werden sie auch unlesbarer.

sehe ich nicht so. Was verstehst du denn unter mächtiger? Wie kann eine Sprache noch unlesbarer sein, als boostiges c++?

[O'Rakl]

<<In C++ kannst Du das Abstraktionsschema frei wählen von sehr niedrig bis sehr hoch. Das ist einer der Gründe, warum C++ so schwer ist.>>

Nein, C++ ist so schwer, weil es das Kunststück fertig bringt, die sehr
hardwarenahe Sprache C, die teilweise den PDP-11-Assembler direkt in Hochsprachenbefehle umsetzt (i++,++i,j--,--j,...), mit abstrakten Datentypen
zu verheiraten. Ich bewundere die Schöpfung von C++ daher. Benutzen
will ich es aber nicht mehr, solange es Alternativen gibt, zumal so überaus
elegante wie Python.

<<Gleichzeitig aber auch so mächtig>>

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.

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.

[Talla]

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?!?

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

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