On Sat, 2011-09-24 at 14:44 +0200, ext Stefan Majewsky wrote:
Why isn't there any variant of Q_ASSERT that expands like
#define Q_ASSERT_ALT(x) x;
in release builds? If it's a simple value check like Q_ASSERT_ALT(x
0), the compiler will optimize the effect-less statement away.
The
On Tuesday, 27 de September de 2011 09:48:29 Joerg Bornemann wrote:
On Sat, 2011-09-24 at 14:44 +0200, ext Stefan Majewsky wrote:
Why isn't there any variant of Q_ASSERT that expands like
#define Q_ASSERT_ALT(x) x;
in release builds? If it's a simple value check like Q_ASSERT_ALT(x
4494 /*
4495 generated by moc
4496 */
4497 template
4498 struct connectProtectedSignal
You need to move this struct to the header, which means either boilerplate
code written by the developer or an include of a moc-generated file in a
public header. Both options would
On Wed, Sep 21, 2011 at 11:43 PM, Thiago Macieira thi...@kde.org wrote:
Also a VERY BAD idea. Q_ASSERT expands to empty in release builds.
Why isn't there any variant of Q_ASSERT that expands like
#define Q_ASSERT_ALT(x) x;
in release builds? If it's a simple value check like Q_ASSERT_ALT(x
On Saturday, 24 de September de 2011 14:01:35 Peter Kuemmel wrote:
Fully agree with Thiago. Making signals private would break an awful lot
of existing code and is in many cases very inconvenient.
I would also prefer if we could continue keeping signals protected, but as
Olivier pointed
On Saturday, 24 de September de 2011 18:02:44 Peter Kuemmel wrote:
Definitely no boilerplate code.
I only see a chance with generated headers, or does 'boilerplate code'
mean only hand written code?
Boilerplate means stuff you have to write to get things up and running.
As an example of
On 9/24/11 6:11 PM, ext Peter Kuemmel syntheti...@gmx.net wrote:
What's more, if this is an *installed* header, we need to make sure that
the
output from moc stays binary compatible on all compilers until Qt 6.
We've
done changes to moc several times during the 4.x lifetime.
Then the
On Saturday, 24 de September de 2011 20:23:35 Peter Kuemmel wrote:
Definitely no boilerplate code.
I only see a chance with generated headers, or does 'boilerplate code'
mean only hand written code?
Boilerplate means stuff you have to write to get things up and running.
OK,
I do not like any solution involving generated headers at all.
The reason is simple: Generated headers are simply not something I can see
us adding to library code. The current headers are nice and relatively
clean.
If we add generated headers, we make deployment of libraries to 3rd
On 9/22/11 5:33 PM, ext Thiago Macieira thi...@kde.org wrote:
On Thursday, 22 de September de 2011 14:06:05 Olivier Goffart wrote:
I almost managed to get the signal private:
class Foo {
public:
class Signal { //This would be in the Q_OBJECT macro.
~Signal() {}; // private
On Wed, 21 Sep 2011 23:43:34 +0200, Thiago Macieira thi...@kde.org wrote:
What is worse for you, that someone unintentionally emits a signal, or
that
you fail to connect because someone made a typo, or accidentally left the
variable names in the SIGNAL or SLOT definition. Not to mention in
On Wednesday 21 September 2011 19:09:11 ext Thiago Macieira wrote:
Is it really nessecairy that _everyone_ has public access to the signal?
What if only QObject had access to it? Would that work? If so, it could
work to just make QObject a friend class of every class that has the
Q_OBJECT
On Thu, Sep 22, 2011 at 8:31 AM, Wolf-Michael Bolle
wolf-michael.bo...@nokia.com wrote:
Why doesn't a class simply provide public connector method templates for the
not so public signals?
// Very simplified example
class Xyz
{
private:
void eventHasHappened(); // A signal
public:
On Thursday 22 September 2011 08:18:49 Frans Klaver wrote:
[...]
I'm still not convinced that the trade-off is worth your while, but you
obviously think it is. There's downsides and upsides to both approaches.
Compile-time check is one thing, but there is also other advantage of the new
code.
On Thu, Sep 22, 2011 at 1:47 PM, Olivier Goffart oliv...@woboq.com wrote:
- You get automatic conversions of the arguments (eg. QString-QVariant or
int-double, ...)
I didn't consider this one.
- You get all the power of connecting using tr1::bind, or to a C++11 lambda
expression.
There
On Thu, Sep 22, 2011 at 2:06 PM, Olivier Goffart oliv...@woboq.com wrote:
class Foo {
public:
class Signal { //This would be in the Q_OBJECT macro.
~Signal() {}; // private destructor
friend class Foo; //- problem: Q_OBJECT macto does not know Foo
};
Signal
- Original Message -
From: Thiago Macieira thi...@kde.org
To: qt5-feedback@qt.nokia.com
Cc:
Sent: Thursday, September 22, 2011 11:33 AM
Subject: Re: [Qt5-feedback] QObject: new signals-slots syntax
On Thursday, 22 de September de 2011 14:06:05 Olivier Goffart wrote:
I almost
On Wednesday, 21 de September de 2011 11.52.03, Peter Kuemmel wrote:
I still see a problem in making signals public, this
completely breaks encapsulation, and makes it possible
for everyone to emit any signal.
There's no way around it. Since we're using the function pointer (actually,
the
On Wednesday, 21 de September de 2011 15.12.21, Thiago Macieira wrote:
There's no way around it. Since we're using the function pointer (actually,
the PMF) to identify the signal, you must have C++ access to the signal
function. That means you must be able to call it.
Other template-based
On Wednesday, 21 de September de 2011 16.06.13, Peter Kuemmel wrote:
One way around it would be on-the-fly inheriting:
https://qt.gitorious.org/~syntheticpp/qt/qtbase-staging-improvements/commit/
c1cf86f08fca7efbbf03106756d4c5bbd991664c
Maybe this commit could be the starting point for a
Thiago Macieira wrote:
On Wednesday, 21 de September de 2011 15.12.21, Thiago Macieira wrote:
There's no way around it. Since we're using the function pointer
(actually, the PMF) to identify the signal, you must have C++ access to
the signal function. That means you must be able to call it.
Op 21-9-2011 17:57, Peter Kuemmel schreef:
...
I don't like it either.
I know, both solutions aren't very elegant, but I hope
someone gets inspired and finds a better solution.
And I still prefer to have things checked by the compiler
and not to trust developers (I promise I never emitted
Stephen Kelly wrote:
Thiago Macieira wrote:
On Wednesday, 21 de September de 2011 15.12.21, Thiago Macieira wrote:
There's no way around it. Since we're using the function pointer
(actually, the PMF) to identify the signal, you must have C++ access to
the signal function. That means you
Op 21-9-2011 19:09, Thiago Macieira schreef:
On Wednesday, 21 de September de 2011 18:47:38 Andre Somers wrote:
Is it really nessecairy that _everyone_ has public access to the signal?
What if only QObject had access to it? Would that work? If so, it could
work to just make QObject a friend
I've been following this discussion since the beginning, but only briefly
participated on devnet. It took a while for me to get my exact thoughts
about this lined up, and a lot has already been discussed, but here goes.
On Wed, 21 Sep 2011 19:20:06 +0200, Thiago Macieira thi...@kde.org
On Wednesday, 21 de September de 2011 23:19:43 Frans Klaver wrote:
To be honest I never really understood why one would insist on
compile-time checking of something that was obviously intended to be used
and checked at run-time.
It was never intended to be done only at runtime. It was done
On Tue, Aug 9, 2011 at 4:05 PM, Olivier Goffart oliv...@woboq.com wrote:
I think the code is ready to be merged in Qt5, so I made a merge requests:
https://qt.gitorious.org/qt/qtbase/merge_requests/42
Feedback welcome.
Could you outline what if anything has been changed since QCS? I
remember
27 matches
Mail list logo
