On 25/04/2012 06:22 AM, Darren New wrote:
> On 4/23/2012 1:31, Invisible wrote:
>> Damn... I'm trying to think of something you can code without actually
>> using recursion. Hmm. Well, I guess there must be /something/...
>
> Almost all business logic.

I suppose I should consider myself lucky that I'm never going to be 
writing anything like that.

> I don't remember seeing any recursion in any
> operating system kernels I've read.

Really? That's surprising. No recursive sorting algorithms for balancing 
the B*-trees that the directory nodes use, or for sorting the ready 
thread list by priority?

> I can't think of any recursive SQL code I've written at all.

SQL is a rather special-purpose language. I'm not sure it even 
/supports/ recursion...

>> So if you want to count how many nodes there are in a binary tree, how do
>> you do that non-recursively?
>
> You use a queue. Each node you visit, you tack on to the end of the
> queue to be counted, and you go until the queue is empty.

In other words, you manually implement the stack.

Tell me, in what way does this prevent you running out of stack?

>> And yet, the way that you call a C function is, apparently, undefined.
>
> It's implementation-defined. You have to read the compiler manual (or
> source code) to know what the sequence is. And different functions in
> the same code can have different calling conventions.
>
> Unless you have a CPU that actually enforces calling conventions.

So... how is it ever possible to statically link software?

>> It sounds like it shouldn't work.
>
> And indeed it doesn't. Try compiling one library with gcc and another
> with visual C and see if they link cleanly.

It's news to me that this /doesn't/ work.

I mean, if every compiler uses its own random calling convention, then 
how /the hell/ is it possible to write some C, link it against GMP, 
wxWidgets and the OS header files, and get a usable binary? You know, 
given that you have no idea which compiler these libraries are compiled 
with...

> Take a library off the mac and link it to a Windows-compiled main().

Yeah, well, one is going to be an ELF object, and the other will be a PE 
module. You won't even be able to find a linker program that understands 
both file formats. :-P That has nothing to do with whether the machine 
code within those files would work if you linked it together.

> For that matter, try compiling one program for x86 and the other for x64.

There's absolutely no reason to expect binaries for different 
architectures to work together.

I would, however, expect that on any given architecture, the C calling 
convention is always the same.

Post a reply to this message