JPEG Thumbnailer

[Ingo Klöcker]

On Wednesday 20 August 2008, Thiago Macieira wrote:
> Ingo Klöcker wrote:
> >I know you will kill me for making the following suggestion. :-)
>
> Yes, I will. Using boost is an major overkill for this. Much more
> than QFile, because QFile is in a library already loaded, while boost
> will require additional code being loaded.
>
> >If QFile is too much overhead then I'd use a boost::shared_ptr with
> >custom deleter [1], i.e.
> >
> >    boost::shared_ptr<FILE> fd_in( fopen(path.toLatin1().data(),
> > "rb"), fclose ); if ( fd_in.get() == NULL )
> >       return false;
> >
> >If you want to close the file explicitly then you call
> > fd_in.reset(). Otherwise you don't have to do anything.
> >
> >Reasons for doing the above:
> >a) We are coding in C++, right? So let's use the power C++ provides.
> > It makes no sense to write error prone code, if there's a way to
> > avoid it.
>
> Uh... std::fstream?

std::fstream does not seem to give access to the FILE handle, so it 
cannot be used in this particular situation.


> >b) Using boost::shared_ptr is just a compile time dependency.
>
> Right, but it'll bring in all of boost's atomic reference counting
> code along. Also remember that some compilers are brain-dead and will
> instantiate the entire class, as opposed to just the parts of it that
> you actually use.

Which compilers? Do we care for those compilers?


> Not to mention that a custom deleter would have to be written.

In this particular case that's not true since
  boost::shared_ptr<FILE> fd_in( fopen( "foo.jpg", "rb" ), fclose );
works perfectly alright.


> What you really want here is std::auto_ptr with a custom deleter.
> There is no shared pointer in this circumstance, so no need to add
> the overhead associated with that,

True.


> >c) Several KDE packages (kdepimlibs, kdepim) do already have a
> >dependency on boost.
>
> Sometimes unwarranted. There's a lot of boost that has equivalents in
> Qt, including shared_ptr/intrusive_ptr (Qt 4.5's QSharedPointer for
> both). But there are nice things in it too.

The same can be said about Qt (in place of boost) and STL (in place of 
Qt). Yes, I know there were reasons for writing your own container 
classes when Qt 1 was written. But even though there might still be 
some broken STL implementations on certain platforms, I'd rather see 
you adopting the STL containers. There's a plethora of useful C++ 
libraries out there that all use STL containers and it really sucks 
that when using Qt one has to use a second set of container classes.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080821/85cf9d32/attachment.sig>