[Development] Adding support for version number comparisons

Keith Gardner kreios4004 at gmail.com
Thu Jul 10 14:21:58 CEST 2014


On Sat, May 31, 2014 at 2:00 PM, Thiago Macieira <thiago.macieira at intel.com>
wrote:

> Em sex 09 maio 2014, às 11:36:08, Keith Gardner escreveu:
> > I have been working on adding a class to QtCore (QVersion) to support
> > storing version numbers, convert to/from QString, and having comparison
> > operators.  My goal was to provide an API to assist in the following use
> > cases:
> >
> >    - Plugin loading where there are multiple versions on the same system.
> >    - File format validation.
> >    - Executing an already installed command line application where the
> >    behavior is dependent on the called application's version.
> >    - Performing software installations and updates.
> >    - QMake support for version number comparisons.
> >
> > Please share other potential use cases where this might be useful.
>
> Ok, since we can't seem to agree, let's settle on the maximum common
> denominator: QVersion will only compare the numeric part of a version
> number.
> By default, two versions with the same numeric part will compare equally,
> regardless of any suffixes that may be present.
>
> Therefore, by default, given:
>         QVersion a("5.3.0");
>         QVersion b("5.3.0pl1");
>         QVersion c("5.3.0beta1");
>
>         a != b != c;            // since they aren't equal
>
>         QVersion::compare(a, b) == 0;
>         QVersion::compare(b, c) == 0;
>
>
In the review of the change, a potential issue with this form of compare
with the operators when using QVersion as the key in a QMap.  Here is the
scenario:
    QVersion a("5.3.0alpha");
    QVersion b("5.3.0beta");
    a != b; //true
    a < b; // false

    QMap<QVersion, QFoo> map;
    map[a] = foo1;
    map[b] = foo2;

With the example, map[a] now is set to "foo2" which is incorrect since 'a'
!= 'b'.  This is not an issue with QHash<QVersion, QFoo> since the suffix
is included into the hashing of a QVersion.  How should we resolve this
conflict with ordering without applying a semantic compare to the suffix?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140710/1748c9dd/attachment.html>


More information about the Development mailing list