Qt-interest Archive, December 2006
C++ GUI Programming with Qt 4: static_cast<Cell*>(tableWidget()->item(row,column))
Message 1 in thread
I found this on page 98 of _C++ GUI Programming with Qt 4_:
Cell *c = static_cast<Cell *>(tableWidget()->item(row, column));
I have to admit, I have never done a downcast with a static_cast. I believe
such a cast is, in general, dangerous. Is that correct? I also believe
dynamic_cast would work as well for this purpose would it not? Is
performance the motivation for using the static cast in this situation?
--
[ signature omitted ]
Message 2 in thread
Steven T. Hatton wrote:
> I found this on page 98 of _C++ GUI Programming with Qt 4_:
> Cell *c = static_cast<Cell *>(tableWidget()->item(row, column));
>
> I have to admit, I have never done a downcast with a static_cast. I believe
> such a cast is, in general, dangerous. Is that correct? I also believe
> dynamic_cast would work as well for this purpose would it not? Is
> performance the motivation for using the static cast in this situation?
>
static_cast is fine if you *know* the item you are casting is always of the
type you're casting to. So if tableWidget's items are always Cells, then
it's safe.
dynamic_cast relies on RTTI, and there is an overhead to that in terms of
code size (but not runtime). If you're not absolutely sure you need it,
don't
use it.
- Keith
--
[ signature omitted ]
Message 3 in thread
Keith Sabine wrote:
> dynamic_cast relies on RTTI, and there is an overhead to that in terms of
> code size (but not runtime). If you're not absolutely sure you need it,
> don't
> use it.
dynamic_cast _impacts_ the performance as the RTTI are checked to see if
the parameter can be changed in something else at runtime. static_cast
makes this "check" at compile time, so there _is_ an overhead in
performance.
Matthieu
--
[ signature omitted ]
Message 4 in thread
On Monday 11 December 2006 07:58, Matthieu Brucher wrote:
> Keith Sabine wrote:
> > dynamic_cast relies on RTTI, and there is an overhead to that in terms of
> > code size (but not runtime). If you're not absolutely sure you need it,
> > don't
> > use it.
>
> dynamic_cast _impacts_ the performance as the RTTI are checked to see if
> the parameter can be changed in something else at runtime. static_cast
> makes this "check" at compile time, so there _is_ an overhead in
> performance.
>
> Matthieu
According to this, the impact is significant:
http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf
OTOH, they mention that dynamic_cast<> is a good candidate for future
optimization. I have been told that at GCC recently changed from using a
string compare to using a string address compare to implement dynamic_cast<>.
The result was a significant performance gain. I don't know if that's
reflected in TR18015 or not.
--
[ signature omitted ]
Message 5 in thread
Monday 11 December 2006 13:58 Matthieu Brucher wrote:
> Keith Sabine wrote:
> > dynamic_cast relies on RTTI, and there is an overhead to that in terms of
> > code size (but not runtime). If you're not absolutely sure you need it,
> > don't
> > use it.
>
> dynamic_cast _impacts_ the performance as the RTTI are checked to see if
> the parameter can be changed in something else at runtime. static_cast
> makes this "check" at compile time, so there _is_ an overhead in
> performance.
Also, on Windows dynamic_cast<> doesn't work across plugins. This is a
limitation of the dynamic loader in Windows and one of the two good reasons
for qobject_cast<> to exist (the other: On embedded platforms rtti is often
not used because of space constraints).
Bo.
--
[ signature omitted ]
Message 6 in thread
Hello!
Bo Thorsen schrieb:
>
> Also, on Windows dynamic_cast<> doesn't work across plugins. This is a
> limitation of the dynamic loader in Windows and one of the two good reasons
> for qobject_cast<> to exist (the other: On embedded platforms rtti is often
> not used because of space constraints).
>
> Bo.
>
What platform/compiler do you use?
One of my applications is split into several DLLs and I'm making heavy
use of dynamic_cast during object (de)serialization. With VC6 and VS2005
(Win 2K and XP) I've never noticed any problems with dynamic_cast.
Kind regards,
Jan
--
[ signature omitted ]
Message 7 in thread
Friday 15 December 2006 12:57 Jan Kellmer wrote:
> Hello!
>
> Bo Thorsen schrieb:
> > Also, on Windows dynamic_cast<> doesn't work across plugins. This is a
> > limitation of the dynamic loader in Windows and one of the two good
> > reasons for qobject_cast<> to exist (the other: On embedded platforms
> > rtti is often not used because of space constraints).
> >
> > Bo.
>
> What platform/compiler do you use?
> One of my applications is split into several DLLs and I'm making heavy
> use of dynamic_cast during object (de)serialization. With VC6 and VS2005
> (Win 2K and XP) I've never noticed any problems with dynamic_cast.
Last I saw it (haven't tried since) was on VC6.
Are you using DLLs linked by Windows or loaded dynamically by your application
as plugins? It is only the latter that doesn't work.
Bo.
--
[ signature omitted ]
Message 8 in thread
Hi!
Bo Thorsen schrieb:
> Friday 15 December 2006 12:57 Jan Kellmer wrote:
[...]
>>> Also, on Windows dynamic_cast<> doesn't work across plugins. This is a
>>> limitation of the dynamic loader in Windows and one of the two good
>>> reasons for qobject_cast<> to exist (the other: On embedded platforms
>>> rtti is often not used because of space constraints).
>>>
>>> Bo.
>> What platform/compiler do you use?
>> One of my applications is split into several DLLs and I'm making heavy
>> use of dynamic_cast during object (de)serialization. With VC6 and VS2005
>> (Win 2K and XP) I've never noticed any problems with dynamic_cast.
>
> Last I saw it (haven't tried since) was on VC6.
>
> Are you using DLLs linked by Windows or loaded dynamically by your application
> as plugins? It is only the latter that doesn't work.
Both.
The main application links again several DLLs, that are loaded by
Windows upon application startup. One of the DLLs contains a self-made
plugin-loader. After startup is finished (main() is entered) the
plugin-loader (located in one DLL) is instantiated and loads the DLLs
found inside a specific directory.
However, I'm not using the Qt plugin system (no Q_EXPORT_PLUGIN and the
like) but built my own, using LoadLibraryEx/GetProcAddress (but this
should not matter: the Trolls are using the very same functions).
Did you use the Qt Plugin Architecture when testing? Where all DLLS
compiled using the same settings (UNICODE, static/shared MSVCRT, same
settings for RTTI, etc)? Did you use a C wrapper (a pure C function;
when declaring a function extern "C", it still can be implemented using
C++)?
I'm just curious: I've heard *lots* of bad things on RTTI ... but I've
never experienced any horror stories myself. Even on not wide-spread
platforms (for example aCC on HP-UX/PA) things work like expected.
Regards,
Jan
--
[ signature omitted ]
Message 9 in thread
Friday 15 December 2006 13:46 Jan Kellmer wrote:
> [snip]
> Did you use the Qt Plugin Architecture when testing? Where all DLLS
> compiled using the same settings (UNICODE, static/shared MSVCRT, same
> settings for RTTI, etc)? Did you use a C wrapper (a pure C function;
> when declaring a function extern "C", it still can be implemented using
> C++)?
>
>
> I'm just curious: I've heard *lots* of bad things on RTTI ... but I've
> never experienced any horror stories myself. Even on not wide-spread
> platforms (for example aCC on HP-UX/PA) things work like expected.
Sorry, but I simply don't remember. I got burned by this about four years ago
(so it was probably Windows 2000 - I know it was VC6 at least), and just
never did it again. I later heard that the trolls had the same experience.
Bo.
--
[ signature omitted ]
Message 10 in thread
> -----Original Message-----
> From: Bo Thorsen [mailto:bo@xxxxxxxxxxxxxxxxxxxxx]
> Sent: Friday, December 15, 2006 4:56 AM
> To: qt@xxxxxxxxxxx; qt-interest@xxxxxxxxxxxxx
> Subject: Re: C++ GUI Programming with Qt 4:
> static_cast<Cell*>(tableWidget()->item(row,column))
>
> Friday 15 December 2006 13:46 Jan Kellmer wrote:
> > [snip]
> > Did you use the Qt Plugin Architecture when testing? Where all DLLS
> > compiled using the same settings (UNICODE, static/shared MSVCRT,
same
> > settings for RTTI, etc)? Did you use a C wrapper (a pure C function;
> > when declaring a function extern "C", it still can be implemented
using
> > C++)?
> >
> >
> > I'm just curious: I've heard *lots* of bad things on RTTI ... but
I've
> > never experienced any horror stories myself. Even on not wide-spread
> > platforms (for example aCC on HP-UX/PA) things work like expected.
>
> Sorry, but I simply don't remember. I got burned by this about four
years
> ago
> (so it was probably Windows 2000 - I know it was VC6 at least), and
just
> never did it again. I later heard that the trolls had the same
experience.
>
> Bo.
>
The problem can STILL exists in XP + the latest Dev Env 2005. However,
you wont always get burned.
Its similar to using STL across DLL boundries, in that unless the
compiler settings are the same (or compatable. The primary one, being
the C runtime library, but also the optimization settings.
With QT 3.X since, QT did NOT have the ability to install 2 QT libs
(debug + release) from 1 install, it was quite common to have your debug
based app pointing to a release based QT. This could cause all sorts of
problems with STL. Since STL is all header based, the release version
usually got a different memory structure etc. Thus causing all sorts of
weirdness.
The same issue with RTTI. It seems to have gotten better, but its still
risky with Dev Env 7.2 (2005). I had a crash the other day, that was
caused by and invalid RTTI setup. Where the pointer was created inside a
DLL, and passed back across to the main app, then handed down to another
DLL.
The second DLL was built separately.
Scott
--
[ signature omitted ]
Message 11 in thread
On 12/15/06, Scott Aron Bloom <scott@xxxxxxxxxxxx> wrote:
> Its similar to using STL across DLL boundries, in that unless the
> compiler settings are the same (or compatable. The primary one, being
> the C runtime library, but also the optimization settings.
>
> With QT 3.X since, QT did NOT have the ability to install 2 QT libs
> (debug + release) from 1 install, it was quite common to have your debug
> based app pointing to a release based QT. This could cause all sorts of
> problems with STL. Since STL is all header based, the release version
> usually got a different memory structure etc. Thus causing all sorts of
> weirdness.
At VC environment you should never mix release and debug dlls, the
problem is not STL-specific. Because of differences in memory
management you mustn't free memory allocated by debug allocator using
release allocator and vise versa. Anything that transfers heap pointer
ownership via release-debug library boundaries will fail sooner or
later. Qt is one of such libraries - for example it deletes objects
allocated by user, so it too should not be used in mixed environment.
--
[ signature omitted ]
Message 12 in thread
Hi,
is someone wrote a wfm export module or have any link, info about
something (tool?..)
I need to import/export svg format datas (on windows first, after maybe
under unix system)
thanks for any tips.
Best regards,
Veronique.
--
[ signature omitted ]
