This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: OOPS and linux


> -----Original Message-----
> From: binutils-owner On Behalf Of Zack Weinberg
> Sent: 14 April 2004 09:10

> For the GNU toolchain there is an additional concern, which is
> portability.  To first order, it is not possible to write truly
> portable code in any language other than C.  C, as you know, does not
> lend itself to an object-oriented style, although it can be done.

  It's worth mentioning that not only _can_ it be done, but it in fact *is*
a fundamental programming technique employed throughout binutils and gcc -
e.g. gcc target vectors and bfd architecture vectors which approximate C++
virtual functions; gcc tree and rtx structures with their macros serving the
roles of set and access functions that approximate derived objects and
switched unions; really, I'd say that OO techniques and principles are
already used throughout the toolchain, but as a matter of pragmatic and
practical program implementation, rather than as a matter of religous style.

  (IMO, the use of these and similar patterns in C enables an application to
gain pretty much all of the fundamental benefits of OO coding style - data
hiding and abstraction, inheritance and overriding - without any of the
complications introduced by the more advanced features of OO languages, and
with just about as much reliability and maintainability as when using the
syntactical sugar that an actual OO language provides to implement the same
functionality.)

  As you rightly point out, C is the language of choice when the broadest
possible range of cross-platform compatibility is a requirement.  java
probably matches or beats C in terms of actual cross-platform source
compatibility and ease-of-porting - how much autoconf does your average java
package need? - but it doesn't run on as broad a range of targets,
particularly at the small embedded cpu end of things.

> And finally, rewriting an existing piece of software in a different
> style or programming language, just for the sake of the new style or
> language, is the sort of exercise that introduces more bugs and more
> confusion than it helps.

  God, yes.  Otherwise known as the
Even-Though-It's-Broke-Let's-Not-Break-It-Even-More-By-Needlessly-Fixing-It-
Any-More-Than-We-Absolutely-Have-To (ETIBLNBIEMBNFIAMTWAHT) principle!


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]