vergesst C++ ...

[Power Off]

volkard schrieb:

doch, klar. ich weise es hiermit von der hand.
einbauen von strings bringt doch mal wirklich gar nix.
containerklassen? wozu als sprachmittel?
array-bounds-checking haben wir doch bereits.

Die Krux mit der STL ist, daß jedesmal ein Haufen Code im Benutzerprogramm landet, wo er eigentlich nix zu suchen hat. Das ist natürlich nicht die Schuld der Sprache C++, sondern der Compilerhersteller, die z.B. keine Lib mit häufig benutzten Template-Instanzen anbieten. Statt dessen wird meist der Code als inline-Code definiert und landet damit im Objekt-Modul. Ist zudem noch inlining ausgeschaltet, dumpt der Compiler den gesamten Template-Code ins Objektmodul. Durch "inline" wird auch die Lokalität aufs Objektmodul beschränkt, wodurch der Linker Duplikate nicht entfernen kann. Deswegen sind auch viele C++ Programme so groß.

Das ist mega-idiotisch, und hätte schon längst mal geändert werden müssen.

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

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.

volkard schrieb:

Power Off schrieb:

Für die vielen Ideen, die ich für C++ hatte, muß ich irgendwann mal einen Referenz-C++ Compiler schreiben, damit ich die Vorzüge davon demonstrieren kann.

ja, mach das mal.

Ja, werd ich vielleicht auch irgendwann.

Ich hab schon etliche Compiler geschrieben. Compilerbau gehört schon seit 1989 zu meinen Spezialgebieten.

volkard schrieb:

Power Off schrieb:

Die bloße Tipparbeit kann sich nämlich schnell summieren, und man hält sich mit endloser Tipperei auf; Ich verwende oft "typedef", um Aliase für Template-Instanzen zu definieren, damit ich weniger tippen muß.

eih, das ist ne tolle idee. daß ich da nicht von alleine drauf gekommen bin! uih uih uih.

Das war nicht als "tolle Idee" gemeint, sondern bloß um zu sagen, was man machen muß, um sich etwas Tipperei zu ersparen. Tipperei, die's in anderen Sprachen gar nicht gibt. Also, da muß ich O'Rakl schon recht geben.

volkard schrieb:

Power Off schrieb:

Ich bin auch ein Verfechter einfacher Programmierschnittstellen.

ich nicht. was sind nochmal schnittstellen?

Eine Programmiersprache ist auch eine Programmierschnittstelle, ein Mensch-Maschine Interface.

volkard schrieb:

wirst bestimmt ne lib im netz finden, die dir wie in java auch Int und Double (beide erben von Object) anbietet.

Ja, aber wer macht das schon? Das ist m.E. z.B. ein eklatanter Fehler im aktuellen C++ Standard, daß keine Wrapper für Basistypen vorgesehen sind.

[kartoffelsack]

dein boost zeug hingegen gehört ( noch? ) nich zum standard

boost muss auch nicht zum Standard gehören. Boost ist eine Bibliothek, die sich mit jedem ausreichend standardkonformen Compiler (und das sind inzwischen alle neueren) übersetzen lässt. Die Winapi kannst Du nicht überall verwenden.

Dein Beispiel war insofern irrelevant, weil es gezeigt hat, dass das was Oracel will in C nicht geht. Zumindest nicht so, wie er's will. Und in C++ gehts eben. Nur nicht mit den C-Sprachmitteln

[:idee:]

vergesst Power Off!

[maximAL]

Sovok schrieb:

nö ich mag c/c++ besonders weil keine andere sprache lowlvl und highlvl so gut verknüpft und dem entwickler überlässt wie abstrakt oder hardwarenah er arbeiten will

kartoffelsack schrieb:

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.

angst davor, mehrere sprachen für unterschiedliche zwecke zu lernen?

[kartoffelsack]

angst davor, mehrere sprachen für unterschiedliche zwecke zu lernen?

nö. Nur seit langem keine Zeit. Aber was ist das jetzt. Erst: Python, Java etc. ist viel besser als C++. Jetzt: Wenn man ein anderes abstraktionsniveau braucht, soll man ne andere Sprache lernen? In C++ hab ich halt alles schon. Das soll einen nicht davor bewahren über den Tellerrand zu gucken. Aber man kann das doch als Vorteil sehen.
T

Ja, aber wer macht das schon? Das ist m.E. z.B. ein eklatanter Fehler im aktuellen C++ Standard, daß keine Wrapper für Basistypen vorgesehen sind.

Wofür bitte???

Außerdem: Wrapper für Basistypen

struct BaseType
{
  virtual ~BaseTypeWrapper=0{};
};

template <typename T> struct BaseTypeWrapper
:public BaseType
{
  BaseTypeWrapper( T t)
  :t_(t)
  {};

  BaseTypeWrapper& operator=(T t)
  {
    t_ = t;
    return *this;
  }

  operator T()
  {
    return t_;
  }

  bool operator<( T t)
  {
    return t_ < t;
  }

};

Das ist ein schönes Beispiel für die Ausdrucksstärke von C++. Im Gegensatz zu Java-Wrapper-Klassen verhält sich das Ding auch so, wie der entsprechende Basis-Typ. Klar, könnte bei der STL dabei sein. Wüsste aber wirklich nicht, wofür man das braucht. Der Grund, warum man das in Java braucht entfällt in C++ wegen der Templates. In C++ heißt es 'do it like the int' in Java wird das 'int' gewrappt, damit es sich wie ein Objekt benimmt. Hat beides seine Vor- und Nachteile. Aber: 'do it like the int' geht nicht in Java. In C kann ich durchaus alles von einem Objekt Ableiten und nur mit Referenzen darauf arbeiten. Und: das Wrappen in Java hat einen technischen, das int-Paradigma in C++ einen inhaltlichen Ursprung. Wo ist da also die höhere Abstraktion?

[volkard]

Power Off schrieb:

Die Krux mit der STL ist, daß jedesmal ein Haufen Code im Benutzerprogramm landet, wo er eigentlich nix zu suchen hat.

bist du sicher, daß wie das selbe C++ meinen? ich sehe das problem eigentlich als gelöst an. und selbst wenn es noch wäre, wäre es kein wesentlicher punkt.

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];

was soll denn dieser schrott? rohe arrays anzufassen ist in c++ doch töricht. genauso wie rohe zeiger auf selber gezogenen freispeicher. das macht keiner außer den paar leuten, die bibliotheken bauen. also wozu willste hier die sprache ändern?

template<typename T,size_t size>
class Array{
   T data[size];
public:
   T& operator[](size_t index){
      assert(index<size);
      return data[indes];
   }
   T const& operator[](size_t index) const{
      assert(index<size);
      return data[indes];
   }
};

und fertig ist der lack. hast du sowas noch nie gesehen? und dafür willste ein sprachmittel? geh doch mit ner anderen sprache spielen.

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

für die masse der anwendungen tut's hier enum. für die paar anderen kann man sich in c++ bei zero performance overhead so ne klasse bauen. es muß nicht in die sprache rein wie bei anderen sprachen, weil es in c++ keine laufzeit kostet, es selber reinzumachen oder ne lib zu nehmen.

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.

hä??? unfug.

Ich hab schon etliche Compiler geschrieben. Compilerbau gehört schon seit 1989 zu meinen Spezialgebieten.

glaub ich nicht. du redest daher wie ein unwissender.

volkard schrieb:

wirst bestimmt ne lib im netz finden, die dir wie in java auch Int und Double (beide erben von Object) anbietet.

Ja, aber wer macht das schon? Das ist m.E. z.B. ein eklatanter Fehler im aktuellen C++ Standard, daß keine Wrapper für Basistypen vorgesehen sind.

kein fehler. man soll in c++ anders programmieren, also wie man das in java machen tut.

[Power Off]

kartoffelsack schrieb:

Power Off schrieb:

Auch ist es nicht möglich, z.B. benutzerdefinierte Notationen zu machen.

was meinst Du damit?

__token {
  __regexp(/0[bB][0-1]+/); 
} binary_constant;
__notation {
  __patch(add,integral_constant_expr);
  binary_constant;
} ;
__token {
  "valof";
} valof_token;
__notation(valof_expr) {
  __patch(add,base_expr);
  valof_token base_type instruction_block;
  __semantics(function_body);
  __generate(basetype_expr);
}

// Anwendung

int a = 0B11101;

int b = valof int {
   int j = superfunc(a,123);
   return j * 127;
}

So in der Art!

Das hab ich mir jetzt aus den Fingern gesaugt, aber so was ähnliches.

Wenn man neue Arten von Konstruktoren beispielsweise machen könnte, oder so, wäre einiges einfacher.

Außerdem bräuchte man mit einem solchen Feature nicht für jeden Kack extra einen eigenen Compiler zu schreiben.

[Power Off]

volkard schrieb:

bist du sicher, daß wie das selbe C++ meinen? ich sehe das problem eigentlich als gelöst an. und selbst wenn es noch wäre, wäre es kein wesentlicher punkt.

Das denkst aber auch bloß Du.

Guck mal in den Code, den Dein toller Compiler erzeugt. Guck ihn Dir an!

Hol schon mal das Prozessorbuch aus dem Schrank.

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.

(Außer Visual Age for C++ 3.5, da gab es einen Intermediate-Linker, der zuviel erzeugten Template-Code reduzieren konnte, allerdings konnte man dann keinen Standard-Code schreiben, man mußte sich an eine bestimmte Syntax halten)

[volkard]

Power Off schrieb:

Das hab ich mir jetzt aus den Fingern gesaugt, aber so was ähnliches.

wann haste das letzte mal ein buch über forth gelesen? die machen recht elegant spracherweiterungen und können die auch zur compilzeit benutzten.

Wenn man neue Arten von Konstruktoren beispielsweise machen könnte, oder so, wäre einiges einfacher.

jo. man bräuchte nich viel weniger builtins. insbesondere so sachen wie for, while, do, else, switch könnten alle in ner lib stehen.

meine forschungen in der reichtung führen mich immer wieder dahin, daß man dann von der zielsprache leichte abstriche machen müßte, und schwupps, bin ich bei lisp. das gibts aber schon, stelle ich dann fest, und höre auf.

[volkard]

Power Off schrieb:

Ich programmier zwar erst seit 1993, also bloß 12 Jahre in C++

warum lasse ich mich mit nubes auch immer wieder auf diskussionen ein?

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

[Power Off]

volkard schrieb:

wann haste das letzte mal ein buch über forth gelesen? die machen recht elegant spracherweiterungen und können die auch zur compilzeit benutzten.

So toll ist FORTH auch wieder nicht, was das betrifft. Man macht ein FORTH Word, evtl. mit COMPILES .. DOES und das war's dann schon. Ändert nix an der Tatsache, daß FORTH z.B. stackbasiert ist. Natürlich kann man in FORTH auch Worte definieren, die direkt Assembler-Code abbilden, dann wird's durchaus interessant. Das ändert aber nix an der Art und Weise wie ein FORTH-System intern funktioniert. Du kannst es drehen und wenden, aber es ist immer noch FORTH.

Ich hab mal aus Jux einen FORTH-Compiler über Nacht geschrieben mit passenden Libraries für AmigaOS.

Ich hab mir auch mal den aktuellen FORTH Standard gekauft, der hat aber über 1000 Seiten, das war mir dann doch zu viel, alles durchzulesen. Da kommt einem dann C++ ziemlich mickrig vor.

volkard schrieb:

jo. man bräuchte nich viel weniger builtins. insbesondere so sachen wie for, while, do, else, switch könnten alle in ner lib stehen.

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

volkard schrieb:

meine forschungen in der reichtung führen mich immer wieder dahin, daß man dann von der zielsprache leichte abstriche machen müßte, und schwupps, bin ich bei lisp. das gibts aber schon, stelle ich dann fest, und höre auf.

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

REBOL geht übrigens auch in die Richtung, unterstützt aber GUIs etc.

Nee, mir ist der Code von REBOL und LISP irgendwie nicht lesbar genug.

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