Was würdet ihr an C++ verbessern?

rüdiger

Als erstes würde ich die Syntax komplett ändern. Die Sprache sollte einfach parsbar sein und zwar für Menschen und Maschinen. C++ ist extrem schwer zu parsen und das hat dafür gesorgt, dass es leider bei den Tools gegenüber anderen Sprachen zurück hängt. Vielleicht ändert sich dies jetzt, wenn man mit Clang ein sauber getrenntes Frontend hat. Zumindest sollte man Trigraphs komplett entfernen. Die machen das Parsen derzeit für alle extra schwierig und dabei benutzt die doch keiner mehr (außer vielleicht irgend ein paar eingestaubte IBM Mainfraimler. Aber die werden wohl eh keinen aktuellen C++0x Compiler haben). Idealerweise wäre natürlich ein Parser direkt ein Bestandteil der Standardbib.

Ein Modulsystem wäre wirklich praktisch. Das include-Zeugs macht das kompilieren unnötig langsam und ist eine unnötige Fehlerquelle.

Viele Dinge explicit machen und lieber ein implicit einfügen. Automatische Generierung von Copyctor/operator würde ich auch rausnehmen. Man könnte lieber explizit sagen, dass das generiert werden soll.

Das Typsystem sollte strikter sein und idealerweise ähnlicher zu ADA als zu C. Design-by-Contract wäre vielleicht auch interessant. Oh und Concepts würde ich gerne haben.

Michael E. schrieb:

Regex-Literale. Reguläre Ausdrücke sind sowieso schon schwer zu lesen, da will ich nicht noch jedes zweite Symbol escapen müssen.

User-defined-Literals haben sie wohl wieder abgeschafft :(.

Also bei Properties sehe ich ehrlich gesagt den großen Vorteil gegenüber normalen Gettern und Settern nicht.

? Auch im Hinblick auf Kommentare (oben 3x nötig, unten 1x, etc.)?

Wozu sind bei deinem Beispiel Kommentare nötig? Wenn es reine Getter und Setter sind braucht man sie nicht, wenn sie etwas mehr machen, braucht man die Kommentare in jedem Fall, egal ob C#-Getter/Setter oder normale C++ Methoden.

Viele von den hier gewünschten Features kommen auch mit C++0x, z.B. Dateisystem, Raw-Strings, Threads, etc..
Es geht also auf jeden Fall in die richtige Richtung.

-Eigene operatoren hinzufügen können

Das wäre wirklich sehr schick! Das würde die Entwicklung von EDSLs enorm erleichtern.

ipsec

Vorteil der Properties: Lesbarkeit. Ich gebe zu, kein großer Vorteil, aber warum sollte man es verbieten? Was sind die Nachteile?

Ich bin aber gegen eigene Operatoren. Ich sehe da den Trend, dass man dann auf normale Methoden komplett zu verzichten versucht und erstmal schaut, ob nicht irgendeine Sonderzeichenkombination entfernt auch den Zweck ausdrücken könnte. Außerdem läst sich sowas schwer mit generischem Code vereinen.
Hinzu kommen sehr große Parseschwierigkeiten. Vor allem, wenn die eigenen Operatoren noch eigene Prioritäten o.ä. haben sollen.
Außerdem gibt es da ein nicht unerhebliches Risiko, durch einen neuen Operator bestehenden Code zu invalidieren. Nicht selten kommen ja auch z.B. Sachen wie if(!*x) vor, wenn dann plötzlich jemand einen !* -Operator definiert, hat man im besten Fall einen Compilefehler, im schlimmsten Fall kompiliert das noch und ist ganz schwer zu finden.

freaky

Michael E. schrieb:

Hast du dein Beispiel mal ausprobiert?

Ja, funktioniert, wieso?

Artchi

rüdiger schrieb:

Als erstes würde ich die Syntax komplett ändern. Die Sprache sollte einfach parsbar sein und zwar für Menschen und Maschinen. C++ ist extrem schwer zu parsen und das hat dafür gesorgt, dass es leider bei den Tools gegenüber anderen Sprachen zurück hängt. Vielleicht ändert sich dies jetzt, wenn man mit Clang ein sauber getrenntes Frontend hat. Zumindest sollte man Trigraphs komplett entfernen. Die machen das Parsen derzeit für alle extra schwierig und dabei benutzt die doch keiner mehr (außer vielleicht irgend ein paar eingestaubte IBM Mainfraimler. Aber die werden wohl eh keinen aktuellen C++0x Compiler haben). Idealerweise wäre natürlich ein Parser direkt ein Bestandteil der Standardbib.

Ich hatte mal einen Blog von einem C++-Komitee-Mitglied gelesen. (Frag mich nicht wo) Der meinte sinngemäß, das nur Leute die keinen C++-Compiler entwickeln, der Meinung sind, das ein C++-Parser schwer zu implementieren ist. Und das dieser Mythos ihm ziemlich auf den Senkel geht, weil diese Forderung komischerweise nur von den Leuten kommt, die keinen C++-Compiler entwickeln müssen.

Was die Tools angeht: das Problem hat MS mit MSVC2010 schon lange gelöst! Vorher gab es ein separates Tool für IntelliSense. Jetzt liefert der MSVC2010-Compiler die Infos für IntelliSense, und scheint ja jetzt auch super zu funktionieren. MSVC2010 zeigt einem sogar bei der Codeeingabe on-the-fly Compilefehler an, ohne das man einen Compile-Vorgang starten muß.

D.h. der Weg war nur falsch. Das Parsen und Analyse des C++ Codes macht jeder C++ Compiler mit links.

Michael E.

FreakY<3Cpp schrieb:

Michael E. schrieb:

Hast du dein Beispiel mal ausprobiert?

Ja, funktioniert, wieso?

CSharp foo = new CSharp();
foo.PZahl = 1;
Console.WriteLine(foo.PZahl);

volkard

ipsec schrieb:

Vorteil der Properties: Lesbarkeit. Ich gebe zu, kein großer Vorteil, aber warum sollte man es verbieten? Was sind die Nachteile?

Kompliziertheit über Kompliziertheit. Kann man von einem Property die Adresse ziehen? Oder eine Referenz? Was macht der Operator+=? Was macht ein property, wenn es zu bool ausgewertet werden soll? Was macht std::forward damit? Können properties virtuell und pur virtuell sein? Was ergeben sizeof und decltype?

Properties brauche ich nur, um meine Klassen so zu bauen, daß sie sich wie Microsoft-Klassen anfühlen. Stört es, vec.size() statt vec.size zu schreiben?

freaky

Michael E. schrieb:

FreakY<3Cpp schrieb:

Michael E. schrieb:

Hast du dein Beispiel mal ausprobiert?

Ja, funktioniert, wieso?
CSharp foo = new CSharp();
foo.PZahl = 1;
Console.WriteLine(foo.PZahl);

So sieht mein Programm ebenfalls aus, wo ist das Problem? Kommt wie erwartet 25 raus.

Ja, funktioniert, wieso?

Aber sicherlich nicht so wie er sich das vorgestellt hat.

Ich sehe da den Trend, dass man dann auf normale Methoden komplett zu verzichten versucht und erstmal schaut, ob nicht irgendeine Sonderzeichenkombination entfernt auch den Zweck ausdrücken könnte.

Wie kannst du einen Trend sehen, wenn eigene Operatoren nicht einmal erlaubt sind.

Außerdem läst sich sowas schwer mit generischem Code vereinen.

Warum das? Template-Argument-Deduction könnte doch auch wunderbar für eigene Operatoren funktionieren.

Hinzu kommen sehr große Parseschwierigkeiten. Vor allem, wenn die eigenen Operatoren noch eigene Prioritäten o.ä. haben sollen.

Das klingt alles so, als hättest du das schon implementiert. Ob der Operator + jetzt Built-In oder User-Defined ist, sollte doch keinen allzu großen Unterschied machen.

Außerdem gibt es da ein nicht unerhebliches Risiko, durch einen neuen Operator bestehenden Code zu invalidieren. Nicht selten kommen ja auch z.B. Sachen wie if(!*x) vor, wenn dann plötzlich jemand einen !*-Operator definiert, hat man im besten Fall einen Compilefehler, im schlimmsten Fall kompiliert das noch und ist ganz schwer zu finden.

Ich dachte im Thread ginge es darum sich erstmal nicht um Abwärtskompatibilität zu kümmern.

Dass eigene Operatoren wunderbar funktionieren zeigt übrigens Haskell.

Michael E.

FreakY<3Cpp schrieb:

Michael E. schrieb:
FreakY<3Cpp schrieb:

Michael E. schrieb:

Hast du dein Beispiel mal ausprobiert?

Ja, funktioniert, wieso?
CSharp foo = new CSharp();
foo.PZahl = 1;
Console.WriteLine(foo.PZahl);
So sieht mein Programm ebenfalls aus, wo ist das Problem? Kommt wie erwartet 25 raus.

Wenn das beabsichtigt war, nehm ich alles zurück.

SideWinder

Wenn wir schon dabei sind:
- Named arguments können manchmal ganz nett sein
- Partial classes
- Schön finde ich auch das in .NET mögliche LINQ, kann aber sein, dass es da ähnliches mit vielen spitzen Klammern und Boost gibt
- Collection-Initializer kommen ja jetzt mit 0x oder?
- Evtl Extension Methods ... was haltet ihr davon?

Ist natürlich vieles aus C# abgeleitet. Ich mag die Syntax von C# schon sehr, zum .NET-Framework habe ich eine andere Einstellung, aber C# als Sprache finde ich sehr fein.

MfG SideWinder

volkard

SideWinder schrieb:

Wenn wir schon dabei sind:
- Named arguments können manchmal ganz nett sein
- Partial classes

Jup.

Matzer

rüdiger schrieb:

User-defined-Literals haben sie wohl wieder abgeschafft

Ich konnte jetzt nur dies finden:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3250.html

Ist das bereits abgesegnet worden? Wäre schade drum...

SideWinder

Wenn man sich den Link von Matzer durchliest muss man am aber an C++ zu zweifeln beginnen. Die Gründe sind ja lächerlich. Nach 10 Jahren Entwicklung sollte man doch feststellen lassen können ob so etwas möglich ist oder nicht. Im Notfall sollte es zumindest eine Art @I can escape here@ geben, oder?

MfG SideWinder

this-*gt*that

SideWinder schrieb:

Ist natürlich vieles aus C# abgeleitet. Ich mag die Syntax von C# schon sehr, zum .NET-Framework habe ich eine andere Einstellung, aber C# als Sprache finde ich sehr fein.

MfG SideWinder

Dem kann ich nur zustimmen. C# ist die schoenste Programmiersprache, mit der ich bis jetzt gearbeitet habe. Und ich habe mit vielen gearbeitet...

Mit C# arbeiten war fuer mich immer traumhaft. Schoene Syntax, zahlreiche schoen implementierte Features wie Delegates, Events, Properties, Indexer, einfache Operatorueberladung, dazu die Streichung ein paar der ekligsten C++ "Features" wie Header und zusaetzlich noch die gigantische .NET Klassenbibliothek, schoende GUI Toolkits und eine grandiose IDE.

Fuer mich ist C# das huebsche Kind von C++ und Java.

rüdiger

Artchi schrieb:

Ich hatte mal einen Blog von einem C++-Komitee-Mitglied gelesen. (Frag mich nicht wo) Der meinte sinngemäß, das nur Leute die keinen C++-Compiler entwickeln, der Meinung sind, das ein C++-Parser schwer zu implementieren ist. Und das dieser Mythos ihm ziemlich auf den Senkel geht, weil diese Forderung komischerweise nur von den Leuten kommt, die keinen C++-Compiler entwickeln müssen.

Die Clang-Leute haben recht lange für ihr C++-Frontend gebraucht. Ich glaube das Projekt ist von 2007 und sie sind erst ende letzten Jahres damit fertig geworden. Das C und Objective C Frontend hatten sie dagegen schon nach ein paar Monaten. Hoffentlich gibt das den Ansporn für ein paar schöne Tools und damit meine ich mehr als nur Vervollständigung im Editor . Refactoring, Static analysis und was man sonst noch so alles schönes machen kann.

Ich mag die Syntax von C# schon sehr

Inwiefern unterscheidet sich die C# Syntax großartig von der C++ Syntax?

zahlreiche schoen implementierte Features wie Delegates, Events, Properties, Indexer

Interessant, genau das sind Features, die mir an C# nicht gefallen, da sie die Sprache meiner Meinung nach aufblähen. Auch werde ich wohl nie verstehen, warum sie keine freien Funktionen erlauben. Immer "public static" vor eine Funktion schreiben zu müssen, nervt...
Aber für GUIs ist C# natürlich erste Wahl, zumindest wenn man für Windows programmiert.

Bashar

this->that schrieb:

Dem kann ich nur zustimmen. C# ist die schoenste Programmiersprache, mit der ich bis jetzt gearbeitet habe. Und ich habe mit vielen gearbeitet...

Schön würde ich sie nicht gerade nennen. C# ist eine typische Microsoft-Sprache, nicht zu vergleichen mit VB, aber man merkt es schon irgendwo. Die Macher haben relativ wenig Hemmungen, an der Sprache herumzuschrauben und die Sprache mit der Library zu verheiraten. Beispiel 1: Die foreach-Schleife funktioniert mit allem, was IEnumerable oder IEnumerable<> implementiert (warum brauchen wir nicht-generische Aufzählungen? Historische Gründe!). Soweit so gut. Beispiel 2: Dictionary-Initialisierer wie

Dictionary<string, int> bla = new Dictionary<string, int> {
  // ruft nach dem Konstruieren bla.Add("hallo", 42)
  // und bla.Add("welt", 1729) auf  
  {"hallo", 42}, {"welt", 1729} 
};

funktionieren mit allem, was IEnumerable<> (ob auch IEnumerable weiß ich grade nicht) anbietet und eine Add-Methode für zwei Argumente hat. Warum? Weil sie die Library durchforstet haben und festgestellt haben, dass die üblichen eigentlich vorgesehenen Interfaces in der Regel nicht implementiert werden. Add mit 2 Parametern gibt es bei allen Dictionaries. Und bei mathematischen Klassen . Also noch die IEnumerable-Bedingung dazu genommen, jetzt passt es.

Das ist so ein übler Hack, in der C++-Standardisierungsgruppe würde man solche Vorschläge wohl als Aprilscherz auffassen. Aus Anwendersicht ist das momentan noch angenehm zu benutzen, aber das geht auch nur solange gut, bis sich die Features irgendwann mal gegenseitig auf die Füße fallen.

ipsec

Ich finde ja C# vom Grundsatz her auch nicht schlecht (arbeite auch zur Zeit damit), aber C++ finde ich in vielen Punkten schöner.

Vieles, was mich an C# stört, ist auch nicht direkt auf die Syntax zurückzuführen. Z.B. verstehe ich bis heute nicht, warum keine Defaultwerte für Parameter zulässig sind. So hätte ich schon in einigen Fällen z.B. viele Konstruktoren auf einen schrumpfen können. Auch hätte ich ganz gerne implizite Konstruktoren. Oft schreibt man sowas wie new A(new B("foo"), new C("bar")) , was auch schöner new A("foo", "bar") sein könnte. Das ist unter anderem ein Grund, warum mit C# nicht mal annähernd so expressive APIs wie mit C++ möglich sind.

Und auch viele Punkte, die ihr hier als besonders schön darstellt, finde ich bei C++ besser: Delegates sind std::function weit unterlegen, ebenso Events boost::signal2 und mir ist schleierhaft, warum es statt der Indexer kein []-Operator sein konnte. Auch fehlen mir manchmal echte Referenzen oder Zeiger (die Datenmember sein können), während auf der anderen Seite durch Referenztypen, kaum const-Unterstützung und über object viele Interfaces verweichtlich werden*. Interfaces selbst sind dann auch wieder ein Thema für sich.

Warum hat eigentlich jede Klasse von Object GetHash() und ToString() geerbt? Gerade bei GetHash() drängt sich mir der Eindruck auf, das wurde nur genommen, damit alle Objekte in Hash-Container passen. Ich habe diese Methode bisher bei keiner meiner Klassen überschrieben. Die Folge: die Objekte passen (wenn es doch mal jemand versucht), aber es passiert absoluter Müll. Das kann doch nicht das wahre sein, tatsächlich gibt es aber keine andere Möglichkeit in C#, außer über eine Schnittstelle IHashable. Wobei ich das sogar noch bevorzugen würde.

* ein Beispiel ist z.B. Thread . Eine eigentlich einfache und auch häufig gebrauchte Aufgabe: man möchte einen Thread mit einem Parameter starten. In C++ kein Problem:

thread_data d;
thread t(bind(foo, d));

In C#:

ThreadData d = new ThreadData();
Thread t = new Thread(new ParameterizedThreadStart(foo)); // Die Syntax ist so umständlich, dass man bei Delegates per Spracherweiterung den Typ weglassen könnte. Bei allen anderen Typen kann man es aber nicht.
t.Start(d);  // Übergabe typunsafe als Objekt. Außerdem könnte ich genauso gut die parameterlose Start-Methode aufrufen, das wird höchstens zur Laufzeit geprüft

SideWinder

Bashar schrieb:

Die foreach-Schleife funktioniert mit allem, was IEnumerable oder IEnumerable<> implementiert (warum brauchen wir nicht-generische Aufzählungen? Historische Gründe!).

Solange das auch für Arrays funktioniert ist die Idee doch nicht übel. Es geht wohl hier nicht um das "Verheiraten" mit der Library. Aber in einer imperativen OOP-Sprache ist es nicht übel auf ein paar "Grund-Interfaces" und "Grund-Klassen" (wie Object) vertrauen zu können. BOOST_FOREACH funktioniert ja auch "für STL-Container und alles was danach aussieht". Ob es da nicht schön wäre "alles was danach aussieht" als Interface klar definiert aufgezählt zu sehen?

Bashar schrieb:

Aus Anwendersicht ist das momentan noch angenehm zu benutzen, aber das geht auch nur solange gut, bis sich die Features irgendwann mal gegenseitig auf die Füße fallen.

Ich glaube eine Sprache die dem Programmierer möglichst weit entgegen kommt und ihm möglichst gut unterstützt in seiner Arbeit ist eine gute Sprache.

ipsec schrieb:

verstehe ich bis heute nicht, warum keine Defaultwerte für Parameter zulässig sind.

AFAIK ist das mit C# 4.0 gekommen, oder? Programmiere aber gerade Haskell und nicht C#

Implizite Typumwandlungen sind halt immer so eine Sache. Das kann auch furchtbar schief gehen und führt sehr schnell zu mehrdeutigen Aufrufen wo keine sein müssten. Klar könnte man dann noch als Programmierer etwas "verexplizitieren"...hmm

Inwiefern sind Delegates std::function und Events boost::signal unterlegen?

Die const-correctness könnte in der Tat noch verbessert werden. Irgendwie wurde da auch in Java vollkommen versagt. Das sollte dringend nachgeholt werden.

Warum man Object in den Sprachen so gerne zumüllt weiß ich leider auch nicht. Auch in Java ist das Phänomen gegenwärtig.

MfG SideWinder