0 or 0L for empty pointers?
Frans Englich
englich at kde.org
Fri Jun 23 13:40:08 BST 2006
On Friday 23 June 2006 12:03, Stefan Teleman wrote:
> On Friday 23 June 2006 07:42, Frans Englich wrote:
> > Yes, some features should be avoided
> > in any case like dynamic_cast, but perhaps there's some template
> > features or the like that should be avoided.
>
> Just out of curiosity, why is dynamic_cast<> a Bad Thing(TM) ?
>
> I think dynamic_cast<> is your friend. It comes with failure guarantee
> which returns NULL for pointers (a Good Thing(TM)). It throws for
> references but then i've rarely seen it used on references anyway.
>
> The legend that dynamic_cast<> is slow is really an Urban Myth these
> days. For any half-decent compiler dynamic_cast<> is nothing more
> than a simple pointer arithmetic in the __vtbl, unless the class
> inheritance tree is a really weird-shaped directed acyclic graph with
> several branches and the C++ run-time has to go through several
> __vtbl jumps to resolve to the proper type.
I agree. I also don't think it's sensible to argue about performance or
converting code to stone-age just because someone thinks(as in
pure-speculation) that something has a negative performance impact.
I think this is largely a question of mentality. Among C++/C developers you
often find an imho frantic code changing for performance(as they claim is the
purpose). For example, if one decides to consistently use a smart pointer
through-out a project, C++ isn't that bad, but if one decides to
reference-count manually, as an "optimization", one is again down in the
C/C++ mud of problems.
In some circles one can't use a language feature because of its asserted
performance issues, even though no one have actually proven it is relevant in
the particular situation. So I would surely see more scientific approaches in
development, and aim towards safety and flexibility. I don't like spending my
life on things computers do better.
Another argument against dynamic_cast is sometimes compiler support on
embedded platforms(although I can't elaborate on that such as how relevant it
is now adays).
Cheers,
Frans
More information about the kde-core-devel
mailing list