Re: [Development] Use of Standard Library containers in Qt source code

Le samedi 02 juillet 2016 à 10:10 -0700, Thiago Macieira a écrit : > On sábado, 2 de julho de 2016 15:44:50 PDT Mark Gaiser wrote: > > I don't get why you would be confused by - for instance - the empty > > method. > > STL has that method, but so does Qt [1] apparently in an attempt to be > > compa

Re: [Development] commas in ctor-init-lists

Le mercredi 01 juin 2016 à 15:36 +0200, Olivier Goffart a écrit : > > Anyone has a config file for clang-format to use with qt so it can be used > with git-clang-format? > This is the most relevant question in this kinda trollish kind of topic. Everyone has different opinion on these matter

Re: [Development] Scalable UIs in QtQuick (take 2)

Le jeudi 18 février 2016 à 14:20 +0100, Oswald Buddenhagen a écrit : > On Thu, Feb 18, 2016 at 10:50:22AM +, Hausmann Simon wrote: > > What do you think? > > > that it's a bit silly that we're having this discussion *yet again*. ;) > http://thread.gmane.org/gmane.comp.lib.qt.devel/6572/focus

Re: [Development] Question about QCoreApplicationData::*_libpaths

Le vendredi 22 janvier 2016 à 01:13 +0100, Kevin Kofler a écrit : > > I think Qt should ignore the "wider C++ community", too. The STL is really a > completely different beast, we only share the language-level parts. That statement sounds very harsh. Please remember that your users are part o

Re: [Development] RFC: more liberal 'auto' rules?

by the type system, because concepts do not exists in the type system yet. No tooling will ever give you a type information here : it depends on the template instanciation. Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

Le vendredi 04 décembre 2015 à 18:10 -0500, Matthew Woehlke a écrit : > On 2015-12-04 17:43, André Pönitz wrote: > > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote: > >> Which of these is easier to read? (More importantly, which is easier to > >> *verify* that it is correct?) > >>

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

a QString&& api, which cover more use cases. Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QString behavior change

Le mardi 11 août 2015 à 10:10 -0700, Thiago Macieira a écrit : > On Tuesday 11 August 2015 18:45:10 Julien Blanc wrote: > > Le mardi 11 août 2015 à 08:46 -0700, Thiago Macieira a écrit : > > > On Tuesday 11 August 2015 10:38:27 Julien Blanc wrote: > > > > That p

Re: [Development] QString behavior change

Le mardi 11 août 2015 à 08:46 -0700, Thiago Macieira a écrit : > On Tuesday 11 August 2015 10:38:27 Julien Blanc wrote: > > That point is certainly valid, but i would like to raise the point that > > string nullness is a *required* feature for QtSQL (a null QString is > > co

Re: [Development] QString behavior change

d not documented. So, could you consider returning StringType("") instead ? (unless i’m wrong, null strings should be handled by the first condition). Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QVector now has rvalue push_back

d implementation (there’s no requirement about not constructing a temporary object in the C++11 standard). gnu stl does the opposite : implement push_back in terms of emplace_back, which is better. Regards, Julien Blanc ___ Development mailing list Deve

Re: [Development] QVector now has rvalue push_back (was: Re: HEADS UP: potential trouble from a recent QVector change)

on I'd want emplace_back? Or vice-versa? emplace_back is really designed to avoid the creation of a temporary object, so, passing a T to it shouldn’t make any difference : that would be in both case a construction via copy (resp move) constructor. regards, Julien Blanc ___

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

to hash collision issues, which may be a security concern in certain context : i wouldn’t recommend such a container for general purpose. Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Le vendredi 10 juillet 2015 à 10:12 +, Curtis Mitch a écrit : > > > > (*) not movable, or bigger than a void*. And user-defined types are not > > movable by default (they're complex). And if we forget > > Q_DECLARE_TYPEINFO on public types, we can't add it back because it's > > binary incomp

Re: [Development] Qt LTS & C++11 plans (CopperSpice)

Le mardi 30 juin 2015 à 22:37 +0200, Bernhard a écrit : > > For example, with moc removed we support template classes that inherit > > from QObject. > > Wow. I would (almost) kill for having that feature in Qt! > You can work around it quite easily. What doesn’t work is adding new signals / s

Re: [Development] Move ctors for q_declare_shared types

about individually moving elements (that would be a huge performance breaker). Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Some Qt3D feedback

Le jeudi 18 juin 2015 à 13:19 +0200, Simon Hausmann a écrit : > On Thursday, June 18, 2015 12:45:53 PM Marc Mutz wrote: > [...] > > The meta-type system and moc are perfectly fine with namespaces. If people > > would just peek over their own noses and over to your cousin, KDE, you'd see > > that,

Re: [Development] Fwd: QTextStream::readLine(0) is an ambiguous overload in 5.5

On 18/05/2015 15:30, Andreas Aardal Hanssen wrote: 2015-05-18 14:56 GMT+02:00 Alejandro Exojo >: El Monday 18 May 2015, Smith Martin escribió: > You omitted that toInt(&ok) is required to test ok for null, which is not > required if ok is a reference.

Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5

On 17/05/2015 15:19, Giuseppe D'Angelo wrote: > On Sun, May 17, 2015 at 2:30 PM, Andre Somers wrote: >> In the spirit of option b), would it be an option to have the method >> take a QString& instead of a QString*? That would resolve the ambiguity. > It would solve, but Qt APIs use pointers instea

Re: [Development] JSON 64 bit int

asically, i think QJson is currently conform to i-json (interoperable json). That should at least : - gives some arguments about *not* using 64bit integers (this is handled by the RFC : use strings in that case) - maybe allows a strict / non

Re: [Development] The dark side of QtSvg

ust a note. Full svg support requires : - CSS support - animation framework support - scripting support - events support - and probably more… I really don’t know how you’re supposed to do that without a full web engine. SVG Tiny is the way to go if you want something tiny. Regards, Ju

Re: [Development] Why can't QString use UTF-8 internally?

, and it's > by now useless, irrelevant and only a source for bugs once you start to > truly support i18n outside of USA and Western Europe. I would be one > step closer to total happiness if C++17 and Qt7 makes this "encoding" > completely unsuppor

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

On 10/02/2015 17:33, Olivier Goffart wrote: > On Tuesday 10 February 2015 17:08:55 Julien Blanc wrote: >> On 10/02/2015 16:33, Knoll Lars wrote: >>> IMO there’s simply too many questions that this one example doesn’t answer >>> to conclude that what we are doi

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

r data structures) implicit sharing to make some real world benchmarks ? Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] changing Q_GADGET

On 28/11/2014 16:13, Gunnar Roth wrote: > Hi Simon > >> 2) On paper it breaks binary compatibility with MSVC, in the unlikely event >> that somebody >> a) produces a DLL and cares about binary compatibility > > Why do you think that is unlikely? > > Actually right now i depend on that. I ge

Re: [Development] Compiler warnings

On 17/10/2014 10:15, Christian Kandeler wrote: > On 10/17/2014 08:48 AM, Kurt Pattyn wrote: >> As we are developing for aerospace, avionics, defence and healthcare, we are >> confronted on a daily basis with a lot of very stringent rules that we have >> to comply with (irrespective if some people

Re: [Development] QConfig update.

ber precision. JavaScript, as well as QJsonValue, do assume that any number is a double precision, but nothing in RFC 4627 says that. libjson (at least) assumes that number values in JSON can be signed int64. This specific issue may be better handled in QJsonValue than in a QConfig class. Re

Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

be ready before c++ provides a core solution ? - is there someone willing to do it ? Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

anywhere where relevant. Best regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QOptional

On 21/08/2014 13:01, Poenitz Andre wrote: > Julien Blanc wrote: >> There are two strong arguments in favor of optional : >> - real life tends to show that the optional &ok parameter is often >> missed in context it should not, leading to hard to find bugs. >> - op

Re: [Development] QOptional

On 21/08/2014 11:50, Poenitz Andre wrote: > Hausmann Simon wrote: >> On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote: >>> Of course, i can:) >>> >>> bool ok; >>> const int value = string.toInt(&ok); >>> if (ok) >>> qDebug() << "value is" << value; >>> >>> // >>> const auto valu

Re: [Development] QOptional

On 21/08/2014 11:17, Milian Wolff wrote: > On Thursday 21 August 2014 13:13:15 Иван Комиссаров wrote: >> Of course, i can:) >> >> bool ok; >> const int value = string.toInt(&ok); >> if (ok) >> qDebug() << "value is" << value; >> >> // >> const auto value = string.toInt(); >> if (value) >>

Re: [Development] QOptional

On 21/08/2014 00:07, Thiago Macieira wrote: > On Wednesday 20 August 2014 20:49:03 Marc Mutz wrote: >> I don't find the QVariant::isNull behaviour any useful or intuitive. It's >> too smart. You can always use v.value().isNull() because value() will >> return a default-constructed T if invalid. >

Re: [Development] Qt 5.2 Beta, possible memory leak(s)

Le 31/10/2013 12:29, Koehne Kai a écrit : > I'm not completely opposed to calling u_cleanup(), but we've to keep in mind > that ICU API might get called very late (e.g. even in destructors of static > objects, when someone decides to add say a qDebug() there). What happens if I > call ICU API af

Re: [Development] Disabling exception support in QtCore?

Le 03/10/2013 10:36, Olivier Goffart a écrit : > On Wednesday 02 October 2013 09:30:58 Thiago Macieira wrote: > >> That would mean any signal could throw ANY exception. It would also preempt >> the execution of further slots, which might be important. >> >> Usually the person who connects a signal