For at least two weeks, I've been rewriting VCS Made Easy from scratch (and it's already working fairly well), a project I announced a long time ago. It's being written in C++ and the code is organized in three (independent) layers:
- The helper library: This provides classes to access operating system specific details. Among others, it has classes to manage processes, users, files, directories, etc. Everything is very simple and, depending on how you look at it, incomplete. I will probably need to add much more functionality to the existing classes (specially, the ones to manage the file system are very poor) and some new ones.
- The vcsme library: This includes all the logic of the program in a frontend-independent way and uses the helper library.
- The console frontend: Uses the vcsme library to service user requests. It does almost nothing on its own, aside parsing the command line.
So far, so good. But now I realize that many things I'm doing in the lowest layer, the helper library, are already implemented in Boost. More specially, what I'm interested in is the Boost Filesystem library. However, if I decide to use this one, I may end up using other functionality, such as the Boost Test library (due to its execution monitor and the unit tests framework) and the Boost Format library (to remove several ugly usages of std::ostringstream). These classes are more tested, more portable and more complete.
Unfortunately, there are some disadvantages. First of all, the Boost source package is huge (around 10Mb). And the binary ones are too, depending on which packaging system you use. This is solvable, though, if package maintainers split the Boost package into multiple small parts (like Debian does. (And I'll probably do it in pkgsrc.)
But the biggest inconvenient I find is that Boost does not cover all my needs, so I might be using it for a few stuff, but still need a lot of custom classes. AFAICT, there is no library to manage processes nor users, a thing I need for this specific project. However, I also think that if I keep the code clearly organized, these custom classes may, some day, end up being part of Boost (and this could be really, really nice).
So now I'm faced the choice of whether to use Boost or not... any comments?
5 comments:
[Originally posted by 2005-02-18 05:23 pm UTC]
Don't Reinvent The Wheel !
I think it's wiser to use Boost instead of reimplementing everything from scratch. It is true that ~10Mb is a PITA, but hey, I'm sure it's gonna be better (more mantainable, reusable, yada, yada...).
I would stick with boost, and if you have the opportunity to contribute twice better !
You know that I disagree with people that keeps RTW, we both know who I am talking about ;-)
[Originally posted at 2005-02-20 04:51 pm UTC]
You might have a look at boost copy to cut down the size of boost, you can cut down the distro to the parts you want using bcp. See
http://www.boost.org/tools/bcp/bcp.html
> there is no library to manage processes nor users, a thing I
> need for this specific project.
Yes, it would be great is someone, such as yourself, would work on such a contributions ;-) We need more library authors...
Anyway, good luck.
Jeff Garland
[Originally posted at 2005-02-20 05:25 pm UTC]
Wow. Neat utility!
Anyway, I'm actually refactoring the boost packages in pkgsrc to make them smaller (specially at runtime) and more modular. This will make my initial concerns go away :)
And BTW, I'm about to send a mail to the mailing list to ask if there is interest in a Boost.Process library. I'm willing to work on it, but don't want to do all the work in vain ;)
[Originally posted at 2005-02-20 06:37 pm UTC]
> And BTW, I'm about to send a mail to the mailing list to ask if there
> is interest in a Boost.Process library. I'm willing to work on it, but
> don't want to do all the work in vain ;)
Great! I will warn you that authoring a library for boost is often not easy. People will have very high expectations w.r.t. documentation, implementation, etc. So expect that it will take months to go thru the whole process and will consume time in ways you might not initially expect. On the other hand, the resulting library that gets created will no doubt be of higher quality than anything you could produce on your own. Hopefully this won't scare you off, but it would be unfair for you to start without being warned....
I have some technical thoughts for you that I'll post on the boost list.
Jefff
[Originally posted at 2005-02-20 06:58 pm UTC]
Hmm... I thought so, given all I've read so far in the website: coding and documentation guidelines, design choices, the review process, documentation for existing libraries, etc. (Very, very interesting, BTW.)
Anyway, this is a very challenging task; I like it ;-) Furthermore, this library is something I've always wanted to do (needed it for some other projects in the past), and if it ends being up a Boost library (after all the required changes WRT design, code or anything else), that'll surely mean that its quality is good. (One only has to look at existing, accepted libraries to know this.)
Of course, for now I've just proposed the idea on the list (I promise nothing anytime soon, but who knows), and any comments will be really welcome. Then, I'll see what I can do with the design, writing docs, etc. And when I get something decent (by that time, I'll know more about Boost than I do now), I'll post to the list again.
Thanks for your comments :)
Post a Comment