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
> >
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
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*. ;)
>
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
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
ring&& api, which cover more use cases.
Regards,
Julien Blanc
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
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 point is certainly valid, but i would like
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
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
converted to a NULL SQL
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
Development@qt-project.org
http://lists.qt-project.org
, 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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo
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
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 incompatible.
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 / slots
).
Regards,
Julien Blanc
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
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, say,
On 18/05/2015 15:30, Andreas Aardal Hanssen wrote:
2015-05-18 14:56 GMT+02:00 Alejandro Exojo s...@badopi.org
mailto:s...@badopi.org:
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
On 17/05/2015 15:19, Giuseppe D'Angelo wrote:
On Sun, May 17, 2015 at 2:30 PM, Andre Somers an...@familiesomers.nl 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
-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 strict mode.
Regards,
Julien Blanc
___
Development mailing
. 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,
Julien Blanc
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 unsupported.
Could not agree more with that part.
Regards,
Julien Blanc
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
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 doing is bad.
Two arguments :
- implicit sharing
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 get stuff
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 might
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.
Regards,
Julien
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
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.valueT().isNull() because value() will
return a default-constructed T if invalid.
I
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 value = string.toInt();
if (value)
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 after
30 matches
Mail list logo
