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