Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 2015-02-09 15:30, André Pönitz wrote: > Will you propose to use 'auto' instead of 'int' whenever it compiles? > Just because 'auto' *sometimes* makes sense? Personally, I'm a fan of AAA :-). However that's not an option for Qt because there is no reasonable way to use it while still supporting C++98. Ergo, comparing 'auto' to Q_NULLPTR is apples and oranges. That said, I'm also a fan of using nullptr everywhere... and Q_NULLPTR *does* allow using it when possible while still being C++98 compatible. (Yes, *everywhere*. IMHO, '0' as a null pointer constant is an anachronism that can and should be avoided in modern code. I would happily enforce a rule to that effect.) -- Matthew ___ 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.)
On 2015-02-09 15:05, Marc Mutz wrote: > On Monday 09 February 2015 20:10:44 André Pönitz wrote: >> On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote: >>> I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I >>> know at some point we will be able to just s/Q_NULLPTR/nullptr/. That's >>> not possible with 0 (not even with NULL (could be C code)), so I don't >>> see the point in continuing to use 0. >> >> At some time you will be able to ran clang-modernize with the >> Use-Nullptr transformation or something similar. >> >> [...] >> Diversity is good in biology. Less so in code. > > By the same token, we should stop fixing code formatting "mistakes" in > passing, > since we could just run clang-format. As a related anecdote, I actually have code bases (okay, personal code bases, but still) that run format checking *as a pre-commit hook*. It's quite nice to have a code base that is completely style-consistent (as much so anyway as tools can validate) :-). (I suspect there are Python code bases for which this is also true.) I've also worked on non-private code bases that have been occasionally audited with code formatting tools. -- Matthew ___ 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.)
On 2015-02-10 17:44, André Pönitz wrote:
> On Tue, Feb 10, 2015 at 05:15:03PM -0500, Matthew Woehlke wrote:
>> On 2015-02-08 16:42, André Pönitz wrote:
>>> I.e. in case of a simple pointer initialization, why should one *ever*
>>> prefer
>>>
>>> void something()
>>> {
>>> Foo *f = Q_NULLPTR;
>>> ...
>>> }
>>>
>>> over
>>>
>>> void something()
>>> {
>>> Foo *f = 0;
>>> ...
>>> }
>>>
>>> ?
>>
>> For the same reason that *any* style rule exists: to encourage standard
>> practices that make it easier to use compiler tools to find bugs.
>>
>> If I religiously use Q_NULLPTR, than I can also turn on the warning that
>> tells me when I use '0' as a null pointer constant. Which in turn can
>> help catch places where I really meant '0' and *not* a null pointer but
>> an unintended conversion is occurring. Conversely, because 'nullptr' is
>> not an integer, you can't accidentally call something that takes an
>> integer when you really meant a pointer (doesn't apply so much to your
>> specific example, but is a reason to use it in general).
>>
>> If '0' is permitted in some contexts, then it is hard to use the
>> warning, and therefore hard to catch bugs. (And, as mentioned, not using
>> it *in headers* can be particularly annoying to someone who wants to
>> employ such a policy downstream, and can't because Qt produces huge
>> amounts of warning spam. Granted, "in headers" should perhaps read "in
>> public macros", but still...)
>>
>> As Bo noted, it's your own problem whether or not to use it in Qt's own
>> .cpp files. Please consider your users when deciding whether or not to
>> use it in headers, however.
>
> Are you reading the mails you are responding to?
...yes?
You asked why nullptr/Q_NULLPTR should be used in contexts where the
benefit is less obvious. I gave several reasons (here and also in a
different reply) why I think it should be - and indeed, why, when
possible, I personally *do* - use it everywhere, including places such
as the above example. I also noted that some of these reasons may or may
not be important to Qt.
(Admittedly some comments may be directed more to the direction of the
discussion in general than particular points of a specific mail. I image
most people prefer fewer mails :-).)
In what way do you feel that is off topic?
--
Matthew
___
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.)
Marc, I'm not sure if you're arguing for or against nullptr :-)... On 2015-02-10 18:23, Marc Mutz wrote: > On Tuesday 10 February 2015 20:13:12 André Pönitz wrote: >> Can't you simply wait until 'nullptr' is available? > > No. > > For a simple reason: using nullptr (Q_ or not) is more expressive than 0. And > why would i want to throw away information I already have? (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to Qt, but just saying...) >> Do you really *need* to use macros instead of the core language? > > Do you use 'emit' when you emit signals? Lemme tell you: It's a pesky macro > and it just adds line noise. I do use 'emit'. It adds information, not noise. When I see 'emit', I know that I am emitting a signal and not just calling some method. I can also search my code for 'emit'. (Searching for signal emissions is very hard if I am not using 'emit'.) Similarly, if for some reason I need to know where a null pointer occurs, I can at least search for 'nullptr' and know I will not get false positives. Try that with '0' and you will get *LOTS* of false positives. (I may not find all of them, but the ones I'd miss, I'd miss regardless of using '0' or 'nullptr'.) -- Matthew ___ 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?
On 2015-02-10 18:33, Thiago Macieira wrote: > Eh... have you tried to convert a UTF-8 or UTF-16 or UCS-4 string to the > locale's narrow character set without using QString? Yup... we would need to standardize libiconv (or an equivalent) for that :-). > Have you tried to convert a number to string? You need C++14 to do that > reasonably, since std::to_string didn't exist in C++11. How about the > reverse? > The only way to do that is sscanf or std::istringstream. (OT: What happened to the proposal for that? Did it die from overengineering?) > We may want to have this discussion for QVector vs std::vector. For QString > and QByteArray, there's no discussion: they stay, period. Heh. That reminds me, when will Qt classes get emplace methods? Or the ability to accept movable-but-not-copyable types? (Or did they? Last I checked, one or both were issues in 5.4 at least...) This is the only reason I am (grudgingly) using STL classes for my unique_ptr's. (Something else to consider for Qt 6 would be fixing the index types to be size_t instead of int. Assuming we don't just drop the classes.) -- Matthew ___ 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?
On 2015-02-10 18:40, Marc Mutz wrote: > On Tuesday 10 February 2015 22:26:50 Thiago Macieira wrote: >> It's not insurmountable. I can think of two solutions: >> 1) pre-allocate enough space for the UTF-16 data (strlen(utf8) * 2), so >> that the const functions can implicitly write to the UTF-16 block when >> needed. Since the original UTF-8 data is constant and if there are no >> out-of-thin-air values, multiple threads could do this operation >> simultaneously safely. > > No, they can't. The writes conflict and neither happens-before the other -> > data race -> UB. If I spin up a bunch of threads that do a memcpy into a common output buffer from a common input buffer, where the latter (input) is immutable (at least until all threads are done executing), do you mean that the contents of the output buffer after any memcpy completes are unpredictable? ...because that would surprise me. (Assume that all writes that occur in the memcpy are atomic.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt containers and non-copyable types (was: Why can't QString use UTF-8 internally?)
On 2015-02-10 19:44, Thiago Macieira wrote: > On Tuesday 10 February 2015 19:07:09 Matthew Woehlke wrote: >> Heh. That reminds me, when will Qt classes get emplace methods? > > I added those methods to my local refactor of QVector, but.. > >> Or the ability to accept movable-but-not-copyable types? > > ... they aren't useful because we'll never accept movable-but-not-copyable > objects. An implicitly shared container implies a copyable contained object. Wouldn't you just disable sharing (and indeed, copying the container at all) if the type is non-copyable? (Isn't this what happens with std::vector? I'd have to think yes...) >> (Something else to consider for Qt 6 would be fixing the index types to >> be size_t instead of int. Assuming we don't just drop the classes.) > > For QVector, we might have to switch to qint64 or to qintptr or some other > name for a *signed* integer type. If it has to be signed, ssize_t (okay, same as qintptr I guess, so really I'm just voting against an always-64-bit type) would seem preferable. (Why does it need to be signed? For methods that return 'not found' I'd expect the all-1's value, a la std::string. Where do you actually need a negative *value*, e.g. -N, not just -1?) -- Matthew ___ 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?
On 2015-02-11 11:29, Thiago Macieira wrote: > On Wednesday 11 February 2015 11:22:59 Julien Blanc wrote: >> 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 ? > > That's true. And add that there are some zero-width characters too and some > characters that are double-width. I'm not going to claim this is the *best* answer, but at least one that seems logical... length() should be the number of times one must hit backspace starting from the end of the text to erase the entire text. IOW, the number of logical glyphs. Double-width characters are one logical glyph. Combining characters are not independently logical glyphs (e.g. 'ñ' is one glyph, regardless of how it is encoded). Conversely, I'm sure there are times when you need to know the number of codepoints (e.g. allocating memory to make a copy). Possibly length() and size() should return different results. (Which is a mess, but...) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt containers and non-copyable types
On 2015-02-11 11:39, Thiago Macieira wrote: > On Wednesday 11 February 2015 11:31:10 Matthew Woehlke wrote: >> On 2015-02-10 19:44, Thiago Macieira wrote: >>> ... they aren't useful because we'll never accept movable-but-not-copyable >>> objects. An implicitly shared container implies a copyable contained >>> object. >> Wouldn't you just disable sharing (and indeed, copying the container at >> all) if the type is non-copyable? (Isn't this what happens with >> std::vector? I'd have to think yes...) > > That would be required, but the problem is that it can't be easily > implemented. Every non-const accessor function has a call to detach(), which > requires the copy constructor. So, it may not count as "easy", but is it not possible to partially specialize a non-COW implementation for non-copyable types? > There are a couple of functions that search backwards if you give them > negative values. Also because we use signed everywhere and the warnings about > comparing signed and unsigned are annoying. Ah, yes. Okay, then. (TBH I've sometimes found it "nice" that Qt containers use 'int' and not size_t, so I've probably run into the conversion thing also and benefited from 'the Qt way'.) -- Matthew ___ 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.)
On 2015-02-11 04:18, Marc Mutz wrote: > On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote: >> Marc, I'm not sure if you're arguing for or against nullptr :-)... > > Then I agree with André; you need to start reading mails (threads) before > responding :) Will someone *please* explain to me why you think I'm not? Marc: what made me scratch my head was your comments regarding 'emit'. In general, you appear to be arguing for nullptr, but then you say you don't like 'emit' while indicating that the arguments in favor of 'emit' are similar to the arguments in favor of nullptr. Am I missing why this isn't a contradiction? Is my irony detector broken? >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to >> Qt, but just saying...) > > While true, this is semantics that we can't rely on in Qt atm. (Ahem: "[this is] not relevant to Qt". Speaking of irony, I guess I'm not the only one that can't keep the entire thread straight...) > nor can it be relied on that Q_NULLPTR doesn't convert to an > integral type. True for a given build. However, there is a fair chance that some other (C++11) build will break in case of such code, increasing the chances that someone will notice any issues of this nature. > The latter is esp. interesting, as I believe some compilers > implement NULL to be nullptr-like even in C++98 (and Q_NULLPTR is NULL if > it's > not nullptr), so you *may* benefit even in C++98 by using Q_NULLPTR instead > of > 0. But you can't _rely_ on that. This too :-). -- Matthew ___ 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?
On 2015-02-11 12:00, Thiago Macieira wrote: > On Wednesday 11 February 2015 11:49:49 Matthew Woehlke wrote: >> I'm not going to claim this is the *best* answer, but at least one that >> seems logical... length() should be the number of times one must hit >> backspace starting from the end of the text to erase the entire text. > > That will depend on the editor. Some may remove the full character with all > the combining characters, some others may not. Yeah, I thought of that :-/. TBH I think these sorts of things should be specified by Unicode (if they don't already; I would rather hope they do) rather than Qt trying to decide how to answer them. >> Conversely, I'm sure there are times when you need to know the number of >> codepoints (e.g. allocating memory to make a copy). Possibly length() >> and size() should return different results. (Which is a mess, but...) > > Uh... no, that's not a good idea. > > If we were going do to something like that, we'd have to find a less > confusing > name. Something like width(). Well... yes, for the sake of compatibility I'm inclined to agree. Changing the meaning of one or both of these, or that they are presently synonyms, would confuse the heck out of people. That said... Bo *did* specify "length()" when he wanted a method to return logical characters and not codepoints. It may be that he's just out of luck there... (@Konstantin, yes I'm aware that logical glyphs != codepoints... that was the whole point of Bo's original request, at least as I understood it.) -- Matthew ___ 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.)
On 2015-02-11 15:38, Marc Mutz wrote: > On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote: >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to >> Qt, but just saying...) > > You said auto ptr = 0 doesn't give you a pointer. By extension, I thought you > were saying that auto ptr = nullptr does (and it does, in a way). Right (well, a nullptr_t anyway which behaves the same as an in-place 'nullptr'; in particular, can be implicitly converted to a pointer, and *cannot* be implicitly converted to a numeric type). > But for Q_NULLPTR, auto ptr = Q_NULLPTR may be deduced as nullptr_t on a > c++11 > compiler, int (NULL = 0) on others, long (NULL = 0L) on yet other, and void* > (NULL = (void*')) on the rest (yes, not all of them are valid in C++). Good point. You're right that Q_NULLPTR "isn't adequate" here. (OTOH, the range of compilers / versions that support C++11 'auto' but *not* C++11 'nullptr' or e.g. something like __null is not so great.) > So I maintain that we can't rely on nullptr semantics here as long as we use > Q_NULLPTR. Same for foo(int) vs. foo(void*). Right. Qt is not at a point where it can write API that relies on the existence of nullptr/nullptr_t. Overloading in particular is a no-go. Q_NULLPTR is still useful because *some* builds will break if you try to pass a Q_NULLPTR where only an integer type is accepted, but not *every* build will catch such errors even using Q_NULLPTR. (I think we're in agreement on this point?) -- Matthew ___ 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.)
On 2015-02-11 16:21, Thiago Macieira wrote: > On Wednesday 11 February 2015 15:54:40 Matthew Woehlke wrote: >> On 2015-02-11 15:38, Marc Mutz wrote: >>> On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote: >>>> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to >>>> Qt, but just saying...) >>> >>> You said auto ptr = 0 doesn't give you a pointer. By extension, I thought >>> you were saying that auto ptr = nullptr does (and it does, in a way). >> >> Right (well, a nullptr_t anyway which behaves the same as an in-place >> 'nullptr'; in particular, can be implicitly converted to a pointer, and >> *cannot* be implicitly converted to a numeric type). > > True, but that's not the point here. The only value allowed for nullptr_t is > nullptr, which is why any nullptr_t can be converted to any pointer. > > However, the point here is: > > auto ptr = nullptr; > ptr = &something; // error! > > void *ptr = nullptr; > ptr = &something; // ok True, but if you know what type you want (e.g. 'void*') you should be specifying it explicitly. I was thinking of a case where you are going to pass nullptr to something, but for some reason you want to put it in a local variable first. (Admittedly, it's a stretch.) I think we've gone just a bit off topic for something I said up front wasn't very interesting :-). > What's the type of ptr in? > auto ptr = __null; > > Hint: GCC prints this warning: > warning: converting to non-pointer type ‘long int’ from NULL [-Wconversion- > null] Huh :-). So much for hoping that __null == nullptr in C++11 mode. (I'm not going to claim to understand the intricacies of __null...) >> Right. Qt is not at a point where it can write API that relies on the >> existence of nullptr/nullptr_t. Overloading in particular is a no-go. > > It can be done, with some effort, for non-public API (that is, not ABI- > binding): > https://codereview.qt-project.org/100076 > specifically > https://codereview.qt-project.org/#/c/100076/4/src/corelib/kernel/qmetatype_p.h Well, sure; I was intentionally ignoring the case of a library work-around to provide a nullptr_t. (Pedantic: shouldn't that have a conversion operator?) >> Q_NULLPTR is still useful because *some* builds will break if you try to >> pass a Q_NULLPTR where only an integer type is accepted, but not *every* >> build will catch such errors even using Q_NULLPTR. (I think we're in >> agreement on this point?) > > Only if we build with -Werror -- which we do, in the compilers that support > __null. Um... do you not have *any* C++11 builds? If Q_NULLPTR == nullptr (which I assume it is in C++11?), and you try to pass Q_NULLPTR to something that wants an integer type, you'd better get a compile error, because such a conversion is not allowed by the C++ standard. (At least gcc-c++-4.8.3-7.fc20.x86_64 correctly rejects this.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Improved Q_ENUM
On 2014-12-15 08:38, Olivier Goffart wrote: > I have been working on some improvements to moc and the meta type system to > improve Q_ENUM. Those changes are targeting Qt 5.5 > [...] > > If you use Q_ENUM, you get: > - Using it with qDebug prints the actual string of the value. > - a QVariant containing that enum can automatically be converted to QString >or QByteArray with the value name. Also, if the QVariant contains a QString >or a QByteArray with a value name, it can be converted to the enum type. >(This could be useful for QML as well, as you should not need to >artificially expose the enums to QML anymore) Sorry to jump in so late, but... *THIS IS AWESOME!* Converting enums to strings and vice versa is very common, but I'm not aware of a generic solution to the problem until now. (Yes, bidirectional; as mentioned, use in settings, UI, file export etc. are all existing non-debug uses. Not that the QDebug support isn't killer by itself :-).) I have two questions, though: 1. How does this interact with QSettings? If I directly pass an enum to e.g. QSettings::setValue, is it written as an int or an enum (I guess int)? What about if I use QVariant::fromValue (i.e. so the variant type is the enum)? 2. If I have a QString that I want to convert to the enum, is there a way to test if the string matches an enum value? (Also, is the conversion case sensitive?) Because I am lazy :-), can you give us a brief summary of how string conversion works (or does it?) for flags? -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Improved Q_ENUM
On 2015-02-18 11:44, Olivier Goffart wrote:
> On Wednesday 18 February 2015 11:25:54 Matthew Woehlke wrote:
>> Sorry to jump in so late, but... *THIS IS AWESOME!* Converting enums to
>> strings and vice versa is very common, but I'm not aware of a generic
>> solution to the problem until now. (Yes, bidirectional; as mentioned,
>> use in settings, UI, file export etc. are all existing non-debug uses.
>> Not that the QDebug support isn't killer by itself :-).)
>>
>> I have two questions, though:
>>
>> 1. How does this interact with QSettings? If I directly pass an enum to
>> e.g. QSettings::setValue, is it written as an int or an enum (I guess
>> int)? What about if I use QVariant::fromValue (i.e. so the variant type
>> is the enum)?
>
> I have not tried QSettings yet, but since it works with QVariant it should
> work.
Sure, I'd expect it to work, also :-). What I meant was, does it get
written as an integer, or as a string?
>> 2. If I have a QString that I want to convert to the enum, is there a
>> way to test if the string matches an enum value? (Also, is the
>> conversion case sensitive?)
>
> Yes, the conversion is case sensitive. It works using QMetaEnum.
> In Qt 5.5 you can do
> QMetaEnum::fromType().keyToValue("ABCD");
That's rather... unfortunate. For the QVariant case (e.g. QSettings, UI
guts) it's maybe tolerable. For the explicit keyToValue, would it be
possible to add a case insensitive option? (I'm thinking of e.g. reading
from user input, where it is desirable to follow a 'liberal in what you
accept' policy.)
>> Because I am lazy :-), can you give us a brief summary of how string
>> conversion works (or does it?) for flags?
>
> Flags, are not yet supported within QVariant. Maybe for 5.6
Fair enough. I'd originally thought that was the case, but when you
later mentioned Q_FLAG, I was less sure. (Obviously this gets into
interesting cases like, how do you convert to/from string when the flag
value is a combination of enum values and does not exactly match an enum
value? Solvable, but requires putting a little more thought into it.)
Related: do you gracefully handle unknown enum values?
Also, If I have a QString that I want to convert to the enum, is there a
way to test if the string matches an enum value? (I don't mean some
particular value, in case that was unclear. Rather, how do you handle
failure of keyToValue because the string doesn't match any enum value?
Does it rely on returning a magic value that must not be a valid enum
value to be detectable? Is there an optional 'okay' parameter? Is there
a way to test first if the conversion would be valid?)
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Improved Q_ENUM
On 2015-02-18 12:14, Thiago Macieira wrote: > On Wednesday 18 February 2015 17:44:05 Olivier Goffart wrote: >> On Wednesday 18 February 2015 11:25:54 Matthew Woehlke wrote: >>> 1. How does this interact with QSettings? If I directly pass an enum to >>> e.g. QSettings::setValue, is it written as an int or an enum (I guess >>> int)? What about if I use QVariant::fromValue (i.e. so the variant type >>> is the enum)? >> >> I have not tried QSettings yet, but since it works with QVariant it should >> work. > > But if already worked, this means the new file format will be different than > what it used to. We may actually have to keep the current format so old > applications can read the settings file produced by new applications. (Did you mean to say that backwards? I would generally expect new settings may not be compatible with old code...) I'm not sure there is an issue here. If I do this: settings.setValue(key, enumValue); ...I think this relies on implicit conversion to int (because QVariant can't construct from an arbitrary type without fromValue, correct?), and so will (continue to) write a number. Even with Q_ENUM. Therefore, this won't break. Similarly, a QVariant with a "genuine enum type" was not previously convertible (correct?), so anyone that is *using* fromValue to serialize is also overloading the stream operators anyway, and in such case probably will not switch to Q_ENUM (or at least will be aware of the possible consequences of doing so). IOW I don't think any existing code will change by accident just by starting to use Q_ENUM. (There might be a case for allowing conversion of QVariant with an int to an enum, if the int is a valid enum value. For that matter, does the other direction work? If I have a QVariant with an enum, can I get the numeric value from that without knowing the enum type?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Improved Q_ENUM
On 2015-02-18 16:53, Thiago Macieira wrote:
> On Wednesday 18 February 2015 12:16:58 Matthew Woehlke wrote:
>>> I have not tried QSettings yet, but since it works with QVariant it
>>> should
>>> work.
>>
>> Sure, I'd expect it to work, also :-). What I meant was, does it get
>> written as an integer, or as a string?
>
> Neither.
>
> It's written as @Variant()
> where the QDataStream serialisation includes the type's name. It also only
> works if you've registered operator<< and operator>> for your type.
enum foo {bar};
QSettings().setValue("foo", bar);
Didn't check, but considering I haven't even registered the metatype,
I'm pretty sure this writes "foo=0". However, that goes back to my
previous point; adding Q_ENUM(foo) is not going to change this, because
the value is already converted to numeric when the QVariant is
constructed, when I'm doing it this way.
If I'm doing QVariant::fromValue(bar), then presumably I already
have my own QDataStreap << and >> operators, and Q_ENUM isn't going to
change that either (at least not without me as a developer being very
aware of that change, which I think is sufficient).
A better question might be if this works:
Q_ENUM(foo) // assume same 'foo' as above
QSettings().setValue("foo", QVariant::fromValue(bar).toString());
auto v = QSettings().value("foo");
v.value(); // does this return foo::bar?
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 07:29, Daniel Teske wrote:
> Qt's container classes and C++11 range based for loop do not mix very well.
> Ranged based for uses std::begin(container), which if not overloaded calls
> container.begin(), which detaches.
As an aside, the "correct" fix for this IMHO is for range-based for to
support a mechanism for marking the RHS 'const', whether or not it
otherwise would be so.
Worst case, Qt could (should?) implement something like:
struct QConstWrapper
{
ContainerType::const_iterator begin() const;
ContainerType::const_iterator end() const;
// remaining "magic" elided
};
QConstWrapper qConst(ContainerType const&);
That said, note that range-based for also differs from foreach in that
the former operates on the original container, whereas the latter
operates on a copy.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 14:28, Thiago Macieira wrote:
> On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
>> That on a non-const shared container
>>
>> for (auto i : container)
>>
>> will detach it. That's why having rules instead of saying "just use
>> it", I guess...
>
> And who says it's not what you wanted?
>
> for (auto &i : container) {
> if (i.startsWith("foo"))
> i = bar;
> }
Correct me if I'm wrong, but:
auto c = expensive();
// assume 'c' is shared and a deep copy of c would be really expensive
foreach (auto const& item, c) { ... } // does not deep copy
for (auto const& item : c) { ... } // *does* deep copy; ouch!
I think the point here is that it's easy to incur deep copies using
range-based for when there is no need to do so. There really "needs" to
be a simple and concise way to stop that from happening.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 14:36, Thiago Macieira wrote:
> On Thursday 19 February 2015 12:07:04 Matthew Woehlke wrote:
>> On 2015-02-19 07:29, Daniel Teske wrote:
>>> Qt's container classes and C++11 range based for loop do not mix very
>>> well.
>>> Ranged based for uses std::begin(container), which if not overloaded calls
>>> container.begin(), which detaches.
>>
>> As an aside, the "correct" fix for this IMHO is for range-based for to
>> support a mechanism for marking the RHS 'const', whether or not it
>> otherwise would be so.
>>
>> Worst case, Qt could (should?) implement something like:
>>
>> struct QConstWrapper
>> {
>> ContainerType::const_iterator begin() const;
>> ContainerType::const_iterator end() const;
>> // remaining "magic" elided
>> };
>>
>> QConstWrapper qConst(ContainerType const&);
>>
>> That said, note that range-based for also differs from foreach in that
>> the former operates on the original container, whereas the latter
>> operates on a copy.
>
> It actually needs to be:
>
> template const T qConst(const T &t) { return t; }
>
> It needs to create a copy and return it. There's a gotcha with range-based
> for
> that it is defined in such a way that your temporaries may be destroyed
> before
> the iteration. The standard defines it as:
>
> {
> auto && __range = ;
> for ( auto __begin = std::begin(__range),
> __end = std::end(__range);
> __begin != __end;
> ++__begin ) {
>= *__begin;
>
> }
> }
>
> If you have a temporary in your right hand of the ':' it will get lifetime-
> extended by that __range reference. Any other temporaries will get destroyed.
>
> That means a cast works and a copy works. Returning a reference doesn't.
You'll note that I did *not* return a reference.
Returning a copy may be okay for Qt since containers are COW (in fact,
your version would result in a range-based for that works much more like
Q_FOREACH, which is probably good for some cases). What I was aiming for
was rather a class that internally holds a reference to the container
(such class would be copyable) and forwards the calls to begin/end to
that container, such that in a range-based for it appears to *be* the
container, but forces use of const_iterator. Note that this would work
equally well for non-Qt containers, as long as they have 'IteratorType
{begin,end}() const' methods. (Trailing return specification may be
required to permit the container's iterator type to be unknown.)
I was initially thinking that this was perhaps simple enough to not be
worth it. Given your point, I am leaning more toward that it *would* be
valuable.
(I still think the best solution is for C++ to just accept 'const
' as a modifier to make the type of '' constant, regardless
of whether or not it was. This would allow things like 'for (auto item :
const container)', '(const this)->begin()', 'foo(const bar)', and so forth.)
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 15:21, Marc Mutz wrote:
> On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
>> more than 400 lambdas in Creator's source
>
> Sounds like lambdas are overused (as any new language feature is overused
> before it's fully understood by the resp. language community).
Maybe, maybe not.
I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
using them most often in QObject::connect. Basically, a lambda saves
writing a protected (or worse, *private*) slot by allowing the relevant
code to be written inline. These are rarely more than a few lines long,
and it's not unusual for them to be one-liners, e.g.:
connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
[d](int value){ d->scrollTo(value); });
The above is basically a private slot that's *actually private*. I've
also had cases of needing to connect a signal to a slot where the slot
needs to be called with additional (constant) arguments; these tend to
look like the above also.
Of course, the usual caveats of binding to a lambda apply, but in many
cases those aren't issues (e.g. my MainWindow class is not going to
disappear without taking its widgets with it, and said widgets aren't
likely to be emitting signals from other threads).
p.s. It would be cool if these restrictions could be relaxed by adding
an overload that takes a QObject that "owns" the slot.
>> and have several interfaces
>> that take a std::function.
>
> What about boost::function?
Ugh, make Qt depend on boost? No, thanks...
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 16:27, Kevin Funk wrote: > On Thursday 19 February 2015 15:41:42 Matthew Woehlke wrote: >> p.s. It would be cool if these restrictions could be relaxed by adding >> an overload that takes a QObject that "owns" the slot. > > http://doc.qt.io/qt-5/qobject.html#connect-6 (since Qt 5.2) > > Isn't that what you need? > - Resolves issues with thread-affinity (via QueuedConnection if req.) > - Automatic disconnect when the receiver/context is destroyed Um... how'd I miss that? Thanks! :-) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-20 04:04, André Somers wrote: > One example I could come up with as a potential new API is > QSortFilterProxyModel. Currently, it requires subclassing to change the > sort or the filter functions: it supplies protected filterAcceptsRow, > filterAcceptsColumn and lessThan functions. I think that it would be > much more convenient if these filters and the comparator could be > supplied as a function object (a lambda, or a functor, or a std::mem_fn, > anything callable as a function). While this wasn't all that practical > in the past, I think C++/11 makes this much more convenient than > subclassing. While that would certainly work... I'm not entirely convinced I would actually use it. Not with lambdas, anyway, unless they just handed off to member functions anyway. This sort of thing is above my threshold of 'things I'd want in inline (source-inline, i.e. lambdas) functions'. That said... QThread. Taking a functor that can be a lambda for something like QtConcurrent::run (which I think may already do this) or to replace the run() of a QThread seems useful. There are probably other examples along similar lines as QThread and QSortFilterProxyModel where currently one must override a virtual method that might be much easier to use a stateful functor instead. Another thing that might be useful is variadic templates. I suspect there are a number of places that right now have overloads for 0-N / 1-N arguments or use default parameters to achieve similar effects that could use variadic templates instead. (QMetaObject::invokeMethod and QString::arg come to mind...) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-20 07:10, Иван Комиссаров wrote: > Sorry for interupting the discussion, but i saw mentioning of a > range-based-for, so i have a question. std::map/unordered_map uses > std::pair as a value type, and map::iterator::operator* returns reference > to a pair, while Qt doesn't have an underlying struct and operator* returns > ref to T (without a Key). So, using range-based-for (and foreach) with Qt > containers doesn't allow to have an access to a key. > Should this behavior be changed in the future (yes, this breaks source > compatibility)? No. No need. (Also... note that foreach doesn't give you keys either.) You can instead wrap the container in an iterator wrapper that gives you iterators rather than values. (I have code somewhere, but not sure I have permission to share it.) No SIC, and you can still iterate directly over values. It's not entirely unlike the trick to do: for (auto const i : qtIndexRange(5)) ...and looks like: for (auto const i : qtEnumerate(map)) Maybe it would be nice for Qt to provide one or both of these? -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 20:26, Thiago Macieira wrote:
> Do NOT do this. This will crash:
>
> for (auto const &item : std::cref(somefunction()) { ... }
Does it crash without the std::cref? If not... seems like a good
argument to support a free 'const'...
> And another reason is that std::cref is a C++11 Standard Library addition and
> we cannot depend on that yet.
...but so is range-based for (and auto).
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-20 14:42, Thiago Macieira wrote:
> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote:
>> for (auto const i : qtEnumerate(map))
>>
>> Maybe it would be nice for Qt to provide one or both of these?
>
> Sounds easy enough. Want to give it a try?
I'm happy to give you my headers; not sure when/if I'd have time to
clean them up as actual patches against Qt, however. For enumerate,
though, I technically need the customer's permission to share it.
> Note that this should also work for foreach:
>
> foreach (const auto i, qtEnumerate(map))
>
> Something like:
>
> template
> struct QEnumerateMap : private Map
> {
> struct const_iterator {
> typename Map::iterator i;
> iterator(typename Map::iterator i) : i(i) {}
>
> // need to return by value
> std::pair
> value() const
> { return std::make_pair(i.key(), i.value()); }
> };
>
> const_iterator begin() const
> { return iterator(Map::begin()); }
> const_iterator end() const
> { return iterator(Map::end()); }
> };
No, that doesn't seem right at all (unless you were going for a
non-broken cref?).
The way I did it is I construct a minimal class that has a reference to
the map (though, as discussed, this might need to be a copy), containing
a private iterator type, and begin()/end() methods. The private iterator
type is constructed from the container iterator, and needs to implement
its own operator++, operator== and operator*. The last one is key; it
returns the underlying iterator, rather than value() of the same.
Index range works on basically the same idea, only the 'underlying
iterator' is a number, you construct it from a number, and begin()
returns an iterator(0) while end returns an iterator(m_end). The
iterator needs the same operators, with the obvious implementations.
This all works with range-based for. Not sure about foreach...
One thing I notice you *did* get right is separating the utility class
from the function to create it; you do need to do this for template
deduction.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-20 04:04, André Somers wrote: > Bo Thorsen schreef op 20-2-2015 om 09:03: >> Andrés question about how this would change the API is a lot more >> interesting. I so far haven't seen a single case where someone has >> described how access to lambdas might improve the API. If they are >> there, I'd love to see them, because maybe this would teach me >> something I haven't figured out yet. > > One example I could come up with as a potential new API is > QSortFilterProxyModel. Currently, it requires subclassing to change the > sort or the filter functions: it supplies protected filterAcceptsRow, > filterAcceptsColumn and lessThan functions. I think that it would be > much more convenient if these filters and the comparator could be > supplied as a function object (a lambda, or a functor, or a std::mem_fn, > anything callable as a function). While this wasn't all that practical > in the past, I think C++/11 makes this much more convenient than > subclassing. On that note... a potential use I just ran into yesterday that I might use is *duck punching* (essentially what you're describing, but in a more general form). I am in the process of porting a multi-column item list from a somewhat ad-hoc implementation to one based on reusable classes. The new version uses a complex two-layer item model setup; an underlying model to track the raw data, and a proxy model to provide an appropriate representation of that data. This *almost* allows me to drop the old subclassed QTreeView in favor of a stock QTreeView... but there's a problem: one of the columns is a "star" that allows the user mark "interesting" items. The user should be able to toggle this just by clicking on the star icon. The old stuff handled this by simply overriding a mouse event handler for the view. The new stuff doesn't (yet?) have a subclassed view, and I'd really like to keep it that way. (I'd also really like to avoid creating a custom delegate widget just for this, as I'd then have to move the display logic to that rather than the proxy model; that's an undesirable duplication of code.) If this was in Python, I'd just replace the mouse event handler in the QTreeView :-). I could imagine it being useful in other situations also to be able to override the event handlers (not necessarily event(), but specific ones e.g. paint(), mouseMoveEvent(), keyPressEvent(), etc.) with a QFunction. p.s. besides being less elegant, installing an event filter doesn't seem to *work*; it doesn't see mouse events! -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
On 2015-03-03 05:17, Koehne Kai wrote: > What's missing from the list IMO is using QObject::connect with > PointerToMemberFunction instead of SIGNAL(), SLOT(). I thought that was just new in Qt5, and that it does *not* require C++11. The documentation seems to imply so, anyway: "The number of arguments in the signal or slot are limited to 6 if the compiler does not support C++11 variadic templates." ...which brings up another potentially missing item; variadic templates. Not sure if any examples would benefit from those or not... -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
On 2015-03-03 14:43, Thiago Macieira wrote:
> On Tuesday 03 March 2015 12:57:55 Matthew Woehlke wrote:
>> On 2015-03-03 05:17, Koehne Kai wrote:
>>> What's missing from the list IMO is using QObject::connect with
>>> PointerToMemberFunction instead of SIGNAL(), SLOT().
>> I thought that was just new in Qt5, and that it does *not* require
>> C++11. The documentation seems to imply so, anyway:
>>
>> "The number of arguments in the signal or slot are limited to 6 if the
>> compiler does not support C++11 variadic templates."
>
> The syntax is possible in C++98, but the greatest improvement of the syntax
> is
> the ability to connect to lambdas.
True :-). (We might have a QFunction at some point, but I agree that
true lambdas are the most useful case.) Although even without true
lambdas, I think the new signatures allow you to implement "pure"
private slots (that is, call a method on a class's Private without
leaking anything at all into the public interface)?
> There's also the problem you mentioned of the limit of parameters. I would
> rather people not have to remember how many they can use, so we should
> restrict this to C++11.
>
>> ...which brings up another potentially missing item; variadic templates.
>> Not sure if any examples would benefit from those or not...
>
> Unlikely, we don't create new template classes in our examples. There are
> also
> very few classes in the Qt sources that would benefit from it.
I can think of a few that *might*... QString::arg,
QMetaObject::invokeMethod... anything that takes a pseudo-variadic list
(there are a few places), maybe. (Although I can imagine that the
internals may not in all cases be conducive to being rewritten as true
variadics.)
And on a different note... what about initializer lists? I literally
just today was writing:
QProcess process;
process.start("cmd", {"arg", "arg", QString::number(value) ...});
I'm not going to start a war on omission of class types (although I do
find it can be quite convenient, especially for things where the type is
obvious, e.g. lots of places that take a QRect, QPoint, QSize, etc.),
but I could see making use of the ability to pass vectors in-place via
initializer.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
On 2015-03-03 16:49, Thiago Macieira wrote:
> On Tuesday 03 March 2015 16:15:59 Matthew Woehlke wrote:
>> And on a different note... what about initializer lists? I literally
>> just today was writing:
>>
>> QProcess process;
>> process.start("cmd", {"arg", "arg", QString::number(value) ...});
>
> Why wouldn't that already work?
It *does* work. I *love* it :-D. But it requires at least partial C++11
support, does it not? My point was, I didn't see initializer lists on
the list of features to potentially use in examples.
>> I'm not going to start a war on omission of class types (although I do
>> find it can be quite convenient, especially for things where the type is
>> obvious, e.g. lots of places that take a QRect, QPoint, QSize, etc.),
>> but I could see making use of the ability to pass vectors in-place via
>> initializer.
>
> Those don't need initialiser lists. The uniform initialisation syntax would
> simply call the appropriate constructor.
Yes, different features. Sorry for muddying things :-). (Although I
personally am a fan of uniform initialization, I'm not arguing for its
use in examples... for one, I'm pretty sure it would further restrict
compiler support. If nothing else, there's a GCC bug as late as 4.8 at
least that references can't be {} initialized.)
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing the -c++11 option from configure
On 2015-03-24 12:51, René J.V. Bertin wrote: > On Tuesday March 24 2015 08:39:17 Thiago Macieira wrote: > >>> if you want to enable support c++11+ by default (it isn't yet?), do it, >>> but why would you *remove* an option? >> >> I want to remove the ability to disable C++11 support. >> >> The support is already enabled by default and we'd like to now enable C++14 >> too, but I'd like not to add complexity to the configuration by adding a >> c++14/no-c++14 option. > > What does that have to do with being able to deactivate C++11? /Methinks it > might be a while before C++14 can become the default on all supported > systems, no? Option 1: Provide selection of language level support. Right now this would require four switches ([no-]c++11, [no-]c++14). This has various and hopefully fairly obvious drawbacks. Option 2: Use the highest available language level support. The drawback is that if your compiler supports C++xy, Qt will be built in C++xy mode *with no way to force a different mode*. Thiago is proposing Option 2. In particular, the emphasized drawback; what is being removed is the ability to *prevent* Qt from enabling C++11 / C++14 mode if the compiler supports such a mode. It does *not* mean that Qt as a whole will require C++14. I think where the confusion is occurring is that there is an implicit "where supported by the compiler" in "enabled by default". C++11 / C++14 will be enabled (by default / unconditionally) *on compilers that support those modes*. We're not talking about dropping support for pre-C++11/14 compilers, just dropping the ability to not make use of the same if it is present. Hopefully that helps clear things up... -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing the -c++11 option from configure
On 2015-03-24 15:04, Keith Gardner wrote: > Why not make it a switch for highest language support. Instead of > -no-c++11, make it -c++03. This would allow for adding -c++1z in the > future without adding the -no-c++* all over. This will also handle the > contradictory -c++03 and -c++14 being in the same configure args since the > existence of -c++14 is the highest requested. Alternatively, only support '-no-c++xy' options, and by default use the highest level not prohibited by such an option. This has similar advantages and also doesn't conflict with the goal of enabling the best possible language level by default. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] share opengl resource
On 2015-03-31 10:12, Alessio Mochi wrote: > Hello,I am reading that share opengl resource is possible with > wglShareList. My software run on windows and mac and I would like > know if exist some qt support to share opengl resource. I use qt > 4.7.4. Qt 4.7 is *really* old. If you use Qt5 and QOpenGLWidget, resources should automatically be shared between widgets with the same parent. See the documentation for details, and how to set up additional sharing if needed. In Qt4, in order to share resources, you must create contexts yourself and set them up to share. It's possible to do this without a special 'sharing context' under the covers, but code-wise it's easier to just create a context that you never actually use except to tell your 'real' contexts to share with it. Again, see the documentation; it explains how to do this. p.s. This is not the appropriate list for such questions; please ask on inter...@qt-project.org instead. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Outdated Branch Guidelines and Commit Policy?
On 2015-04-01 11:32, Thiago Macieira wrote: > 5.4 should receive important and non-risky bugfixes. Can I request that https://bugreports.qt.io/browse/QTBUG-43269 and https://bugreports.qt.io/browse/QTBUG-45328 be fixed in 5.4? At present, one must employ hackish work-arounds (in one case, using low-level GL functions directly) for these in order to use QOpenGLWidget and QOpenGLFramebufferObject together, which seems like a not-so-trivial flaw in that subsystem. It's possible that current distros will pick up 5.4.2 soon after it is released, but 5.5.x may not be available until 2016. (On a related note, I'd really love to see a fix for https://bugreports.qt.io/browse/QTBUG-38599 in 4.8.7. Yes, 4.x; Qt4 is going to be around for a while yet, especially in LTS distros, and this is a fairly painful bug.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Why is QTBUG-27186 closed?
I'm getting a little sick of my users having problems because QFileDialog::getSaveFileName does not add the extension. Can someone please explain to me why this (apparently quite popular) bug is not only *NOT* fixed after so long, but the bug claims it *is* fixed and has been closed? -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why is QTBUG-27186 closed?
On 2015-04-02 09:11, Friedemann Kleint wrote: > the behavior of the widgets-based dialog is equivalent to Qt 4.X and > that was the end of the story back then. As reading material for Easter, > I pushed up a proposal to gerrit ( > https://codereview.qt-project.org/#/c/109815/ ). I expect KDE 5 will > (again) provide a spectactular native file dialog? Likely. Still... equivalent (to Qt 4) or not, it seems clear to me from the numerous comments both on Qt bugs and on e.g. Stack Overflow, that users (i.e. not just myself) expect and desire for the Qt internal dialog to have the same behavior as the KDE dialog. It may be too late to change this for Qt 4, but please, let's get it right for Qt 5 :-). Thanks for repoening. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why is QTBUG-27186 closed?
On 2015-04-02 10:38, René J.V. Bertin wrote: > On Thursday April 02 2015 09:46:29 Matthew Woehlke wrote: >> It may be too late to change this for Qt 4, but please, let's get it >> right for Qt 5 :-). > > With KF5 aiming to be "just" a modular set of extensions to Qt 5, why > not leave it like that, and just push the KDE devs to implement the > file dialogs in something that's reasonably small and standalone? Do you honestly expect that every Qt install on a Linux-based platform will also have the base KF5 libraries installed? Even on a machine that is otherwise running some other desktop (Gnome, XFCE, etc.)? (*Especially* on a machine that only has Qt installed because of some one-off application?) I don't find that reasonable. Nor does it help anyone who, for whatever reason¹, is disabling use of native dialogs. In short, I don't see this as a solution unless it *replaces* QFileDialog. (¹ And there *are* legitimate reasons. Some applications may need the ability to tweak the dialogs or their behavior. I've seen some do it just for cross-platform consistency.) > Adding specific code to an extension library is usually preferable to > patching Qt ... There may be cases in which I would agree with that statement. This is not one of them. This is *not* a bug that is specific to Linux. It affects all platforms that do not replace QFileDialog with a platform native dialog, whether because such is not available, or because the user has disabled the native dialogs for whatever reason. It's not a platform issue, it is a defect in QFileDialog. Patching Qt is the *exact right* thing to do in this case. Instances where the patch are not appropriate are instances where the code shouldn't be executing in the first place². (² Maybe this means that the code change should check that the built-in dialog being used, and not a native dialog. That would make sense, and I would have no objection to having the change only apply in that case. The code change still needs to be made in Qt itself, however; the case that does not work is the case where an extension library is *not* in play.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why is QTBUG-27186 closed?
On 2015-04-02 12:27, René J.V. Bertin wrote: > On Thursday April 02 2015 11:58:58 Matthew Woehlke wrote: >> Do you honestly expect that every Qt install on a Linux-based platform >> will also have the base KF5 libraries installed? Even on a machine that > > No, and I didn't say that. I did mention "reasonably small" and "standalone", > meaning not requiring all of the base KF5 libraries. Yes, but unless it's *part of Qt*, it's still something else that you have to make a special effort to install (or else convince distros that Qt should package-require it). And if it is as small as you are suggesting, why *not* just have it be part of Qt? :-) >> (¹ And there *are* legitimate reasons. Some applications may need the >> ability to tweak the dialogs or their behavior. I've seen some do it > > Isn't that exactly what this is about? How does fixing QFileDialog > help applications that disable these dialogs to roll their own? In my experience, applications that roll their own do so by subclassing QFileDialog. Ergo, this has a chance of helping them. If they're completely rolling their own, then Qt has very limited ability to help them do the right thing, besides provide useful tools, which I think we already do to anything within the extent of "reasonable effort". Frankly, however, I am more concerned with applications that are just using the built-in QFileDialog as-is, which is the case this would benefit most directly. >>> Adding specific code to an extension library is usually preferable to >>> patching Qt ... >> >> There may be cases in which I would agree with that statement. This is >> not one of them. This is *not* a bug that is specific to Linux. > > That statement was not specific to the QFileDialog issue [...] Fair enough. My reply was aimed at this specific case. As I said, in other instances, I may well agree. (I decline to commit to agreeing or not simply because I can't think of a concrete example case offhand.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Are SiCs through #include cleanups considered acceptable?
On 2015-04-09 07:04, André Somers wrote: > I think it *is* reasonable to remove such indirect includes if they are > not needed for Qt itself. However, it is worth looking into how the > thing was documented to begin with. In the case of qHash(), the > documentation for that one actualy says the include is . I think > it is *not* reasonable to break that. Is that relevant? My understanding is that what is being changed is not that #include declares qHash (which seems to me like it should - and probably, must, since QHash itself needs qHash - continue to happen), but that unrelated headers that incidentally used to include qhash.h would newly include only qhashfunctions.h instead. I don't object to that. I also support the notion of a separate header *just* for qHash. Bonus points if we get :-). Slightly off-topic: included ? Ick, that's one change I'm glad to see. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On 2015-04-14 12:27, Thiago Macieira wrote: > The problem is the public, *user* class if they derived from QApplication. > > If they've overridden notify(), then I need to know when the *user* class > begins destruction so that we stop calling notify(). Would it be horrible to add a new method, e.g. shutdown(), which subclasses are required to call in their dtor? It won't fix existing applications, but it at least provides a mechanism to make things work. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
On 2015-04-15 10:43, Marc Mutz wrote:
> On Wednesday 15 April 2015 11:49:56 André Somers wrote:
>> void MyClass::setFoo(QString value)
>> {
>>PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY
>>Q_UNUSED(guard);
>>
>>m_foo = value;
>> }
>
> This is an interesting idea, though I don't think I have encountered the
> problems with which you motivate PropertyGuard.
>
> For use in a library, though, I fear the string-based mechanism is too
> inefficient. For use within QtWidgets, say, I'd suggest a mechanism that
> works
> on the member data directly.
FWIW I had the same thought; also, I'm not a fan of needing the
Q_UNUSED, or using a macro to 'hide' it.
What about something like this?
QPropertyGuard g{this};
g.addProperty("a"); // use QObject::property
g.addProperty("b", m_b); // take value member by reference
g.addProperty(m_c, &cChanged); // ...and also slot address
It's slightly redundant because declaring the guard and adding a
property are separate, but there is no unused object, and you can use
the same guard for multiple properties.
The implementation is trickier (probably you need a dynamically
allocated templated helper class with a virtual base to store the value
and check for changes), but avoids multiple string-based look-ups.
The "slot" could be a functor, like QObject::connect accepts, that could
be any of the actual slot, std::function, lambda, etc.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
[Valid points about the inconsistent state of the object elided.] On 2015-04-15 10:58, André Somers wrote: > What if that slot [connected to the instance property changed > signal] triggers something that ends up deleting the instance? Then the slot is broken. What if the sender needs to do something after it delivers the signal? What if other slots are connected? Deleting a signal sender from a slot connected to the signal is inherently dangerous. Don't do it. This is why we have deleteLater()... IMO it's perfectly valid for an object to assume that emitting a signal will not cause it to be deleted. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
On 2015-04-15 12:29, Andre Somers wrote:
> On 15-4-2015 17:08, Matthew Woehlke wrote:
>> What about something like this?
>>
>>QPropertyGuard g{this};
>>g.addProperty("a"); // use QObject::property
>>g.addProperty("b", m_b); // take value member by reference
>>g.addProperty(m_c, &cChanged); // ...and also slot address
>>
>> It's slightly redundant because declaring the guard and adding a
>> property are separate, but there is no unused object, and you can use
>> the same guard for multiple properties.
>>
>> The implementation is trickier (probably you need a dynamically
>> allocated templated helper class with a virtual base to store the value
>> and check for changes), but avoids multiple string-based look-ups.
>>
>> The "slot" could be a functor, like QObject::connect accepts, that could
>> be any of the actual slot, std::function, lambda, etc.
>
> I'm not sure I understand your solution, or what it yields over what I
> am using now. Of course what I do is not using multiple string lookups.
> The property is looked up once on construction of the guard object. Then
> the current value is copied as a QVariant, as it is made available
> through the property system. The signal meta-method is also stored from
> the constructor, so the destructor can use it. So, only one
> string-lookup needed per property. The elegance is that it uses the
> property system to get the value *and* the notification signal to
> trigger, so it is really easy to use.
The second form would thus save the value <-> QVariant comparison and
not much else. The third form however eliminates the string look-up
entirely by having the user provide both the backing member variable
*and* what to do when a change should be emitted. (I'd expect this to be
the change signal most of the time, but taking a functor adds the
flexibility of allowing users to do other things if needed.)
> The need for a Q_UNUSED is inherent in any RAII class that you don't
> explicitly use any more. It works without, but you get a warning about
> an unused variable which is annoying. QMutexLocker suffers from the same
> problem.
"Yes", but separating the construction and property binding eliminates
that (because you "used" the guard after all) and allows one guard to
track multiple properties, with a potential saving in memory complexity.
The down side is that it's a little more typing, so it's a trade-off.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
On 2015-04-15 13:55, Alan Alpert wrote: > The common case is one property I think, so keep that case to one > line. I'd envision using it in all my basic setters to save code at > the start of a project, and then when the features start to creep in > it's easier to add complexity into the setters. If you use the helper class always, sure. I was thinking I probably would not use it for the "easy" cases, i.e. where only one value changes, and instead use it only where it becomes more important to have the helper, in which case it's more likely you have two or more values. Anyway... > Still, you could always leave in a convenience constructor or just > wrap it in a macro as before. ...there's always this :-). The case with one property (or, for that matter, if you don't care about having multiple instances of the helper) can still use a macro to collapse the two lines of code that either version "needs". For that matter, the addProperty flavor doesn't preclude having convenience ctors that also call addProperty :-). -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modifying and accessing environment variables in Qt
On 2015-04-28 04:52, Simon Hausmann wrote: > [getenv/setenv not thread safe] > > There are various options about what we can do with different degrees of > "perfection", > but ultimately it's all going to require a compromise. The option that we are > favoring > at the moment is two-fold: > > 1) Policy in Qt is to use the Qt wrappers for accessing the environment > (qgetenv, etc.). > > 2) These functions we protect with a mutex. > > The concrete proposal of change is at > > https://codereview.qt-project.org/#/c/58/ > > What do you think? Is there a reason not to use a read/write mutex for this? -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.7 release candidate available
On 2015-04-30 09:17, Salovaara Akseli wrote: > If blocker issues for Qt 4.8.7 release (i.e. new regression) are found please > report those to bugreports.qt.io and raise issue also (with bug id) on > releasing mailing list. Is there no hope for getting https://bugreports.qt.io/browse/QTBUG-38599 fixed? This is a really nasty bug that cripples all (newly launched) Qt applications when it happens. It's listed as P1 and has been reproduced, but I don't know enough about the bowels of QSessionManager to suggest a solution. KDE4 is likely to be around for a while yet (e.g. LTS distros) and it would be good if this can be fixed. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-20 14:42, Thiago Macieira wrote:
> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote:
>> for (auto const i : qtEnumerate(map))
>>
>> Maybe it would be nice for Qt to provide one or both of these?
>
> Sounds easy enough. Want to give it a try?
I *finally* got permission to share this. Sorry it took so long.
The attached code, excluding the copyright notices, is hereby placed
into the Public Domain. Permission is also granted to use the attached
code under either the BSD license, as stated in the files themselves, or
pursuant to Kitware's CLA with Qt.
It is my hope that this is useful to other people. (Also that the first
one finds its way into STL eventually :-), though that's a bit OT for here.)
These are both C++11 code. At minimum, they'll need brace-initialization
changed to parentheses-initialization in order to build in C++03 mode.
However, qtIndexRange also uses trailing return type specification, and
I'm not sure it's possible to avoid that without losing type deduction,
which sort-of defeats the purpose. There are also lots of elided type
specifiers, though those are easy enough to add.
Personally, I wouldn't consider it a terrible loss if these were only
available in C++11-or-later mode, since they're intended to be used with
range-based for.
> Note that this should also work for foreach:
>
> foreach (const auto i, qtEnumerate(map))
I'm not sure if it will or not; it was designed to work in range-based
for, i.e. it supplies begin() and end(). I'm not sure if that's enough
to automagically work in Q_FOREACH.
Thiago, do you want me to take another look at integrating these into Qt
proper, or do you have it in hand?
--
Matthew
/*
Copyright 2015 Kitware, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither name of Kitware, Inc. nor the names of any contributors may be used
to endorse or promote products derived from this software without specific
prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS''
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Based on code written by Matthew Woehlke and used by permission.
*/
#ifndef __qtEnumerate_h
#define __qtEnumerate_h
//-
template class qtEnumerator
{
public:
class iterator;
qtEnumerator(Container const& container) : c(container) {}
iterator begin() const { return {c.begin()}; }
iterator end() const { return {c.end()}; }
protected:
Container const& c;
};
//-
template class qtEnumerator::iterator
{
public:
using Iterator = typename Container::const_iterator;
Iterator operator*() const { return i; }
iterator& operator++() { ++i; return *this; }
bool operator==(iterator const& other) const
{ return i == other.i; }
bool operator!=(iterator const& other) const
{ return i != other.i; }
protected:
friend class qtEnumerator;
iterator(Iterator const& iter) : i{iter} {}
Iterator i;
};
//-
template
qtEnumerator qtEnumerate(Container const& container)
{
return {container};
}
#endif
/*
Copyright 2015 Kitware, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other mat
Re: [Development] Suggested addition to wiki.qt.io/Coding_Conventions
On 2015-05-13 04:25, Marc Mutz wrote:
> Hi,
>
> I'd like to suggest the following addition to the Qt Coding Conventions:
>
> === Exporting Classes ===
>
> Export polymorphic classes as a whole:
>
>
> class Q_LIB_EXPORT QMyWidget : public QWidget
> { ...
>
>
> But don't export non-polymorphic classes that way. Instead, only export the
> following non-inline methods.
>
> * public
> * protected
> * private, if called from inline functions (now or in the past)
>
> Rationale: On Windows, symbols from a DLL that don't have inline linkage
> (templates or inline functions have inline linkage) need to be exported for
> clients to link against them, This is what the Q_*_EXPORT macros are
> for. On some Unix systems, the macros map to a similar mechanism that
> hides symbols not exported that way, positively affecting startup
> performance and library size.
>
> But exporting the whole class, while convenient, has several drawback:
>
> * it exports symbols that don't need exporting:
> ** private methods never called from user code
> ** methods of private nested structs and classes
Many Qt classes have corresponding Private (PIMPL) classes. Private
methods would hopefully be few and far between.
Is it possible to override the export decoration for things like this
that should *not* be exported?
> ** inline methods
> * exporting inline methods makes MSVC call the library implementation in
> debug
> builds
That's a feature. There are reasons why debug builds don't inline
(mostly because it makes stack traces unreliable).
> ** a copy of the function is placed in the library even though the library
> itself may never use it
What if I need to take the address of an inline method (e.g. to use it
as a functor argument)?
> ** exported inline functions can no longer be removed
They can't anyway, as this would be both an API and ABI break; see
previous point.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-04-30 16:04, Matthew Woehlke wrote: > On 2015-02-20 14:42, Thiago Macieira wrote: >> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote: >>> for (auto const i : qtEnumerate(map)) >>> >>> Maybe it would be nice for Qt to provide one or both of these? >> >> Sounds easy enough. Want to give it a try? > > I *finally* got permission to share this. Sorry it took so long. > > The attached code, excluding the copyright notices, is hereby placed > into the Public Domain. Permission is also granted to use the attached > code under either the BSD license, as stated in the files themselves, or > pursuant to Kitware's CLA with Qt. > > It is my hope that this is useful to other people. (Also that the first > one finds its way into STL eventually :-), though that's a bit OT for here.) > > These are both C++11 code. At minimum, they'll need brace-initialization > changed to parentheses-initialization in order to build in C++03 mode. > However, qtIndexRange also uses trailing return type specification, and > I'm not sure it's possible to avoid that without losing type deduction, > which sort-of defeats the purpose. There are also lots of elided type > specifiers, though those are easy enough to add. > > Personally, I wouldn't consider it a terrible loss if these were only > available in C++11-or-later mode, since they're intended to be used with > range-based for. > >> Note that this should also work for foreach: >> >> foreach (const auto i, qtEnumerate(map)) > > I'm not sure if it will or not; it was designed to work in range-based > for, i.e. it supplies begin() and end(). I'm not sure if that's enough > to automagically work in Q_FOREACH. > > Thiago, do you want me to take another look at integrating these into Qt > proper, or do you have it in hand? Ping? -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-05-14 10:58, Thiago Macieira wrote: > On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote: >> I'm afraid your solution is not working with temporaries containers. > > That should be submitted as a change request to the standard. There are a > couple of other cases where this bites people. > > It needs a new paper. Can you (both) please elaborate? That's... interesting. I'm taking a copy of the container and taking iterators from the copy. It seems to me that the RHS expression in a range-based for should most definitely not go out of scope within the for. Is that not the case? (Does range-based for just not work on temporaries at all?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-05-14 16:37, Thiago Macieira wrote: > On Thursday 14 May 2015 11:34:25 Matthew Woehlke wrote: >> On 2015-05-14 10:58, Thiago Macieira wrote: >>> On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote: >>>> I'm afraid your solution is not working with temporaries containers. >>> >>> That should be submitted as a change request to the standard. There are a >>> couple of other cases where this bites people. >>> >>> It needs a new paper. >> >> Can you (both) please elaborate? >> >> That's... interesting. I'm taking a copy of the container and taking >> iterators from the copy. It seems to me that the RHS expression in a >> range-based for should most definitely not go out of scope within the >> for. Is that not the case? (Does range-based for just not work on >> temporaries at all?) > > for (auto x : function(function2())) > > If function returns a temporary and function passes through a reference, [...] Er... wait. My bad. Does it resolve the issue if 'Container const& c;' in qtEnumerator is changed to be a copy (i.e. remove the '&') rather than a reference? (I was thinking it was a copy when I wrote the above, and, given that this is likely only going to be used on Qt containers, it probably ought to be a copy.) Back on the subject of C++ standard proposals, I thought there was already a proposal regarding lifetime extension of temporaries? (Or did that die? Or not cover this use case?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Q_OBJECT and "override"
On 2015-06-04 08:12, Christian Kandeler wrote: > as anyone who uses clang has probably already noticed, this compiler has > recently added "-Winconsistent-missing-override" to the collection of > flags enabled via "-Wall". What happens if you (push state and) disable the warning at the start of the Q_OBJECT expansion, and pop state after? Ideally this would tell clang to not consider those functions for the purpose of the warning. (And maybe the clang developers would be amenable to making it work that way if it doesn't currently.) p.s. I don't use clang, but if I did I would probably have this switched on as an *error*. Thus, I at least would like to see a solution that doesn't involve turning it off globally. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Avoid overloading of 'error'
On 2015-06-10 10:20, Koehne Kai wrote:
> Hi,
>
> I'm currently converting a codebase from old-style connects to new-style
> ones. Thanks to Qt Creator's refactoring support this is actually quite easy
> ... it gets ugly though when either the signal or slot method name is
> overloaded, and you have to write nice code like
>
> connect(&process, static_cast (QProcess::*)(QProcess::ProcessError)>(&QProcess::Error), this,
> &MyClass::processError);
Not exactly what you were getting at, but relating to the overloaded
signals/slots problem in general:
template
auto qOverload(R (T::*m)(Args...)) -> decltype(m)
{ return m; }
connect(&process, qOverload(&QProcess::error),
this, &MyClass::processError);
In pre-C++11 you can write out explicit flavors for up to however many
arguments you need. Not sure if you can still get return type deduction
that way, though. (I mean in the template argument list... you'd have to
spell out the return type in the helper declaration, obviously.)
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Notes from Modern C++ session
On 2015-06-12 04:17, Marc Mutz wrote: > On Friday 12 June 2015 08:08:51 André Somers wrote: >> Available for use then: > > range-for? > variadic macros (these we already use in tests/ and no-one complained so far). André, you mentioned 'auto'... does that include return type deduction? What about trailing return specifiers? (I recently posted a useful "helper function" - qOverload - that uses a variadic template.) >> Not available for use are: >> * = default, >> * = deleted, Where are these not supported? I have code that (AFAIK) has been using these already, and IIRC our compiler requirements are lower. >> For now, don’t put std lib ABI into Qt ABI, except for nulltpr_t. > > Too late: QException inherits std::exception (for a looong time already), and > by virtue of various exported subclasses of QVector and QList, we export ABI > that contains std::vector and std::list (toStdList(), toStdVector()). We > probably also export ABI using std::string, because I'm sure someone > somewhere > has inherited an exported class from QString... Besides being inline (template, dontcha know), isn't there an option to disable those? (Maybe not std::exception one, but at least the Qt <-> STL container conversions?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Notes from Modern C++ session
On 2015-06-12 13:02, Marc Mutz wrote: > On Friday 12 June 2015 16:49:38 Matthew Woehlke wrote: >> On 2015-06-12 04:17, Marc Mutz wrote: >>> On Friday 12 June 2015 08:08:51 André Somers wrote: >>>> For now, don’t put std lib ABI into Qt ABI, except for nulltpr_t. >>> >>> Too late: QException inherits std::exception (for a looong time already), >>> and by virtue of various exported subclasses of QVector and QList, we >>> export ABI that contains std::vector and std::list (toStdList(), >>> toStdVector()). We probably also export ABI using std::string, because >>> I'm sure someone somewhere has inherited an exported class from >>> QString... >> >> Besides being inline (template, dontcha know), isn't there an option to >> disable those? (Maybe not std::exception one, but at least the Qt <-> >> STL container conversions?) > > No, they are members. If the conversion was a free function, exporting > QVector > or QList wouldn't export the STL types. We can't disable them, either, as > they're already exported. It would also be source-incompatible to do so. Oh, right. Sorry, I missed the "exported subclasses" part. Yes, with exported instantiations, you can't magically make the symbols go away. (Though I suppose users that disable STL would at least not be able to call them, since the declarations would be missing?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some Qt3D feedback
On 2015-06-15 04:18, Marc Mutz wrote: > On Monday 15 June 2015 08:24:22 Simon Hausmann wrote: >> A namespace for functions only, no public classes within. > > _That_ argument again... :) > > Could you explain to me why you think that classes are different from > functions, pleaae? With a small number of exceptions, generally (always?) starting with 'q' (lower case), there aren't global functions in Qt. There are "static member" functions (including actual static member functions in particular, but also namespaced functions), instance member functions, and global class names. For naming convention purposes, a namespace is in effect equivalent to a non-constructible class with only static members. IOW, there is naming symmetry between e.g.: QString::fromUtf8 - and - QtConcurrent::run (Well... except for the 'Qt' vs. just 'Q', but...) However, there is no e.g. 'QtCore::QThread' which would lead to e.g. 'QtCore::QThread::msleep'. > There's simply no difference between a class in a namespace and a free > function in a namespace The difference is explained above: with a few exceptions, functions in Qt public API are (were) qualified by exactly one scope (...until classes in namespaces started appearing). -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some Qt3D feedback
On 2015-06-16 09:33, André Somers wrote: > Marc Mutz schreef op 16-6-2015 om 15:41: >> For type conversions, you're supposed to use static_cast on the rhs: >> >> auto integer = static_cast(someLongLong); > > Sorry, but that just looks silly to me. Why obfusticate the type of the > variable - making it harder to reason about the code - when it yields > you nothing at all? Ignoring whether or not to use 'auto', there actually *is* a reason to use the static_cast... it communicates that, yes, you really want back an 'int', even if that means a conversion loss e.g. because your input is a 'double'. (See e.g. '-Wconversion'.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Notes from Modern C++ session
On 2015-06-12 17:45, Thiago Macieira wrote: > On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote: >>> On Friday 12 June 2015 08:08:51 André Somers wrote: >>>> Not available for use are: >>>> * = default, >>>> * = deleted, >> >> Where are these not supported? I have code that (AFAIK) has been using >> these already, and IIRC our compiler requirements are lower. > > GCC requires 4.7 for this. I think we were discussing whether our minimum is > 4.6 or 4.7. Again... really? I have code using '= default' that sometimes¹ is built on GCC *4.4*. '= delete' seems to be accepted also. (Now... it may be that '= default' is actually broken, i.e. generates bad code, but based on a very simple test I just whipped up, '= delete' at least seems to work. This is with gcc44-c++-4.4.7-1.el5.) (¹ Well... it's 'intended to work on GCC 4.4' and does occasionally get tested, but maybe not often or - as far as verifying that it actually runs correctly - well.) Did it get broken by 4.6 or something like that? >> Besides being inline (template, dontcha know), isn't there an option to >> disable those? (Maybe not std::exception one, but at least the Qt <-> >> STL container conversions?) > > QT_NO_STL isn't supported since 5.0. Ah... don't use it, hadn't paid attention or noticed :-). -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some Qt3D feedback
On 2015-06-18 09:07, Marc Mutz wrote: > 4. Includes: >a. includes the whole module (as is the case for QtCore, ... now) >b. There's no include for just the namespace (with enums, free > functions, etc). To get the namespace, users include any class from the > module (much like no-one is using atm, but relies on any >to include it indirectly). Are you sure? I've used a good handful of times. In general I find it helpful to be able to include just the types / macros / free functions without dragging in some random class that I don't actually care about. Reasons I have used : - I want only the macros - I want only the platform / compiler feature symbols - I want only some free function (e.g. qRound) - I want only the convenience typedefs (e.g. qint64, qreal) So I definitely would not say that there is no use for having a header with a module's global entities separate from the per-class headers. In fact, I'm annoyed that is missing... IMHO if it's a public header, it should have a wrapper. (Well, *was* missing; it was added in Qt5, thankfully!) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some Qt3D feedback
On 2015-06-18 11:17, Marc Mutz wrote:
> On Thursday 18 June 2015 15:45:06 Matthew Woehlke wrote:
>> Reasons I have used :
>>
>> - I want only the macros
>> - I want only the platform / compiler feature symbols
>> - I want only some free function (e.g. qRound)
>> - I want only the convenience typedefs (e.g. qint64, qreal)
>>
>> So I definitely would not say that there is no use for having a header
>> with a module's global entities separate from the per-class headers.
>>
>> In fact, I'm annoyed that is missing... IMHO if it's a
>> public header, it should have a wrapper. (Well, *was*
>> missing; it was added in Qt5, thankfully!)
>
> I believe people with so narrow use-cases can be bothered to include
> .
"Bothered", yes, but it's ugly and inconsistent.
> IIRC, the alternative proposal was to let people include
> the whole module () to get the namespace.
Unacceptable. This drags in a HUGE amount of stuff when I only want a
small piece. From a compile perspective, it would be much better, though
still not optimal, to include some small but irrelevant class, but then
that's bad from a semantic perspective ("why does this header include
when it never mentioned QString?").
> If you step back a bit, you'll notice that both and ,
> as
> well as are big, fat, mistakes.
Why? How can QtNumeric, in particular, be a mistake unless qnumeric.h is
also a mistake?
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some Qt3D feedback
On 2015-06-18 16:33, Marc Mutz wrote:
> On Thursday 18 June 2015 18:16:30 Matthew Woehlke wrote:
>>> If you step back a bit, you'll notice that both and
>>> , as well as are big, fat, mistakes.
>>
>> Why? How can QtNumeric, in particular, be a mistake unless qnumeric.h is
>> also a mistake?
>
> because is the header that brings in all of module Qt Foo. And
> neither
> Qt{Global,Numeric,Namespace} fit that description. Neither does
> QtConcurrent{Run,Map}, btw.
Neither does . Whether or not should be allowed (vs.
) is an interesting discussion, but not one I was trying
to make.
I think we're arguing for different points. It's not the specific name
that matters to me as that there is *some* header which is named
according to modern C++ convention (in particular, no ".h"). If we have
those for e.g. , then IMO we should have them for *all* public
headers. Or we shouldn't have them at all.
I agree that having modules and conceptual groups use the same naming
convention is unfortunate, but I disagree that not providing
modern-named headers *at all* is the correct solution to that problem.
--
Matthew
___
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
On 2015-07-10 06:37, Smith Martin wrote: > ok, thanks, G. That explains it. And then there is the further point that it > is unwise to use Q_DECLARE_TYPEINFO to declare C to be "good" in this case. > What was the reasoning there? It really depends. The issue with Q_DECLARE_TYPEINFO is that adding/changing it breaks binary compatibility, so whether fiddling with Q_DECLARE_TYPEINFO is "unwise" or not really comes down to whether breaking binary compatibility for your project is "unwise" or not. Is your project an application with no exported symbols? Is it part of an application where you tightly control the end product and have no external users linking to your libraries? Then probably there is no issue. OTOH if your project is a widely used library, then breaking BC is almost certainly going to... irritate (to put it mildly) your users. In terms of adding/changing Q_DECLARE_TYPEINFO for classes *within Qt*, then you're definitely in "unwise" territory. HTH, -- Matthew ___ 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
On 2015-07-21 01:06, Thiago Macieira wrote: > On Tuesday 21 July 2015 02:26:41 Kevin Kofler wrote: >> For the implicitly shared data types, QList actually does NOT add another >> layer of indirection (as documented: "If T is itself a pointer type or a >> basic type that is no larger than a pointer, or if T is one of Qt's shared >> classes, then QList stores the items directly in the pointer array."), >> so in that case, it is almost the same as QVector, except that it allows >> prepending items much more efficiently (O(1) in many cases, whereas it's >> always O(n) in QVector). > > Except if the type is larger than sizeof(void*), like QVariant is. > > Or like QString and QByteArray will be in Qt 6. Are these still implicitly shared? Is it possible to have Qt type traits on a type T such that QList will always be QVector-like? Or would it be impossible to support that in QList? (This would be for Qt 6, obviously.) It seems like it would be useful for any shared-data class to be QVector-like in QList, even if larger than a single pointer. (At least, have the ability to make such a type thusly.) ...Is QStringList going to become a QVector? -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QVector now has rvalue push_back
On 2015-07-21 11:53, Thiago Macieira wrote:
> On Tuesday 21 July 2015 09:09:36 Julien Blanc wrote:
>> On 2015-07-20 15:26, Thiago Macieira wrote:
>>> 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 woul
>
> I'm asking why one of the two would be better than the other if I'm trying to
> add a single T to std::vector. You've explained that emplace_back is
> efficient, but you haven't said whether push_back is as efficient, more
> efficient or
> less efficient than that.
>
> emplace_back will do perfect forwarding without copy direct into the vector.
> Does push_back do the same?
Do you *already have* the item instance? If yes, there should be no
difference; both (in an ideal implementation) should result in the item
being constructed in-place using its move ctor.
emplace_back is meant for when you haven't yet constructed the item. For
example:
std::vector list;
// less efficient
auto&& pen = QPen{Qt::red, 1.5f};
list.push_back(pen);
// more efficient
list.emplace_back(Qt::blue, 2.0f);
(Assuming that the compiler doesn't inline and copy-elide them into
equivalence, anyway.)
The second form avoids creation of a temporary. QPen instance is
constructed in the vector in-place; no copy/move (of a QPen) occurs.
(And the construction arguments are normally forwarded, so they aren't
copied/moved either except for POD types for which the "copy" cost is
trivial.)
QPen is not an ideal example; it's most useful for large types that are
expensive to construct, even by move. However, it's pretty well always
going to be more efficient than constructing an object and immediately
appending it to a list, even if only marginally so.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] xcode emplace_back (was: QVector now has rvalue push_back)
Since this touches on a possible standards issue, CC'ing the standards list.
On 2015-07-21 13:00, Gunnar Roth wrote:
> 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)... )); }
From http://www.cplusplus.com/reference/vector/vector/emplace_back/:
"Inserts a new element at the end of the vector, right after its
current last element. This new element *is constructed in place* using
args as the arguments for its constructor." (emphasis added)
From http://en.cppreference.com/w/cpp/container/vector/emplace_back:
"Appends a new element to the end of the container. The element is
constructed through std::allocator_traits::construct, which typically
*uses placement-new to construct the element in-place* at the location
provided by the container." (emphasis added)
Ergo, that implementation looks... suspicious, and *may* even be
non-conforming. (Unless push_back is doing something really funky, which
I somewhat doubt.) You may want to file a bug against that implementation.
@std-discussion, since I don't have a copy of the standardese handy, is
in-place behavior (or possibly rather use of 'std::a_t::construct')
*required* for standards conformance, or is it just QoI? (Is there any
way that the above implementation can be doing in-place construction?)
--
Matthew
___
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.)
On 2015-07-23 08:23, Marc Mutz wrote: > On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> * Q_NULLPTR - strongly encouraged > > Ok, trying to summarize the discussion so we can move forward. > > There's a bug report (https://bugreports.qt.io/browse/QTBUG-45291) about Qt > headers not compiling with -Wzero-as-null-pointer-constant, sometimes not > even > when locking the Qt headers away behind an -isystem. I understood the > discussion in this thread as follows: > > - ok to use Q_NULLPTR in public headers (the bug report suggests that this > should actually be enforced by headersclean). The bug reporter would appreciate that, yes :-). Especially in macros (e.g. Q_OBJECT¹) and default parameter values. (The reporter would also appreciate https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486 getting fixed, but that doesn't seem likely to happen any time soon :-(. And no, I'm not asking Qt to fix GCC bugs; just mentioning it because it is pertinent.) (¹ Pedantic: the original report indicates that the problem in Q_OBJECT is indirect, via QT_TR_FUNCTIONS. IIRC in 4.8.x there are a lot more such issues in Q_OBJECT, most of which have been fixed by now. Also, QT_TR_FUNCTIONS may be fixed already in 5.5; I haven't checked yet.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
On 2015-07-28 04:29, Andreas Aardal Hanssen wrote: > Isn't this needless convenience? Yet another environment variable that > needs documenting? If you want to inspect the contents of a QString, can't > you just add the suitable escape code to your own code? Forcing > qPrintable() or qUtf8Printable() on everyone who wants to keep human > readable debug output sounds pretty evil, but having e.g. toHtmlEscaped() > or a similar function doing the octa/hex thing could be better. While I'm generally trying to stay out of this debate, I'd like to toss in that a QString → QString or QString → QByteArray function that converts from "raw" to either C-style escaped or HTML-style escaped (or for bonus points, both), AND BACK AGAIN, would be useful in other contexts. (For instance, I recently needed to write a new file format that is SSV-like but needs to contain user supplied strings. In order to make tokenizing not incredibly painful, it was decided to HTML-escape the strings so that they would not contain spaces or strange unprintable characters. I've also written C-style escaping functions more than once, especially for encoding and decoding quoted strings with escaped embedded quotes and so forth.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QString behavior change
On 2015-07-30 03:38, Gerhard Scheikl wrote:
> The behavior of QString::trimmed has changed from 5.3.2 to 5.5.
> .trimmed() on an empty string (" ") makes it null
> .trimmed() on an empty string ("") doesn't make it null
>
> Is this intended or a bug?
Whether or not it is¹ should not be relevant; QString has for a very
long time (since mid-4.x at least if not 4.0 or even longer) STRONGLY
discouraged differentiating between empty and null states. Don't do that
:-).
(¹ For a more literal answer, see Thiago's reply.)
> By the way: the output of qDebug is not as expected:
> there are additional whitespaces before true/false and there is even
> another one before null at the first "Before trim" output.
>
> qDebug() << "String with space";
> QString my_string(" ");
> qDebug() << "Before trim: empty:" << my_string.isEmpty() << " null:" <<
> my_string.isNull();
> my_string = my_string.trimmed();
> qDebug() << "After trim: empty:" << my_string.isEmpty() << " null:" <<
> my_string.isNull();
>
> Output:
>
> String with space
> Before trim: empty: false null: false
> After trim: empty: true null: true
Your expectation that is wrong ;-). As noted, QDebug adds spaces between
"things", and you have a space in '" null:"', so the expected output is
two spaces between the previous item and "null"; one added automatically
by QDebug, and one that you printed explicitly.
--
Matthew
___
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
On 2015-08-09 07:58, Kevin Kofler wrote: > Thiago Macieira wrote: >> Please see the C++17 proposal of destructive moves instead. > > It took 4 years for Qt to agree to require a limited subset of C++11, so, > realistically, C++17 features are not likely to end up used (everywhere, at > least) before at least 2021. > > I guess it will also require good compiler optimization to be as effective > as a memmove operating on the whole vector. (Basically, the compiler needs > to detect that you are memmoving a whole vector and convert it to a > memmove.) Please *see* the proposal. The major point is to have the ability to mark such as defaulted, and to detect when it is *trivial*. When its trivial, containers can use memmove/realloc/etc. instead of copying. (It's not clear yet if they will do so directly, or via some helper, but that shouldn't matter performance-wise.) -- Matthew ___ 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
On 2015-08-09 21:58, Thiago Macieira wrote: > On Monday 10 August 2015 02:36:20 Kevin Kofler wrote: >> realloc doesn't work if you are inserting or removing in the middle of a >> vector. > > Sure it does. It's required if you need to insert anywhere but don't have > enough space. > > Now, if you're not appending to the end, you'll need to memmove elements > around, sure. But that's a second step. If you are doing both, isn't it more efficient to allocate and do two partial memmove's rather than doing a realloc? (In the case that you can't do an in-place realloc, that is...) ...that would require a try_realloc though... -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enhancement to QIODevice?
On 2015-09-14 06:25, Andrzej Ostruszka wrote:
> I'd like to ask for possibility to enhance a bit QIODevice.
>
> My problem/wish is following. I'm using QSerialPort and (as all
> QIODevice-s) it is tailored for reading in "lines" ('\n') which is fine
> since most of the time this is exactly what I need. But I just happen
> to have to deal with an older lock-in device which communicates via
> messages terminated by '\r'.
>
> So what I'm aiming to is to make the "line" (or more generally "packet")
> termination a bit more flexible [...]
This sounds like an opportunity to discuss with the folks working on CAN
bus how to make QIODevice more generally friendly to protocols that
communicate with some form of "packet", for whatever that definition
happens to be. QUdpSocket could presumably benefit also.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 0 vs. NULL
On 2015-10-09 11:51, René J.V. Bertin wrote:
> On Friday October 09 2015 13:58:37 Pocheptsov Timur wrote:
>> And yes, void * in C++ can be indeed considered generic, because
>> you can do this:
>>
>> int * p = ... void * pv = p;
>
> Coming from C I have some trouble with that concept of generic
> pointer. Once you're used that it implies not only "can be assigned
> to any type of pointer" but also "can be assigned any type of
> pointer" it's not so easy to remember which of the 2 properties has
> been dropped. I don't see any evident reason why in the above example
> it should be possible to assign p to pv without an explicit cast, but
> not the other way round.
For similar reason as:
struct A {...}; struct B : A {...};
B* b = ...;
A* a = b; // okay
B* also_b = a; // error
That is, 'void' is somewhat like a base class of everything (even POD
types), so an implicit upcast is allowed as always, but also as usual,
not an implicit downcast.
--
Matthew
___
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
On 2015-10-13 15:59, Jake Petroules wrote: > On Oct 13, 2015, at 1:46 PM, Marc Mutz wrote: >> I would therefore like to propose to abandon QString for new API (and over >> time phase it out of existing API), and only provide (const QChar*, size_t) >> as >> the most general form. I would propose to package the two into a class, >> called >> - you guessed it - QStringView. > > In general this sounds like a dangerous idea because it carries over > all the old API concepts (i.e. (QChar *, size_t) is an extremely > broken abstraction). You need to read and truly comprehend > https://developer.apple.com/swift/blog/?id=30 before suggesting any > changes to string-related APIs for the next major version of Qt, > because if anything, THAT is what it should look like. Anything but > that is a near-useless wrapper around binary data, not a true string > class. While I don't necessarily disagree with that article, I think that the points being made are orthogonal to what Marc is proposing. The idea of QStringView would, I presume, be similar to that of std::string_view; namely, to provide an abstraction over a bag of "characters" (using that term rather loosely). It does NOT in any way relate to doing any sort of operations (besides slicing) on a "string". The idea is to be able to inexpensively pass around "text", whether it comes from QString, QStringRef, wchar_t*, or what have you, without having to perform superfluous memory allocations to convert to One True Form (i.e. QString) when the consumer doesn't actually care. That said... I note that slots probably still need to take QString, because a queued call with a QStringView is horribly broken (for reasons which I hope are obvious). At least unless the event dispatcher is clever enough to promote these to QString in the event. -- Matthew ___ 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
On 2015-10-14 07:15, Knoll Lars wrote: > In addition, it might be tricky to use QStringView in signals and > slots. As I previously stated, I'm pretty sure you *CAN'T* use QStringView to call slots, except for direct call. In any other case, you risk the backing data being modified or, worse, deallocated, before the slot dispatches (this is *especially* dangerous with cross-thread dispatch, since now you have thread safety to worry about). The only way around that would be for QStringView to take a COW reference to the underlying data. We already have a class like that. It's called QString. What *might* work is if the event dispatcher, when it makes copies of the arguments, makes a deep copy of QStringView into a QString. I'm not sure if this is possible, though, and anyway then you're in the same boat of making a (potentially) unnecessary deep copy if you had a QString in the first place. -- Matthew ___ 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
On 2015-10-14 06:16, Marc Mutz wrote: > First, afaiu from what Thiago mentions in reviews, Q6String will have SSO > (small-string-optimisation) which makes many short strings expensive to copy > (if you think that copying 24 bytes is slower than upping an atomic int > through an indirection) or cheap to copy (if you think the opposite). In any > case, small strings will be very cheap to create (no allocation), so for many > strings there will be not much difference between passing a QStringView or > passing a QString. Atomic operations are expensive (I think I heard once 'on the order of 100 instruction cycles', but that's highly apocryphal), mainly I would guess due to the need to maintain cache coherency. A small copy might happen entirely in local hot cache. 24 bytes is a whole three registers on a modern 64-bit machine. That's probably not going to be very slow. (Mind, atomics still blow full mutexes out of the water, but they're still an order of magnitude slower than small stack allocations and most single machine instructions.) >> Yes, signed please. We can discuss whether it should be 64bit for Qt 6. > > The current std API uses size_t. Do you (= both of you) expect that ever to > change? If it doesn't, Qt will forever be the odd one out, until we finally > drop QVector etc for std::vector etc and then porting will be a horror > because > of MSVC's annoying warnings. STL should change. In Qt and Python, you can use negative indices to refer to a distance (length) relative to the end (length) of the string. In STL you can't do that, which is a significant limitation by comparison. Please don't drop this useful functionality! > array_view cannot compete with QByteArray's API. E.g. there's no toInt(). ...and it *shouldn't*. Never mind that you're talking about a function that deals with *strings*, it's debatable whether that sort of thing belongs as class methods at all. Anyway, they aren't "missing" in the standard library; they're free functions. (That said, the CSL could use better flavors, and there was some talk of that, but AFAIK it didn't get anywhere. I can pretty well guarantee you the committee isn't going to be adding that sort of thing to array_view, or even string_view, any time soon.) -- Matthew ___ 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
On 2015-10-14 10:30, André Somers wrote:
> Op 14-10-2015 om 15:59 schreef Matthew Woehlke:
>> STL should change. In Qt and Python, you can use negative indices to
>> refer to a distance (length) relative to the end (length) of the string.
>> In STL you can't do that, which is a significant limitation by
>> comparison. Please don't drop this useful functionality!
>
> I'm not so sure anymore. Do you really think that for instance passing
> in a negative _from_ in QString::indexOf to search from the back of the
> string is intuitive API? I don't.
Huh? Of course it is.
s.indexOf('c', 5); // find 'c', forward, starting at offset 5
s.indexOf('c', -5); // find 'c', forward, starting at offset N-5
A negative offset -K is exactly the same as N + 1 - K (N = length of
string). It just saves having to write that out yourself. It *doesn't*
change the behavior of the function. (I think you are confusing
tail-relative offset with reverse operation, which is totally different
and orthogonal.)
Even STL supports this, partially, for -1; string::npos is generally
equivalent to -1 in Qt.
Bah. Okay, apparently Qt actually *doesn't* support tail-relative, but
just treats n<0 like string::npos. That could be improved for Qt 6
though, but only if n is signed.
--
Matthew
___
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
On 2015-10-15 02:38, Ziller Eike wrote: > So from where does 's.indexOf(‘c’, i-2)' search? > > This is similar to integer overflow, and I think utilizing that in an > API leads to less readable and potentially unexpectedly behaving > code. It depends on the value of i, of course. And you're not going to get any better results with an unsigned offset. > Anyhow this seems to be only vaguely related to the things that are discussed > in this thread. There was a question whether to use signed or unsigned as the size type, that somewhere turned into Qt's use of signed for string sizes/offsets being inconsistent with STL/CSL. I suppose it has wandered off a bit on a tangent, though. -- Matthew ___ 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
On 2015-10-14 18:27, Thiago Macieira wrote: > On Wednesday 14 October 2015 21:51:23 Bubke Marco wrote: >> Is UTF 16 seekable? You still have surrogates and you can merge merge code >> points. > > Seekable enough. It's much easier to deal with than UTF-8. A surrogate pair, > as its name says, appears *only* in pairs, so you always know if you're on > the > first or on the second. Moreover, all living languages are encoded in the > Basic > Multilingual Plane, so no surrogate pairs are required for any of them. > Handling of surrogate pairs can be moved to non-critical codepaths. Oh? 😕 -- Matthew ___ 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
On 2015-10-16 19:52, Kurt Pattyn wrote: > On 17 Oct 2015, at 01:18, Marc Mutz wrote: >> I find it intolerable that todays software takes 1000x the memory, >> 1000x the CPU capacity and doesn't get a given jobs done in less >> wallclock time than software 20 years ago. > > These are 'numbers'. Is it like that? Really 1000x the memory, 1000x the CPU > capacity? Er... yes? An 80286 of yesteryear ran as fast as 25 MHz¹. A modern, 6-core 4 GHz CPU has a "theoretical" 24 GHz of "computing power". That's almost exactly 1000x (more, considering the ISA improvements). The same machine could address up to 16 MiB of RAM. A lot of machines around my office have 16 GiB of RAM (my home desktop has more; OTOH, many home machines have less). That's pedantically a factor of 1024x; again, close enough. Basically, yeah... computers some 10-20 years ago had similar specs as modern computers - CPU speed in the single to low double digits, memory in similar ranges - except the numbers were in one 1000/1024-order of magnitude less units (MHz vs. GHz, MiB vs. GiB). The increase in disk space is, if anything, even more extreme. There remains, of course, *some* exaggeration there... modern computers are, after all, tackling quantities of data that computers 20 years ago couldn't dream of touching (consider any process run on large clusters, for example). Even so, it's sobering to think about, especially as a lot of user software is "prettier" but in many ways not actually *better*, at least not in proportion to the increase in resource requirements. (¹ https://en.wikipedia.org/wiki/Intel_80286) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Avoid overloading of 'error'
On 2015-10-29 14:56, Sergio Martins wrote:
> On Wednesday, June 10, 2015 01:55:01 PM Matthew Woehlke wrote:
>> relating to the overloaded signals/slots problem in general:
>>
>> template
>> auto qOverload(R (T::*m)(Args...)) -> decltype(m)
>> { return m; }
>>
>> connect(&process, qOverload(&QProcess::error),
>> this, &MyClass::processError);
>
> Thanks for the tip, how about upstreaming qOverload ?
I haven't gotten around to it. If you want to prepare a patch, feel free
:-). I'd love to see it upstream.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] extending the cocoa native style via a plugin: feasible?
On 2015-12-01 09:03, Olivier Goffart wrote: > Are you talking about the additional roles in KColorScheme? Then I guess the > solution is to add them to QPalette. Yes, please :-). I was disappointed that QPalette didn't get to looking more like KColorScheme in Qt5. It's really useful to have themed colors for more than just "basic text" and "basic background". There are many places that could make use of these, if only they were available. (I cringe inside whenever I make text "red", because I know that someone, somewhere, has red as their default text color, or worse, default background color. With KColorScheme I can use "negative foreground" instead and be confident that it will appear as the user wants.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-03 13:02, Thiago Macieira wrote: > On 2015-12-03 13:49, Marc Mutz wrote: > I'd at least like to propose, for new code and as >> a drive-by, the *required* use of auto for: >> >> - 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 You probably want my index range helper¹ for index iteration... otherwise you need ugly work-arounds to use type deduction. The enumerate helper is also useful for iterating over (Qt) associative containers. (Needs to change to make a copy of the container, though, so that it doesn't have dangling references in case of temporaries. That's a trivial change though.) (¹ http://permalink.gmane.org/gmane.comp.lib.qt.devel/21327) > Except for primitives, because "int" is shorter than "auto". Automatic matching of the index type to the type that the container *actually uses for indices* is preferable to a shorter name. Even if you "know" that the type is int. Whether or not uses of Qt containers are ever replaced with use of STL containers, it's just good habit. Maybe less important in Qt itself, but I still submit that it would be good for Qt to demonstrate the "right" way to do things. Because for your users, it *does* matter. (I have a code base that is absolutely rife with index type mismatches because it predates auto and qtIndexRange. With proper use of those, such errors are avoided.) MHO: don't use a possible type conversion if you can avoid it, and if you do, use uniform initialization so that the compiler will reject a narrowing conversion. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal to change connectSlotsByName behavior
On 2015-12-04 03:01, André Somers wrote: > On 2015-12-03 21:00, Thiago Macieira wrote: >> Note that for widgets, the order is not pure luck. The order of >> children of a QWidget implies the tabbing order. Therefore, it is >> usually well-defined. > > There are explicit methods for setting the tab order. Relying of the > order of creation (which may be the default tab order - I did not check) > is also pure luck, especially with designer-created UI's. I would have to disagree with that (and agree with Marc). I'm quite careful (or at least, I try to be) when using Designer to ensure that my widgets are defined in the .ui file in tab order. I, like Marc, consider it bad form to override the implicit tab order. (For one, it's a maintenance headache.) At any rate, any time I find that my tab order is wrong, I *always* fix it by changing the order of the widgets in the .ui file. (p.s. I believe that the order also controls the order in which widgets are painted. Although this shouldn't matter 99.9% of the time, it does if you have overlapping widgets.) IMHO, QWidget::setTabOrder should be used exclusively when you need the tab order to differ from the child order. > I'd like to add a new alternative (though it does not exclude a change > now either): > > - Deprecate the behaviour and remove in Qt 6. > > I have never thought this feature to lead to good design. It makes for > "magic" in the sense that it is tricky to trace what happened. It leads > to un-Qt-ish naming of methods, and it leads to naming methods based on > when they are triggered instead of what they do. +1. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-04 15:35, André Pönitz wrote: > On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote: >> and it's one reason less to make errors: >> Using 'int' instead of 'quint64' or 'size_t', or QString instead of >> QByteArray >> is way to frequent. (and the compiler won't complain) > > ["QString instead of QByteArray" does not happen with proper > QT_NO__CAST_*_ASCII settings. Not to mention the cases where mindless > replacement of explicit types by 'auto' doesn't produce identical results.] But wrongly mixing integer types *does* happen. I speak from personal experience based on a code base that has a relatively large mess of *exactly* such errors. > Code is typically read more often than changed. Targeting at making > specific refactorings easier is optimizing the wrong utility function. 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]); for (auto i : qtIndexRange(list.size()) foo(list[i]); Which is *really* more meaningful? "The type of 'i' is 'int', and I really, really hope that 'list' is actually indexed by 'int'", or "the type of 'i' is the index type of 'list'¹"? Do you really *care* what is the type of 'i'? Or do you care that it is the *correct* type. I (and others) submit that the latter is more valuable. (¹ ...assuming that decltype(list.size()) is the index type, which it had darned well better be or whoever wrote the API of decltype(list) needs to have their coding privileges revoked.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
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]);
>
> Whether the access is correct depends on the type of list, which you don't
> disclose.
That's sort of *the point*. I can't tell if the above is correct or not.
If it used 'auto', I'd know.
(And it's sort of implied that it *is* wrong. Because, y'know, I see
loops like the above quite often where, indeed, they do in fact use the
wrong type. Actually, QList/QVector are about the *only* times the above
is written correctly without using 'auto'. More often than not, a loop
like that written against a non-Qt container uses the wrong index type.)
> In any case, this loop follows a well-known pattern.
It also follows a really *bad* pattern. The count is reevaluated every
time (well, you hope the compiler will hoist it, but the code says that
it is). Using type deduction... well, sucks:
for (auto i = decltype(list.size()){0}; i < list.size(); ++i)
>> 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))
Just because it isn't standardized (or in Qt) yet doesn't mean it's
"unheard of". It's just that C++ users have been suffering with the
difficult to use form while programmers in other languages have had the
much more sensible form for a long time.
Really, it's not hard... nasty glorified while loop vs. 'I want to
iterate over the indices [starting at zero] up to list.size()'.
There's a reason I strongly prefer the latter form and use it whenever I
can (usually subject to compiler compatibility limitations).
> Moreover it is more to type.
Really?
for (auto i : qtInlist.si))
- vs. -
for (int i = 0; i < list.si; ++i)
Hey, look... mine's *fewer* keystrokes. And much more importantly, it's
*correct*. Yours... may or may not be... as you pointed out, I don't
know without knowing decltype(list). (Or I could use the much longer,
*much* uglier old-style for loop with decltype that is correct, but then
mine wins hands-down.)
> The extra level of parantheses makes it harder to parse for
> humans,introducing an aditional source of errors, which you nicely
> demonstrated by making the example non-compilable.
Bah. A decent IDE would have flagged that as soon as I stopped typing.
(Actually, a decent *text editor* would have shown me () matches, so I
would have noticed *as* I was typing. I challenge you to write bug-free
code the first time in a text editor whose most advanced feature is cut
and paste.)
>> Which is *really* more meaningful?
>
> The first one.
Sorry, but I must strongly disagree.
>> "The type of 'i' is 'int', and I
>> really, really hope that 'list' is actually indexed by 'int'", or "the
>> type of 'i' is the index type of 'list'¹"?
>>
>> Do you really *care* what is the type of 'i'?
>
> Yes, I do care about types, almost always.
Why? As long as it's the *correct* type, what difference did it make?
Let's say that the correct type is my_list::index_t. Let's say I used that:
for (my_list::index_t i = 0; i < list.size(); ++i)
How is that better? Do you know now what is the actual type of 'i'?
I submit that writing 'my_list::index_t' is not a significant
improvement over 'auto'. It didn't tell you anything about the actual
type of 'i'. (It does suggest that the type of 'list' might be 'my_list'
and that a 'my_list' probably uses 'my_list::index_t' as its indexing
type. But there's still that "probably". Whereas 'auto' says the type
*is* the indexing type.)
> Your message has been heard. I do not agree with you.
Likewise.
> I feel more comfortable arguing about whether a type is the right one
> if the type is known than when it is unknown.
Then you are missing the point. In fact, you are missing the whole point
of 'auto'. By using 'auto' correctly, it's possible to know that the
type *is correct*, even if you don't know what the type actually *is*.
(Or if a change elsewhere should change what is the correct type.)
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-04 19:44, André Pönitz wrote: > You don't know whether operator[] or .at() is the best way to access > by index until you know the type of list. Once you know the type of > list, you also know what the type of i should be. There's no point > in being fuzzy about it unless there is a *significant* advantage > to it (like using 'auto' for iterator types which are mostly line > noise). Then there is also no significant advantage to writing an explicit type rather than inferring it. You can't have it both ways. > The context of this discussion is the development of Qt. Thank you for > confirming that 'int' is the right thing to use. The correct *actual* type is 'int'. Whether Qt should encourage bad programming practices by writing explicitly typed index loops, that are more often wrong than otherwise outside of Qt containers, is a different question. > [ > If you care about size() re-evaluation: > > for (int i = 0, n = list.size(); i < n; ++i) > ... > ] ...and now 'n' is mutable, opening the door to bugs due to accidental modification thereof. (As is 'i', for that matter; a range-based for over an index enumerator¹ allows you to make that const also.) (¹ English-language sense, not C++ "enum".) > On Fri, Dec 04, 2015 at 06:10:45PM -0500, Matthew Woehlke wrote: >> On 2015-12-04 17:43, André Pönitz wrote: >>> In any case, this is an uncommon pattern, using some unknown qtIndexRange() >>> function. >> >> Really? >> >> (Python) > > Please stay on topic. The topic was whether to be more 'liberal' with > the use of auto in Qt, written mostly in C++, not Python. The point is that index enumerators are *not* an unknown programming construct, as you assert. >>> The extra level of parantheses makes it harder to parse for >>> humans,introducing an aditional source of errors, which you nicely >>> demonstrated by making the example non-compilable. >> >> Bah. A decent IDE would have flagged that as soon as I stopped typing. > > You are basically assuming that there's no need for you to write sane > code to start with because during your development work you have a > decent IDE to help you out. This assumption is wrong, independent > of the existence of such an IDE. Uh... no? The point is your bashing a particular construct because it can be mistyped *in the pitiful excuse for a text editor with which I'm writing this message*, but will be easily and immediately noticed in a decent editor, is silly. Or, maybe we should stop using C++ because of all those pesky ';'s one has to remember at the end of every statement. > Since the discussion here is about what to use in Qt, the whole Qt > development workflow matters. A lot of Qt code reading happens on Gerrit > without IDE features at hand. The context there usually just a few lines. > The appropriateness of an expression 'list[x]' is impossible to judge > on Gerrit after applying an 'Almost always auto' policy. Well, then, I guess you can't judge if 'int' is the correct type for 'x', either. Sounds like an excellent reason *to* use 'auto'!!! Anyway, if you're going to bash a feature, you need to find a better reason than obvious compile errors that are flagged in the user's editor. Because the chances of those ever being committed locally, much less merged (or indeed, even lasting more than a few seconds) are virtually nil. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-05 06:08, Julien Blanc wrote: > 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) If you don't actually *need* the index, then yes. "Broken" might be strong, but yes, the example is somewhat lacking. A better example would be: foo(i, list[i]); (And yes, if you don't need the index, *please do* iterate over the elements directly!) > On 2015-12-03 13:49, Marc Mutz wrote: >> - 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 ?). Agreed. But the above started with objections to using 'auto' for indexed iteration :-). -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-07 07:48, Ziller Eike wrote:
> On Dec 4, 2015, at 8:01 PM, Olivier Goffart wrote:
>> Because the type is redundent and it's one reason less to make errors:
>> Using 'int' instead of 'quint64' or 'size_t', or QString instead of
>> QByteArray
>> is way to frequent. (and the compiler won't complain)
>
> The compiler will then still not complain if you pass that ‘auto’
> variable to a function taking ‘int’ (or QString, if you don’t have
> NO_CAST_...), will it?
...it won't complain any *less* than if you'd done the cast in an
assignment. But it *might* complain, e.g. if you use the auto in an
initializer list that results in narrowing. Or it might call an
appropriate function overload for the larger type.
At worst, is equally dangerous. But in some cases it will be less dangerous.
Another argument is that the correct way to use 'int' is:
auto i = int{list.size()};
...which will fail to compile if a narrowing conversion occurs. (Or if
you're *truly* paranoid, use 'auto' and then static_assert the actual
resulting type.)
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: new moc feature
On 2015-12-05 07:00, Sean Harmer wrote: > No idea if all of our > supported compilers allow hooking in custom preprocessors or not. Okay, that sentence just scares the pants off me... forget whether or not the *compilers* support it; what about the build systems? Not everyone uses qmake. At minimum you'll want/need to support CMake as well. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-08 09:52, Oswald Buddenhagen wrote: > On Mon, Dec 07, 2015 at 03:39:25PM +0100, Marc Mutz wrote: >> - auto everywhere in C++ means that the type of the rhs defines the >> type of the variable > > it starts with the fact that you didn't specify that you mean just local > variables - it's your unstated assumption. your triple emphasis that > it's not necessary *anywhere* in python implied that you do indeed mean > more than just locals. Any variable definitions, actually... not just local, but also member (static or otherwise) and global. Although IME, AAA is not pushed so much for other than local variables. (Also, 'auto' for NSDM's requires compiler support for default initializers, which is less widely available than 'auto' itself.) >> - the simiarity with C++ auto is that no type name is visible >> - this is what I was referring to >> - the difference to C++ (auto or not) is that in Python, the variable is >> weakly >> typed / dynamically typed / duck-typed, however you may want to call it. >> - in particular, the variable can hold an integer first, then a string, and >> later an object of class type. Conversely, any type can be held in any >> variable. >> >> - this is orthogonal to the omission of the type name, which C++ auto and >> the whole thread is all about, thus *completely irrelevant* to the >> discussion. > > no, it's actually not orthogonal, and that's the whole point. in the > generic case, it's impossible to implement "auto *everywhere*" without > going dynamic. To be clear, the "everywhere" here is limited to variable declarations. (Which must be definitions. Which is one of the objectives of AAA; it prevents uninitialized variables.) Function/method parameters are specifically excluded. (Although using 'auto' there - which C++ is actually moving to allow, although I'm not necessarily thrilled by such - is still not dynamic typing; rather, it is implicit templatization. There are some possible benefits to this, along the lines of AAA, but overall there are many more drawbacks.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-09 07:18, Knoll Lars wrote: > For loop variables, I don’t think we should require ‘auto’. Using it > can be the right thing to do in some cases, esp when using patterns > like ‘for(auto item: items)’ , but when looping using integer > indices, I still prefer ‘for (int i=...; cond; ++i)’. For the record, while I still think 'for (auto const i : qIndexRange(list.count()))' is better, my objection here isn't so much to failing to mandate 'auto' in such cases as forbidding it entirely in such cases. Especially if there ever does end up being code in Qt operating on STL objects where the correct type is something esoteric like 'std::vector::size_type'. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-09 08:15, Bubke Marco wrote:
> Should we recommend forward(universal) references in for loops (which are
> "const &value" for "const values"):
>
> for (auto &&value : values)
Someone remind me; what's the benefit of this vs. 'auto const&'
(assuming that I won't be modifying 'value')?
> or
>
> for (const auto &value : values)
>
> to show the difference to
>
> for (auto &value : values)
I personally prefer making everything I can 'const'. That means 'const&'
returns from functions ("forces" a copy elision), 'const' local
variables, etc.. In the case of loops like the above, if I'm not going
to modify the value, I prefer to say so. If I *am* going to modify it, I
prefer 'auto&' to a) also say so, and b) statically ensure that I *can*.
That's just my 2¢ however; I'd be interested in hearing arguments for
'auto&&'.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFF: nullptr rules
On 2015-12-09 10:14, Marc Mutz wrote:
> in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler,
> but
> there are no guidelines as to its use in the coding conventions (to the
> extent
> they need to be in there).
>
> I propose the following, based on Thiago's proposal from January this year,
> considering the new situation that we now require nullptr support in the
> compiler:
> [...]
> - compilers that have it, will have -Wzero-as-nullptr-constant added during
> headersclean[0]
Yay! :-) Yes, please, for exactly the reason you gave.
> - APIs that require the use of nullptr for disambiguation are discouraged,
> but may be acceptable to be decided on a case-by-case basis.
On that note, there *is* one case in which '0' as nullptr makes sense...
default values for QFlags. A literal '0' "looks like" an empty bitset
much more than 'nullptr', even though IIRC it actually ends up
implemented via a void* ctor. This probably means that those should be
changed to use '{}' as the default initializer instead (i.e. not
'nullptr'). I'm not sure what this means for compiler support (i.e. if
any compilers that Qt still supports don't support it), though I do know
offhand it does exclude GCC < 4.7.
(Alternatively, there could be a qNullFlag or some such, but that might
have compatibility problems.)
> Arguments against:
> - it's uglier than "0", and more to type
FWIW, I'm with Sergio here; not sure I agree about it being "uglier"...
it's certainly more obvious that 'nullptr' is... a null pointer, and not
an integer literal...
(And, likewise, I'm more sympathetic to '0' vs. 'Q_NULLPTR'. But since
that's not what we're talking about...)
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fwd: RFF: nullptr rules
On 2015-12-09 12:23, Richard Moore wrote: > On 9 December 2015 at 15:14, Marc Mutz wrote: >> Arguments in favour: >> -Wzero-as..., >> and it makes no sense to have two sets of rules for headers and impl > > There's nothing that says we need to allow people to use that warning, ...except that it isn't just a question of whether Qt uses it internally, it affects whether or not *consumers* (of Qt) can use it. (And yes, there is some extent to which this is a compiler problem, but fixing it in the compiler is apparently really, really difficult. See e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486.) > and nothing stopping us disabling it for our headers, ...except when that doesn't work, e.g. the bug report Marc referenced. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFF: nullptr rules
On 2015-12-09 17:29, Thiago Macieira wrote: > On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote: > I'd like to propose this: > [...] > c) which means no -Werror=zero-as-nullptr outside of headersclean I just want to say that I think this is fair. The key phrase there is "outside of". -Wzero-as-nullptr is controversial and I can totally understand and accept the Qt project not wanting to go there. It's the *public* headers that (potentially) spill over into preventing other projects that use Qt from choosing to use -W[error=]zero-as-nullptr themselves. So only enforcing it there is more than sufficient to satisfy external consumers of Qt. (Also; thanks for thinking of said consumers!) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-22 05:26, Ziller Eike wrote:
> So, directly after the above example in Item 5, Item 6 in Effective
> Modern C++ continues with the examples of how you can shoot yourself
> in the foot _because_ you used auto. [...]
>
> We have something similar in Qt:
>
> QString a = "ABC";
> QString b = "abc";
> auto result = a + b;
> a.replace("A", "C");
> qDebug() << result;
>
> prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is
> defined, because result is not a QString in that case.
Someone ought to note... one of the arguments for AAA is that it avoids
uninitialized variables. It's actually still AAA to write:
auto result = QString{a + b};
...and in fact that is what AAA recommends when you need to ensure a
specific type.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-22 09:50, Marc Mutz wrote: > foreach(const QString &s : someLongExpression()->fooBar().names()) > > const auto strings = someLongExpression()->fooBar().names(); > for (const QString &s : strings) On that note, is there any case in which Q_FOREACH is superior to a range-based for? (Besides the obvious one where the original list is modified from within the loop?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] foreach (was: RFC: more liberal 'auto' rules?)
On 2015-12-22 11:08, Marc Mutz wrote: > Try to port all your Q_FOREACH to range-for loops. You will be surprised how > much digging is required if you don't always want to take the hit of taking a > copy. Okay, thanks for the info. (One reason I ask is because qtExtensions¹ actually replaces 'foreach' with either a real range-based for, or - for pre-C++11 compilers - a clever construct that is very nearly equivalent²³.) (¹ https://github.com/kitware/qtextensions, although the public version doesn't have the relevant changes yet.) (² See https://github.com/Kitware/vital/blob/master/vital/vital_foreach.h... qtExtensions QTE_FOREACH omits the BOOST_FOREACH flavor but is otherwise identical. We do require that the compiler supports at least partial C++11, including auto.) (³ I believe the only significant difference from how range-based for is specified is that our version currently requires begin and end to be methods on the container. That's mostly laziness; if it ever becomes an issue, we could try to improve this.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-24 19:16, Kevin Kofler wrote:
> Matthew Woehlke wrote:
>> auto result = QString{a + b};
>
> IMHO, that's just a complicated and ugly way to write:
> QString result = a + b;
>
> There is no way the variable can be uninitialized if you initialize it right
> there in the declaration.
That's nice, but what about when you forget to initialize something? If
you (almost) always use auto, the compiler will squawk. The benefit
comes from *consistency*.
Anyway, I'm not trying to argue passionately that Qt should follow AAA.
I'm just saying that it's incorrect to state that you have to deviate
from AAA because it might give you the wrong type. (And, as Marc notes,
AAA, used correctly, actually *better* documents code in such case.)
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
On 2015-12-26 20:17, Kevin Kofler wrote: > And what is hard to parse for humans? The "char* p,q" "issue"? That's a > formatting bug then, this ought to be written "char *p, q", which makes it > very clear what is going on. That's... debatable. Personally, I dislike combining names and type information. And it doesn't always work out so nicely. What, for example, is the type of 'q' here?: char const* const *p, q; Explicit pointer/reference types and multiple declarations should simply not appear in the same statement¹. Period. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
