On Thu, Jan 09, 2014 at 09:49:15AM +0000, Paulo Pinto wrote: > On Thursday, 9 January 2014 at 09:38:31 UTC, Ola Fosheim Grøstad > wrote: > >On Thursday, 9 January 2014 at 09:10:07 UTC, Paulo Pinto wrote: > >>I have only seen those things work in small AAA class teams. > > > >But you have probably seen c programs allocate a bunch of > >different small structs with a single malloc where it is known > >that they will be freed in the same location? A compiler needs > >whole program analysis to do the same. > > > >So yes, c programs will have fewer allocs if the programmer cared. > > Yes, I did. > > Not much different than memory pools in Turbo Pascal and Objective-C > for that matter. > > And even more strange things, where the whole memory gets allocated > at start, then some "handles" are used with mysterious macros to > convert back and forth to real pointers. > > I have also seen lots of other storage tricks that go easily out of > control when the team either grows over a certain size, or > management decides to outsource part of the development or lowering > the expected skill set of new team members. > > Then you watch the older guys playing fire brigade to track down > issues of release X.Y.Z at customer site, almost every week. [...]
Exactly!! All these tricks are "possible" in C, but that's what they essentially are: tricks, hacks around the language. You can only keep it up with a small, dedicated core team. As soon as the PTBs decide to hire new grads and move people around, you're screwed, 'cos the old guy who was in charge of the tricky macros is no longer on the team, and nobody else understands how the macros work, and the new guys are under pressure to show contribution, so they barge in making assumptions about how things work -- which usually means naïve C semantics, lots of strcpy's, direct pointer arithmetic, I don't use these weird macros 'cos I don't understand what they do. Result: fire brigade. :-) This is why compiler-enforced type attributes ultimately trumps any kind of coding convention. It forces everyone to do the Right Thing. This is why strings (arrays) with built-in length is better, because it allows slicing without needing to decide whether you should copy or modify in-place (*someone* will inevitably get it wrong). C's superiority is keyed on the programmer being perfect -- the philosophy of the language is to trust the programmer, to believe that the programmer knows what he's doing. Theoretically speaking, this is a good thing, because the compiler won't stand in your way and annoy you when you're trying to do something clever. (This is also what made me like C in the first place -- I was 19 at the time, so it figures. :-P) Unfortunately, in practice, humans are fallible -- very much fallible and error-prone -- so this philosophy only leads to pain and more pain. With a single-person project you can still somewhat maintain some semblance of order. But when you have a team of 15+ programmers (at my job we have up to 50), then it's total chaos, and you start to code by paranoia, i.e,, assume everyone else will screw up and add every possible safeguard you can think of in your part of the code, so that when things go wrong it's not your fault. Which means every string modification requires copying, which means performance is out the window. It means adding layers of indirection to shield your code from the outside world. Which means even more pointers to work with, which in turn means you start getting into pointer management problems, and start needing reference counting (which, as I described in an earlier post, people *still* screw up). At some point, you start wishing C had a GC to clean up the mess. T -- Public parking: euphemism for paid parking. -- Flora