bool equal = std::all_of(c.begin(), c.end(), [&c] (T elem) { return elem == c.front(); });

Es gibt viele Möglichkeiten, aber die anderen scheinen mir noch komplizierter, weil man zusätzlich einen Iterator vergleichen muss. Würdet ihr eine herkömmliche Schleife verwenden?

- z0r0id

bool equal = std::count(c.begin(), c.end(), c.front()) == c.size();

Allerdings müssen hier in jedem Fall alle Elemente durchlaufen werden.

- z0r0id

Nachteil ist aber, dass bei nem leeren Container true herauskommt, jdf. bei meinem Test.

Nachteil ist aber, dass bei nem leeren Container true herauskommt, jdf. bei meinem Test.

Was soll denn sonst rauskommen? Es sind doch alle Elemente gleich.

c.empty() || std::equal(std::begin(c), std::prev(std::end(c)), std::next(std::begin(c)));
// bzw.
!c.empty() && std::equal(std::begin(c), std::prev(std::end(c)), std::next(std::begin(c)));

vor. Wobei die Semantik subtil anders ist, wenn operator== nicht transitiv ist, aber in dem Fall hat man sowieso ein Definitionsproblem und muss genauer nachdenken.

Nachteil ist aber, dass bei nem leeren Container true herauskommt, jdf. bei meinem Test.

Ist konsistent mit der Mathematik.

Nachteil ist aber, dass bei nem leeren Container true herauskommt, jdf. bei meinem Test.

Ist konsistent mit der Mathematik.

Man definiert schließlich das Gleichsein aller Elemente auch so, dass es nicht zwei Elemente gibt die verschieden sind.

Ich werfe auch noch

std::mismatch( std::begin(c), std::end(c), std::next(std::begin(c)), std::end(c) ).first == std::end(c)

in den Ring. (Ungetestet)

Edit: Keine Ahnung, was die Lösung, soll, das ist eigentlich nur seldons aber Invers (Teste nicht ob alle gleich sind sondern finde den ersten Mismatch).

Man definiert schließlich das Gleichsein aller Elemente auch so, dass es nicht zwei Elemente gibt die verschieden sind.

Waehle eine Erklaerung aus: http://math.stackexchange.com/questions/202452/why-is-predicate-all-as-in-allset-true-if-the-set-is-empty (Moege es nicht die rockenden Kinder sein).

Nochwas komplett unnötiges, das mir aufgefallen ist: Bei

std::count(c.begin(), c.end(), c.front()) == c.size();

ist oberlästig, dass ich eine Compilerwarnung wegen signed/unsigned-Konflikt erhalte. Wer hatte wieder die brilliante Idee, in std::count() einen anderen Typen als std::size_t zurückzugeben? Wie oft sind Anzahlen negativ?

- z0r0id

Danke für die Ideen. Ich muss sagen, sowas simples wie zu prüfen, ob alle Elemente gleich sind, ist wahnsinnig kompliziert in C++.

Nur weil es viele Moeglichkeiten gibt? Nein. Was soll an deiner Variante 1 kompliziert sein?

Wie oft sind Anzahlen negativ?

Der Klassiker:
Ein Ingenieur, ein Physiker und ein Mathematiker beobachten einen Aufzug, und sehen, wie im Erdgeschoss zwei Leute in den Aufzug einsteigen, und im ersten Stock drei aussteigen.
Meint der Ingenieur: "Da war wohl schon einer im Aufzug!"
Der Physiker: "Das muss ein Messfehler sein!"
Und der Mathematiker: "Wenn jetzt einer in den Aufzug einsteigt, ist der Aufzug leer!"

bool all_equal( const std::vector<int>& v )
{
   typedef std::vector<int>::iterator iterator;
   typedef std::pair<interator,iterator> iter_pair;

   if( !v.empty() )
   {
      iter_pair p = equal_range( begin( v ), end( v ), v.front() );
      return p.first == begin( v ) && p.second == end( v );
   }
   return true;
}

PS:
Ist auch nicht eleganter als std::mismatch ...

Kommt ohne Schleife aus

pardon? Intern...?

Was ist mit equal_range ? Kommt ohne Schleife aus und terminiert beim ersten Mismatch.

Ich glaub ich würd dich zur Erschießung vorschlagen, wenn du mir sowas anbötest.

Was ist mit equal_range ? Kommt ohne Schleife aus und terminiert beim ersten Mismatch.

1. Nur für sortiert
2. equal_range nutzt intern lower_bound und upper_bound, was der binary-search-Version von find entspricht. Man hätte also keinen Gewinn, nur mehr overhead.

krümelkacker schrieb:

Bieten die STL Container -- ausgenommen vielleicht unordered_* -- nicht von sich aus schon relationale Operatoren an?!

Nur für Vergleiche zwischen zwei Containern. Hier geht es aber darum, die Elemente innerhalb eines Containers zu vergleichen.

mismatch ist schon das Beste.

pardon? Intern...?

Interessiert niemanden, alle vorgeschlagenen Moeglichkeiten basieren auf Schleifen. Koennten aber auch end-rekursiv implementiert sein. Duerfen sie laut Standard rekursiv sein?

Sone schrieb:

pardon? Intern...?

Interessiert niemanden, alle vorgeschlagenen Moeglichkeiten basieren auf Schleifen. Koennten aber auch end-rekursiv implementiert sein. Duerfen sie laut Standard rekursiv sein?

Except where explicitly specified in this standard, it is implementation-defined which functions in the Standard C++ library may be recursively reentered.

Das ist alles, was überhaupt zu Rekursion in dem Library-Abschnitt steht.

Also ja, das dürfen sie wahrscheinlich. Ist schließlich alles Implementationsspezifisch.

Sonst geht's wohl nicht einfacher als mit nem std::algorithm + nem kleinen Lambda, ich bin immer noch für V1.

Auch wenn ein QC-Kommentar in allen Fällen sowieso angebracht ist.

Ich finde seldons Variante am elegantesten.

Ja, du findest Write-Only-Code generell elegant Ich musste seldons Code etwa 20 Sekunden lang anschauen, bis ich verstanden habe, was er überhaupt tut. Die zusätzliche Abfrage auf empty() verwirrt nur noch mehr.

krümelkacker schrieb:

Bieten die STL Container -- ausgenommen vielleicht unordered_* -- nicht von sich aus schon relationale Operatoren an?!

Was bringt das hier? Um zwei Container zu vergleichen, müsste ich ja eine Kopie erstellen.

knivil schrieb:

Nur weil es viele Moeglichkeiten gibt? Nein. Was soll an deiner Variante 1 kompliziert sein?

Nein, weil die simpelste Möglichkeit bereits Lambda-Ausdrücke (mit Capture) erfordert. Schlussendlich hat man recht viel Boilerplate-Syntax.

Ausserdem drückt man mit ihr aus: "prüfe für alle Elemente, ob sie gleich dem ersten Element sind". Das ist aber ein Implementierungsdetail, schöner wäre "prüfe alle Elemente auf Gleichheit". Muss ich halt selbst eine Abstraktionsebene höher schreiben.

Eisflamme schrieb:

ich bin immer noch für V1.

Ja, ich machs jetzt auch so, kleinstes Übel. Oder bei Negation mit std::any_of und !=.

- z0r0id

Ja, du findest Write-Only-Code generell elegant

Nein. Schon gar nicht in Anwendungscode. Ich finde nur die Syntax von Lambdas (gerade so direkt in der Argumentenliste) sehr hässlich und nicht literarisch.

Ich musste seldons Code etwa 20 Sekunden lang anschauen, bis ich verstanden habe, was er überhaupt tut.

Ich nicht, ich kenne den Trick schon längst. Und den STL-Algorithmus.

Die zusätzliche Abfrage auf empty() verwirrt nur noch mehr.

Hä? Die ist nur optional, für alle die es so brauchen.

std::all_of(c.begin(), c.end(), [&c] (T elem) { return elem == c.front(); })

vs

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

Das ist doch kein Vergleich.
Mit using namespace std; davor:

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

Kommentiert muss der Code in beiden Fällen werden.

Nein, weil die simpelste Möglichkeit bereits Lambda-Ausdrücke (mit Capture) erfordert. Schlussendlich hat man recht viel Boilerplate-Syntax

Akzeptiert, lambda ist tatsaechlich Boilerplate.