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

[Julien Blanc]

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
> > compatible with the STL API.
> 
> That doesn't mean we will allow the use of those methods in our own 
> libraries. 
> I *will* reject any code that uses empty() to mean isEmpty() on a Qt 
> container.
> 
> The whole point of this thread is that using certain methods is misleading 
> or, 
> at best, confusing.

While I agree with you that isEmpty is a far better name than empty, I
don’t think renaming is the best idea.

As for the argument of using size() == 0 (which I prefer over renaming),
note that :
- std::forward_list does not have a size() member
- std::list size() may have linear complexity before C++11

About the example you gave, I see two things that could be improved,
with a much broader scope than just empty -> isEmpty (which is a
particular case) :

- the use of side-effects functions (aka : non const) in conditionals :
IMHO they’re bad for readability, especially if the condition is a bit
complex. If it is banned (or, banned unless commented), then there is no
ambiguity.
- visual distinction between const / non-const functions / variables
usages in QtCreator/whatever ide you’re using. This one would be a
must : the fact that empty is const makes it really clear what it does,
but you currently have to either know it or read the doc.

Following Stephen Kelly’s mails, I’m convinced that instead of wrapping
stl containers, implementing a free function qIsEmpty is less work and
addresses all your readability concerns.

Regards,

Julien

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

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 matters, and, this is more a
matter of style / habits than real arguments. But there’s one thing that
matters a lot more than code style itself : consistency.

But to go back to the topic, we’re in 2016 now, and still we face the
same discussions as in the nineties. Why is that that I can’t work with
the code the way *I* want, and share it with the others the way *they*
want. Hey, we now have really pretty decent tools to reformat code !
What i have in mind is something like :

- post-checkout/clone git hook that reformat code to *my* style when i
work on it
- pre-commit hook that reformat code to the *neutral* (ie, qt style
rules) style when committing
- difftool customization so that diff are displayed in my style rather
than the neutral one
- server-side : style is checked in the pre-commit hook, either it is
reformatted automatically or rejected if not in the good format.

Never had the time to play with something like that, i’m wondering if
someone ever did, and in that case what’s working and what’s not, the
issues faced.

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

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=6807
> 
> i find the point about using arcminutes as a truly device independent
> unit particularly relevant. i thought we discussed this topic somewhere
> in more depth already, but i failed to find anything relevant.


I made some experiments with that, but unfortunately, that’s far from a
perfect solution either.

The main problem is that the readability of items depends on both the
size and the number of pixels (to say it differently : you can write
smaller text on a retina display while still being human-readable). So
you get to consider both, which basically completely breaks the purpose
of angle oriented units. Add to that that some elements (eg touch
buttons) must have some minimal physical size to be usable. There’s also
the issue that the « typical eye distance » information is missing on
devices  (a 24“ computer fullhd monitor has not the same eye distance
than a 24” fullhd TV, despite having the same physical characteristics).

For now, i reverted to sailfish silica-like approach, which i found
gives the best result (basically, use theme-given sizes for your
elements, and layout them accordingly). However, some smarter logic than
just a basic scaling factor could be implemented to automagically
compute theme values depending on the device (instead or in complement
of device-specific themes).

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

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 of this « wider C++ community », in the sense that they rarely use
Qt only.

Any effort (and lots have already been done, thanks) to make Qt
integrate well with other C++ code, including one that relies on modern
techniques*) is greatly appreciated. I completely agree with Mark here
in his statement that the lack of communication between Qt community and
C++ wider community deserve both.

Regards,

Julien

* since this thread has been talking about dangling references, please
have a look at
https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetimes%
20I%20and%20II%20-%20v0.9.1.pdf and what will (hopefully) land in our
compilers in the upcoming years
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

Le samedi 05 décembre 2015 à 12:08 +, Bubke Marco a écrit :

> >
> >> - template code (esp., but not necessarily only, when the type name
> >> would require the use of 'typename')
> >
> > This is the one i’m not at ease with. Template code tends to be
> > difficult to read, partly *because* there’s no type information. For
> > readability concerns, i would prefer a local typedef named by the
> > concept. Yes, that makes it two lines instead of one, but i think that’s
> > one case where hinting the reader with a well-chosen type name makes a
> > lot of sense.
> 
> Most typedefs I have seen was about hiding pointer or container types like 
> CursorPointer or Cursors. But is CursorPointer a unique pointer,  a shared 
> pointer and which flavor is it. Cursors is the same because it could be 
> std::vector or QList. Some would hide a dictionary behind this name. So the 
> typedef can be misleading. In that case I prefer auto. 
> 
> std::shared cursorPointer = document.cursorAtPostion(46);
> 
> CursorPointer cursorPointer = document.cursorAtPostion(46);
> 
> auto cursorPointer = document.cursorAtPostion(46);
> 
> I prefer the last but we need good tooling to show the type. It would be nice 
> to have much more information like size,  is it movable or copyable. It is 
> not only the type and we can provide that information. 

My understanding of Marc’s proposal was that it was more for the
following case :

template void algorithm(List& input)
{
typename List::value_type& first = input.front();
...
}

replaced by :
template void algorithm(List& input)
{
auto& first = input.front();
...
}

whereas i prefer 
template void algorithm(List& input)
{
typedef typename List::value_type Serializable;
// there are some requirements on List : item_type must be
// Serializable : now i can look the doc to see what a
// Serializable is
Serializable& first = input.front(); 
// i know what to expect from first, which methods i can call
...
}

I think the latter improves readability over the two others, because it
just gives more information to the reader. And this information is
currently *not* given 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?

[Julien Blanc]

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?)
> >>
> >>   for (int i = 0; i < list.size(); ++i)
> >> foo(list[i]);
[snip] 
> 
> >>   for (auto i : qtIndexRange(list.size())
> >> foo(list[i]);
> > 
> > In any case, this is an uncommon pattern, using some unknown qtIndexRange()
> > function.
> 
> Really?
> 
>   (Python)
>   for i in range(len(list))

Am I the only one to think that this example is inherently broken ? I
mean, why wouldn’t any sane person write :

for(auto const& element : list)
foo(element)

or
std::for_each(list.begin(), list.end(), foo);

Because :
- it’s shorter
- it’s more readable
- it works for non random-access-container types
- bonus : range checking is not needed, so it should be more performant
- bonus : it doesn’t resort to a temporary value, same remark


Now, getting back to what Marc proposed initially, because the debate
has gone far away from his initial proposal :

> - template code (esp., but not necessarily only, when the type name
> would require the use of 'typename')

This is the one i’m not at ease with. Template code tends to be
difficult to read, partly *because* there’s no type information. For
readability concerns, i would prefer a local typedef named by the
concept. Yes, that makes it two lines instead of one, but i think that’s
one case where hinting the reader with a well-chosen type name makes a
lot of sense.

> - all loop variables (both index and iterators)
>   the reason being that spelling out the name is usually wrong:
>  size_t i = stdVector.size() // wrong, should be
>  std::vector::size_type...
>  also helps when porting from Qt containers to STL ones

That looks perfectly fine for me. Index based loops should be avoided
whenever it is possible, and for iterator based loops auto makes no harm
(seriously, who wants to write
std::vector::const_iterator instead of auto ?).

> - all references to elements in a collection (same problem - way too
> easy to misspell std::pair for std::pair...)

Same thing.

Regards,

Julien

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

Le lundi 19 octobre 2015 à 16:08 -0700, Thiago Macieira a écrit : 

> 
> So the summary of QStringView is:
>  a) never used as return type
>  b) used only as a parameter if the function processes the data and never 
>  stores it and will never, ever store it (lazy processing)
>  c) for existing API, needs to be overloaded with QString
> 
> I'm not buying the cost/benefit ratio.


I don’t get b) statement.

If you need to store it, as a QString, and you can afford to expose that
to the user, then i think it’s better to provide a QString&& overload.
This :
- makes clear that you will store the value « as-is ».
- should be more efficient than copying the string
- still allows copying the string if the user needs to keep its own copy
of the data.
- cohabites well with a QStringView api

I do not see the benefit of a QString api vs a QStringView and 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

[Julien Blanc]

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 to raise the point that
> > > > string nullness is a *required* feature for QtSQL (a null QString is
> > > > converted to a NULL SQL, whereas a non-null empty QString is converted
> > > 
> > > That's a misfeature. QtSql should have been using something like
> > > QOptional for a nullable string. In addition, it usually uses
> > > QVariant, which has its own null setting -- it allows for a null int,
> > > different from a value of zero.
> > 
> > What are the chances that such a change can be accepted ? (i mean, i can
> > submit such a patch, but that would mean breaking a *lot* of code).
> 
> QOptional does not exist yet and for very good reasons.
> 
> QVariant is already in use, so I don't think you'd be sending a patch to use 
> QVariant.
> 
> What are you proposing to send?

Changing QtSql so that :
- null QString are binded to SQL '' (same as empty string)
- to bind to NULL you thus require a null QVariant (same as for null
int), that require no change

I don’t expect such a change to be accepted before at least Qt6, but i’d
be happy to hear i’m wrong.

> There are just too many places where strings are mutated, so we cannot offer 
> to 
> keep the nullness stable for everything.

I will not put on the same level QString API with other mutators (like
QUrl(QString()).toString() ). In an ideal world, I would expect the
first one (QString API) to keep the nullness stable, not the second one
(imho building a QUrl with a null QString is a contract violation,
undefined behaviour is fine).

However, i got your point that this is not going to happen for
performance reasons.

> We should remove it, indeed, but only after std::optional can be used 
> properly 
> in API that needs it (like after refactoring QtSql). I don't think it will 
> happen in time for Qt 6.

Like you said, QVariant offers an already existing (yet inferior)
alternative to std::optional in many places. It looks like there’s a
chicken and egg problem :
- null QString is used in some modules
- as long as null QString exists, modules will rely on it (QtSql is
probably not the only one)
- as long as modules rely on it, null QString will stay

I can work on the QtSql part, but like I said, that’s a code-breaking
change (acceptable for Qt6 ?).

> I won't do this change, but I will accept a patch from someone who
> does. I will accept it only because it's a performance improvement,
> not because it keeps the nullness.

Thanks, i’ll submit a patch.

Regards,

Julien

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QString behavior change

[Julien Blanc]

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, whereas a non-null empty QString is converted
> 
> That's a misfeature. QtSql should have been using something like 
> QOptional for a nullable string. In addition, it usually uses 
> QVariant, which has its own null setting -- it allows for a null int, 
> different 
> from a value of zero.

What are the chances that such a change can be accepted ? (i mean, i can
submit such a patch, but that would mean breaking a *lot* of code).

> > So, could you consider returning StringType("") instead ? (unless i’m
> > wrong, null strings should be handled by the first condition).
> 
> No.

By no, do you mean that i am wrong (ie, a null QString passing via
trimmed_helper would fail the begin == str.cbegin() && end == str.cend()
test, for a reason i don’t understand, nor does my compiler), or that
you have a good reason for not returning StringType("") ? In the latter
case, i would be very glad if you explain it.

> If you want to pass a null QString to QtSql, you can. If you want to check 
> whether a string you got from QtSql is null, you can.

Please consider the following case :

if(str.isNull())
   q.bind(0, QString(""));
else
   q.bind(0, str.trimmed());

That code looks perfectly valid, but is in fact broken by a subtle,
counter-intuitive implementation detail.

> That has nothing to do with trimmed(). Other API doesn't guarantee to keep 
> null either when mutating strings, so I don't see why we should here. If the 
> API doesn't specifically deal with null QStrings, expect that it will 
> randomly 
> change between null and not null.

If nullness of QString is so much broken, then please consider removing
it at all (Qt6 ?). I will thank you for that. But until that’s done, is
it possible to not add more brokenness to it ?

Regards,

Julien

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QString behavior change

[Julien Blanc]

Le vendredi 31 juillet 2015 à 09:01 -0700, Thiago Macieira a écrit : 

> >  wrote:
> > > In this particular case, it was reasoned that the API was inconsistent and
> > > broken. So the behaviour was changed intentionally.
> > 
> > TBH, it looks like it's still inconsistent (an empty string keeps its
> > storage allocated, a string made of spaces doesn't).
> 
> Right, they are these two cases of trimmed_helper:
> 
> if (begin == str.cbegin() && end == str.cend())
> return str;
> if (begin == end)
> return StringType();
> 
> The consistency of nullness is secondary to performance in this code section. 
> I'm not going to add a test before those two.
> 

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, whereas a non-null empty QString is converted
to a ''). This makes a huge difference when dealing with not null sql
fields. The fact that trimming an empty string may make it null is
counterintuitive, a behaviour change, and 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

[Julien Blanc]

Le mardi 21 juillet 2015 à 19:00 +0200, Gunnar Roth a écrit :
> Hello,
> Out of curiosity i just looked at the Xcode 6.4 headers for the
> implementation of std::vector::emplace_back,
> and i don’t think there is any difference between
> push_back(QPen(Qt::red,1.5f)) and emplace_back(Qt::red,1,5f))
> 
> 
> The implementation is like this:
> template 
> _LIBCPP_INLINE_VISIBILITY void emplace_back(_Args&&... __args)
> { push_back ( value_type ( _VSTD::forward<_Args>(__args)... )); }

> Am i wrong?

That’s a suboptimal but valid 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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

Le lundi 20 juillet 2015 à 12:26 -0700, Thiago Macieira a écrit : 

> On Monday 20 July 2015 18:25:43 Keith Gardner wrote:
> > > What's the difference in std::vector between an rvalue push_back and
> > > emplace_back?
> > 
> > emplace_back takes variadic template arguments to construct the item
> > directly in the vector instead of creating a temporary and then performing
> > a move operation. If the template argument is just an rvalue of the
> > container type, it will perform just like the rvalue push_back function.
> > 
> > http://en.cppreference.com/w/cpp/container/vector/emplace_back
> 
> Aside from the variadic and the templateness, what's the difference?
> 
> The templateness changes how a type different than the vector's type gets 
> constructed (it might undergo a conversion first). 


Not sure i understand you well there. The variadic and templateness
changes it so that no temporary gets constructed at all, object is
constructed in-place with a call to a placement new and T’s constructor
with provided arguments.


> But assuming I am pushing 
> back a T, is there any reason 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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

Le jeudi 16 juillet 2015 à 23:09 +0200, Gunnar Roth a écrit :


> 
> The vector classes are now very bad in this case. QHash
> is considerable better than any other.
>  
> So I deduce from this test that for a container with up to 100
> elements , std::vector is the best choice , if you want fastest
> lookup, but Vector should be avoided. For larger container QHash
> should be used for best lookup performance.


Unless your vector content changes often, you should use a sorted vector
and a dichotomic search for that use case. Also note that hash are
usually subject 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

[Julien Blanc]

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.
> 
> How is it binary incompatible?


I believe this is because of the allocation strategy change in QList.

I wonder, however, if explicit template declaration / instanciation
(which is a new C++11 feature) would solve this issue.

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

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 inside a template class. So just add a base class
declaring these signals/slots, and make your template class inherits
from it.

Unless you wan’t to use the template class as signal/slots arguments,
this works fine.

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Move ctors for q_declare_shared types

[Julien Blanc]

Le vendredi 26 juin 2015 à 16:14 +0200, Olivier Goffart a écrit :


> > 
> > - Standard containers guarantee that the old elements get either move
> > assigned or destroyed.
> 
> I partially disagree.
> The wording seems to indeed implies that the move assignement operator of 
> std::vector should do iterate over all elements to destroy or move them. But 
> in practice, GCC implementation does not do that:
> http://cpp.sh/2s4w
> 
> Is it a bug in the GCC's stdlib implemenation?  Or is it a misunderstanding 
> of 
> the wording of the standard?


Actually this is an error in your example, not gcc.

Line 15 :
v.push_back( {} ); --> a.push_back({});

The wording says that existing elements in the *destination* container
should be move assigned or destroyed. In that case, gcc correctly
destroys them.

The wording says nothing 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

[Julien Blanc]

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, kdepimlibs would have a very hard time indeed, if QMetaType or
> > moc would have any trouble with namespaces whatsoever.
> 
> Let me give you a concrete example of where "no trouble whatsoever" does not 
> hold in my opinion:
> 
> Qt3D has a QKeyboardInput class:
> 
> namespace Qt3D {
> 
> class QKeyboardInput: public QComponent
> {
> ...
> Q_SIGNALS:
> void leftPressed(Q3DKeyEvent *event);
> ...
> };
> 
> The Q3DKeyEvent class is declared in a namespace as well:
> 
> namespace Qt3D {
> class Q3DKeyEvent : public QObject
> {
> ...
> };
> }


Then you shouldn’t do that. You should use the fully qualified name in
your signal definition. IIRC the doc is clear on this.


> 
> The moc generated code for QKeyboardInput stores "Q3DKeyEvent*" as
> type name for the parameter of the leftPressed signal.


Then the question is : can moc be improved to trigger an error (or
generate C++ code that triggers an explicit error, via static_assert for
example) when defining such signals ?

Because yes, that’s an issue, and a troublesome one. Marc told earlier
about the SC break : it’s easy to deal with SC break that triggers
compile-time errors. But SC breaks that silently triggers bugs are much
more a burden. There is a strong precondition imho before doing a move
to namespace, which is being able to detect all connection / method
invocation / ... errors. Because that’s the kind of SC break that will
inevitably occur.

Regards,

Julien

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

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.
That's extra work in the implementation in order support a nicer
API to the
users, e.g. to support toInt() with the null value as default
argument, in
addition to the "passing a pointer makes clear that the value could be
modified".

Very true! In fact the "opposite API" to toInt() was chosen in 
QIODevice::getChar() to ensure that even the extra line of testing for 
OK on the client side could be eliminated. For toInt(), it's rare that 
the output arg needs to be tested, but for QIODevice::getChar(), it's 
the opposite.


char ch;
if (device->getChar(&ch)) {
// foo
}

http://doc.qt.io/qt-5/qiodevice.html#getChar

Imagine reading code like this:

char ch;
if (device->getChar(ch)) {
// foo, wtf is ch for??
}


Which is exactly what the standard lib does :

  (see overload 2)

Notice that instead of returning a boolean, the stream is returned, 
which is then converted to a bool for testing its validity.


See also :



So, this is common design as well, and does not seems to cause much 
trouble as long as the semantic of the operation is clear :).


Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

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 instead of references for
> out-arguments (and that's a very good code policy).

That *was* a good policy (it has its drawbacks). C++11 tends to remove 
the need of raw pointers, C++14 makes a step further in that direction. 
Sticking to such a rule would mean going against the general evolution 
of the language.

That said, i wish there were a « ref X » or « out X » keyword needed 
when calling a function that takes a reference, like in C# or Ada. In 
C++, you should resort to const-correctness to prevent mistakes. I like 
the suggested idea of highlightings potentially modified parameters in 
qtcreator.

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] JSON 64 bit int

[Julien Blanc]

On 12/02/2015 08:42, Knoll Lars wrote:
>
> Yes, 80 or 128bit doubles are out of the question. The RFC basically
> doesn’t specify the range of allowed values, but hints that it should at
> least support doubles. We can go above that and allow 64bit integers as
> well as they are rather common these days. But anything above that is IMO
> something that is out of scope for Qt.
>
> So I’d be ok with a patch that adds builtin support for 64bit integers.
> We’d then need to decide at parse time whether to store the value as
> integer or double, and since JSON only talks about numbers the getters
> have to do automatic conversion (or we’d break existing code). To be able
> to deal with them you’d need a isInteger() flag on QJsonValue.

This thread is quite old, but there are some news here that are relevant :

http://www.rfc-editor.org/rfc/rfc7493.txt

Basically, 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 strict mode.

Regards,

Julien Blanc
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The dark side of QtSvg

[Julien Blanc]

On 12/03/2015 16:47, Massimo Callegari wrote:
Apologies if my mail doesn't have proper carriage returns in pipermail 
! (my crappy webmail's fault)


Just want to add a third advantage in decoupling QtWebEngine from SVG:

3- it removes duplicated code between QtSvg and QtWebEngine


Just 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,

Julien Blanc
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

On 11/02/2015 10:32, Bo Thorsen wrote:
> 2) length() returns the number of chars I see on the screen, not a
> random implementation detail of the chosen encoding.

How’s that supposed to work with combining characters, which are part of 
unicode ?

> 3) at(int) and [] gives the unicode char, not a random encoding char.

Same problem with combining characters. What do you expect :

QString s = QString::fromWCharArray(L"n\u0303");
s.length(); // 1 or 2 ??
s[0]; // n or ñ ??

> std::string fails at those completely basic requirement, which is why
> you will never see me use it, unless some customer API demands it or I'm
> in one of those exceptional cases where there is sure to be ascii only
> in the strings.

QString (at least in qt4, not tested with qt5) fails, too, but less often.


> Another note: Latin1 is the worst idea for i18n ever invented, 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 unsupported.

Could not agree more with that part.

Regards,

Julien Blanc
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

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 is convenient, and really developer friendly. It is
>> probably a good idea since strings are really present a lot in signals
>> and slots (and afaik, passed by value in these context)
>> - implicit sharing is implicit, you don’t have the choice not to pay for
>> it, which is a bad thing.
>>
>>   From my experience, QStrings are slow. About two times slower than
>> using plain std::string in our use cases, but the culprit for this
>> slowness is, as far as we know, the internal 16 bits encoding, whereas
>> our data sources are all using utf-8. We have no evidence that the
>> implicit sharing cost is significant or not.
> std::string is NOT an equivalent of QString

No, they’re not equivalent. I was not saying that QString is poorly 
optimized or so. I was saying that QString is about twice slower than 
std::string in our use case, which starts to make us think seriously to 
get completely rid of it in some parts of our code (the non gui parts).

> The equivalent of QString would be std::wstring or std::u16string.
> The equivalent of std::string would be QByteArray.
The bad thing being that you can’t seriously replace QString with 
QByteArray, in, nearly everywhere. QtSql uses QString, QtXml uses 
QString, and nearly anything that works with strings in Qt uses QString, 
because that is the default string class. Which means getting rid of 
QString is also getting rid of these components, which starts to be a 
big deal.

> Note that some STL implementation (most notably the GNU one) use implicit
> sharing for std::string
That may have been true in the past, but i’m pretty sure this is no 
longer the case now. The main problem with COW for std::string is that 
operator[] non-const may invalidate iterators, which is really something 
you don’t expect (i can’t find evidence that the standard forbids it 
though i’ve read it somewhere).

> Also, we don't share data structures among threads so much in a 
> typical application. So the arguments given against implicit sharing 
> are not really valid. 

In fact that makes them worse. It means you pay for something you don’t 
use. The question being « is it worth the cost » is probably yes if you 
consider it permits lazy developers to not crash their application 
because QString is thread safe. Problem comes when you know what you’re 
doing and don’t want to pay for features you don’t use.

Regards,

Julien Blanc
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

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 is convenient, and really developer friendly. It is 
probably a good idea since strings are really present a lot in signals 
and slots (and afaik, passed by value in these context)
- implicit sharing is implicit, you don’t have the choice not to pay for 
it, which is a bad thing.

 From my experience, QStrings are slow. About two times slower than 
using plain std::string in our use cases, but the culprit for this 
slowness is, as far as we know, the internal 16 bits encoding, whereas 
our data sources are all using utf-8. We have no evidence that the 
implicit sharing cost is significant or not.

Now the question is, is there some simple way to disable QString (and 
eventually other 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

[Julien Blanc]

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 build against qt 5.2.1 dlls 
> and use that stuff and my stuff using at 5.3.2 by exchanginng thge qt dlls 
> with my 5.3.2 dlls , so  i rely on binary compatibility.

What’s unlikely is that you get all a), b) and c) :

 a) produces a DLL and cares about binary compatibility
 b) exposes bare structures
 c) relies on Q_GADGET turning access permission levels to private


I guess most people don’t do c). Actually, any sane person would not 
like a macro to change the private / public context as a side effect, 
and the fact that Q_OBJECT does it (because it just can’t do otherwise) 
should more be considered a bug / lack in C++ than anything else, 
certainly not a feature to rely on.

However, i may be missing something but Q_GADGET needs also to 
explicitely change the private / public context to introduce public 
members. So, the initial proposal to not changing that context would 
require Q_GADGET to be in a public context. I guess that one would break 
a lot of code.

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compiler warnings

[Julien Blanc]

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 find these rules outdated, 
>> stupid, ridiculous or not). That's why we always compile with as much 
>> compiler warnings as possible. Our code must be audited by an external 
>> office anyways, so we better make sure we can avoid a bad report as soon as 
>> possible.
>> Some examples of 'stupid' rules (which after second consideration aren't 
>> that stupid after all):
>> - a switch statement must always have a default statement (also all cases 
>> must be handled)
> Doesn't this actually make the code *worse* when using enums? Adding a
> default statement when you handle all possible values will inhibit
> genuine compiler warnings when you forget to add a case for a newly
> added enum value. In fact, this is almost guaranteed to happen in a
> non-trivial project, so this rule seems almost absurdly wrong to me.

That one is always subject to debate. There is one thing not to forget 
in favor of this rule : enums are *not* guaranted to have a value 
amongst the defined ones. Undefined behaviour in that case is not an option.

I wish i could have both a default statement and my compiler warning…

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QConfig update.

[Julien Blanc]

On 14/10/2014 19:06, Milian Wolff wrote:
> It might mean that you'll have to store
> everything as a string in JSON to prevent a loss of data when storing e.g.
> std::limits::max() (note: JSON only knows double).

To be more precise : JSON itself does not assume anything about number 
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 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

[Julien Blanc]

On 09/10/2014 09:27, Thiago Macieira wrote:
> The only one that poses trouble are ISO-9660 CD-ROMs that have Rock Ridge
> extensions for Unix attributes and longer file names. Do people still have CD
> drives?

People also have zip files, which unfortunately may have various 
encoding in them, since the only normative encoding for zip files is cp437…

I have a bunch of such zip files, that :
- cannot be extracted with gui tools
- will result in bad filenames (including invalid utf-8) when extracted 
using « stupid » command line tools.

IMHO saying « the problem does not exist » is not a good answer, because 
if it really didn’t this issue would never have been raised. The 
questions to answer are :
- is it worth breaking lot of code ? (because it will : a good solution 
needs a complete refactor of qt io code, just providing a QFilePath 
class will not be enough)
- will it 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

[Julien Blanc]

On 07/10/2014 12:11, Tomasz Siekierda wrote:
> For file paths, I feel QString is really enough.
> Changing it to something else because of a few corner cases seems like
> an overkill to me. We already have a lot of classes that are connected
> with paths and the file system (QFile, QFileInfo, QDir, QDirIterator,
> and more), that is enough. In my view, at least.

Imho using QString for file path (or, more generally, using any string 
objects with a static api) is somewhat a very widespread bad idea. The 
std::experimental::filesystem  api, for example, looks really better.

However, i agree that changing this would :
* break a lot of code
* permit only to solve really lower level / corner case issues
* be redundant with the std::filesystem api when it will be standardized 
(hopefully for C++17). I hope Qt will then add the relevant overrides to 
make its use possible 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

[Julien Blanc]

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.
>> - optional is much more friendly to static verification than &ok (dependancy 
>> between variables is a mess to check).
>>
> I am actually not quite sure what you mean with the second item.

I’m talking about what tools like coverity / polyspace can verify on the 
code. Checking that an optional is not used when it is not tested for 
nullness is doable (it is a lot like static checking against null 
pointers dereference), whereas checking for another variable is beyond 
what current static checkers can do afaik.

>
> Something like the following?
>
> struct S { int m_a, int m_b, int m_c);
>
> // "Tradtional, wrong result"
> bool S::parse(QString a, QString b, QString c)
> {
>  bool ok;
>  m_a = a.toInt(&ok);
>  m_b = b.toInt(&ok); // Oops, overwrites first ok value.
>  m_c = c.toInt(&ok);
>  return ok;
> }

I wasn’t thinking about this one, but that’s an issue, yes.

>
> vs
>
> // "Tradtional, right result"
> bool S::parse(QString a, QString b, QString c)
> {
>  bool oa, ob, oc;
>  m_a = a.toInt(&oa);
>  m_b = b.toInt(&ob);
>  m_c = c.toInt(&oc);
>  return oa && ob && oc;
> }

I would not recommend writing code like that (although i think it’s 
widespread). I would expect that parse, when failing, does not alter the 
object at all, so that it stays in a corerent state (aka 
“strong-guarantee”). This is not the case with such implementation.

I would write it that way :

bool S::parse(QString a, QString b, QString c)
{
 int tmpa, tmpb, tmpc;
 bool oa, ob, oc;
 tmpa = a.toInt(&oa);
 tmpb = b.toInt(&ob);
 tmpc = c.toInt(&oc);
 if(oa && ob && oc)
 {
  m_a = tmpa;
  m_b = tmpb;
  m_c = tmpc;
  return true;
 }
 return false;
 }


>
> vs
>
> // "Optional"
> bool S::parse(QString a, QString b, QString c)
> {
>  auto oa = a.toInt();
>  auto ob = b.toInt();
>  auto oc = c.toInt();
>  m_a = *oa;
>  m_b = *ob;
>  m_c = *oc;
>  return oa && ob && oc;


This one is obviously wrong and would trigger an undefined behaviour if 
any string is not convertible to int. The good thing is that I expect 
smart static verification tools to tell you this. To fix it, I would 
write it that way :

 bool S::parse(QString a, QString b, QString c)
{
 auto oa = a.toInt();
 auto ob = b.toInt();
 auto oc = c.toInt();
 if(oa && ob && oc)
 {
  m_a = *oa;
  m_b = *ob;
  m_c = *oc;
  return true;
 }
 return false;
 }

Note that we gained strong guarantee in the process without even aiming 
for it, at no line of code cost.

>
> vs
>
> // "isInt"
> bool S::parse(QString a, QString b, QString c)
> {
>  bool oa = a.isInt(&m_a);
>  bool ob = b.isInt(&m_b);
>  bool oc = c.isInt(&m_c);
>  return oa && ob && oc;
> }
>
> vs
>
> // "something else"
> bool S::parse(QString a, QString b, QString c)
> {
>  return a.isInt(&m_a) && b.isInt(&m_b) && c.isInt(&m_c);
> }

Those versions have the same “no strong-guarantee” problem.

> If so, the "Optional" variant doesn't look much simpler than any
> of the others, even less so when one doesn't accept the use of
> 'auto' there.

I never advocated that Optional makes for shorter code :) (yup, I know 
others have, but i disagree with that statement). However, i think 
Optional is a mean for *better* code. Your examples confort me in this 
thinking : with Optional, strong-guarantee is achieved within the same 
code amount. Without, it requires at least twice as more code than the 
unsafe version.

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QOptional

[Julien Blanc]

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)
>>>  qDebug() << "value is" << *value;
>> To be honest: I find the "bool ok" variant much easier to read.
>> "if (value)" on an auto variable can mean so many things. In the
>> above example you could very easily think: Ah, toInt returns an int,
>> so the type of "value" is probably int, so if (value) checks if it's 
>> non-zero.
> So the "ugliness" of the "traditional" code is essentially hidden
> by the use of 'auto' in contexts where the type is not obvious
> to the casual reader.
>
> Another can of worms. In practice this would end up often
> enough with
>
> bool ok;
> const int value = string.toInt(&ok);
> if (ok)
> qDebug() << "value is" << value;
>
> vs
>
>const QOptional value = string.toInt();
>if (value)
>   qDebug() << "value is" << *value;
>
> which is as cluttered as before in my eyes.

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. People 
just write

const int value= string.toInt();

optional makes it more obvious for the lazy user that this can fail in 
some contexts. It can also assert in debug if dereferenced, for example, 
making bug finding easier.

- optional is much more friendly to static verification than &ok 
(dependancy between variables is a mess to check).

Still, the issue about the semantic of “if(value)” when value == 0 / 
false is still a concern (and one of the reason optional is not part of 
the standard iirc)

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QOptional

[Julien Blanc]

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)
>>  qDebug() << "value is" << *value;
> This is a source-incompatible change (and the bool* ok = 0 is optional). You
> cannot add such an API in Qt 5. You'd need to chose a different name.
>
> While I agree that the existing API is not nice, coming up with new names
> won't be much nicer. In Qt 6, I we can just use std::optional and similar. In
> Qt 5, personally, I'd say lets stick with what we have and not try to reinvent
> yet another part of the STL.

Unfortunately, std::optional is not part of the standard, neither will 
it be included in c++14.

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QOptional

[Julien Blanc]

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.
> I agree it's not intuitive, but it's there and this feature is used by QtSql.
>
> When getting a nullable column, a null entry is signalled by a typed QVariant
> for which isNull() == true.
>
> I'd have preferred that QtSql use optionals to indicate such columns:
>
>   varchar => QOptional
>   varchar not null=> QString

QString may not be the best example, as it already supports the 
nullability concept, which makes QOptional quite useless...

> The question I have is: how can we prepare a transition from current state
> (both a QString) in such a way that doesn't break existing code?
>
> Should it be a connection-time option for QSqlDatabase? Maybe a query-time
> option?

Do you mean that you would change QSqlRecord::value to return, instead 
of a QVariant that can be null, a QVariant holding either an optional or 
a non-optional object ? I don’t see any advantages in doing so. That 
would make sense if you could get rid of the whole QVariant stuff, but 
that would imho need a complete redesign of QtSql. Otherwise, it’ll just 
add an extra layer, not providing any usefull feature (QVariant already 
does the job quite well in providing the nullability feature).

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

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 u_cleanup() is called? Will it just miss data, or crash? 
> This would need to be thoroughly tested ...

Seems a good candidate for a phoenix singleton[1], then.

Wouldn’t it make sense to call u_cleanup only in debug mode ? Since it 
is just a matter of false positive in memory leaks analyzers…[2]

Regards,

Julien

[1] as per Alexandrescu’s definition in modern c++

[2] the issue may not be as neglictible as it seems. Having no memory 
leaks reported is a sane check in a continuous integration system.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Disabling exception support in QtCore?

[Julien Blanc]

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 to a slot is a completely different
>> developer than who wrote the signal or the slot.
> I think your assumptions are false.
> When using signals and slot in an application one write both the signal and
> the slot at the same time, to wire two part of that same appliation.
This may be true in a (small) application, but definitely not if you are 
developping a library. Usually, you write signals but don’t have any 
clue about the slots that will be connected to.

>> That would mean people who do connections should have to pay attention to
>> what slots throw and know what signals can cope with exceptions being
>> thrown.
> Signals and slots are not different from normal functions in that respect
> (especially virtual functions)
> One need to take care who calls your function when you throw exceptions.
That would mean that both slots and signals needs to document which 
exception they can respectively throw/handle. With qt5 we gained static 
checking of signal/slot compatibility. Introducing exceptions here would 
ruin this gain, since it will introduce a new way for signal and slots 
to be incompatible.

And i don’t know how you can reasonably catch an exception in an 
asynchronous call.

IMHO, slots should be nothrow.

>> I would accept at most exceptions through the invokeMethod mechanism in a
>> DirectConnection, since that's a 1:1 relationship and there are no signals.
+1. Exceptions outside DirectConnection would be very strange animals.

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development