On Wed, Sep 21, 2016 at 08:57:01AM +0200, Olivier Goffart wrote:
> > No, it's not. It's changing undefined behavior into defined
> > behavior.
> 
> But in many case, we want to put something in a QVariant, and we
> never compare this variant.  Forbidding types that do not have an
> operator== to be in a QVariant might be to strict.

Forbidding types without operator== in QVariants is not needed,
not even if one wanted to use associative container with 
QVariants as keys.

[Pseudocode]

bool operator(QVariant(Foo) a, QVariant(Bar) b)
{
    if Foo != Bar:
        return false
    if Foo has no operator==():
        return true
    return (Foo)a == (Foo)b
}

establishes an equivalance relation by lumping all "uncomparable"
objects into a single equivalency class.

One might argue that considering all instances of classes without
operator== as equal makes associative containers of them not
exactly useful, but it is at least formally correct, defined
behaviour and can be easily turned into correct, defined and
useful behaviour by the user himself by providing some operator==
for his types.

This is certainly better than the current behaviour that is not
exactly useful[1], formally incorrect, undefined and unfixable from
the user side.

Andre'


[1] "Not exactly useful" e.g. as in "funny effects like the number
of elements in an associative container depending on the insertion
order":

int main()
{
    QVariant v1('a'), v2(QChar('a')), v3(QString("a"));

    QMap<QVariant, int> maps[] = {
        { {v1,1}, {v2,1}, {v3,1} }, { {v1,1}, {v3,1}, {v2,1} },
        { {v2,1}, {v1,1}, {v3,1} }, { {v2,1}, {v3,1}, {v1,1} },
        { {v3,1}, {v1,1}, {v2,1} }, { {v3,1}, {v2,1}, {v1,1} }
    };
    
    for (auto h : maps)
        qDebug() << h.size();
}

-> 2 2 1 1 2 2


_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to