Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > LIFO in C

Reply
Thread Tools

LIFO in C

 
 
Keith Thompson
Guest
Posts: n/a
 
      12-14-2010
Malcolm McLean <(E-Mail Removed)> writes:
> On Dec 13, 6:22*pm, Keith Thompson <(E-Mail Removed)> wrote:
>> Malcolm McLean <(E-Mail Removed)> writes:
>> > On Dec 12, 9:29*pm, Keith Thompson <(E-Mail Removed)> wrote:
>> >> Malcolm McLean <(E-Mail Removed)> writes:
>> >> > On Dec 10, 9:06*am, arnuld <(E-Mail Removed)> wrote:

>>
>> >> >> enum { VAL_ERR = -1, VAL_SUCC = 0, LIFO_ARR_SIZE = 10 }; *

>>
>> >> > You may not define VAL_ERR in a LIFO stack module, if you want the
>> >> > code to be reusable.

>>
>> >> Why not?

>>
>> > Namespace pollution.

>>
>> So your concern is that it could conflict with a definition of the
>> identifier VAL_ERR in another library? *The same applies to VAL_SUCC
>> (and to LIFO_ARR_SIZE, for that matter). *I assumed your remark
>> applied specifically to VAL_ERR.
>>

> No, not LIFO_ARR_SIZE. Once identifiers get beyond a certain length
> and degree of generality, the chance of a collision becomes very low.


Ok, so you're saying VAL_ERR and VAL_SUCC are poor choices of names.

I'm just pointing out that that was *very* unclear in your previous
article. I assumed there was some significance to the fact that you
specifically mentioned VAL_ERR but not VAL_SUCC (I thought you might be
confused about the restriction on identifiers starting with E).

If your intent was to help arnuld, you needed to explain *why* the names
VAL_ERR and VAL_SUCC were poor choices.

> Almost every module needs VAL_ERR or VAL_SUCC, because the number of
> functions that return error or success conditions is very high.
> However only a last=in first out module is likely to need
> LIFO_ARR_SIZE.


Few modules would use those particular names, but you do have a point.

>> > Bool breaks libraries.

>>
>> What does Bool have to do with this? *If you're referring to C99's
>> "bool", that's not visible without a #include <stdbool.h>. *If you're
>> referring to something else, what?

>
> The bool problem was a huge one, and the same issue.


Can you expand on that? Personally, I think bool was a problem
prior to C99 (though there were workarounds), and that C99's _Bool
and <stdbool.h> were a reasonably good solution, perhaps the best
possible given the constraints of backward compatibility. I have
no idea from what you've written so fare whether you agree. We
can't read your mind.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      12-15-2010
On Dec 14, 6:00*pm, Keith Thompson <(E-Mail Removed)> wrote:
> Malcolm McLean <(E-Mail Removed)> writes:
>
> > The bool problem was a huge one, and the same issue.

>
> Can you expand on that?
>

Muggins wants a routine to invert a matrix (let's say). It something
he could write himeslef, but it's non-trivial.

Dopey is a library writer. His routine goes

typedef in bool

/*
Invert a matrix, in place
Returns - true if successful, false if matrix is singular (can't be
inverted)
*/
bool invertmatrix(double *mtx, int N)

The return is inherently true/false, so in a sense Dopey is doing the
wrong thing.

The problem is that now Muggins does

#include "invertmatrix.h"

/* now I have bool defined */

So he's either go to go through the entire source, #including Dopey's
header anywhere he needs a bool, or he's got to juggle bool, Bool,
boolean, bool_t. If someone else defines bool then you have to do a
bit of hackery with #ifdefs and #undefs.
Often it's a lot easier for Muggins simply to throw up his hands and
write the silly matrix invert routine from scratch.

That's how bool break libraries.
*
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Q] How far can stack [LIFO] solve do automatic garbage collectionand prevent memory leak ? Standish P Python 91 08-26-2010 08:48 PM
[Q] How far can stack [LIFO] solve do automatic garbage collectionand prevent memory leak ? Standish P C++ 87 08-26-2010 08:44 PM
[Q] How far can stack [LIFO] solve do automatic garbage collectionand prevent memory leak ? Standish P C Programming 52 08-25-2010 02:43 PM
LIFO in C, need your suggestions Sumit C Programming 20 08-11-2009 02:51 AM
can we implement LIFO using SRL16 ??? Oleg VHDL 5 02-18-2004 10:29 PM



Advertisments