On 5/6/08, Marc Mutz <marc@kdab.net> wrote:
> On Monday May 5 2008 15:19, Dmitry Ivanov wrote:
> > On 5/5/08, Frank Osterfeld <frank@kdab.net> wrote:
> > > On Sunday 04 May 2008 21:50:15 Dmitry Ivanov wrote:
> > > > SVN commit 804009 by divanov:
> > > >
> > > > Get sourceFeedId from the collection being retrieved
> > > >
> > > >
> > > >  M  +2 -3      rssresource.cpp
> > > >  M  +1 -0      rssresource.h
> > > >
> > > >
> > > >
> > > > --- trunk/playground/pim/krss/resource/rssresource.h #804008:804009
> > > > @@ -48,6 +48,7 @@
> > > >
> > > >  private:
> > > >
> > > > +        KFeed::Item convertToKFeedItem(const Syndication::ItemPtr
> > > > syndItem);
> > >
> > > Better pass it per const reference:
> > >
> > > const Syndication::ItemPtr & syndItem
> >
> > That would be a double indirection to the data (i.e. the Item) because
> > ItemPtr is just a wrapper containing the pointer to the Item.
> > So if syndItem is passed as a reference it would be basically a reference
> > to a pointer.
> >
> > I learnt this trick from Thiago's blog [1] though I'm not completely sure
> > about this very case.
> >
> > [1] http://labs.trolltech.com/blogs/2008/04/28/string-theory/
> <snip>
>
> This has premature pessimisation written all over it. This is a slow
> function,
> you can't compare it to the well-researched case of QLatin1String, which is
> used 1000x more frequently than this function here.
>
> Whether or not this is an optimization at all depends on the actual
> implementation of the smart pointer. E.g. sizeof(std::tr1::shared_ptr<>) can
> be 2*sizeof(void*), or 1*sizeof(void*), and only the second implementation
> would benefit from passing in registers, the first one would be too large.
> On
> top of that, shared pointers need to update the reference count on copying,
> which has a much bigger performance impact than pass-in-registers.
>
> Please follow standard advice (as found e.g. in "C++ Coding Standards" by
> Sutter/Alexandrescu) in C++, and leave optimizations for when they're
> needed.

Ok, the lesson learnt. I should make no assumptions on the internals of
an object and treat it like a regular C++ object.

>
> Thanks,
> Marc
>
> --
> Marc Mutz - marc@kdab.com, mutz@kde.org - Klarälvdalens Datakonsult AB
> Platform-independent software solutions - www.kdab.com info@kdab.com
>

Best,
  Dmitry, who is going to order a copy of "C++ coding standards"

-- 
A: Because it destroys the flow of the conversation
Q: Why is top-posting bad?