Kleine Umfarge: C++09 oder Ur-C++

Jonas OSDever

Englischer Wiki-Eintrag... Schlecht. Ich hab nix gegen Englisch aber laut meiner Englischlehrerin kann man solche Texte erst mit Klasse9-Englisch verstehen. Ich muss noch knapp zwei Jahre warten.

Bashar

Und ab welchem Alter kann man laut deinem Informatiklehrer den Sinn eines neuen Standards beurteilen? Frag mal nach!

MFK

Jonas OSDever schrieb:

Aber ein neuer Standard wird den Proggern aufgezwungen .

Hast du den neuen Standard so weit verstanden, dass du erfassen kannst, inwieweit du deinen Code anpassen müsstest? Wie oft benutzt du auto?

Jonas OSDever

Naja OK. Ich warte mal ab bis VC++ das Ding nahtlos unterstützt und sehe mirs dann mal an. Und ab wann man den Standard beurteielen kann das kann jeder Progger selbst entscheiden. Außerdem ist das ja nur meine Meinung. Ich will ja euere hören. Und wenn ihr den Standard gut findet akzeptier ich dies. auto benutz ich nie. Wird von VC++ irgendwie nicht unterstützt.

hustbaer

Ich finde es gut dass die Sprache auch mal erweitert wird, ist lange überfällig.

Einerseits doof dass es so lange gedauert hat, andrerseits gut dass nicht alle paar Woche ne Erweiterung gemacht wird wie z.B. bei C#.

Jonas OSDever

hustbaer schrieb:

Ich finde es gut dass die Sprache auch mal erweitert wird, ist lange überfällig.

Einerseits doof dass es so lange gedauert hat, andrerseits gut dass nicht alle paar Woche ne Erweiterung gemacht wird wie z.B. bei C#.

Das ist vielleicht auch der Grund warum ich dieser Meinung bin. C++ war bis vor kurzem die einzige Sprache von der ich wusste das danach kein x.x steht. Ich bin halt etwas skeptisch aber vielleicht wird mir der neue Standard auch mal aus der Patsche. Überfällig finde ich zwar nicht aber ich hab vielleicht 2 einhalb Jahre C++-Erfahrung. Da könnt ihr "alten Hasen" natürlich mehr sagen. Wie gesagt ich schau mirs nochmal an.

Dravere

Jonas OSDever schrieb:

Englischer Wiki-Eintrag... Schlecht. Ich hab nix gegen Englisch aber laut meiner Englischlehrerin kann man solche Texte erst mit Klasse9-Englisch verstehen. Ich muss noch knapp zwei Jahre warten.

Wie wäre es mal mit versuchen? Am besten lernt man Englisch, in dem man es anwendet.

Jonas OSDever schrieb:

Aber was die kompatiblität der Compiler betrifft... Ich hab ja ein Beispiel gegeben.

Meinst du dieses hier?

Jonas OSDever schrieb:

Zum Beispiel VC++ 2008 unterstützt (obwohl eingestellt ist Als C kompilieren) C99 nicht vollständig.

VC++ kann überhaupt kein C99! Microsoft hat auch nicht vor C99 zu unterstützen. Die Gründe dafür sind mir nicht so ganz klar, aber ich denke mal, dass Microsoft hauptsächlich auf C++ setzt und daher nur deswegen den C89 Standard unterstützt.

Jonas OSDever schrieb:

Ich bin aber eben auch der Meinung: Was sich einmal bewährt hat lässt sich so schnell nicht ersetzen. Und Ur-C++ hat sich schon lange bewährt!

Du weisst schon, dass es wirklich ein Ur-C++ gibt, welches sich bewährt hat? Es gab nämlich auch ein C++ vor der Standardisierung im Jahre 1998. Bin ich froh, dass wir heute einen Standard haben!
Da man nicht gezwungen ist, den neuen Standard einzusetzen, sehe ich einfach keine Probleme. Zudem bringt der neue Standard wirklich sehr gute und längst überfällige Dinge. Wobei er mir noch nicht mal weit genug geht. Fortschritt erreicht man nicht dadurch, dass man stehen bleibt.

Grüssli

knivil

Du sagst also, du gehst in die 7te Klasse und der neu Standard von C++ ist kacke. Meinst du nicht, dass du etwas jung bist fuer eine fundierte Meinung. Ich finde den neuen Standard wesentlich besser.

Jonas OSDever

Das es einen Standard gibt - jadarüber bin ich auch froh. Aber warum Microsoft kein C99 unterstützen will?
Ok ich mag etwas jung sein, aber ich möchte auch keine fundierte Meinung abgeben. Und Ok: Kacke ist auch nicht das richtige Wort. Ich bin nur der Meinung das manche neuen Sprachkonzepte schwierig zu handhaben sind und manchmal weniger bringen als sie kosten. Die neue stdlib ist ja gar nich mal so schlecht - Threads und Dateisystem sind wichtige Themen. Der alte Standard stmmt aus der Zeit wo Multithreading noch nicht bekannt oder wenig verbreitet war. Ich meine mit neuem Standard auch hauptsächlich die Sprachkonzepte und nicht die stdlib. Und bitte nicht immer das ich erst in die 7te Klasse gehe. Ich weiss, ich bin etwas jung aber proggen ist nunmal mein Hobby. Und wie gesagt ich meine einige Sprachkonzepte sind Kacke und nicht alles. Und fundiert.. Nö ich hab nur eine Meinung wie jeder Mensch. Viele sagen auch Windows gut, Linux blöd, obwohl sie nicht fundiert sind . So, ich geh jetzt für den Rest der Woche off. Internet ist teuer. Ihr könnt wenn ihr wollt weiter diskutieren.

Dravere

Jonas OSDever schrieb:

So, ich geh jetzt für den Rest der Woche off. Internet ist teuer. Ihr könnt wenn ihr wollt weiter diskutieren.

Ehm ... mir bleibt die Sprache weg ...

Jonas OSDever schrieb:

Und wie gesagt ich meine einige Sprachkonzepte sind Kacke und nicht alles.

Wäre nur mal interessant, wenn du dies präzisieren könntest. Dann könnte man auch mal über etwas argumentieren, bzw. diskutieren

Grüssli

player424

Ich nutze einmal die Gelegenheit um einmal meine Meinung über den neuen Standard loszuwerden.
Am Anfang habe ich mich auch überhaupt nicht damit auseinandersetzen wollen. Ich habe mir den Artikel mehrmals etwas durchgelesen, war aber von der teils komplizierten Syntax zu abgeschreckt um mich weiter einlesen zu können.
Vor kurzem habe ich es mir dann noch einmal in Ruhe durchgelesen, und bin dann zu der Meinung gekommen, dass einige sinnvolle Erweiterungen drin sind.
Besonders die Erweiterung der Standardbibliothek hat mir gefallen.
Allerdings finde ich auch, dass der neue Standard viel unnötiges an Bord hat, und manches nur überflüssiger Syntax-Zucker ist.
Ich finde auch, dass der Standard die Sprache einen Tick zu High-Level macht, und sich C++ zu weit vom eigentlichen Konzept entfernt.

Dravere

player424 schrieb:

Allerdings finde ich auch, dass der neue Standard viel unnötiges an Bord hat, und manches nur überflüssiger Syntax-Zucker ist.
Ich finde auch, dass der Standard die Sprache einen Tick zu High-Level macht, und sich C++ zu weit vom eigentlichen Konzept entfernt.

Könntest du das ein wenig präzisieren?
Wenn du das so allgemein stehen lässt, kann man doch gar nicht auf die Kritik eingehen. Daraus ensteht keine sinnvolle Diskussion.

Grüssli

player424

Stimmt. Dann will ich das einmal nachholen.
Die Lambda-Funktionen z.B. finde ich unnötig. Ich hatte jetzt noch keinen wirklichen Fall, wo sie einen erkennbaren Mehrwert gebracht hätten. Dem Nutzen dieser Spracherweiterung steht dann auch die etwas undurchsichtige Syntax entgegen.
Das auto Keyword ist auch eine ganz nette Sache, aber auch dabei habe ich die Bedenken, dass es den Quellcode unleserlicher machen könnte.
Aus der Standardbibliothek hätte man, meiner Meinung nach auch die Klasse für statische Arrays und Tuples auslassen können.

Blue-Tiger

ich finds sehr schade dass wir kein restrict gekriegt haben. Ich seh nicht ein wozus einen null_ptr braucht. Ich haette mir Concepts gewuenscht, schade dass man da keine Loesung gefunden hat.
Ich finds gut, dass auf Multitthreading eingegangen wird. Ich freu mich auf lambdas.

Alles in Allem: der Standard haette besser sein koennen, aber er ist sicher eine Verbesserung zu C++98. Sobald es einen brauchbaren Compiler gibt, werd ich aber vermutlich auf D 2.0 umsteigen.

Blue-Tiger schrieb:

Ich seh nicht ein wozus einen null_ptr braucht.

http://channel9.msdn.com/shows/Going+Deep/Stephan-T-Lavavej-Everything-you-ever-wanted-to-know-about-nullptr/

Allgemein gibt es auch noch einen 5 teiligen msdn webcast.
Dieser stellt zwar nur die quasi Standard features von VS2010 vor, aber ist sicherlich auch für den einen oder anderen interessant:
hier mal ein link für den 1. teil:
http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=1032455633

Dravere

Blue-Tiger schrieb:

Ich seh nicht ein wozus einen null_ptr braucht.

http://www.c-plusplus.net/forum/viewtopic-var-t-is-220511.html

player424 schrieb:

Die Lambda-Funktionen z.B. finde ich unnötig. Ich hatte jetzt noch keinen wirklichen Fall, wo sie einen erkennbaren Mehrwert gebracht hätten. Dem Nutzen dieser Spracherweiterung steht dann auch die etwas undurchsichtige Syntax entgegen.

Die Syntax ist wirklich alles andere als schön gewählt. Da stimme ich dir zu. Aber praktisch ist es definitiv. In C# verwende ich an sehr vielen Stellen Lambda-Ausdrücke. In Verbindung mit den Algorithmen aus der Standardbibliothek ist das sehr praktisch. So muss man keine zusätzliche Funktoren mehr schreiben und kann direkt Lambda-Ausdrücke verwenden.

Nehmen wir ein ganz einfaches Beispiel:

class User
{
private:
  std::string m_firstname;
  std::string m_lastname;

  // ...

public:
  std::string const& get_firstname() const { return m_firstname; }
  std::string const& get_lastname() const { return m_lastname; }

  // ...
};

// Wir haben nun einen std::vector<User> mit Werten gefüllt:
std::vector<User> users;

// Nun möchten wir diesen nach dem Nachnahmen sortieren:
auto lastname_cmp = [](User const& lhs, User const& rhs) { lhs.get_lastname() < rhs.get_lastname(); };
std::sort(users.begin(), users.end(), lastname_cmp);

// Oder doch lieber nach dem Vornamen?
auto firstname_cmp = [](User const& lhs, User const& rhs) { lhs.get_firstname() < rhs.get_firstname(); };
std::sort(users.begin(), users.end(), firstname_cmp);

Sowas ist sehr praktisch. Man kann auch einfach Prädikate und anderes erstellen, was man in Zusammenhang mit solchen Algorithmen verwenden kann.

player424 schrieb:

Das auto Keyword ist auch eine ganz nette Sache, aber auch dabei habe ich die Bedenken, dass es den Quellcode unleserlicher machen könnte.

Gerade das Gegenteil ist der Fall. Vielfach interessiert mich der Typ gar nicht gross, ich will nur den korrekten Verwenden. Wieder ein einfaches Beispiel:

template<typename T>
typename std::map<std::string, std::pair<std::string, T> >::reverse_const_iterator foo();

// ...
std::map<std::string, std::pair<std::string, int> >::reverse_const_iterator iter = foo<int>();

// zu:
auto iter = foo<int>();

Was sieht übersichtlicher aus?
In C# gibt es var und ich verwende es mehr und mehr, weil es die Übersicht extrem erhöht. Zum Beispiel auch für ganz einfache Dinge:

var obj = new ThisIsAClass();
// sieht doch besser aus als:
ThisIsAClass obj = new ThisIsAClass();

Gleiches könnte man sich auch für C++ vorstellen:

auto obj = new ThisIsAClass();

Es ist sowieso klar, dass obj vom Typ ThisIsAClass* sein wird, da müssen wir dies nicht noch explizit angeben.

player424 schrieb:

Aus der Standardbibliothek hätte man, meiner Meinung nach auch die Klasse für statische Arrays und Tuples auslassen können.

Und was ist der Grund? Beides Dinge, welche ich regelmässig brauchen werde.

Grüssli

rüdiger

Bei dem Compilersupport mache ich mir nicht so viele Sorgen. Die Compilerbauer sind ja schon fleißig dabei die Unterstützung einzubauen (http://gcc.gnu.org/projects/cxx0x.html) und laut Stroustrup hat man diesmal auch mehr auf die Compilerbauer gehört, um so etwas wie export zu vermeiden.

player424 schrieb:

Die Lambda-Funktionen z.B. finde ich unnötig. Ich hatte jetzt noch keinen wirklichen Fall, wo sie einen erkennbaren Mehrwert gebracht hätten. Dem Nutzen dieser Spracherweiterung steht dann auch die etwas undurchsichtige Syntax entgegen.

Bei Lambda-Funktionen finde ich die Syntax nur hässlich. Ansonsten sind sie imho sehr nützlich, da man ja oft mal schnell einen Funktor braucht und derzeit dafür dann irgend wo eine kleine Klasse basteln muss.

player424 schrieb:

Das auto Keyword ist auch eine ganz nette Sache, aber auch dabei habe ich die Bedenken, dass es den Quellcode unleserlicher machen könnte.

Es macht in den meisten Situationen den Code sicher leserlicher.

zB was bei mir öfters im Code vorkommt:

template<typename Lhs, typename Rhs>
typename detail::add<Lhs, Rhs>::type
add(Lhs const &lhs, Rhs const &rhs) {
  ...
}

wird mit auto imho deutlich lesbarer

template<typename Lhs, typename Rhs>
auto add(Lhs const &lhs, Rhs const &rhs) {
  ...
}

player424 schrieb:

Aus der Standardbibliothek hätte man, meiner Meinung nach auch die Klasse für statische Arrays und Tuples auslassen können.

Was?! Nein! Beides sind imho sehr sinnvolle Klassen, die ich auch regelmäßig benutze.

player424

Teilt ihr euch ein Gehirn ?

OK bei den Sprachfeatures kann man wohl sagen: wenn mans mal braucht ist es bestimmt nützlich. Aber wozu braucht ihr eine Klasse für etwas, dass schon fest in der Sprache eingebaut ist (std::array)? Und was die Tuple-Klasse angeht: Mir fallen spontan nur wenige Beispiele ein, bei denen man so etwas brauchen könnte.

krümelkacker

rüdiger schrieb:

player424 schrieb:

Die Lambda-Funktionen z.B. finde ich unnötig. Ich hatte jetzt noch keinen wirklichen Fall, wo sie einen erkennbaren Mehrwert gebracht hätten. Dem Nutzen dieser Spracherweiterung steht dann auch die etwas undurchsichtige Syntax entgegen.

Bei Lambda-Funktionen finde ich die Syntax nur hässlich. Ansonsten sind sie imho sehr nützlich, da man ja oft mal schnell einen Funktor braucht und derzeit dafür dann irgend wo eine kleine Klasse basteln muss.

Dass sie nützlich sind steht eigentlich außer Frage. Die Alternativen dazu sind:
(1) Code des Funktors irgendwo anders ablegen --> zerstört den Lesefluss
(2) Eventuell kriegt man ein entsprechendes Funktionsobjekt mit std::bind hin. Lesen+Verstehen ist bei dem, was dabei raus kommt, schwieriger.

Ich denke die Syntax ist auch nur eine Frage der Gewöhnung. Es gefällt mir sogar, dass ich über die "Capture-Clause" steuern kann, was kopiert und was referenziert wird vom "Umfeld". Ich hätte mir allerdings noch ein "move-capture" gewünscht, zB so etwas:

template<class Fun>
void exec(Fun fun) {
  fun();
}

void foobar()
{
  unique_ptr<int> p (new int);
  *p = 1729;
  exec([-p]{ // <-- kein C++0x, aber so könnte ein "move-capture" aussehen.
    cout << *p << '\n';
  });
}

auto...

rüdiger schrieb:

Es macht in den meisten Situationen den Code sicher leserlicher.
zB was bei mir öfters im Code vorkommt:
template<typename Lhs, typename Rhs>
typename detail::add<Lhs, Rhs>::type
add(Lhs const &lhs, Rhs const &rhs) {
  ...
}
wird mit auto imho deutlich lesbarer
template<typename Lhs, typename Rhs>
auto add(Lhs const &lhs, Rhs const &rhs) {
  ...
}

Das wär nett gewesen. Aber Du kannst nicht einfach den return-Typ weglassen. Oder meintest Du

template<typename Lhs, typename Rhs>
auto add(Lhs const &lhs, Rhs const &rhs) -> decltype(lhs+rhs) {
  ...
}

?

Die Alternative dazu wäre

template<typename Lhs, typename Rhs>
decltype(declval<Lhs const&>()+declval<Rhs const&>())
add(Lhs const &lhs, Rhs const &rhs) {
  ...
}

Innerhalb von decltype habe ich lhs durch declal<Lhs const&>() ersetzt. Wir brauchen keine extra detail::add-Klasse schreiben. declval ist dazu da, für decltype-Ausdrücke Objekte herzuzaubern.

rüdiger schrieb:

player424 schrieb:

Aus der Standardbibliothek hätte man, meiner Meinung nach auch die Klasse für statische Arrays und Tuples auslassen können.

Was?! Nein! Beides sind imho sehr sinnvolle Klassen, die ich auch regelmäßig benutze.

Sehe ich auch so.

kk

Die echten Probleme von C++ löst der neue Standard auch nicht, weil er dann nicht mehr kompatibel wäre.