avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] Re: [avr-gcc-list] Re: What Happened to the sbi() and cbi


From: Victoria Welch
Subject: [avr-libc-dev] Re: [avr-gcc-list] Re: What Happened to the sbi() and cbi() Macros????
Date: Mon, 31 Jan 2005 13:16:29 -0800
User-agent: KMail/1.7.2

On Monday 31 January 2005 05:30, Joerg Wunsch wrote:
> As E. Weddington wrote:
> > This is another reason why I am proposing <avr/bit.h>,
> > because it will supply a *full* range of bit
> > manipulating macros. Newbies can go use the macros
> > which should be easy to select, and they can always
> > look inside at how they're implemented and maybe learn
> > a thing or two.
>
> I'm not completely opposed to it, but I'm not very
> enthusiastic about it either.  I'd be more comfortable
> with the idea of either writing a FAQ entry for it (quick
> method), or maybe an entire doxygen page of its own
> describing the C basics of bit manipulation, including
> cut'npaste-able macro definitions.  That way, you can
> make sure people actually have to read something about it
> before they can use it. ;-)
>
> See my argumentation, in the end I think everyone should
> rather see this as a chance to improve their level of
> abstraction, and instead of blindly replacing cbi/sbi by
> another macro of the same function, invent a macro that
> is more descriptive in terms of what it does in that
> particular application (like turning LEDs on/off in my
> example).

I think some folks are missing the point here.

Had the sbi / cbi stuff not been there in the first place 
AND not been so HEAVILY used, this would hardly be an 
issue :-).

Academic purity is a fine thing, but there is a real world 
out there where everyone doesn't have a doctorate in C and 
(believe it or not :-) doesn't want one :-).

Most importantly there is the issue of backwards 
compatibility.  This *IS* a serious real world 
consideration.

Not everyone has a net connection / time / inclination to 
spend forever rooting around trying to find fixes for stuff 
that is obviously already in something that they got for a 
reason. 

If the twi stuff got moved to compat for whatever reason, 
something as HEAVILY used as the sbi / cbi stuff has been, 
then just do the same with that or anything else that is 
used to some degree.

This might not be something the academics would encourage 
but in the real world usage it is IMNSHO indespensible 
given the existing conditions.

Whether we like it or not, all this is out in the real world 
with people using it.  Maybe these people will learn regex 
and bit manipulation and replace them all if they don't get 
discouraged away from it assuming it is just broken.

Not everyone is a C guru.  I, for one, started out that way 
and moved on to a better knowlege of C (Still Not A C 
Guru(TM) ;-). 

 Everyone can be happy and all the legacy code does not turn 
into a hassle for newbies who just might assume all this is 
broken and develop a bad feeling for open source stuff.

I already have my fix for this so it really matters not to 
me personally what is decided, but I hope some 
consideration to "legacy" code and potential newbies 
figures into the decision.

Thanks & take care, V.
-- 
Victoria Welch, WV9K/7.  "Engineering is the art of making 
what you want from things you can get."-  Jerry Avins
"Learning about the U.S. from the mainstream media is like 
learning about plumbing by sitting in a cesspool."  -- 
Michael Phelps




reply via email to

[Prev in Thread] Current Thread [Next in Thread]