Marc Mutz wrote:
> The underlying issue is that any user-specialisation of std::hash should
> delegate to a stdlib-provided one, because implementations are free to add
> seeding, and, lacking an extra argument, the only way to incorporate the
> seed is to call a library-provided specialisation.
>
Randall O'Reilly wrote:
> One of the major innovations in Go is that it avoids all of those
> problems. You only ever write things once, in one place (no .h vs. .cpp),
> and, like an interpreted language, the only distribution mechanism *is the
> source itself*. There is no such thing as binary co
15.04.2017, 01:23, "Shawn Rutledge" :
>> On 13 Apr 2017, at 14:02, Randall O'Reilly
>> wrote:
>>
>> With the recent language explosion, there are now languages to fit
>> everyone’s biases and aesthetics.
>
> This explosion is possible because of common language backends and VMs like
> the J
Em sábado, 15 de abril de 2017, às 10:14:45 PDT, Randall O'Reilly escreveu:
> > Because there's no such thing as binary distribution in the first place.
> > That means you cannot provide a component without the source. If we
> > insisted on all Qt users simply recompiling every time that Qt changed
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 ever write things once, in one place (no .h vs. .cpp), and, like
>
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 ever write things once, in one place (no .h vs. .cpp), and, like
> an interpreted language, the only distribution mechanism *is
On Samstag, 15. April 2017 00:23:01 CEST Shawn Rutledge wrote:
[...]
> The Rust guys make the point that it’s necessary to rewrite lots of old
> stuff in Rust in order to have all the security that it can guarantee.
No, that's a common myth.
I've heard people say: "There is no point in making/usin
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 best. As
> such,
> the problem described in Paragraph 5 of
> https://iso
On Saturday 15 April 2017 14:40:40 Giuseppe D'Angelo wrote:
> Il 15/04/2017 08:15, Marc Mutz ha scritto:
> > On Saturday 15 April 2017 00:49:35 Giuseppe D'Angelo wrote:
> >> * Q_DECLARE_TYPEINFO over suitable Standard Library datatypes;
> >
> > I can only think of std::pair here, and it's done alr
Il 15/04/2017 08:15, Marc Mutz ha scritto:
> On Saturday 15 April 2017 00:49:35 Giuseppe D'Angelo wrote:
>> * Q_DECLARE_TYPEINFO over suitable Standard Library datatypes;
>
> I can only think of std::pair here, and it's done already, in qhashfunctions.h
>
> Specifically, we can say nothing about
On Saturday 15 April 2017 08:15:44 Marc Mutz wrote:
> So while it's trivial to add std::hash specialisations for something like
> [...] QSizePolicy
https://codereview.qt-project.org/191742
How to document such things with qdoc is a different question
--
Marc Mutz | Senior Software Enginee
11 matches
Mail list logo
