vergesst C++ ...

volkard

Power Off schrieb:

Aber es ist nicht von der Hand zu weisen, daß eingebaute Features wie
- Strings
- Containerklassen wie Listen, Vektoren, Maps, etc.
- Array-Bounds-Checking (und Konfiguration)
sinnvolle Spracherweiterungen wären, die es dem Compiler ermöglichen würden, mehr zu optimieren als bei der Verwendung von Template-Klassen.

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.

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.

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.

Ich bin auch ein Verfechter einfacher Programmierschnittstellen.

ich nicht. was sind nochmal schnittstellen?

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

also garbage-collection, strings als sprachmittel, eingebaute container, whitespace-overloading, range-checking, optionale sockets, threads und gui als sprachmittel, reflection und objektpersistenz.

(Es gibt auch Compiler für Perl z.B., aber leider nicht für umme)

ein prog, das den perl-compiler und den code in eine exe-datei knallt? jo, hab ich schon benutzt.

Dein Beispiel würde in C++ ca. 100 Programmzeilen erfordern, weil man erst noch eine virtuelle Basisklasse und davon abgeleitete Spezialisierungen für double und string machen muß, bevor man das Zeug in eine Liste schieben kann. Das Problem ist, daß es bei Templates keine dynamische bzw. kontextabhängige Typisierung gibt.

D.h. ich kann nicht dieselbe Template-Instanz (von list z.B.) für zwei verschiedene Objekttypen benutzen, außer, die Objekttypen basieren auf derselben Basisklasse.

Da ist z.B. Java besser dran, da ausnahmslos alle Datentypen von der Klasse Object abgeleitet sind. Wenn das in C++ auch so wäre, könnte man Templates machen, die Object als Parameter haben.

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

maximAL

groovemaster schrieb:

maximAL schrieb:

gut, dass das noch kommt, nachdem man seitenlang alles getan hat um klar zu machen, das C++ eh alles kann, nur natürlich viel besser.

Ich wüsste nicht, dass das jemand getan hat, wobei ich nicht jeden Beitrag bis ins Detail gelesen habe.

oh doch, genau darum geht es hier.

und wer ernsthaft den standpunkt vertritt, dass C++ ein ebenso hohes abstraktionsniveau wie andere, höhere spachen hat (speziell python kenn ich nicht) und sich grundsätzlich alle probleme ebenso leicht lösen lassen (natürlich, mit lib xyz und wenn man weiss wie etc. pp. ist sowieso alles möglich), der hat entweder
- gar keinen plan
oder
- ein verflucht großes brett vorm kopf

absolut diskussionsunwürdiges thema.

kartoffelsack

O'Rakl schrieb:

Zeig' mal, wie Du die Liste
L=["hallo","python", 2.4, "ist cool"]
in C++ programmierst.

C/C++ Code:
char* sBuffer [] = { "hallo", "python", "2.4", "ist cool" };
C/C++ Code:
char* sBuffer [] = { "hallo", "python", "2.4", "ist cool" };

Der vorgeschlagene Code ist C, nicht c++!

#include <list>
#include <boost/assign/list_of.hpp> // for 'list_of()'
#include <boost/any.hpp>
#include <boost/variant.hpp>

using namespace std;
using namespace boost;
using namespace boost::assign; // bring 'list_of()' into scope

list<any> l = list_of( any( string("hallo")))
                     ( any( string("python")))
                     ( any(2.4))
                     ( any( string( "ist cool")));

Ich geb zu, ich hatte auch nicht erwartet, dass ich überall explizit string und any angeben muss, deswegen musst ich ein bisschen rumprobieren (habs in der Kombination noch nie benutzt (wann braucht man sowas in realen Projekten? Normalerweise nur in Tescode). Das wär in Python aufs erste mal schneller gegangen. Punkt ist aber, dass C++ mit Bibliothen dieselbe Ausdruckskraft erreicht, wie andere Sprachen über eingebaute Sachen. Und da man nicht alles einbauen kann ist C++ mE ausdrucksstärker. Dass das nicht so schnell zu haben ist, hat keiner bestritten.

Sovok

maximAL schrieb:

und wer ernsthaft den standpunkt vertritt, dass C++ ein ebenso hohes abstraktionsniveau wie andere, höhere spachen hat (speziell python kenn ich nicht) und sich grundsätzlich alle probleme ebenso leicht lösen lassen (natürlich, mit lib xyz und wenn man weiss wie etc. pp. ist sowieso alles möglich), der hat entweder
- gar keinen plan
oder
- ein verflucht großes brett vorm kopf

absolut diskussionsunwürdiges thema.

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

abgesehn davon hängts vom problem ab welche sprache am geeignetsten is... der rest is unnütze verallgemeinerung

Sovok

kartoffelsack schrieb:

O'Rakl schrieb:

Zeig' mal, wie Du die Liste
L=["hallo","python", 2.4, "ist cool"]
in C++ programmierst.

C/C++ Code:
char* sBuffer [] = { "hallo", "python", "2.4", "ist cool" };
C/C++ Code:
char* sBuffer [] = { "hallo", "python", "2.4", "ist cool" };

Der vorgeschlagene Code ist C, nicht c++!
#include <list>
#include <boost/assign/list_of.hpp> // for 'list_of()'
#include <boost/any.hpp>
#include <boost/variant.hpp>

using namespace std;
using namespace boost;
using namespace boost::assign; // bring 'list_of()' into scope

list<any> l = list_of( any( string("hallo")))
                     ( any( string("python")))
                     ( any(2.4))
                     ( any( string( "ist cool")));
Ich geb zu, ich hatte auch nicht erwartet, dass ich überall explizit string und any angeben muss, deswegen musst ich ein bisschen rumprobieren (habs in der Kombination noch nie benutzt (wann braucht man sowas in realen Projekten? Normalerweise nur in Tescode). Das wär in Python aufs erste mal schneller gegangen. Punkt ist aber, dass C++ mit Bibliothen dieselbe Ausdruckskraft erreicht, wie andere Sprachen über eingebaute Sachen. Und da man nicht alles einbauen kann ist C++ mE ausdrucksstärker. Dass das nicht so schnell zu haben ist, hat keiner bestritten.

die c syntax gehört zu c++ und somit is es standard c++ code
dein boost zeug hingegen gehört ( noch? ) nich zum standard

sonst könnt ich ja auch mit irgendwelchen m$ variant datentypen ankommen

kartoffelsack

Dein Beispiel würde in C++ ca. 100 Programmzeilen erfordern, weil man erst noch eine virtuelle Basisklasse und davon abgeleitete Spezialisierungen für double und string machen muß, bevor man das Zeug in eine Liste schieben kann. Das Problem ist, daß es bei Templates keine dynamische bzw. kontextabhängige Typisierung gibt.

D.h. ich kann nicht dieselbe Template-Instanz (von list z.B.) für zwei verschiedene Objekttypen benutzen, außer, die Objekttypen basieren auf derselben Basisklasse.

völlig falsch. s.o.

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

was meinst Du damit?

und wer ernsthaft den standpunkt vertritt, dass C++ ein ebenso hohes abstraktionsniveau wie andere, höhere spachen hat (speziell python kenn ich nicht) und sich grundsätzlich alle probleme ebenso leicht lösen lassen (natürlich, mit lib xyz und wenn man weiss wie etc. pp. ist sowieso alles möglich), der hat entweder
- gar keinen plan
oder
- ein verflucht großes brett vorm ko

Behaupte ich. Unterstützt sogar höhere Abstraktionsschema also so manche andere Sprachen (policy-based-Design, z.B.). 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. Gleichzeitig aber auch so mächtig. Du hast den ganzen Platz, nicht nur ne Strecke mit Bande. Deswegen ist C++ auch eine Sprache die sich für (fast) alles eignet (wenn man jetzt von ganz anderen Ansätzen wie funktionalem Programmieren etc. absieht).

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

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 ) {
   // ...
}