Can you please move this OT discussion to SG-14
(https://groups.google.com/a/isocpp.org/forum/#!forum/sg14), where it belongs?
Thanks,
Marc
On Friday 16 September 2016 22:43:39 Matthew Woehlke wrote:
> I will never, *ever* replace the PRNG shown with a high quality
> generator. The use case for
On 2016-09-05 20:02, Thiago Macieira wrote:
> Em segunda-feira, 5 de setembro de 2016, às 19:00:40 PDT, Giuseppe D'Angelo
> escreveu:
>> Il 02/09/2016 17:01, Thiago Macieira ha scritto:
>>> https://wiki.qt.io/QtCS2016_QtCore
>>>
>>> * Deprecation of APIs
>>>
>>> * qrand/qsrand -> replacement i
Em terça-feira, 6 de setembro de 2016, às 17:10:19 PDT, Kevin Kofler escreveu:
> Thiago Macieira wrote:
> > It was a *choice* not to depend on the C++ Standard Library ABI for
> > features outside of the language support. The choice was made during Qt
> > 5.0 development, in response to the -no-st
Giuseppe D'Angelo wrote:
> So please do not derail this sub-topic. The subject at hand here is
> using Standard Library datatypes in our public API.
And I was just pointing out that doing so also waters the API consistency,
in addition to the ABI issues.
> 1) BECAUSE. THEY. ARE. NOT. BETTER. In
On Tuesday 06 September 2016 18:01:18 Marc Mutz wrote:
> Noo don't feed the Troll...! :)
(with apologies to the original Trolltech people!)
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
Noo don't feed the Troll...! :)
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lis
Il 06/09/2016 17:10, Kevin Kofler ha scritto:
> I think it was a mistake to remove -no-stl to begin with, and that Qt API
> should not be littered with ugly std:: APIs, not just for ABI reasons, but
> also for API (consistency) reasons.
Having APIs which follows the naming in the Standard Libra
Thiago Macieira wrote:
> It was a *choice* not to depend on the C++ Standard Library ABI for
> features outside of the language support. The choice was made during Qt
> 5.0 development, in response to the -no-stl option being removed. It was
> originally done so that applications and libraries on
Em terça-feira, 6 de setembro de 2016, às 07:24:19 PDT, Marc Mutz escreveu:
> On Tuesday 06 September 2016 02:02:50 Thiago Macieira wrote:
> > > https://codereview.qt-project.org/#/c/142782/
> >
> > We decided to make a QUIP out of this, in a later session. Stay tuned.
>
> ENOABBREV
It's a backr
On Tuesday 06 September 2016 02:02:50 Thiago Macieira wrote:
> > > * C++11 Standard Library compatibility list
> > >
> > >
> > > * no volunteers yet
> >
> >
> >
> > Is this a matter of converting this documented into qdoc?
> >
> >
> >
> > https://codereview.qt-project.org/#/c/142782/
>
> We
Em segunda-feira, 5 de setembro de 2016, às 19:00:40 PDT, Giuseppe D'Angelo
escreveu:
> Random comments:
>
> Il 02/09/2016 17:01, Thiago Macieira ha scritto:
> > https://wiki.qt.io/QtCS2016_QtCore
> >
> > * Deprecation of APIs
> >
> > * qrand/qsrand -> replacement is Standard Library or you
On 2016-09-05, Giuseppe D'Angelo wrote:
>> * C++ ABI
>> * libstdc++ still breaking compatibility in std::function
>> * not now, revisit in a year or two
>
> There hasn't been time to discuss this at QtCon, but I'd say we should
> not spend another year before revisiting this at the next Qt
On Monday 05 September 2016 19:00:40 Giuseppe D'Angelo wrote:
> > * QStringView & QByteArrayView
> >
> > * Deprecate QStringRef
> > * Not QArrayView: discuss later
>
> IOW: the views will have the full blown QByteArray/QString API on them?
The const subset, yes, minus deprecated API, if a
Random comments:
Il 02/09/2016 17:01, Thiago Macieira ha scritto:
> https://wiki.qt.io/QtCS2016_QtCore
>
> * Deprecation of APIs
> * qrand/qsrand -> replacement is Standard Library or your own
Unfortunately there's no replacement for a thread safe, easy to use,
deterministic, low quality ran
https://wiki.qt.io/QtCS2016_QtCore
* Deprecation of APIs
* qrand/qsrand -> replacement is Standard Library or your own
* FIPS compliance
* QCryptographicHash, random generator
* requires external (optional) implementation, provided by OpenSSL
* loading of OpenSSL libcrypto: either
15 matches
Mail list logo