Alle Elemente im Container gleich?

[Sone]

otze schrieb:

Sone schrieb:

Kommentiert muss der Code in beiden Fällen werden.

Es geht hier nicht um die Codelänge.

Darum ging es mir gar nicht! Ich habe das nur angemerkt, dass sie kommentiert werden sollten.

Selbst mit Kommentar schaut man eine Weile drauf, bevor man kapiert, was da abgeht.

Genau dafür sind Kommentare da: Man muss die Zeile gar nicht angucken, das Kommentar sagt, was sie tun.

[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.