On quarta-feira, 11 de janeiro de 2017 10:27:50 PST Hamish Moffatt wrote:
> Qt 5.7 requires at least OS X 10.8 to run though, according to
> https://wiki.qt.io/Qt-5.7.0-tools-and-versions . I'm not sure why.
Because we dropped support by removing deprecated function calls.
Qt 5.8 requires 10.9 an
On 03/01/17 09:25, René J. V. Bertin wrote:
Thiago Macieira wrote:
Qt 5.7 and up requires C++11, including initialiser lists.
FWIW: I understand that should be available even on OS X 10.7 when you install a
recent libc++ and clang compiler. Not for the faint of heart, and it won't
compensate f
Thiago Macieira wrote:
> Qt 5.7 and up requires C++11, including initialiser lists.
FWIW: I understand that should be available even on OS X 10.7 when you install
a
recent libc++ and clang compiler. Not for the faint of heart, and it won't
compensate for any missing ObjC features.
___
Roger Leigh wrote:
> Which versions are you referring to, specifically?
I am not sure and haven't yet had the time to see if I can figure out under
what
circumstances I had to work around lack of initialiser list support. It's
possible this was on 10.6 but it's also possible it was in Qt4-base
On Mon, Jan 2, 2017 at 4:45 PM, René J.V. Bertin
wrote:
>
> What, you mean that inserting 0 items will finish at an infinitely long
> ago moment? ;)
>
Oh, I've never thought about it, but sounds legit. :)
___
Interest mailing list
Interest@qt-project.or
02.01.2017, 16:16, "Thiago Macieira" :
> On segunda-feira, 2 de janeiro de 2017 12:36:10 BRST Shawn Rutledge wrote:
>> It’s an interesting point though, if you have a fixed set of data then you
>> could use a perfect hash and a perfect number of buckets. There’s
>> undoubtedly some other libra
actually yes... you can insert 0 elements even repeatedly (finitely often).
At no *finitely long ago* moment you had to wait for this to finish...
Am 02.01.2017 um 17:45 schrieb René J.V. Bertin:
> On Monday January 02 2017 16:50:12 Konstantin Shegunov wrote:
>
>> I assume the choice of underlyin
On Monday January 02 2017 16:50:12 Konstantin Shegunov wrote:
> I assume the choice of underlying data structure was made so even in the
> worst case scenario the complexity is logarithmic, in contrast with QHash
What, you mean that inserting 0 items will finish at an infinitely long ago
moment?
On segunda-feira, 2 de janeiro de 2017 15:18:48 BRST René J. V. Bertin wrote:
> Konstantin Shegunov wrote:
> > Then I'd vote for Thiago's solution. The only drawback with it is that it
> > requires C++11 support, but that should be available pretty much anywhere
> > nowadays.
>
> Still quite a siz
On segunda-feira, 2 de janeiro de 2017 15:15:11 BRST René J. V. Bertin wrote:
> Thiago Macieira wrote:
>
> Oops, I didn't see all replies before answering to Konstantin..
>
> > The closest thing you have is the std::initializer_list constructor:
> >
> > static const QHash data = {
> > { Value1,
On Mon, Jan 2, 2017 at 4:47 PM, René J.V. Bertin
wrote:
>
> And that seems surprising, one could expect it to be more efficient to add
> items sequentially to a list that would maintain a sequential order anyway.
> But I'll take your word for it, I'm not a computer scientist by any kind of
> forma
On Monday January 02 2017 16:37:50 Konstantin Shegunov wrote:
> The remark is relevant for "larger" sets of data. For micro maps it
> probably doesn't matter.
That seemed (and seems) evident.
> Anyway, QMap is a balanced binary tree, so
> inserting items sorted by key sequentially would cause it
On 02/01/2017 14:18, René J. V. Bertin wrote:
Konstantin Shegunov wrote:
Then I'd vote for Thiago's solution. The only drawback with it is that it
requires C++11 support, but that should be available pretty much anywhere
nowadays.
Still quite a sizeable population of users of older Mac OS X v
On Mon, Jan 2, 2017 at 4:27 PM, René J. V. Bertin
wrote:
> Still quite a sizeable population of users of older Mac OS X versions out
> there,
> who don't have proper C++11 support unless they do a libc++ conversion
> hack. And
> even then I'm not 100% sure that initialiser lists are available and
Konstantin Shegunov wrote:
> (a static array should serve you perfectly fine).
Yes, true. Presuming the enum values assigned by the compiler and thus 0-based
and incremented by 1.
> It would mean the binary tree to be degenerate, and
> ultimately you'd get a rebalancing with each insert.
I did
On Mon, Jan 2, 2017 at 4:15 PM, René J. V. Bertin
wrote:
>
> > Note that all of this is constructed at *load* time, not at compile time
> and
> > not on first use.
>
> so it doesn't work like a classical static variable which is initialised
> only
> once, presuming you meant to say "not on first u
Konstantin Shegunov wrote:
> Then I'd vote for Thiago's solution. The only drawback with it is that it
> requires C++11 support, but that should be available pretty much anywhere
> nowadays.
Still quite a sizeable population of users of older Mac OS X versions out
there,
who don't have proper C
On Mon, Jan 2, 2017 at 4:02 PM, René J.V. Bertin
wrote:
>
> QMap dict = { {Enum1, QStringLiteral("Enum1")}, {Enum2,
> QStringLiteral("Enum2")} };
>
As a side note, if your enums are sequential and starting from 0, as most
are, my advice is not to use QMap (a static array should serve you
perfectl
Thiago Macieira wrote:
Oops, I didn't see all replies before answering to Konstantin..
> The closest thing you have is the std::initializer_list constructor:
>
> static const QHash data = {
> { Value1, "Value1" },
> { Value2, "Value2" }
> };
That's exactly what I was thinking about, and expecti
On Mon, Jan 2, 2017 at 4:02 PM, René J.V. Bertin
wrote:
>
> Yes and no. Behind the scenes the code would of course look much like
> that, but in user code I was thinking along the lines of
> [snippet]
>
That's easily achieved by a rather trivial inline function returning a
reference to the hash (
On Monday January 2 2017 14:36:03 Konstantin Shegunov wrote:
>Do you mean something like this?
>It isn't exactly pretty but should work okay.
Yes and no. Behind the scenes the code would of course look much like that, but
in user code I was thinking along the lines of
QMap dict = { {Enum1, QSt
On segunda-feira, 2 de janeiro de 2017 13:02:12 BRST René J.V. Bertin wrote:
> Hi,
>
> I must be overlooking or even forgetting something: is there a way to
> initialise a QMap or QHash instance with a static table, say when you're
> creating a fast lookup dictionary mapping enums or preprocessor
On segunda-feira, 2 de janeiro de 2017 12:36:10 BRST Shawn Rutledge wrote:
> It’s an interesting point though, if you have a fixed set of data then you
> could use a perfect hash and a perfect number of buckets. There’s
> undoubtedly some other library which can do that.
It's called gperf.
--
T
Do you mean something like this?
enum MyEnum {
Enum1, Enum2
};
static struct _hashInit {
_hashInit()
{
MyEnum myEnumTable[] = {
Enum1, Enum2
};
QString myStringTable[] = {
QStringLiteral("Enum1"), QStringLiteral("Enum2")
> On 2 Jan 2017, at 13:02, René J.V. Bertin wrote:
>
> Hi,
>
> I must be overlooking or even forgetting something: is there a way to
> initialise a QMap or QHash instance with a static table, say when you're
> creating a fast lookup dictionary mapping enums or preprocessor tokens to a
> QStr
Hi,
I must be overlooking or even forgetting something: is there a way to
initialise a QMap or QHash instance with a static table, say when you're
creating a fast lookup dictionary mapping enums or preprocessor tokens to a
QString?
That's information known a compile time so I was expecting to
26 matches
Mail list logo
