Em sexta-feira, 3 de março de 2017, às 11:02:18 PST, Lars Knoll escreveu:
> > On 3 Mar 2017, at 16:54, Marc Mutz wrote:
> >
> > On Friday 03 March 2017 16:11:54 Thiago Macieira wrote:
> >> But we should not add more global tables.
> >
> > Apart from "Thiago says so", are there any reasons for th
> On 3 Mar 2017, at 16:54, Marc Mutz wrote:
>
> On Friday 03 March 2017 16:11:54 Thiago Macieira wrote:
>> But we should not add more global tables.
>
> Apart from "Thiago says so", are there any reasons for this?
How about: "Lars agrees with Thiago"? ;-)
More seriously: constant global table
On Friday 03 March 2017 16:11:54 Thiago Macieira wrote:
> But we should not add more global tables.
Apart from "Thiago says so", are there any reasons for this?
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB
Em sexta-feira, 3 de março de 2017, às 03:19:42 PST, Marc Mutz escreveu:
> The simplest implementation of an immutable class that cannot or should not
> contain all state inline (like QRect) is an int +
> Q_GLOBAL_STATIC(Container). If you put all init code into the ctor of the
> Container class, t
On 3 March 2017 at 11:33, Marc Mutz wrote:
> On Friday 03 March 2017 10:43:56 Richard Moore wrote:
> [...]
> > QSslCipher should be an integer index into a table. The
> > fact that it isn't is a poor workaround for weak API from openssl
>
> Would you mind to expand on that? I don't see any a-pri
On Friday 03 March 2017 13:37:36 Olivier Goffart wrote:
> On Freitag, 3. März 2017 12:19:42 CET Marc Mutz wrote:
> > But don't - ever- use ref-counting on immutable classes. It's not easier
> > (you need to implement all the special member functions, which peoole, me
> > included[1][2], get wrong m
On Freitag, 3. März 2017 12:19:42 CET Marc Mutz wrote:
> But don't - ever- use ref-counting on immutable classes. It's not easier
> (you need to implement all the special member functions, which peoole, me
> included[1][2], get wrong more often than we dare to admit).
refcounting is easy:
class
On Friday 03 March 2017 10:43:56 Richard Moore wrote:
[...]
> QSslCipher should be an integer index into a table. The
> fact that it isn't is a poor workaround for weak API from openssl
Would you mind to expand on that? I don't see any a-priori reason why
QSslCipher can't be fixed to contain an
On Friday 03 March 2017 10:59:21 Lars Knoll wrote:
> I agree, that we should not use any implicit sharing in those cases. But in
> many cases, I don’t see a problem using a pointer to the data. Of course
> if shouldn’t detach. Instead, it should be explicitly shared (with or
> without refcounting d
On 03/03/2017 10:59, Lars Knoll wrote:
I agree, that we should not use any implicit sharing in those cases.
But in many cases, I don’t see a problem using a pointer to the data.
Of course if shouldn’t detach. Instead, it should be explicitly
shared (with or without refcounting depending on whet
I agree, that we should not use any implicit sharing in those cases. But in
many cases, I don’t see a problem using a pointer to the data. Of course if
shouldn’t detach. Instead, it should be explicitly shared (with or without
refcounting depending on whether the data is generated at compile or
On 3 March 2017 at 07:30, Marc Mutz wrote:
> Bad example: QSslCipher. Look at all the messy API that just deals with the
> fact it's pimpled. That class is particularly hideous because it allocates
> memory on every copy!
>
>
Please avoid using the SSL code as the example since you don't really
Hi,
If you have a class that just represents a concrete immutable entity, like
some system resource's ID, or an SSL elliptic curve algorithm, you can use an
enum.
Or you can use a class, if you want some richer API than can be had with an
enum.
In that case, however, *don't* use a Private poi
13 matches
Mail list logo
