vergesst C++ ...

[Power Off]

volkard schrieb:

was waren nochmal die repos beim gcc? war das nicht sowas? und der comeau, kann der nicht export?

Stimmt, der Comeau kann export. Da haben wir glaube ich, letztes Jahr schonmal drüber gesprochen. Sorry, das Alter ... sollte mich besser bald verrenten lassen.

Den GCC wollte ich mir auch mal richtig angucken, im Source usw., mir haben schon einige gesagt, ich soll doch dem GCC Projekt beitreten, anstatt einen eigenen Compiler zu schreiben (d.h. ich könnte ja dann meine Sprache als Frontend einbauen, oder C++ tatsächlich erweitern), aber bis jetzt hab ich mir noch nicht die Zeit dafür nehmen können oder wollen. Mal sehen ...

[volkard]

Power Off schrieb:

Stimmt, das ist eine coole Idee! Stell Dir mal vor, die Sprachdefinition wäre in einer Lib, oder noch besser, in einer Datenbank!

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

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. 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*).

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