On Thu, Jul 12, 2012 at 4:37 PM, Ezequiel Garcia <elezegar...@gmail.com> wrote: > On Thu, Jul 12, 2012 at 5:14 PM, Michael Mol <mike...@gmail.com> wrote: > >> >> Developer here, too. Mostly C++ on Windows, though I far prefer the >> way Linux does things. :) >> >> In theory, using in-house code seems like a great thing. Having >> written it, I understand it, I understand its API, and it's not a big >> blob of unknowns for me to fear when debugging my programs. >> >> In practice, I've seen more time (and money!) spent reinventing the >> wheel for any given project than it would take to pull in a library. >> I've seen and participated, designed and/or led in the redevelopment >> of locking mechanisms, nested image compositing engines, database >> abstraction layers, deferred I/O abstraction frameworks and probably a >> half-dozen other things I'm forgetting right now. >> >> Each and _every_ time, a great deal amount of developer time is >> consumed at the outset with development, and then over the life of the >> code as bugs (some of which simply come from underestimating or >> misunderstanding the resulting complexity of the system) turn up. >> >> NIH costs. I'd rather use a widespread library than write my own, >> wherever possible. >> >> But, of course, that's just _my_ humble opinion. And each circumstance >> warrants its own cost/benefit analysis. >> > > This is off-topic now :-( But it's a nice discussion :-) > > I agree with you mostly. I think you're a bit biased against > rolling-your-own, perhaps > because working on windows enforces that -there are less open > libraries/programs you can reuse-. > > Again, it's a great thing to re-use and it's evil to reinvent the wheel. > It has all sorts of advantages, we all know that. > > On the other hand, as you say, each circumstance needs its own analysis. > > Let me use an example: I'm writing a middle-size application in C++ that > will run on an embedded device, linux only. > Let's say I need some threads and some mutexes. > Heck, I'm not going to use boost if I can just wrap pthreads around > some lightweight classes.
In that circumstance, you're mostly going to be distributing firmware blobs. I'd probably rip the relevant code out of boost (perhaps set up a script to do this), drop it somewhere in my project folders, and tie it in with my build system. Respecting, of course, the license requirements of boost. It's unfortunate that boost's build system isn't modular, and especially that it won't parallelize. I'll probably look at it at some point to figure out if I know enough to rewrite it in autotools. I could totally see a "--with-this-module=yes" per-module, as opposed to an "--enable-all" for those users who don't know which parts they do or don't need. It's something that needs to be done. The question is who's going to have the time and inclination. -- :wq
