Warum wurde-pair-Bereich Zugriff entfernt von C++11?

Ich habe gerade entdeckt, dass an einer Stelle, die C++11-Entwurf hatte std::begin/std::end überladungen für std::pair erlaubt, dass die Behandlung von einem paar von Iteratoren als Bereich geeignet für den Einsatz in einem range-basierte for-Schleife (N3126, Abschnitt 20.3.5.5), aber das hat sich inzwischen entfernt.

Weiß jemand, warum es entfernt wurde?

Finde ich die Entfernung sehr schade, denn es scheint, dass es keinen anderen Weg, um zu behandeln, ein paar von Iteratoren, die als eine Reihe. In der Tat:

Die lookup-Regeln für das beginnen/enden in einem range-basierte for-Schleife sagen, dass begin/end-gesucht-in-1) als member-Funktionen der "range" - Objekt 2) als freie Funktionen in den "zugehörigen namespaces"
std::pair keine begin/end-member-Funktionen
Die nur im Zusammenhang namespace für std::pair<T, U> im Allgemeinen namespace std
Wir dürfen nicht zu überlasten std::begin/std::end für std::pair uns
Können wir spezialisieren std::begin/std::end für std::pair (weil die Spezialisierung hätte teilweise und das ist nicht zulässig, Funktionen)

Gibt es eine andere Möglichkeit, die ich bin fehlt?

Nicht begin(), end() für ein std::pair die gleiche Sache wie .ersten und .zweite?
Ja, aber, es zu benutzen in eine range-basierte for-Schleife, die wir brauchen, begin() und end().
Wahrscheinlich, weil der Semantik (ein paar nicht necessarilty Bereich) und Unklarheiten zu vermeiden, wie z.B. hier berichtet: stackoverflow.com/questions/4155450/...

InformationsquelleAutor HC4 - reinstate Monica | 2011-05-29

c++c++11 foreach range std-pair

41

Ich denke, dass die 2009 Papier "Paare machen sich nicht gut-Bereiche" von Alisdair Meredith ist zumindest ein Teil der Antwort. Im Grunde, viele algorithmen zurück Paare von Iteratoren, die sind tatsächlich nicht garantiert werden gültig, reicht. Es scheint, Sie entfernt die Unterstützung für pair<iterator,iterator> aus dem-Bereich Schleife aus diesem Grund. Allerdings ist die vorgeschlagene Lösung nicht vollständig angenommen.

Wenn Sie wissen, für bestimmte, dass ein paar von Iteratoren wirklich bedeutet, ein zulässiger Bereich dann könnten Sie wickeln Sie Sie in einem benutzerdefinierten Typ, bietet begin()/end() member-Funktionen:
```
template<class Iter>
struct iter_pair_range : std::pair<Iter,Iter> {
    iter_pair_range(std::pair<Iter,Iter> const& x)
    : std::pair<Iter,Iter>(x)
    {}
    Iter begin() const {return this->first;}
    Iter end()   const {return this->second;}
};

template<class Iter>
inline iter_pair_range<Iter> as_range(std::pair<Iter,Iter> const& x)
{ return iter_pair_range<Iter>(x); }

int main() {
    multimap<int,int> mm;
    ...
    for (auto& p : as_range(mm.equal_range(42))) {
       ...
    }
}
```
(ungetestet)

Ich Stimme das ist ein bisschen wie eine Warze. Funktionen, die Rückkehr gültigen Bereiche (wie equal_range) sagen sollte also mit einer entsprechenden Rückgabetyp. Es ist ein bisschen peinlich, dass wir manuell zu bestätigen, diese über so etwas wie as_range oben.
- boost::Reihe macht genau das. mit boost;:Palette, anstatt etwas handschriftliche vorzuziehen. [1]: boost.org/doc/libs/1_53_0/libs/range/doc/html/range/reference/...
- Meredith identifiziert nur 5 Bibliothek Funktionen, die von diesem problem betroffen. Wäre es nicht einfacher für Sie, um einfach diese Funktionen garantieren gültigen Bereiche, anstatt erweitern das Typ-system? Ich bin mir nicht wirklich sicher, ob ich sehen, wie diese neue Art wirklich löst ohnehin nichts; man kann immer noch das erstellen einer Instanz eines mit Iteratoren, die nicht mit einer gültigen Bereichs.
- Ich denke, das Hauptproblem ist, dass es viele der bestehenden Anwendungs-code verwendet-pair-Mädchen für andere Zwecke (dies würde wahrscheinlich ungewöhnlich sein angesichts des ephemeren Natur von Iteratoren, aber Sie könnte sich vorstellen, eine Karte von Iteratoren zu Iteratoren zum Beispiel). Die Definition eines separaten Typ für einen iterator-Bereich macht, der seinen Zweck klar und garantiert wird es keine unerwarteten Nebenwirkungen von bereits bestehenden Anwendungs-code.
- boost::make_iterator_range macht das selbe wie die Sache für Sie. Ich verstehe, dass dieser code ist für die Ausstellung nur.
InformationsquelleAutor sellibitze
8

Können Sie boost::make_iterator_range.
Es erstellt eine iterator_range mit begin() und end() Methoden.
boost::make_iterator_range akzeptieren kann std::pair von Iteratoren.

InformationsquelleAutor mgsergio
6

aufbauend auf die obige Antwort, die mit c++11 Optimierungen:
```
#include <utility>

template<class Iter>
struct range_t : public std::pair<Iter, Iter> {
    using pair_t = std::pair<Iter, Iter>;
    range_t(pair_t&& src)
    : std::pair<Iter, Iter>(std::forward<pair_t>(src))
    {}

    using std::pair<Iter, Iter>::first;
    using std::pair<Iter, Iter>::second;

    Iter begin() const { return first; }
    Iter end() const { return second; }
};

template<class Iter>
range_t<Iter> range(std::pair<Iter, Iter> p) {
    return range_t<Iter>(std::move(p));
}

template<class Iter>
range_t<Iter> range(Iter i1, Iter i2) {
    return range_t<Iter>(std::make_pair(std::move(i1), std::move(i2)));
}


//TEST: 

#include <iostream>
#include <set>
using namespace std;

int main() {

    multiset<int> mySet { 6,4,5,5,5,3,3,67,8,89,7,5,45,4,3 };

    cout << "similar elements: ";
    for (const auto&i : range(mySet.lower_bound(5), mySet.upper_bound(10))) {
        cout << i << ",";
    }
    cout << "\n";

    int count = 0, sum = 0;
    for (const auto& i: range(mySet.equal_range(5)))
    {
        ++count;
        sum += i;
    }
    cout << "5 appears " << count << " times\n"
    << "the sum is " << sum << "\n";

return 0;
}
```
- Funktioniert sehr gut, kleinere Haarspalterei - posix behält sich das postfix -_t. Siehe: Was sind die Regeln über die Verwendung eines Unterstriches in einem C++ - Bezeichner?.
- "Namen, enden mit" _t " sind reserviert für weitere Typ-Bezeichnungen." range_t<> ist ein Typ. Also alles ist gut 🙂
- Aus der verlinkten Antwort - "Einige zusätzliche Klassen von Bezeichner-Namen sind reserviert für künftige Erweiterungen der Sprache C oder POSIX.- 1-Umfeld. Während Sie mit diesen Namen für Ihre eigenen Zwecke Recht jetzt vielleicht nicht ein problem verursachen, Sie erhöhen die Möglichkeit von Konflikten mit zukünftigen Versionen der C-oder POSIX-standards, so dass Sie sollten es vermeiden, diese Namen." Also, nur weil Sie es sind, die für eine Art nicht verhindern, dass eine mögliche zukünftige Konflikte.
- Mit Respekt denke ich, werden Sie finden, dass eine zukünftige _t-Typ-Namen werden in die std:: - namespace. Das suffix _t ist reserviert für Arten - im Gegensatz zu den Instanzen von Typen. Also das ist falsch: int my_int_t; - und dies ist Recht: struct my_tag_t {};
- Ehrlich gesagt Nein, POSIX erhebt den Anspruch auf alle Bezeichner mit dem Suffix _t finden Sie unter GNU - Reservierte Namen. Also POSIX hält sich frei, jetzt oder zu irgendeinem Zeitpunkt in der Zukunft, deklarieren Sie eine neue Art mit diesem suffix im globalen namespace. POSIX ist kein C++, also eine neue Art nicht geschachtelt std es wird global sein. Wenn dieser Typ Konflikt mit einer Art in eine bestehende Codebasis, dann, dass die codebase ist als (und schon immer) in der falschen nicht spielen nach den Regeln.
- hmm. in diesem Fall posix-im Einklang mit einem großen Teil der boost-library und einige ziemlich einflussreiche c++ - Entwickler. Ich denke, wenn wir wollen super-sicher können wir behaupten, dass ein _t auf eine Art ist zulässig, in jedem anderen namespace als der Globale namespace - denn das ist der einzige, der eventuell verschmutzt sein, von c (und damit posix) - code.
- Dieses "kleine Haarspalterei" gegangen ist, ein bisschen weiter als gedacht ;-). Ich Stimme völlig zu, dass viele Entwickler angenommen haben, die Konvention. Persönlich ich vermeiden, dass das suffix, zum Beispiel in der übernahme der Lösung, die ich verwendet struct range, und make_range für die Kostenlose Funktionen. Aber das ist ein Fall von irrenden auf der Seite des seins besonders vorsichtig sein.
- Die Diskussion war hilfreich, ich habe etwas gelernt 🙂 ich mag das suffix _t wie es erlaubt mir, zu behaupten, dass der name ist eine Art in eine unaufdringliche Art und Weise. Ich ganz gerne mit lower_case_names in c und c++ aber ich finde Sie einfacher und natürlicher zu Lesen als camelCaps. Ich habe auch oft Namen funktoren wie diese: struct do_something_f; zu behaupten, dass es ein function-Objekt.
- Der ctor von pair_t ist unter einer rvalue-Referenz und damit bindet nur an rvalues. Es ist keine universal - /forwarding-Referenz, weil das argument es nicht herausgeführt. Die std::forward Aufruf übergeben wird, eine nicht-Referenz-Typ, so bedingungslos bewegt. Das ist ok, aber möchten Sie wahrscheinlich zu akzeptieren lvalues, zu.
- Ja, die. Für eine move-würdig argument geben Sie den ctor ist, sollte ein Wert nicht ein. - ref. Obwohl ich Frage das tun müssen beliebiger move Zeug mit Iteratoren; es ist wahrscheinlich nicht Wert. Tun alle Iteratoren sinnvolle move-Semantik?
InformationsquelleAutor Richard Hodges

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.