On 2016-01-19 05:52, Marc Mutz wrote:
> And a QVector provides exactly the same guarantees as a std::vector. How come
> one is easier to use than the other? Because QVector has indexOf()?
append, back, first, front, indexOf, insert(index), last, lastIndexOf,
mid, pop_front, prepend, remove,
On 2016-01-16 00:07, Kevin Kofler wrote:
> I suspect we would lose at least some optimizations from
> Q_DECLARE_TYPEINFO
C++ desperately needs something like this. There was talk a while back
about destructive moves, but I don't believe it ever materialized into a
proposal.
I'd rather see the
On 2016-01-16 07:06, Bubke Marco wrote:
> On January 16, 2016 06:08:14 Kevin Kofler wrote:
>> I suspect we would lose at least some optimizations from
>> Q_DECLARE_TYPEINFO.
>
> std::is_trivially_copyable and other type traits are your friends.
Not really. There is a huge difference between a
On 2016-01-17 07:55, Marc Mutz wrote:
> Another argument against CoW is that it creates non-local dependencies. In
> that, it's like having global variables. With pretty much the same problems,
> cf. the QStringLiteral-in-unloaded-plugins problems.
Ah... no? The problem with QStringLiteral is
On 2016-01-18 12:47, Giuseppe D'Angelo wrote:
> On Mon, Jan 18, 2016 at 6:09 PM, Matthew Woehlke wrote:
>> On 2016-01-17 07:55, Marc Mutz wrote:
>>> Another argument against CoW is that it creates non-local
>>> dependencies. In that, it's like having global variables. Wi
On 2016-01-18 13:40, Bubke Marco wrote:
>> On 2016-01-16 07:06, Bubke Marco wrote:
>>> std::is_trivially_copyable and other type traits are your friends.
>>
>> Not really. There is a huge difference between a relocatable type (many,
>> if not most), and a trivially copyable type (a lot fewer).
On 2016-01-15 06:40, Bo Thorsen wrote:
> I would not mind removing some (maybe even most) of the Qt containers
> for Qt 6 or 7 and forcing people to learn the use std instead. Hash,
> map, set and linked list would be the first I'd get rid of.
Ugh... I *really* hate the idiotic insistence of std
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
&g
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
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
On 2015-12-22 09:50, Marc Mutz wrote:
> foreach(const QString : someLongExpression()->fooBar().names())
>
> const auto strings = someLongExpression()->fooBar().names();
> for (const QString : strings)
On that note, is there any case in which Q_FOREACH is superior to a
range-based
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";
>
On 2015-12-09 08:15, Bubke Marco wrote:
> Should we recommend forward(universal) references in for loops (which are
> "const " for "const values"):
>
> for (auto & : values)
Someone remind me; what's the benefit of this vs. 'auto const&'
(assuming that I won't be modifying 'value')?
> or
>
>
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;
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
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
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".
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
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,
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
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
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
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)
>
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)
>
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
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
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; }
(Apologies for reposting information, but my other message is stuck
somewhere in the moderation queue...)
On 2015-10-26 22:58, Thiago Macieira via Development wrote:
> On Tuesday 27 October 2015 09:05:34 kl222 via Development wrote:
>> Thiago Macieira:
>>
>> 1. I think this is a bug. When using
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
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
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,
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, w
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,
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
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
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
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
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
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
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
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 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
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
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
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
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
On 2015-06-18 09:07, Marc Mutz wrote:
4. Includes:
a. QtFoo includes the whole module (as is the case for QtCore, ... now)
b. There's no QtLike include for just the namespace (with enums, free
functions, etc). To get the namespace, users include any class from the
module
On 2015-06-18 11:17, Marc Mutz wrote:
On Thursday 18 June 2015 15:45:06 Matthew Woehlke wrote:
Reasons I have used QtGlobal:
- 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
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 QtGlobal and
QtNumeric, as well as QtNamespace are big, fat, mistakes.
Why? How can QtNumeric, in particular, be a mistake unless qnumeric.h is
also
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
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
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
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
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
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
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
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.
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:
code
class Q_LIB_EXPORT QMyWidget : public QWidget
{ ...
/code
But don't export non-polymorphic
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
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
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
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
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
[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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/.
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
201 - 300 of 329 matches
Mail list logo
