JPEG Thumbnailer

[Thiago Macieira]

Ingo Klöcker wrote:
>> >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.

I agree it doesn't apply to this situation, but I was answering 
your "let's use C++'s power". The C++ class for dealing with files is 
std::fstream.

I can't remember the last time I used it. The only thing from iostream I 
ever use is std::cout, probably once a year.

>> >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?

Yes, we do: Microsoft Visual Studio.

>> 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.

I didn't know that.

>> >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.

While our containers are better[1] than STL's and while we have to 
maintain an API that works in all platforms we support, we won't be able 
to use STL.

I don't really care for STL containers and iostream, but other parts of 
STL are certainly very, very useful. I just wish we could use it (TR1's 
<type_traits>, for instance), same as C++0x's variadic templates and 
other goodies. Maybe in 2015.

[1] better = clearer API, following Qt guidelines, implicitly shared, just 
as efficient as the best STL implementations (save for the atomic 
refcounting), but consistently efficient in all platforms, regardless of 
which compiler you have.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080822/23608fa0/attachment.sig>