Was würdet ihr an C++ verbessern?

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

Bashar

SideWinder schrieb:

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?

Ja. Immer das gleiche, man fängt mit einer kleinen, "sauberen" Sprache an, weist auf die Komplexität von C++ hin, aber dann baut man nach und nach alles rein, was man eigentlich mal absichtlich weggelassen hatte.

Programmiere aber gerade Haskell und nicht C#

C# hat Linq, das stillt ein bisschen den Hunger nach richtigen Programmiersprachen

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

Wieso versagt? Das ist ein Feature, dass man absichtlich nicht drin hat.

ipsec

Zu Delegates: die Bindung funktioniert nur an den aktuellen this-Zeiger, die Parameter müssen übereinstimmen. Mit bind kann ich alles aufrufen, was man callen kann, ich kann binden, was ich will, das Funktionsziel muss nicht die korrekten Parameter haben (die kann ich um-binden) usw.
Diese Vorteile in C++ übertragen sich dann natürlich auf Signale/Events. Brauchst du in jedem Event den Sender- oder den EventArg-Parameter? Warum musst du ihn dann immer hinschreiben? Du wolltest schonmal einen zusätzlichen Parameter an den Event-Delegaten übertragen? Tja, Pech. Da musst du dir wohl ne neue Klasse schreiben, die diesen Parameter aufnehmen kann und die Verarbeitung übernimmt.
bind ermöglicht sowas ohne jegliche Mehrkosten.

Davon abgesehen muss ich sagen, von LINQ bin ich ein bisschen begeistert. Mir ist bisher auch nicht eingefallen, wie man das genau so umfangreich in C++ nachbauen könnte.

GPC

Irgendwer schrieb:

Auch werde ich wohl nie verstehen, warum sie keine freien Funktionen erlauben. Immer "public static" vor eine Funktion schreiben zu müssen, nervt...

http://blogs.msdn.com/b/ericlippert/archive/2009/06/22/why-doesn-t-c-implement-top-level-methods.aspx

Bashar schrieb:

SideWinder schrieb:

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?

Ja. Immer das gleiche, man fängt mit einer kleinen, "sauberen" Sprache an, weist auf die Komplexität von C++ hin, aber dann baut man nach und nach alles rein, was man eigentlich mal absichtlich weggelassen hatte.

Die optionalen Parameter wurden eigentlich nur im Zuge von dynamic eingeführt. Das Hauptproblem war ja, dass C++ und VB6 optionale Parameter bieten und die beiden meistbenutzten Sprachen für COM sind. Dem entsprechend war es oft ziemlich ätzend, aus .NET COM anzusprechen, weil man auch optionale Parameter mitangeben musste. Das führte zu deutlich mehr Schreibaufwand. In dem Bereich ist man jetzt aus dem Schneider.
Für normalen .NET Code wird die Verwendung von optionalen-Parametern aber dennoch nicht empfohlen. Und zwar deshalb, weil der Defaultwert fest in den die Funktion aufrufenden Code kompiliert wird (verhält sich analog zum const-Schlüsselwort, darum benutzt man besser readonly).
Ich denke, dass gerade dieses Feature unglücklich umgesetzt ist und wirklich nur für Interop/COM benutzt werden sollte.

Oh, ach ja... C# ftw 111elf! :p

this->that schrieb:

+ Weg mit den Scheiss Headern

Einheitliches Format für libs, damit alle Compiler miteinander können.
Keine automatische Konvertierung int <-> bool...

Nexus

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.

Ich habe etwas mit Raw-Literalen ohne Escape-Sequenzen in Erinnerung... Ist das nicht mehr aktuell?

Bashar schrieb:

Wieso versagt? Das ist ein Feature, dass man absichtlich nicht drin hat.

Naja, mit final hat man es halbwegs drin, aber eben nicht konsequent. Ausserdem gibts Immutable-Klassen, es besteht also zumindest eine schwache Tendenz zur Const-Correctness. Nicht zuletzt hat man sich mit const als nutzloses reserviertes Schlüsselwort ein Hintertürchen offen gelassen

Bei const correctness weiß ich auch nicht, ob mir das schon jemals was gebracht hat und nen bug verhindert hat.

SideWinder

Und ich hab' nie verstanden wie man eine moderne Sprache noch ohne const-correctness ausliefern kann. Das ist also tatsächlich nicht universal als notwendig und super angesehen?

MfG SideWinder

Michael E.

Nexus schrieb:

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.

Ich habe etwas mit Raw-Literalen ohne Escape-Sequenzen in Erinnerung... Ist das nicht mehr aktuell?

Ehrlich gesagt wusste ich nicht, dass dieses Feature Thema für C++0x ist oder war. Es ist mir lediglich als erstes eingefallen

krümelkacker

Ich finde, die Entwicklung von C++98 nach C++0x überwiegend positiv. Mir fallen jetzt auch auf Anhieb nicht so viele Dinge ein, die mich da stören:

die Sonderregel bei Template-Argument-Deduktion bei P=T&&, wobei P der Funktionsparametertyp und T der Typparameter ist, für die Implementierung von "perfect forwarding". Das wird eine Sache, über die noch viele stolpern werden, schätze ich.
Lambdas: Das "Capturing" ist zu restriktiv (kein Move-Capture, Beschränkung auf Entitäten aus dem lokalen Scope) und es gibt keine Möglichkeit aus anonymer_lamda_object_typ::operator() ein Template zu machen (aka "polymorphe lambdas").
Late return-type: Ich muss bei der neuen Funktionsdeklarationssyntax immer noch einen return-Typ angeben, obwohl ich bei Lambdas dazu nicht mehr gezwungen werde. Das finde ich inkonsequent. Beispiel:

auto sum1(int a, int b) -> int {return a+b;}  // OK
auto sum2(int a, int b) {return a+b;}         // nicht erlaubt

int main() {
  auto sum3 = [](int a, int b){return a+b;};  // OK
}

In diesem Beispiel ist das nicht wild. Es kann aber bei komplizierteren Funktionstemplates nerven, dass man den RückgabeTyp noch zusätzlich angeben muss. Gut, man könnte sich mit decltype ein Makro baseln, um das zu emulieren, aber das ist dann auch nicht so schön.

Sonst wäre es vielleicht noch nett, eine bessere Unterstützung für Pimpl bereitzustellen. ZB wäre es nett, wenn man so etwas machen könnte

incomplete_type *ptr = ...;
ptr->some_function(27,3.1415);

also, Klassen partiell zu definieren (öffentliche Schnittstelle im Header verraten, aber mehr auch nicht, also keine Implementierungsdetails). Der Typ würde dann noch unvollständig sein, man könnte aber trotzdem Elementfunktionen (zumindest die, die im Header deklariert werden) aufrufen. Damit spart man sich das Bauen einer Pimpl-Wrapper Klasse und das Replizieren der Schnittstelle.

Ein Modulsystem wär auch nicht schlecht. Hatte mir auch das Proposal mal dazu angesehen, aber so richtig durchblickt hatte ich das auch nicht.

Mir wär auch ein einfaches Sprachfeature recht, mit welchem ich diese enable_if-Tricks loswerde. Die Anwendung des enable_if-Tricks führt zu schwer lesbarem Code und der Trick ist auch nicht überall einsetzbar, wo man es bräuchte. Ein aufgeblasenes concept-System muss nicht unbedingt sein. Aber wenn man eine einfache requires-Klausel mit boolschen Ausdrücken einführt, dann verbaut man sich vielleicht damit die Möglichkeit für ein besseres concepts-System.

rapso

ich wuerde gerne eine automatische oder simple art accessor functions zu erstellen gern im standard sehen, so wie es automatisch ctor/dtor gibt.

also

class foo
{
int bar;
};

sollte automatisch

int bar();
int bar()const;
template<class T>
void bar(const T& b){bar=b;}
}

[edit:tags fixen]
als public bekommen.

oder wenigstens "simple art", so dass man angibt welche art, z.b.

class foo
{
int bar:public:Bar;
};

ps. das ist nur brainstorming, kein final draft meines vorschlages

zudem waere eine ueberarbeitung von den std::... nett, sowas wie .c_str()... ist mir ein grauss.

zudem wuerde ich gerne die compiler richtlinien ueber aliasing usw. ueberarbeitet sehen, sodass compiler besser optimieren koennen. ansonsten sind simple optimierungen wie loop unrollen oft verhindert, weil irgendwelche aliasing rules anschlagen von denen die meisten garnicht wahrnehmen dass es passiert.

(nicht dass ich hier jetzt einen flamewar anstossen will, aber ich verstehe ehrlich nicht was hier manche gegen header dateien haben, wenn ich mir so manch java sourcefile anschaue, ist das echt nicht so schoen zu ueberblicken wie ein simpler c++ header, wenn man etwas einfach nur benutzen will, was die meiste zeit ueber sein duerfte, wenn man fremden source nimmt).