Alle Elemente im Container gleich?

[knivil]

Fuer intuitive bedienbare Programme gibt es auch Handbuecher. Liesst du die?

[cooky451]

Klare Sache:

std::is_sorted(c.begin(), c.end(), [] (int a, int b) { return a != b; });

Damit gibt's sogar gleich ein debug-assert sobald der Container nicht sortiert ist. Da spart man sich die manuelle Prüfung!

[knivil]

!= ist keine strikt weak ordering.

[Kellerautomat]

Also ich bin ja fuer:

begin == end || (std::sort(begin, end), std::unique(begin, end) == begin + 1)

[Sone]

@Kellerautomat: Um auch Unterstützung für nicht-RA-Iteratoren zu bekommen, nutze std::next .

[Kellerautomat]

Noe, std::sort braucht RA.

[Sone]

Kellerautomat schrieb:

Noe, std::sort braucht RA.

[cooky451]

knivil schrieb:

!= ist keine strikt weak ordering.

Daher das hilfreiche debug assert.

[Bashar]

Für Mathematiker:

set{c.begin(), c.end()}.size() <= 1

[Sone]

Bashar schrieb:

Für Mathematiker:

set{c.begin(), c.end()}.size() <= 1

Das ist schön!

[Kellerautomat]

Wie waere es mit rotate_copy + equal?

[ipsec]

Bashar schrieb:

Für Mathematiker:

set{c.begin(), c.end()}.size() <= 1

Das ist schön, aber hat unnötig hohe Komplexität und kein Short Circuit.

Sone schrieb:

equal(begin(c), prev(end(c)), next(begin(c)))

Das braucht BidirectionalIterator , theoretisch würde InputIterator ausreichen.

Ich schlage vor:

template<class InputIt]
bool all_equal(InputIt first, InputIt last) {
    if(first == last) return true;

    typedef decltype(*first) T;
    T elem = *first++;
    return find_if(first, last, [&](const T& e) { return e != elem }) == last;
}

Wenn man die Kopie vermeiden möchte, kann man e == *first als Prädikat nehmen, aber dann braucht man wieder ForwardIterator .

[Bashar]

ipsec schrieb:

Bashar schrieb:

Für Mathematiker:

set{c.begin(), c.end()}.size() <= 1

Das ist schön, aber hat unnötig hohe Komplexität und kein Short Circuit.

Ich denke mal, spätestens seit der sort-unique-Lösung sind wir beim spaßigen Teil des Abends angelangt...

[Gast]

And the winner is...

[otze]

knivil schrieb:

Noch klarer wäre allerdings eine Schleife

Jein.

Vergleich: In der Funktionalen Programmierung...

Oh Entschuldige. Ich war nicht im exakt Modus. Das haben wir gleich:

"Noch klarer wäre allerdings in C++ eine Schleife".

C++ bietet kein kurze und klare Syntax für die hier gnannten Sachen im funktionalen Programmierstil. Funktionale Programmierung in C++ ist deswegen low-level total hässlich. Natürlich verbietet dir niemand eine schön funktionale Implementation von equal_elements zu machen, aber unterhalb dieser Abstraktion ist die klarste Lösung eben die Schleife.

template<class Range>
bool all_equal(Range const& range){
    for(auto& x: range){
        if(x != range.front())
            return false;
    }
    return true;
}

[Kellerautomat]

*auto&

[otze]

Danke. kann gut sein, ich verwende keine c++11 features. Ich korrigiere das mal

[Kellerautomat]

Das verhindert, dass du die Elemente bei jedem Durchlauf kopierst.

[Bashar]

otze, ich weiß nicht, ob du knivils Argument verstanden hast. Er hat nicht gesagt, du sollst funktional programmieren. Es war eine Analogie: In der funktionalen Programmierung vermeidet man nackte Rekursion zugunsten von Funktionen höherer Ordnung; entsprechend sollte man in der imperativen Programmierung nackte Schleifen vermeiden und generische Algorithmen verwenden.

[otze]

Bashar schrieb:

entsprechend sollte man in der imperativen Programmierung nackte Schleifen vermeiden und generische Algorithmen verwenden.

Die Botschaft hör' ich wohl, allein mir fehlt der Glauben.

Man sollte erstmal das Werkzeug verwenden, welches für das Problem angemessen ist. So gut wie alle hier präsentierten Lösungen haben irgendeinen mehr oder weniger graviernden Nachteil: zu hohe Anforderungen an den Iterator, zu hohe komplexitätsklasse, kein early exit, schwer zu verstehen, komplexe Syntax.

Und ich werfe dagegen das range based for in den Ring, welches die Syntaxzucker-variante des funktional-generischen std::for_each algorithmus ist :).