comp.lang.c - 25 new messages in 11 topics - digest
comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en
Today's topics:
* subroutine stack and C machine model - 8 messages, 8 authors
http://groups.google.com/group/comp.lang.c/t/9246f53562c33dfc?hl=en
* sorting routine - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/cdf56102e860bf38?hl=en
* C99 IDE for windows - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/c4913e93bc7b7815?hl=en
* Excuse me !! - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/5df49a9b319cbf8e?hl=en
* non-standard functions in libc -- bad design? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/91e0d63d5c28679f?hl=en
* copying zero characters - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/8d11beb8d9e8498c?hl=en
* A C implementation of Binary Heap - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/f991c6d731c73e93?hl=en
* Improving mask-to-bit macro - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/09f4eb1d530ab56b?hl=en
* Adapting software to multiple usage patterns - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/daa37b7bd5a632cf?hl=en
* ┈━═☆ GOOD NEWS!!! Cheap price wholesale Watches: Rado Watch, D&G Watch,
Burberry Watch, Cartier Watch, Prada Watch....at website www.fjrjtrade.com ===
(paypal payment) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/688d5a83d2c3352d?hl=en
* ⊙┳⊙Paypal Wholesale Nike Air Max Shoes: Air Max 87,Max 89,Max 90,Air Max
2009,Air Max LTD, Max TN <www.dotradenow.com> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/e6b874defaf6ada8?hl=en
==============================================================================
TOPIC: subroutine stack and C machine model
http://groups.google.com/group/comp.lang.c/t/9246f53562c33dfc?hl=en
==============================================================================
== 1 of 8 ==
Date: Wed, Oct 14 2009 3:10 am
From: James Kuyper
Frank wrote:
> In Dread Ink, the Grave Hand of Richard Heathfield Did Inscribe:
>
>> In <KrGA5I.8Dw@cwi.nl>, Dik T. Winter wrote:
>>
>>> In article <Qp6dnThm5-7EuUnXnZ2dnUVZ8iydnZ2d@bt.com>
>>> rjh@see.sig.invalid writes:
>>> > In <ooh15vgl4q35.ueitgdn9lkri$.dlg@40tude.net>, Frank wrote:
>>> > > In Dread Ink, the Grave Hand of Richard Heathfield Did
>>> > > Inscribe:
>>> ...
>>> > >> that, those are not two of my favourite functions.
>>> > >
>>> > > Ok. Why are they unfavo(u)red?
...
>>> I think Frank is criticising your use of British spelling.
>> Oh, okay. Thanks for the interpretation. I note that, if "Frank"'s
>> recent posting history is anything to go by, his criticisms are not
>> terribly valuable.
...
> Ohmiheck. Would you care to pick a page number for _C Unleashed_ and have
> me tell you the proximity of typing errors?
Well, if you consider "favourite" to be a typing error, I'm sure you'll
find lots of them in any book written in British English. That would
tell us more about your ignorance than about the quality of the
proofreading.
== 2 of 8 ==
Date: Wed, Oct 14 2009 3:52 am
From: Ben Bacarisse
Frank <frank@example.invalid> writes:
> Do you think that an integer exists, such that I can't find a typo within
> 15 pages?
-48,562?
--
Ben.
== 3 of 8 ==
Date: Wed, Oct 14 2009 4:30 am
From: "Joachim Schmitz"
Nick Keighley wrote:
> On 14 Oct, 09:08, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
> wrote:
>> Default User wrote:
>>> Joachim Schmitz wrote:
>
>>>> While I accept that you don't like to be called Kiki, I fail to
>>>> understand why this is offensive?, mind to explain?
>>
>>> Besides what the others have mentioned, in English-speaking
>>> countries it's generally a female name.
>>
>> Hmm, here too (but not exclisivly), but I think females might be
>> offended of you to think of a female nicknames to be offensive...
>
> applying a female name to a male person might quite well be offensive
> to the male person.
That's not what Brian said (but might well have been what he meant)
> Are you from Mars or something?
Not quite. I just deliberatly took Brian by what he said and forgot to add a
smiley...
Bye, Jojo
== 4 of 8 ==
Date: Wed, Oct 14 2009 5:30 am
From: Richard
Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> On 13 Oct, 20:45, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
> wrote:
>> Keith Thompson wrote:
>> > "Joachim Schmitz" <nospam.j...@schmitz-digital.de> writes:
>> >> REH wrote:
>> >>> On Oct 13, 1:08 pm, "Joachim Schmitz"
>> >>> <nospam.j...@schmitz-digital.de> wrote:
>> >>>> Keith Thompson wrote:
>
>> >>>> While I accept that you don't like to be called Kiki, I fail to
>> >>>> understand why this is offensive?, mind to explain?
>
>> >>> You need a better reason than it's not his name, and it's a juvenile
>> >>> attempt to antagonize him?
>>
>> >> Yes.
>>
>> > No, you don't.
>>
>> Well, I do. It's not vital though...
>>
>> > To be clear, you certainly don't *need* to know why I dislike it.
>>
>> Right. But I need to know what is offensive about it.
>
> ?? if someone uses a name for him that he dislikes and only uses to
> cause
> offense then isn't almost by definition offensive?
>
> I mean this is playgound stuff shouldn't we have grown out of this
> sort of
> thing?
>
> And *why* do you need to know why its offensive? Surely Keith's
> dislike
> of it it enough for a polite and reasonable person to desist using it.
In all of the technical groups I read, only YOU are incapable of setting
your newsread properly. Why is that Nick? An attempt to be different?
>
>> > I don't mind explaining it, as I've already done elsethread.
>> > But surely the reasons cited by REH are good enough.
>>
>> For disliking it yes, but I don't think this is enough to explain it's
>> offensiveness
>
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
== 5 of 8 ==
Date: Wed, Oct 14 2009 5:32 am
From: Tim Rentsch
James Kuyper <jameskuyper@verizon.net> writes:
> bartc wrote:
>>
>> "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> wrote in message
>> news:hb40t9$7b4$1@online.de...
>>> Default User wrote:
>>>> Joachim Schmitz wrote:
>>>>
>>>>> While I accept that you don't like to be called Kiki, I fail to
>>>>> understand why this is offensive?, mind to explain?
>>>>
>>>> Besides what the others have mentioned, in English-speaking countries
>>>> it's generally a female name.
>>>
>>> Hmm, here too (but not exclisivly), but I think females might be
>>> offended of you to think of a female nicknames to be offensive...
>>
>> You just don't seem to get it. What exactly do you have to call
>> somebody in public, in your part of the world, to belittle them and
>> show contempt and disrespect?
>
> It's somewhat sexist that using a feminine nickname for someone is a
> way "to belittle them and show contempt and disrespect". [snip]
ISTM that any deliberately mis-applied label frequently offers an
implicit slur. It isn't sexist to observe that often people use a
feminine nickname with the intention of belittling and showing
contempt; what is sexist is using a feminine nickname in such a
way. IME most listeners are responding more to the attitudes of
the speaker than they are to any inherent prejudices of their own.
== 6 of 8 ==
Date: Wed, Oct 14 2009 5:41 am
From: Moi
On Mon, 12 Oct 2009 22:00:26 -0700, Ben Pfaff wrote:
> The page at http://www.freetype.org/david/reliable-c.html is a "paper"
> that describes this kind of design technique.
Excellent stuff.
Thanks for the link, Ben,
AvK
== 7 of 8 ==
Date: Wed, Oct 14 2009 5:42 am
From: James Dow Allen
On Oct 14, 5:14 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> James Dow Allen <jdallen2...@yahoo.com> writes:
> > It can also be used as a carefree man's backtracker as at
> > http://james.fabpedigree.com/rrome.htm
> > where the calls occur from the following macros:
>
> > #define EITHER if (S[1] = S[0], ! setjmp((S++)->jb)) {
> > #define OR } else EITHER
> > #define REJECT longjmp((--S)->jb, 1)
> > #define END_EITHER } else REJECT;
>
> Just a word of warning: the behaviour of the above is undefined due to
> the severe limits placed on the way setjmp can be called.
Thanks for this, Ben! Although the code *does*
seem to work on at least a few different platforms,
I've wondered whether this might just be a lucky
happenstance due in part to the fact that the
function is otherwise rather tame.
>
> Basically you can have nothing more complex than !setjmp(...) or
> setjmp [relational or equality op] [integer constant expression] as
> the controlling expression of an if/switch/while/for/do.
One simple change I could make would be to
move the comma operator to inside the setjmp
argument, i.e. replace
if (S[1] = S[0], ! setjmp((S++)->jb)) {
with
if (! setjmp((S[1] = S[0], (S++)->jb))) {
Would this solve the problem?
The comma operator isn't just a fetish here,
but seemed essential to the "smoothness" of
these macros in the presence of "else".
If we insist, for some reason, on not using
the comma operator *at all*, a workaround may
be harder, assuming we reject an approach like:
/* which END_EITHER to use depends on number of OR's */
#define END_E1 } else REJECT; }
#define END_E2 } else REJECT; }}
#define END_E3 } else REJECT; }}}
#define END_E4 } else REJECT; }}}}
#define END_E5 } else REJECT; }}}}}
#define END_E6 } else REJECT; }}}}}}
Perhaps there's a clever solution based on some
" do { ... break ...} while()" construct, but I'll
leave that as an exercise. :-)
Another interesting puzzle -- solution for which
would be embarrassing for me, but perhaps not overly
surprising -- is to redesign the macros to avoid
setjmp/longjmp altogether. (I would not consider a
solution "valid" in this sense if its overall
complexity increases, or if threads or fork()s
are substituted for the setjmp()s.)
Feel free to deprecate my code! Much of my C coding
is for my own amusement; code I've delivered to
paying customers has never been this bizarre.
> Ben.
James Dow Allen
== 8 of 8 ==
Date: Wed, Oct 14 2009 6:06 am
From: Nick Keighley
On 14 Oct, 13:30, Richard <rgrd...@gmail.com> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> > And *why* do you need to know why its offensive? Surely Keith's
> > dislike
> > of it it enough for a polite and reasonable person to desist using it.
>
> In all of the technical groups I read, only YOU are incapable of setting
> your newsread properly. Why is that Nick? An attempt to be different?
to my knowledge google provides no automatic way to do this.
I think I've told you this before...
==============================================================================
TOPIC: sorting routine
http://groups.google.com/group/comp.lang.c/t/cdf56102e860bf38?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Oct 14 2009 3:39 am
From: "osmium"
"Richard Heathfield" wrote:
> An instant is a duration, [...].
This may be a British/American thing but one of our main dictionaries says
an instant is an infinitesimal space of time. Calculus says there is
nothing smaller than that, so an instant is a point in time.
==============================================================================
TOPIC: C99 IDE for windows
http://groups.google.com/group/comp.lang.c/t/c4913e93bc7b7815?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Oct 14 2009 3:44 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
arnuld <sunrise@invalid.address> writes:
>>1) find out how much storage you need for the string;
>>2) allocate that much;
>>3) call sprintf to build the string.
>you mean you missed the 4th step ;)
>1) find out how much storage you need for the string
>2) malloc() that much
>3) call sprintf to build the string
>4) don't forget to free() the memory
Still, both of you did not check the result of malloc.
== 2 of 2 ==
Date: Wed, Oct 14 2009 5:47 am
From: Richard
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> arnuld <sunrise@invalid.address> writes:
>>>1) find out how much storage you need for the string;
>>>2) allocate that much;
>>>3) call sprintf to build the string.
>>you mean you missed the 4th step ;)
>>1) find out how much storage you need for the string
>>2) malloc() that much
>>3) call sprintf to build the string
>>4) don't forget to free() the memory
>
> Still, both of you did not check the result of malloc.
>
Why bother? It malloc fails for a few bytes your system is almost
certainly irrecoverable ..........
Besides that, he didn't NEED to specifically state the check because (2)
includes (or possibly includes), the check since its target was to
"malloc() that much". if malloc failed, then the target was not met.
J
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
==============================================================================
TOPIC: Excuse me !!
http://groups.google.com/group/comp.lang.c/t/5df49a9b319cbf8e?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Oct 14 2009 4:00 am
From: abu omer
Excuse me!!
Would you stop for a moment?!
Haven't you thought-one day- about yourself ?
Who has made it?
Have you seen a design which hasn't a designer ?!
Have you seen a wonderful,delicate work without a worker ?!
It's you and the whole universe!..
Who has made them all ?!!
You know who ?.. It's "ALLAH",prise be to him.
Just think for a moment.
How are you going to be after death ?!
Can you believe that this exact system of the universe and all of
these great creation will end in nothing...just after death!
Have you thought, for a second, How to save your soul from Allah's
punishment?!
Haven't you thought about what is the right religion?!
Here you will get the answer
my mail: abuomer75@hotmail.com
==============================================================================
TOPIC: non-standard functions in libc -- bad design?
http://groups.google.com/group/comp.lang.c/t/91e0d63d5c28679f?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Oct 14 2009 4:20 am
From: blmblm@myrealbox.com
In article <5839e041-6974-44d7-80c7-72d21cf47c32@e34g2000vbm.googlegroups.com>,
Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> On 1 Oct, 07:06, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <Id-dnR7yvrB_o17XnZ2dnUVZ_hqdn...@posted.internetamerica>,
> > Gordon Burditt <gordonb.9c...@burditt.org> wrote:
>
> > > >I've been involved, in another context, in a long and contentious
> > > >discussion about whether functions that are part of the POSIX
> > > >standard but not the C standard -- getpid() in particular --
> > > >should be regarded as "third-party".
>
> I don't think "third-part" is a very useful/helpful term.
>
>
> > > If it comes with the OS, and it's used by the C implementation, I
> > > don't think "third-party" is the right term to use for it.
> >
> > > The C standard doesn't use that term, and I don't think it
> > > appears in licenses referring to functions in a library.
> > > Does it matter?
> >
> > Not really; it's a terminology quibble, but sometimes those are
> > hard to resist. Sort of a :-).
>
> but the litmus test for correct vocabulary is "is it useful?".
> I don't think "third-party" is useful enough in this context.
>
Could be. I'm inclined to think that the other party to the
original dispute used "third party" mostly as a way to disparage --
something, I'm not sure what -- but I agree that arguing about
the definition doesn't really advance a discussion of relevant
technical issues.
[ snip ]
> > But, um, the "C library" appears to be packaged in at least two
> > distinct parts already, one with the math functions and one with
> > the rest. So why not further separate out the not-C-standard
> > extensions?
>
> You are drifting a bit here. You started talking about header files
> now you are talking about library files.
Well, one of the questions in my initial post was about what
should be included in a particular library file (see below).
> P.J.Plauger wrote an
> excellent book about the implementaion of a Standrad C library (C89
> only).
> As I remember his standard headers were pretty clean in that they
> only had stuff from the standard in them; except he had some magic
> implementation defined header files which he included. But to
> make the library actually work you had to link with something
> implementation specific.
>
> How will dividing the library up help the developer. I confess
> I wish POSIX were cleaner but in practice it doesn't seem to make much
> odds.
> Wishing things were different probably isn't going to make much
> difference.
I'm not sure it's a question so much of what would help the developer
as of what can be defended as "good design" -- or not.
[ snip ]
> > > >(*) Is there a compelling reason to avoid including anything
> > > >that's not part of the C standard library in libc (and instead
> > > >put it in a separate library)?
> >
> > > The compelling reason to NOT do that is that it would break a lot
> > > of stuff, including C.
> >
> > So, replacing libc.{so,a} on an existing system with one that
> > doesn't include the POSIX extensions would break a lot of things.
> > But that doesn't really address the question of whether putting
> > them together in the first place was a good design, right?
> >
> > I'm thinking now that comp.unix.programmer may be the right place
> > to ask about that.
>
> You'll get even less sympathy there! "Why would we want to break
> our Posix compliant code to make clc happy?".
Maybe it's not clear (though maybe it doesn't need to be) .... :
I'm not the one who said that putting C-standard and not-C-standard
functions in the same library file was "broken"; I started
this thread rather hoping someone would help me come up with
convincing arguments to the contrary, though I'm also willing to
hear arguments supporting the other party to the initial dispute.
As best I can tell, the majority view has been "this is how
things are, and to change it would be a lot of disruption for
no particular payoff", which isn't quite the same thing as
"this was a brilliant design, and here's why .... " <shrug>
It's been educational anyway.
[ snip ]
> > Eh. It's nitpicking and quibbling about terminology and like that,
> > but really, isn't that a big part of what people *DO* here? Sort
> > of a :-).
>
> A lot of the c.l.c. verbiage seems to be devoted to the numerical
> density of cavorting nubile seraphim upon pinheads.
> CBFalconer
I like it. :-)
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
== 2 of 2 ==
Date: Wed, Oct 14 2009 5:09 am
From: James Kuyper
blmblm@myrealbox.com wrote:
> In article <5839e041-6974-44d7-80c7-72d21cf47c32@e34g2000vbm.googlegroups.com>,
> Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
...
>> but the litmus test for correct vocabulary is "is it useful?".
>> I don't think "third-party" is useful enough in this context.
>>
>
> Could be. I'm inclined to think that the other party to the
> original dispute used "third party" mostly as a way to disparage --
> something, I'm not sure what -- but I agree that arguing about
> the definition doesn't really advance a discussion of relevant
> technical issues.
I doubt it. I suspect that the issue was about conformance. The C
standard imposes some requirements that an implementation of C must
satisfy to be considered conforming, and other requirements that source
code must satisfy in order to produce defined behavior when compiled by
such implementations.
In principle, a standard like POSIX could have taken either of two
routes: it could have defined it's library to meet the requirements
imposed on conforming extensions to the C standard library, or it could
have defined it's library to be a third-party library independent of the
C standard library, to be linked to by user code. The most important
distinction between those two options is the naming conventions: to
qualify as a conforming extension to the C standard library, POSIX
identifiers would have had to use exclusively names reserved to the
implementation; as a third-party library it would have been prohibited
from doing so.
POSIX didn't follow either of those approaches; it's both part of and in
addition to the C standard library. It imposes additional requirements
on functions in the C standard library, but also adds additional
functions with names that are not reserved by the C standard to the
implementation. Historically, this is because both standards were
standardizing existing practice that pre-dated either library, and I'm
not sure there were any significant better options available to the
standardizers - but it makes describing the relationship between the
libraries defined by the two standards somewhat confusing.
==============================================================================
TOPIC: copying zero characters
http://groups.google.com/group/comp.lang.c/t/8d11beb8d9e8498c?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Oct 14 2009 4:46 am
From: Tim Rentsch
Keith Thompson <kst-u@mib.org> writes:
> Francois Grieu <fgrieu@gmail.com> writes:
>> Richard Harter a @C3{A9}crit :
>>> If memcpy/memmove is given a value of zero for the number of
>>> characters to be copied/moved is it guaranteed that nothing will
>>> be done? The standard can be read that way but I'm checking.
>>
>> The standard reads:
>>
>> #include <string.h>
>> void *memcpy(void * restrict s1,
>> const void * restrict s2,
>> size_t n);
>>
>> The memcpy function copies n characters from the object pointed
>> to by s2 into the object pointed to by s1.
>>
>> IMHO it follows that when n is 0, no character is copied.
>
> Yes, but it does assume that s1 and s2 both point to objects.
>
>> That is a pretty common assumption, and lots of code would
>> break if it did not.
>
> Certainly a memcpy that copied 1 byte given a third argument of 0
> would break code. But I think the case being considered is:
>
> memcpy(NULL, NULL, 0);
>
> I believe the behavior of that call is undefined.
Confirmed, supplying a null pointer (for either argument (and
also for memcpy)) is undefined behavior.
An argument could be made that the text of 7.1.4p1, which
specifies the default conditions for valid arguments, allows null
pointers when the value for 'n' is zero. (More specifically,
see the sentence starting "If a function argument is described
as being an array,".) However, such an argument is undercut
by 7.21.4.5p2, which illustrates needing to allow null pointers
explicitly when such values are to have defined behavior.
==============================================================================
TOPIC: A C implementation of Binary Heap
http://groups.google.com/group/comp.lang.c/t/f991c6d731c73e93?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Oct 14 2009 4:46 am
From: arnuld
> On Oct 9, 3:59 pm, Mark Bluemel <mark.blue...@googlemail.com> wrote:
>> On 9 Oct, 11:18, arnuld <sunr...@invalid.address> wrote:
> Hint: How many elements do you think you have? Why do you think that?
> Have you stepped through your code with a pad of paper and a pencil?
> If not, why not?
>
> ...SNIP..
I have corrected it and it prints only the existing elements. See down
for the new code.
> > free(root);
>
> This is pointless. If you want to do this properly, you need to have a
> decent cleanup mechanism - free()ing the root isn't that.
Actually, this was just a dummy thing, the real idea is to create a
heap_free() function which will recursively free() the whole heap. It
does not work as desired, has some memory leak and also it added 2
values and they are inside the heap but it does not print the
statement I added but I am trying figure out the problems. I
theoretically know what a heap is and what a binary tree is. I am
*not* confused. Its that reading theory, understanding it and writing
code are skills 2 worlds apart from each other:
/* A simple program using a struct to implement a Binary Heap in C.
This binary heap will support 3 operations:
*
* - insert an element to the heap O(log(n))
* - delete the element with the highest priority (which of course is
the root node in a Binary Heap) O(log(n))
* - find the maximum element without removing it (again it will be
root node, but will take only O(1) time)
*
* The struct will contain a character string (as priority) and a char
as (his grade). We will use the string to decide
* whether some student has higher priority than the other.
*
* As per Wikiepdia: http://en.wikipedia.org/wiki/Binary_heap#Building_a_heap
, directly inserting an element in a Binary Heap
* is not as much efficient as compared to first adding all elements
to a Binary Tree and then heapify the Binary-tree to make a
* Binary-heap. So we will first add entries to a Binary-Tree and then
heapify it to get a Binary Heap.
*
*
* VERSION 0.1
*
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
enum { VAL_SUCC = 0,
VAL_ERR = -1
};
enum { PRIORITY_SIZE = 10 };
struct BH_node
{
char prio[PRIORITY_SIZE];
char grade;
struct BH_node* left;
struct BH_node* right;
};
struct BH_node* BH_init(void);
struct BH_node* BH_insert(struct BH_node*, char [], char );
void BH_print(struct BH_node* );
void BH_free(struct BH_node* s);
int main(void)
{
struct BH_node* root = NULL;
root = BH_insert(root, "A1", 'A');
root = BH_insert(root, "A2", 'B');
BH_print(root);
BH_free(root);
root = NULL;
return 0;
}
struct BH_node* BH_insert(struct BH_node* s, char p[], char g)
{
int cmp = VAL_ERR;
if(NULL == s)
{
s = BH_init();
if( NULL == s)
{
fprintf(stderr, "IN: %s, LINE: %d, Out of memory\n", __FILE__,
__LINE__);
}
else
{
strcpy(s->prio, p);
s->grade = g;
}
}
else
{
cmp = strcmp(s->prio, p);
if( 0 == cmp )
{
printf("Duplicate entry, will not add\n");
}
else if( cmp < 0 )
{
printf("value added to LEFT\n");
s->left = BH_insert(s->left, p, g);
}
else
{
printf("value added to RIGHT\n");
s->right = BH_insert(s->right, p, g);
}
}
return s;
}
struct BH_node* BH_init(void)
{
struct BH_node* p = malloc(1 * sizeof *p);
if( NULL == p )
{
return NULL;
}
p->left = p->right = NULL;
return p;
}
void BH_free(struct BH_node* s)
{
/* Don't have any idea on how to recursively free the Binary Heap */
if(s)
{
if( (NULL == s->left) && (NULL == s->right) )
{
free(s);
s = NULL;
}
else
{
BH_free(s->left);
BH_free(s->right);
}
}
}
void BH_print(struct BH_node* s)
{
if( NULL == s ) return;
BH_print(s->left);
printf("priority: %s, grade: %c\n", s->prio, s->grade);
printf("--------------------------\n");
BH_print(s->right);
}
=================== OUTPUT ===========================
[arnuld@dune programs]$ gcc -ansi -pedantic -Wall -Wextra binary-
heap.c
[arnuld@dune programs]$ ./a.out
value added to LEFT
priority: A2, grade: B
--------------------------
priority: A1, grade: A
--------------------------
[arnuld@dune programs]$
== 2 of 2 ==
Date: Wed, Oct 14 2009 5:37 am
From: Ben Bacarisse
arnuld <arnuld.mizong@gmail.com> writes:
> I
> theoretically know what a heap is and what a binary tree is. I am
> *not* confused. Its that reading theory, understanding it and writing
> code are skills 2 worlds apart from each other:
That mean you know that the code you wrote for "insert" is for a
binary search tree. Do you want someone to re-write it to be a heap?
I am not sure what you are asking about anymore.
<snip code>
--
Ben.
==============================================================================
TOPIC: Improving mask-to-bit macro
http://groups.google.com/group/comp.lang.c/t/09f4eb1d530ab56b?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Oct 14 2009 5:13 am
From: Francois Grieu
Phil Carmody wrote:
> Francois Grieu <fgrieu@gmail.com> writes:
>> in an embedded project, the hardware manufacturer has defined
>> hardware equates on the tune of
>>
>> #define BIT2MASK(b) (1<<(b))
>>
>> #define TIMER_CTRL_FOO BIT2MASK(0) // enable mask for feature FOO
>> #define TIMER_CTRL_BAR BIT2MASK(5) // enable mask for feature BAR
>> #define TIMER_CTRL_ZOO BIT2MASK(7) // enable mask for feature ZOO
>>
>> I need to revert the effect of BIT2MASK, and get back at the bit
>> number
>>
>> When b is in range [0..7] this can be done with one of
>>
>> // "straightforward"; first constant is octal for "clarity";
>> #define MASK2BIT(m) ((01623753433>>(m)%11*3)+5&7)
>>
>> // short variant suggested by Harald van Dijk
>> #define MASK2BIT(m)(6773270%((m)+9)%8)
>>
>> // alternate short variant
>> #define MASK2BIT(m)(478414%((m)+37)&7)
>>
>>
>> Can we extend this when b is in range [0..15], or better [0..31],
>> and still have a conformant and "pure" macro, which evaluate its
>> argument only once ?
> What's wrong with inline functions?
Several things:
A) the C preprocessor does not know them, this I can't
use them in the condition for a #if
B) the only supported compiler for my target CPU is stuck to C89.
<ot>
C) I use MASK2BIT in inline assembly, for an instruction which
syntax requires a bit number (note: this also precludes use
of the selection operator, and any assignment)
</ot>
> If you aren't satisfied with your compiler's ability to inline
> functions, complain to your provider.
I complained that the compiler barks at enum{foo,}; because of
the extra comma, twice, with no result. All black holes in the
universe will have evaporated long before inline support is added.
> Basically you squish all 32 5-bit values into a single 32-bit value
> (presuming existence of leading zeroes too), and then permute them.
>
> So IIRC, it's something like:
> #define DODGYMACRO(v) (lookup[(MAGIC>>((v)%37))&0x1f])
That is a reasonable avenue for a run-time evaluation (although
for small arguments the technique in my original post is faster
and more compact on many platforms). But most compilers that I
practice are unable to evaluate this at compile time when v is
a constant. And again, no preprocessor can.
The rest of my original question remains:
>> Or/and can we generate a compile-time error when m is
>> not a power of two ?
>>
>> Can things be made readable, perhaps at the price of removing the
>> "purity" requirement (which is admitedly pointless in my case) ?
François Grieu
== 2 of 2 ==
Date: Wed, Oct 14 2009 6:25 am
From: Tim Rentsch
Francois Grieu <fgrieu@gmail.com> writes:
> Phil Carmody wrote:
[snip]
>> So IIRC, it's something like:
>> #define DODGYMACRO(v) (lookup[(MAGIC>>((v)%37))&0x1f])
>
> That is a reasonable avenue for a run-time evaluation (although
> for small arguments the technique in my original post is faster
> and more compact on many platforms). But most compilers that I
> practice are unable to evaluate this at compile time when v is
> a constant. And again, no preprocessor can.
>
> The rest of my original question remains:
I'm confused about just what it is you're looking for...
>>> Or/and can we generate a compile-time error when m is
>>> not a power of two ?
#define NOT_A_FINITE_INTEGER_POWER_OF_TWO(k) \
( !(k) || (k) & (k)-1 )
#if NOT_A_FINITE_INTEGER_POWER_OF_TWO( some_constant_expression )
#error "hey buddy, you messed up"
posted by twitter @ 6:59 AM
0 Comments
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home