[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: none
From: |
David Philippi |
Subject: |
Re: none |
Date: |
Thu, 15 Aug 2002 11:58:40 +0200 |
User-agent: |
KMail/1.4.1 |
On Wednesday 14 August 2002 17:26, Ingo Ruhnke wrote:
> Factories must not jump around in the XML tree, they should work on
> the node they get and fail if it is an empty one. Since the above kind
> cause quite funny and hard to track down errors, like this one:
> AxisFactory::create(cur);
> AxisFactory::create(cur->next);
> Both factories will refer to the *same* node when the xmlIsBlankNode()
> check is done in the factory and cur is an empty node, instead of
> giving an error about an incorrect node as one would expect.
Well, my motivation was a bit different - I consider the call
AxisFactory::create(cur->next); simply awfull.
But since it's a good idea to have the different XML parsers in Pingus work
the same way I'll change the Controller parser so that it never call a
factory with an empty node and let the factories enforce this behaviour.
> >- virtual float get_y_delta () const =0;
> >+ virtual const float& get_y_delta () const =0;
> Any special reason for replacing float with 'const float&'? I thought
> const references would be kind of useless on primitive datatypes.
I'm not sure wheter passing a parameter as const reference will make any
difference with an int / float / pointer compared to passing by value. I
would only be surprised if someone told me that it's slower.
Anyway, this isn't what I'm doing here. If you take a deeper look you'll see
that I've only changed return values since returning a const reference may
allow the compiler to remove temporaries or other optimizations. There are
some changes of this sort, like making pointers itself const which may or
may not make any difference.
The intention of this changes is to feed more information to the
compiler/optimizer to make it possible for some optimizations to be applied.
It's always a good idea to use const whereever possible - in the worst case
you'll get an error when trying to change the value and than you may think
about why it was declared const in first place before removing the const or
using a const_cast<>.
Bye David
- Re: none, Ingo Ruhnke, 2002/08/14
- Re: none,
David Philippi <=
- Re: none, David Philippi, 2002/08/15