Imebra

When I started to develop Imebra I made few choices that shaped the library's API and determined the development time.

In particular, the API contains few reinvented wheels (the most visible are the smart pointers, the jpeg codec and synchronization classes) that increased the development time and the code to maintain.

Why did I do it?

• keep the library independent: the end user didn't have to install boost or other libraries
• keep control over the library general structure
• keep control over the licensing options

Here I will focus on the first listed reason: keep it simple for the user.

If the user has to download a single library which is self sufficient, then probably he will find it easier to build and use it.

The first impression counts, as the second one does: but the second impression will never come if the first one is negative.

Now the boost library is getting almost everywhere, so I have to reconsider what "self-sufficient library" means: is boost so widely used that actually the user will find it easier to deal with Imebra if it was using boost smart pointers and thread classes?