Alle Elemente im Container gleich?

knivil

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

Ist konsistent mit der Mathematik.

Sone

knivil schrieb:

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

knivil

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

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

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

knivil

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!"

Bashar

http://stackoverflow.com/questions/7505083/why-does-the-c-standard-algorithm-count-return-a-ptrdiff-t-instead-of-size-t

DocShoe

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

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

Sone

Kommt ohne Schleife aus

pardon? Intern...?

Bashar

DocShoe schrieb:

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.

krümelkacker

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

Marthog

DocShoe schrieb:

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.

knivil

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?

Selber einen ALgo schreiben?

Sone

knivil schrieb:

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.

Eisflamme

Also wenn sortiert, würde ich einfach front() auf back()-Gleichheit prüfen.

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

Sone

Ich finde seldons Variante am elegantesten.

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

Sone schrieb:

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

Sone

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.

Sone

Kommt schon.

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.

knivil

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.