c/c++ has always been my primary choice of programming language. Although I started my career as an embedded platform developer, I used Visual Studio 6.0 extensively as my IDE, whenever I could. I used it mainly because I liked its editor and although when necessary, I have used vi/vim/emacs, I needed something that had a GUI. At that time, I recollect trying a couple of the other alternatives on Windows like Nebeans and JEdit, which were primarily IDEs for Java development but could be used for other languages as they had good syntax highlighting. However, what really kept me going back to VS was its powerful debugger. So, even though, the code that I wrote was for MIPS platforms, I landed up using VS for prototyping and unit testing my code first. Then, I would port this over to the embedded platform. This would, of course, break win32 compatibility. But after the porting of that particular module was complete, I normally did not have to go back to the prototyping/debugging/unit testing cycle. I would use whatever native tools were there for the embedded platform from that point on as I was confident that I had ironed out all the kinks during prototyping and had built a solid foundation. And I pretty much repeated this cycle for every module that I worked on.
This approach certainly had the drawback of having to write first for win32 and then having to port the code to the embedded platform. Since most of my code was on top of the standard libraries I could squeak by without having to write any win32 wrapper and if I had to implement code that talked to the hardware or interface with other modules, I just implemented mock objects. This approach started to get harder and more painful as the size of my module got bigger and tightly integrated with the hardware. I could almost never re-compile the code on VS after integrating the code with the rest of the project as I hated to use #ifdef's all over the code. Over time, I began to notice my pattern. I would start a new module prototype by first copying snippets from my original win32 versions as a starting point and build and debug it there as much as I could. This got worse as time progressed and I had a implemented a lot of handy utilities and classes that I could reuse but there were different versions and embedded deep in the various modules and ported to different platforms. Also, after programming a few of the interface modules in Java, C# and ObjectiveC, I liked their powerful libraries and higher level entities that they provided and wanted to have a means of using them in my c++ projects going forward.
Out of all my code snippets, utilities and learnings from Java/C#/ObjectiveC, I have decided to finally build a library for c++ with the hopes of achieving the following goals:
- lightweight - design on demand. implement api's on a necessity basis not for completeness (for example, don't implement overloaded functions for all the possible datatypes that can potentially be passed in)
- embeddable - compact enough to be used in an embedded device project.
- portable - work across different OSs. initial goal is win32 and linux.
- modern - provide libraries that have more modern api's and utilities (like an http client) found in newer languages like C# and Java.
- configurable - provide an easy way of configuring implementation aspects.
- customizable - be able to take only parts of the library that are needed.
- unit tested - unit tests for all the classes and api's.
The default libraries in c++ lack abstractions for threads, synchronization objects, datatype converters, sockets etc. Additionally, some of the calls are not exactly the same across Windows and Linux (for example, shutting down of TCP sockets). There are a couple of good opensource alternatives like boost or poco but they do not seem to fit my needs of being lightweight, embeddable and portable. Presenting (drum roll please) lepcpplib. Pronounced - lepsy-pee-pee. You can make it sound French by speaking like Steve Martin in the Pink Panther movie. As of now, only the Apache MIT license file and a header with some of my thoughts on the namespace, the eventing scheme etc are checked in at code.google.com/p/lepcpplib. The next step is to start extracting my code snippets and finding homes for them and add abstractions as and when necessary.
Apart from the above reasons, I just wanted to build a utility library from scratch in which I made the judgement call on its how's, why's and what's. It's more fun this way to start to build something with these goals in mind and to violate each of these as time progresses by and end up with a gobbledygook of a bloated library!
