Em domingo, 16 de abril de 2017, às 23:02:15 PDT, Jason H escreveu:
> You're right I don't know how C++ handles virtuals, but should I care? This
> is OOP, I want to use OOP. You're telling me that because the
> language/compiler implements something poorly, that I can't use OOP?
To make a long st
Op 17/04/2017 om 08:02 schreef Jason H:
> Maybe templates are the way to go. But I just had to change some lines
> because I was using vectors and Qt was using QList. I'd like to eliminate the
> need/cost for QList::toVector() and QVector::toList(). If there was a base
> that provided the basi
Maybe templates are the way to go. But I just had to change some lines because
I was using vectors and Qt was using QList. I'd like to eliminate the need/cost
for QList::toVector() and QVector::toList(). If there was a base that provided
the basics so that I don't have to worry about it's repres
Em domingo, 16 de abril de 2017, às 18:25:49 PDT, Jason H escreveu:
> I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point,
> etc]) don't use an interface? I recently moved some code from ints to
> floats, and I had to change far more code than I should have had to.
If you're th
On 17 April 2017 at 13:25, Jason H wrote:
> I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point,
> etc]) don't use an interface?
> I recently moved some code from ints to floats, and I had to change far more
> code than I should have > had to.
>
> My proposal is to change QR
You're going a lot a mental masturbation there. While it's a lot of fun, it
would be a tremendous effort to make . those sweeping changes. I would focus on
how to to get there iteratively.
A few other comments:
- C++ works the same way everywhere. It's on more platforms than Java and .NET.
- The
I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point, etc])
don't use an interface? I recently moved some code from ints to floats, and I
had to change far more code than I should have had to.
My proposal is to change QRect to QRectI, and make QRect an interface.
In the past,
On Apr 15, 2017, at 19:14, Randall O'Reilly wrote:
> On Apr 16, 2017, at 1:28 AM, Thiago Macieira
> wrote:
>>
>> Em sexta-feira, 14 de abril de 2017, às 22:38:25 PDT, Randall O'Reilly
>> escreveu:
>>> One of the major innovations in Go is that it avoids all of those problems.
>>> You only ev
Em domingo, 16 de abril de 2017, às 15:16:54 PDT, Mark Gaiser escreveu:
> Ohh, that's great!
>
> One question. Would it be possible and sane to - by default - provide
> it as the patch implements it there, but with the addition of a define
> that can influence the behavior of the iterators?
Most
Em domingo, 16 de abril de 2017, às 15:09:16 PDT, Mark Gaiser escreveu:
> On Sun, Apr 16, 2017 at 5:53 PM, Thiago Macieira
>
> wrote:
> > Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
> >> That again makes me wonder, why did Qt diverge from that?
> >
> > We didn't diver
Em domingo, 16 de abril de 2017, às 11:54:03 PDT, Ville Voutilainen escreveu:
> On 16 April 2017 at 20:51, Giuseppe D'Angelo
wrote:
> > Il 16/04/2017 18:32, Corentin ha scritto:
> >> More on point:
> >>* You don't actually need to include anything from the STL to
> >>
> >> implement std::has
On Sun, Apr 16, 2017 at 9:48 PM, Samuel Gaist wrote:
>
>> On 16 Apr 2017, at 17:53, Thiago Macieira wrote:
>>
>> Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
>>> That again makes me wonder, why did Qt diverge from that?
>>
>> We didn't diverge. We never had that. The Qt
On Sun, Apr 16, 2017 at 5:53 PM, Thiago Macieira
wrote:
> Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
>> That again makes me wonder, why did Qt diverge from that?
>
> We didn't diverge. We never had that. The Qt style predates the Standard
> Library having relevance in
> On 16 Apr 2017, at 17:53, Thiago Macieira wrote:
>
> Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
>> That again makes me wonder, why did Qt diverge from that?
>
> We didn't diverge. We never had that. The Qt style predates the Standard
> Library having relevance in
On 2017-04-16 20:54, Ville Voutilainen wrote:
On 16 April 2017 at 20:51, Giuseppe D'Angelo
wrote:
Il 16/04/2017 18:32, Corentin ha scritto:
More on point:
* You don't actually need to include anything from the STL to
implement std::hash.
You actually do: you need to see the primary temp
On 16 April 2017 at 20:51, Giuseppe D'Angelo wrote:
> Il 16/04/2017 18:32, Corentin ha scritto:
>>
>> More on point:
>>* You don't actually need to include anything from the STL to
>> implement std::hash.
>
> You actually do: you need to see the primary template for
> std::hash (otherwise you
On Sonntag, 16. April 2017 16:41:27 CEST Alberto Mardegan wrote:
> Hi all,
> I'm about to use QMimeType in my application, and I'd found it useful
> if it were a Q_GADGET. Can I just go on and submit a patch to add that,
> or are there some cons (a small increase on the library size, I assume)?
>
Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
> That again makes me wonder, why did Qt diverge from that?
We didn't diverge. We never had that. The Qt style predates the Standard
Library having relevance in Qt. When the first QHash-like class was added, it
was just like
Em domingo, 16 de abril de 2017, às 09:32:53 PDT, Corentin escreveu:
> Redundant algorithms & utilities ( mutex, shared pointer, etc ),
> should probably not exist at all at this point, though they used to make
> sense.
Note that we don't consider redundant when the Qt type provides significant
a
Il 16/04/2017 18:32, Corentin ha scritto:
>
> More on point:
>* You don't actually need to include anything from the STL to
> implement std::hash.
You actually do: you need to see the primary template for
std::hash (otherwise you can't specialize it). Also, how to implement it
is another bur
I think that part of the issue is that the way the STL should be treated is
a bit of a polarizing issue.
Of course, there are technical considerations, such as some STL
implementations being lacking on older platforms, but mostly Qt and the STL
have some overlaps, and people can't agree on how to h
Qt wasn't initially designed with STL compatibility in mind ( in the early
2000, STL support was poor on most platforms and Qt actually predates c++98
- though QMap do not, I think). - I would argue that STL compatibility is
still an issue more often than not, but it's another discussion :)
As for
Very unlikely I'd say. Hashes are used all over the place in ppl' code and
making this change will break way too much to be sensible.
On Sun, Apr 16, 2017 at 6:05 PM, Mark Gaiser wrote:
> On Sun, Apr 16, 2017 at 4:44 PM, Corentin
> wrote:
> > Funny, a friend at kdab asked me about that exact qu
On Sun, Apr 16, 2017 at 4:44 PM, Corentin wrote:
> Funny, a friend at kdab asked me about that exact question a few minutes
> ago.
> The reason for the difference is most certainly an historical one ( and
> can't be changed because it would break quite a bit of code ).
>
> If you want the same beh
Funny, a friend at kdab asked me about that exact question a few minutes
ago.
The reason for the difference is most certainly an historical one ( and
can't be changed because it would break quite a bit of code ).
If you want the same behavior, you can create a proxy for your associative
container
Hi all,
I'm about to use QMimeType in my application, and I'd found it useful
if it were a Q_GADGET. Can I just go on and submit a patch to add that,
or are there some cons (a small increase on the library size, I assume)?
In general: is it a good idea to add Q_GADGET to non QObject classes
with
On Sat, Apr 15, 2017 at 12:49:35AM +0200, Giuseppe D'Angelo wrote:
> Howdy,
>
> I'm looking for a resolution regarding the problem of including Standard
> Library headers from Qt ones. Most notably, I'd like to find a solution
> for the problems of:
>
> * Q_DECLARE_TYPEINFO over suitable Standard
Hi,
Take this simple example:
QHash test = {
{10, "aaa"},
{20, "bbb"},
{30, "ccc"}
};
for (const auto &entry: qAsConst(test)) {
qDebug() << entry;
}
It returns:
"aaa"
"ccc"
"bbb"
and the std::unordered_map version:
std::unordered_map test = {
{10, "aaa"},
{20,
On Saturday 15 April 2017 16:10:16 charleyb123 . wrote:
>
>
> Marc:
> > I know Howard's ideas about hashing, and I agree with them. In Qt, we
> > largely
> > ignore the issue of hash collisions for a given type and just hash its
> > members, combining with boost::hash_combine, and hope for the be
29 matches
Mail list logo
