Was würdet ihr an C++ verbessern?

ipsec

SideWinder schrieb:

ipsec schrieb:

SideWinder schrieb:

Darf man zusammenfassen, dass ihr eine Art syntaktisches C# mit Template-Metaprogrammierung und STL wünscht?

Auf keinen Fall! Die C#-Syntax finde ich teilweise nicht gelungen, in fast allen Fällen finde ich die C++-Alternative besser. Auch würde ich z.B. Properties syntaktisch nicht wie in C# umsetzen wollen.

Nun aber raus mit der Sprache, Beispiele, Beispiele, Beispiele. Bitte

MfG SideWinder

Ich will das hier nicht zu einem C#-Bash-Thread machen, nur mal ein Beispiel, was ich bei C++ besser finde: Zugriffsmodifizierer wirken sich auf alle nachfolgenden Elemente aus.

Bei sowas wie Networking in der Standardbibliothek sehe ich vor allem das Problem der Aktualisierung. Bei boost.asio z.B. werden auch heute noch Bugs gefixt. boost ist auch schnell mal aktualisiert, aber wie oft aktualisiert ihr eure Standardbibliothek? Bei den Containern und Algrithmen kann man nunmal nicht so viel falsch machen. Hinzu kommt, dass man dann jedesmal Jahre warten müsste, bis z.B. ein neues Netzwerkprotokoll in den Standard aufgenommen wurde, während andere Bibliotheken da viel flexibler sind.

Raw-Strings kommen übrigens mit C++0x.

CCodex

-Standard für socket
-Standard für ein filesystem
-Eigene operatoren hinzufügen können

Artchi

ipsec! Der Standard definiert ja nicht die Implementierung einer Bibliothek! Du kannst doch jeder Zeit ein Bugfix-Release einer C++-Std-Lib nutzen. Alle Compiler-Hersteller liefern Bugfixes aus, wenn in deren C++-Standard-Library ein Fehler auftritt. Außerdem müsste die Network-Lib keine Hi Level Protokolle definieren. Aber es wäre einfacher überhaupt Hi Level Protokolle zu implementieren, wenn die Std-Lib wenigstens Low-Level-Protokolle anbietet. Meines Wissens hat boost.asio eh keine Hi Level Protokolle.

Michael E.

FreakY<3Cpp schrieb:

Artchi schrieb:

SideWinder schrieb:

...

Hem, ist für mich echt ein konstruiertes Beispiel. Was ist, wenn neben dem reinen return und assignment noch was anderes passieren soll?
class CSharp
{
    private int zahl;
    public int PZahl
    {
        get
        {
            return zahl * 5;
        }
        set
        {
            zahl = value * 5;
        }
    }
}
Letztendlich werden Properties auch zu getter und setter, sehen meiner Ansicht nach aber besser aus.

Hast du dein Beispiel mal ausprobiert?

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.