Haha, yes it is, I was reading it as if it was italicized like the rest of
the docs.
- Swyped from my droid.
On May 23, 2013 2:02 PM, "Constantin Makshin" wrote:
Another place to find that information is the documentation on
QGraphicsItem::type(). :-)
On May 23, 2013 10:57 PM, "Jonathan Grei
Another place to find that information is the documentation on
QGraphicsItem::type(). :-)
On May 23, 2013 10:57 PM, "Jonathan Greig" wrote:
> I have implemented the type() method for all of my derived classes so that
> qgraphicsitem_cast would work. I just tested it out and apparently it will
> n
I have implemented the type() method for all of my derived classes so that
qgraphicsitem_cast would work. I just tested it out and apparently it will
not work unless the value returned is an enum of the class. Returning an
enum that isn't part of the class fails every time.
I'm showing this here in
Yes, qgraphicsitem_cast isn't as powerful as dynamic_cast, but this
simplicity also makes it faster.
Anyway, Jonathan asked about casting C++ objects and now has several
methods to choose from. :-)
On May 23, 2013 9:17 PM, "Jan Kundrát" wrote:
> On Thursday, 23 May 2013 19:04:53 CEST, Constantin
There's also qgraphicsitem_cast made specifically for casting to classes
derived from QGraphicsItem.
On May 23, 2013 11:47 AM, "André Somers" wrote:
> Op 22-5-2013 22:42, Jonathan Greig schreef:
>
> I did check the qobject_cast docs and noticed that, but I wasn't
> inheriting from QObject and ha
Op 22-5-2013 22:42, Jonathan Greig schreef:
I did check the qobject_cast docs and noticed that, but I wasn't
inheriting from QObject and haven't needed signals or slots in the
items in my scene. I'm trying to keep the item classes as light as
possible for speed and memory. The items are CAD o
I did check the qobject_cast docs and noticed that, but I wasn't inheriting
from QObject and haven't needed signals or slots in the items in my scene.
I'm trying to keep the item classes as light as possible for speed and
memory. The items are CAD objects, so "40,000 chips" demo is in line with
wha
Op 22-5-2013 21:34, Thiago Macieira schreef:
> On quarta-feira, 22 de maio de 2013 16.52.29, Jonathan Greig wrote:
>> Thank you André. The dynamic_cast worked perfectly. I'm from a C background
>> and have been doing C-style casts for years without any major problems.
>> Apparently this guy has als
Thanks Thiago. I got caught up in using the convenience shape items and
then multiple inheriting from them and my base class instead of rolling my
own base class that derived from one of the item classes. I try to avoid
multiple inheritance, but apparently I didn't think about it long enough to
see
I was able to get static_cast to work also if I static casted the
QGraphicsItem* to a DerivedObject* and then static casted the
DerivedObject* to a BaseObject*. I'll probably just derive my BaseObject
from QGraphicsPathItem since it has most of what I need and just use
static_cast to avoid the RTTI
On quarta-feira, 22 de maio de 2013 16.52.29, Jonathan Greig wrote:
> Thank you André. The dynamic_cast worked perfectly. I'm from a C background
> and have been doing C-style casts for years without any major problems.
> Apparently this guy has also:)
> http://stackoverflow.com/questions/28002/reg
They are not.
static_cast exists for purpose.
On Wed, May 22, 2013 at 10:10 AM, Constantin Makshin wrote:
> Well, C-style casts are still useful because, unlike dynamic_cast, they
> need neither RTTI nor run-time checks, making the compiled code somewhat
> smaller and faster. You just need to be
Well, C-style casts are still useful because, unlike dynamic_cast, they
need neither RTTI nor run-time checks, making the compiled code somewhat
smaller and faster. You just need to be very careful with them. :-)
On May 22, 2013 8:52 PM, "Jonathan Greig" wrote:
> Thank you André. The dynamic_cast
Thank you André. The dynamic_cast worked perfectly. I'm from a C background
and have been doing C-style casts for years without any major problems.
Apparently this guy has also:)
http://stackoverflow.com/questions/28002/regular-cast-vs-static-cast-vs-dynamic-cast
- Swyped from my droid.
On May 22
Op 22-5-2013 16:03, Jonathan Greig schreef:
> BaseObject* base = (BaseObject*)item;
> if(base) { base->setObjectRubberPoint(key, point); }
The above looks suspicious. The cast you're doing here is unsafe. Your
check on base on the second line is useless, as the C-style cast you'r
I've attached the relevant files and a partial backtrace.
- Swyped from my droid.
On May 22, 2013 7:33 AM, "André Somers" wrote:
Op 22-5-2013 14:25, Jonathan Greig schreef:
>
> I have an abstract base class that contains a private QHash member.
> There is a public functio...
You'll need to sho
Op 22-5-2013 14:25, Jonathan Greig schreef:
>
> I have an abstract base class that contains a private QHash member.
> There is a public function that sets the key/value in the QHash. When
> calling the function through a base class pointer, it segfaults when
> it comes to the line that sets the
I have an abstract base class that contains a private QHash member. There
is a public function that sets the key/value in the QHash. When calling the
function through a base class pointer, it segfaults when it comes to the
line that sets the key/value. When calling the function through a derived
cl
18 matches
Mail list logo
