Mehr fällt mir dazu im Augenblick auch nicht ein.

Gruß,
SP

Mehr fällt mir dazu im Augenblick auch nicht ein.

Ist vielleicht nicht das Schlechteste. Viele befürchten ja, dass ein so riesiges Sprachfeature, das auf einen Schlag hinzugefügt wird, zu Problemen führen könnte. Man hat nicht besonders viel Erfahrung damit (soweit ich weiss, nur ein paar Prototypen wie ConceptGCC), und könnte einiges riskieren.

Naja, ich kann das natürlich auch nicht genau beurteilen, aber mir ist es lieber, wenn ich noch ein wenig warte, und dafür eine sauberere und durchdachtere Implementierung habe. Zumal Concepts nicht unbedingt das Feature ist, nach dem ich mich schon seit Ewigkeiten sehne...

Fällt damit nicht auch die foreach-Schleife weg? Ich meine mal gehört zu haben, dass sie auf Concepts beruht.

du hast doch noch auto und decltype.
das allein genügt.
#define foreach(cont) for(decltype(cont)::iterator i=cont.begin(),e=cont.end;i!=e;++i)
oder
#define foreach(cont) for(auto i=cont.begin(),e=cont.end;i!=e;++i)

Ich würde es zum Beispiel sehr schätzen, wenn ein Konzept von einem Funktionstemplate oder Klassentemplate automatisch erstellt würde. Irgendsowas muss der Parser und Kompiler im Hintergrund sowieso bereits haben. Und darauf dann nur noch eine Art von concept_map für das entsprechende umbiegen. Das wäre einfacher für den Programmierer und bereits etwas sehr tolles.

Grüssli

Man hat nicht besonders viel Erfahrung damit (soweit ich weiss, nur ein paar Prototypen wie ConceptGCC), und könnte einiges riskieren.

Das sind ja auch gute Gründe.

Nexus schrieb:

Zumal Concepts nicht unbedingt das Feature ist, nach dem ich mich schon seit Ewigkeiten sehne...

Naja, "modular type checking for templates" -- wie es Doug Gregor in seinem Vortrag nannte -- wäre schon nett gewesen. Nicht nur, um die ätzenden Fehlermeldungen loszuwerden, sondern auch als Ersatz für all die Template-Tricks (SFINAE,...).

Welches sind denn Eure Top 3 C++0x Sprach-Features? Von dem, was noch übrig ist, würde ich sagen: Rvalue-Referenzen, Variadische Template und Typinferenz (auto, decltype).

Wovon ich nicht so richtig überzeugt bin ist "thread_local" als Speicherklasse.

volkard schrieb:

du hast doch noch auto und decltype.

Ja, damit würde es gehen. Ich würde aber immernoch den "Umweg" über eine Traits-Klasse (als Concept/Concept Map-Ersatz) machen. Also in etwa so:

for ([i]#1[/i] : [i]#2[/i]) {
  [i]#3[/i]
}

==[ersetzen durch]==>

{
  auto && _range = [i]#2[/i];
  typedef typename remove_reference<decltype(_range)>::type __RangeType;
  typedef range_traits<__RangeType> __RangeTraits;
  for (auto _beg = __RangeTraits::begin(_range),
            _end = __RangeTraits::end(_range);
       _beg != _end; ++_beg)
  {
    [i]#1[/i] = *_beg;
    [i]#3[/i]
  }
}

Welches sind denn Eure Top 3 C++0x Sprach-Features? Von dem, was noch übrig ist, würde ich sagen: Rvalue-Referenzen, Variadische Template und Typinferenz (auto, decltype).
Wovon ich nicht so richtig überzeugt bin ist "thread_local" als Speicherklasse.

Genau. Diese vier sind es.
Und: Compilezeitaufrufbare Funktionen.

Sebastian Pizer schrieb:

==[ersetzen durch]==>

Das ist "Jede Sprache, die was taugt, tendiert dazu, Lisp zu sein".
Ja, ich hätte gerne Zugriff auf den Parsebaum und würde ihn frei ummodeln können. Aber ich habe zugleich auch Angst davor.

Welches sind denn Eure Top 3 C++0x Sprach-Features?

Alles?

Also von neuen Sprachfeatures:
1. auto, decltype -> vielleicht in diesem Zusammenhang auch die neue Funktionsdeklaration.
2. variadic templates
3. Lambda Funktionen

Bibliothekfeatures:
1. Bind/Functions (wobei das natürlich schon im tr1 dabei ist)
2. Threads
3. Futures (oder gehört das zu Threads?)

Aber der ganze Rest ist natürlich auch toll. Gibt glaub ich kein neues Feature, auf welches ich mich nicht freue.

Grüssli

Sebastian Pizer schrieb:

==[ersetzen durch]==>

Das ist "Jede Sprache, die was taugt, tendiert dazu, Lisp zu sein".
Ja, ich hätte gerne Zugriff auf den Parsebaum und würde ihn frei ummodeln können. Aber ich habe zugleich auch Angst davor.

Hä? Die Idee von dem for-range loop war schon immer, dem Compiler vorzuschreiben, dass er eine solche (oder äquivalente) Ersetzung durchführen soll, sofern der Typ von _range kein Array oder keine Initializer-List ist. Ich habe lediglich das Concept Range<X> durch die Traits-Klasse range_traits<X> ersetzt.

Gruß,
SP

Hä?

Ups, bin über das Ziel hinausgeschossen.
Ich wünsche mir seit Jahren, daß man das "==[ersetzen durch]==>" selber definieren kann. Ich habe eh ganz andere Wünsche als mein Nächster. Die best practices kann man ja dann standardisieren.
Jede Einführung von mehr Compilermagie-Klassen lehne ich dagegen ab. std::string aus std::exception aus new bringt mich regelmäßig zum weinen.

Nexus schrieb:

Man hat nicht besonders viel Erfahrung damit (soweit ich weiss, nur ein paar Prototypen wie ConceptGCC), und könnte einiges riskieren.

Das sind ja auch gute Gründe.

Die wesentlichen, IMHO. Genau derselbe Fehler wie bei export.

Sebastian Pizer schrieb:

Welches sind denn Eure Top 3 C++0x Sprach-Features?

Lambda-Funktionen, Typinferenz, Variadic Templates.

std::string aus std::exception aus new bringt mich regelmäßig zum weinen.

Äääääh? Wo bekommst du nen std::string aus ner std::exceptions???
what() gibt nicht ohne Grund nen char const* zurück...

Wovon ich nicht so richtig überzeugt bin ist "thread_local" als Speicherklasse.

Naja, wie es ausschaut haben die ThreadLocal in Java (und anderen Sprachen?) genügend beeindruckt ums auch in C++ zu übernehmen

Was ich mir auf jeden Fall wünsche sind neue Bibliotheken. Sprachfeatures haben wir eigentlich genug. Man kann immer wieder was verbessern, ich finde z.B. Lambdas und das auto-Keyword super.

Aber freuen würde ich mich wenn endlich mal die Std-Lib erweitert wird. Und nein, nicht um GUI o.ä. Sondern um Filesystem, Date and Time und Netzwerk. Das was man auf jedem System (Desktop, Server und Embedded) am ehesten benötigt. Die Thread-Lib in C++0x ist schon mal ein sehr guter Anfang. Ich hoffe das bald C++0x endlich verabschiedet wird und es ruck zuck an TR2 geht!

Aber freuen würde ich mich wenn endlich mal die Std-Lib erweitert wird. Und nein, nicht um GUI o.ä. Sondern um Filesystem, Date and Time und Netzwerk. Das was man auf jedem System (Desktop, Server und Embedded) am ehesten benötigt. Die Thread-Lib in C++0x ist schon mal ein sehr guter Anfang. Ich hoffe das bald C++0x endlich verabschiedet wird und es ruck zuck an TR2 geht!

Das sehe ich gleich. Obwohl lambda und co. ganz toll sind, "braucht" man sie nicht wirklich, da man das es (meist) Lösungen mit dem aktuellen Standard gibt. Wohingegen man bei einem Filesystem (rein Sprachbezogen) aufgeschmissen ist. Man muss auf externe Bibliotheken zugreifen (oder nat. alles selbst schreiben). Aber wie du schon sagst ist Thread alleine schon sehr nett. Vor allem als Basis von Netzwerken.

Obwohl lambda und co. ganz toll sind, "braucht" man sie nicht wirklich, da man das es (meist) Lösungen mit dem aktuellen Standard gibt.

Gerade bei Lambda-Funktionen finde ich das Argument unangebracht. Workarounds wie boost.lambda sind oftmals eher eine Last denn eine Hilfe; das Scope-Capturing läßt sich nunmal nicht mit Bibliotheksfeatures simulieren. Ähnliches gilt für BOOST_TYPEOF.

Bibliothekserweiterungen sind schön und gut, aber real viel zu spät - mittlerweile verwendet ohnehin jeder seinen ganz persönlichen Workaround. Viel wichtiger finde ich die Erweiterung der Sprachmöglichkeiten, also Dinge, die man nicht über externe Bibliotheken nachrüsten kann.

drakon schrieb:

Obwohl lambda und co. ganz toll sind, "braucht" man sie nicht wirklich, da man das es (meist) Lösungen mit dem aktuellen Standard gibt.

Gerade bei Lambda-Funktionen finde ich das Argument unangebracht. Workarounds wie boost.lambda sind oftmals eher eine Last denn eine Hilfe; das Scope-Capturing läßt sich nunmal nicht mit Bibliotheksfeatures simulieren.

Ja, aber ich meinte, dass man es nicht wirklich braucht. Man hat dann halt eine etwas unleserliche Syntax und mehr arbeit, wenn man halt einen Funktor schreiben muss, aber grundsätzlich geht das, was man erreichen will. Keine Frage es ist umständlicher und Mehrarbeit, aber es geht.

Ja, aber ich meinte, dass man es nicht wirklich braucht. Man hat dann halt eine etwas unleserliche Syntax und mehr arbeit, wenn man halt einen Funktor schreiben muss, aber grundsätzlich geht das, was man erreichen will. Keine Frage es ist umständlicher und Mehrarbeit, aber es geht.

Diese Argumentation führt zwangsläufig zu C zurück. Oder ziehst du eine willkürliche Grenze?

drakon schrieb:

Ja, aber ich meinte, dass man es nicht wirklich braucht. Man hat dann halt eine etwas unleserliche Syntax und mehr arbeit, wenn man halt einen Funktor schreiben muss, aber grundsätzlich geht das, was man erreichen will. Keine Frage es ist umständlicher und Mehrarbeit, aber es geht.

Diese Argumentation führt zwangsläufig zu C zurück. Oder ziehst du eine willkürliche Grenze?

Das führt noch weiter zurück. - Nein, nicht willkürlich, aber irgendwo muss eine Balance her. Mir persönlich brächte es mehr, wenn ich eine anständige Lib für Netzwerk an die Hand gelegt bekäme, als eine Lib, die es mir ermöglicht lambda Funktionen zu schreiben. Die Grenze ist natürlich subjektiv und hängt auch ab, in welchem Bereich man vor hat die Features zu nutzen..

Stell dir das umgekehrte vor. Du hast eine Sprache, die dir etliche Sprachfeatures bietet, jedoch nicht einmal eine Bibliothek für String Verarbeitung bietet. Auch nicht so toll, oder?

drakon schrieb:

Ja, aber ich meinte, dass man es nicht wirklich braucht. Man hat dann halt eine etwas unleserliche Syntax und mehr arbeit, wenn man halt einen Funktor schreiben muss, aber grundsätzlich geht das, was man erreichen will. Keine Frage es ist umständlicher und Mehrarbeit, aber es geht.

Diese Argumentation führt zwangsläufig zu C zurück. Oder ziehst du eine willkürliche Grenze?

Falsch! Diese Argumentation führt zu Assembler zurück. Oder wir geben gleich selber 0 und 1 ein. Mehr brauchen wir ja nicht
Es scheint aber ziemlich eindeutig zu sein, dass er hier eine subjektive Grenze zieht.

Edit: Zu spät, da hat drakon schon selber geantwortet

audacia schrieb:

Bibliothekserweiterungen sind schön und gut, aber real viel zu spät - mittlerweile verwendet ohnehin jeder seinen ganz persönlichen Workaround. Viel wichtiger finde ich die Erweiterung der Sprachmöglichkeiten, also Dinge, die man nicht über externe Bibliotheken nachrüsten kann.

Ich stimme dir zwar zu, dass man viel zu spät ist, aber trotzdem ist es nützlich. Die alte Software wird bei seinen Workarounds bleiben, die neuen dagegen können endlich auf einen Standard setzen. Vielleicht gibt es ja sogar ein paar alte Softwaresystem, welche wechseln werden

Ich bin allerdings gespannt, was Boost machen wird. Gibt es da schon eine Aussage von den Entwicklern?

Grüssli

Stell dir das umgekehrte vor. Du hast eine Sprache, die dir etliche Sprachfeatures bietet, jedoch nicht einmal eine Bibliothek für String Verarbeitung bietet. Auch nicht so toll, oder?

Nein, aber so ähnlich sieht es bei C++ ja aus. Da C++ aus verschiedenen Gründen dennoch relativ große Marktdurchdringung hat, haben sich eben Alternativbibliotheken gefunden und mehr oder weniger etabliert.

Dravere schrieb:

Ich stimme dir zwar zu, dass man viel zu spät ist, aber trotzdem ist es nützlich. Die alte Software wird bei seinen Workarounds bleiben, die neuen dagegen können endlich auf einen Standard setzen. Vielleicht gibt es ja sogar ein paar alte Softwaresystem, welche wechseln werden

Ja, natürlich ist es nützlich, und ich begrüße außerordentlich, daß die Standardbibliothek mit einer Threading-Library und den anderen vorgeschlagenen praxisorientierten Erweiterungen mal etwas weiter in die reale Welt tritt. Aber all das ist nichts, was es nicht jetzt schon gäbe, nur steht eben "Standard" drauf. Deshalb finde ich Sprachfeatures, die es in C++ noch nicht gibt, bei weitem wichtiger.

Eine Sprachbibliothek muß die Balance finden zwischen einem Minimalkompromiß, der in vielen Bereichen nur beschränkten praktischen Nutzwert bietet (dem ist die gegenwärtige C++-Standardbibliothek recht nahe) und einer voll ausgestatteten "Featuritis"-Bibliothek (z.B. die Java-Library oder das .NET-Framework), die viel schneller zum Ballast wird, als mancher wahrhaben mag. Einen interessanten und, wie ich finde, sehr attraktiven Mittelweg gehen Rich-Client-Frameworks wie VCL und Qt - aber ob das der richtige Ansatz für die C++-Standardbibliothek wäre, weiß ich nicht so recht.

string operator + (string const& a, string const& b)
{
   string tmp (a);
   tmp += b;
   return tmp;
}

string a ("this ");
string b = a + "a" + "b" + "cd";

a + "a" ruft doch nicht operator + (string const& a, string const& b) auf (wieso zur Hölle den konstante Referenzen), sondern operator +(string& a, const char* b)?!
Und was verschiebt sich dann hier???

auto concept Bla <typename A, typename B>
{
   operator +(A const&, B const&);
}

template <typename T, typename B, ...Args> requires Bla<T, B>
auto foo(T& a, B& b, Args&& ... args) -> decltype(a + b) {
   return a + b;
}

ist doch totaler müll!!! braucht kein mensch!!

Kann mir mal jemand den Sinn von Rvalue-Referenzen erklären?

Der Sinn ist mehrfach dokumentiert:
N2027: A Brief Introduction to Rvalue References
Rvalue Reference 101

Hä? schrieb:

string operator + (string const& a, string const& b)
{
   string tmp (a);
   tmp += b;
   return tmp;
}

string a ("this ");
string b = a + "a" + "b" + "cd";

a + "a" ruft doch nicht operator + (string const& a, string const& b) auf (wieso zur Hölle den konstante Referenzen), sondern operator +(string& a, const char* b)?!

Ich denke, das Beispiel, was Du zitierst, geht nicht davon aus, dass es einen operator+(string const&, char const*) gibt. Nimm der Einfachheit wegen an, dass "string" eine eigene Klasse ist:

class string {
  .....
public:
  string();
  string(char const*);
  string& operator+=(string const& x);
  .....
};

Nimm weiter an, dass die folgenden operator+ Funktionen die einzigen sind, die auf string arbeiten:

string operator+(string const& lhs, string const& rhs)
{
  string tmp;
  tmp.reserve(lhs.length() + rhs.length());
  tmp += lhs;
  tmp += rhs;
  return tmp;
}

string operator+(string && lhs, string const& rhs)
{
  lhs += rhs;
  return std::move(lhs);
}

Wo ist nun das Problem?

Gruß,
SP