Alle Elemente im Container gleich?

knivil

Keine Schleife, eher deine Variante 1. Variante 2 hat kein early exit wenn ein Element innen drin ungleich ist.

Eisflamme

Verlesen. Ja, was spricht gg Variante1?

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

Bashar

Eisflamme schrieb:

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.

Ich schlag mal

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.

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.