binary_negate im Komparator angeben funktioniert nicht

lolz

Kommentier mal die For-Schleife aus und nachdem es dann kompiliert schau dir nochmal genau an was für einen Iteratortyp du für iter angegeben hast.

LordJaxom

Es kommt noch dazu dass binary_negate keinen Konstruktor mit Null Parametern hat. Und da der Konstruktor von set< T, Comp > als Default für den ersten Parameter nunmal Comp() hat, klappt das nicht.

gh0st124

Danke für die Antworten.

Der Hauptgrund ist also

binary_negate erfüllt in Kombination mit less (also die Strict Weak Ordering nicht, weil z.B. reflexiv.
---
das stimmt nicht ganz-> s.nächsten Beitrag

gh0st124

CStoll schrieb:

Erstens: Die Negation von less<> ist kein legaler Vergleichsoperator für set's (>= ist keine strikte Ordnung).

Ich habe jetzt folgendes ausprobiert: ich habe den Funktor greater_equal (keine strikte Ordnung) benutzt und alles funktioniert wunderbar. Anscheinend hat das nichts damit zu tun.

LordJaxom Argument gefällt mir da schon besser: binary_negate hat keinen Default-Konstruktor und Comp() findet diesen nicht.

camper

gh0st124 schrieb:

Ich habe jetzt folgendes ausprobiert: ich habe den Funktor greater_equal (keine strikte Ordnung) benutzt und alles funktioniert wunderbar.

Dann versuch mal ein Element wiederzufinden.

CStoll

gh0st124 schrieb:

CStoll schrieb:

Erstens: Die Negation von less<> ist kein legaler Vergleichsoperator für set's (>= ist keine strikte Ordnung).

Ich habe jetzt folgendes ausprobiert: ich habe den Funktor greater_equal (keine strikte Ordnung) benutzt und alles funktioniert wunderbar. Anscheinend hat das nichts damit zu tun.

Der Compiler kann leider nicht überprüfen, ob dein Prädikat die Anforderungen erfült, eine "strict weak ordering" zu sein - der würde auch ein set<int,equal<int>> durchgehen lassen. Das Problem dabei ist, daß du mit einem ungeeigneten Vergleichskriterium nichts mehr findest (set<T,Pred> definiert "gleich" als !Pred(x,key)&&!Pred(key,x) )

gh0st124

camper schrieb:

gh0st124 schrieb:

Ich habe jetzt folgendes ausprobiert: ich habe den Funktor greater_equal (keine strikte Ordnung) benutzt und alles funktioniert wunderbar.

Dann versuch mal ein Element wiederzufinden.

klappt ohne Probleme:

set<int, greater_equal<int> > m;
    m.insert(3);
    m.insert(4);
    m.insert(1);
    m.insert(1);
    m.insert(5);
    set<int, greater_equal<int> >::iterator f = find(m.begin(), m.end(), 1);
    if (f != m.end())
        cout << *f << " gefunden!\n";
    for (set<int, greater_equal<int> >::iterator iter = m.begin(); iter != m.end(); iter++)
        cout << *iter << endl;

Ausgabe:

1 gefunden!
5
4
3
1
1

WARUM muss es denn unbedingt eine Strict weak ordering sein? Wann geht es denn bei greater_equal(<- Keine Strict Weak Ordering) schief?

camper

versuch mal das hier:

#include <set>
#include <cmath>
#include <functional>
#include <algorithm>
#include <ctime>
#include <iostream>
using namespace std;

int main()
{
    srand( time( 0 ) );

    typedef set<int, greater_equal<int> > set_type;

    set_type s;

    for ( int i = 0; i < 5000; ++i )
        s.insert( rand() );

    int count = 0;

    for ( set_type::iterator i = s.begin(); i != s.end(); ++i )
        if ( s.count( *i ) == 1
            && s.find( *i ) == i
            && s.lower_bound( *i ) == i
            && distance( i, s.upper_bound( *i ) ) == 1 )
            ++count;

    cout << count << " von " << s.size() << " richtig gefunden\n";
}

bei mir steigt das im debug Modus mit einem assert aus, ohne dieses geht es ab in die ewigen Jagdgründe.

CStoll

Die set<> verwaltet ihre Elemente in einem (balancierten) binären Suchbaum - alle Elemente links sind "kleiner", alle Elemente rechts "größer" als das Wurzelelement ("kleiner" und "größer" wird durch das verwendete Prädikat definiert). Gleichheit zwischen Elementen gilt, wenn keins von beiden "kleiner" ist als das andere.

Bei einer strikten Ordnung R gilt für zwei beliebige Werte x und y grundsätzlich eine der Beziehungen "x R y", "y R x" oder "x =_R y", auf dieser Voraussetzung arbeitet set<>. Bei einer Halbordnung gilt das nicht mehr - was unter Umständen zu Problemen führen könnte.

hustbaer

gh0st124 schrieb:

camper schrieb:

gh0st124 schrieb:

Ich habe jetzt folgendes ausprobiert: ich habe den Funktor greater_equal (keine strikte Ordnung) benutzt und alles funktioniert wunderbar.

Dann versuch mal ein Element wiederzufinden.

klappt ohne Probleme:
set<int, greater_equal<int> > m;
    m.insert(3);
    m.insert(4);
    m.insert(1);
    m.insert(1);
    m.insert(5);
    set<int, greater_equal<int> >::iterator f = find(m.begin(), m.end(), 1);
    if (f != m.end())
        cout << *f << " gefunden!\n";
    for (set<int, greater_equal<int> >::iterator iter = m.begin(); iter != m.end(); iter++)
        cout << *iter << endl;
Ausgabe:

1 gefunden!
5
4
3
1
1

WARUM muss es denn unbedingt eine Strict weak ordering sein? Wann geht es denn bei greater_equal(<- Keine Strict Weak Ordering) schief?

Du siehst an der Ausgabe schon dass es nicht funktioniert. Würde es funktionieren dürfte die 1 nur 1x vorkommen - ist ja schliesslich