[M3devel] heap vs. stack? (sort of)

[Jay]

I totally want common code, there's just no point in moving it into a separate function.
For now I used a separate function, and I made it nested.
I also tried WITH that got its value from "PickBuffer", also a useless function but at least small, but functions can't return open arrays.
 
The problem with heap allocation is that it is slow. This code is optimizing it away in the first place for "small" strings, that's not my doing. Of course you have to pick some heuristic "small" and hope not to blow too much wasted stack. 256 bytes of stack is not small sometimes.
 
It appears that nested functions have to occur up in the variable section but that is very dificult to glean from the documentation or the error messages. Blech.
 
 - Jay



> Date: Mon, 28 Jan 2008 12:39:10 +0100> From: lemming at henning-thielemann.de> Subject: Re: [M3devel] heap vs. stack? (sort of)> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> > > On Mon, 28 Jan 2008, Jay wrote:> > > Is it possible to have this pattern in Modula-3:> >> > PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF (len <= NUMBER (buf)) THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); END; END Parse;> >> > PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: BOOLEAN): T => > I think it is a good idea to encapsulate the common code in DoParse. If> DoParse needs local variables, it can be turned into a local PROCEDURE of> Parse. On the other hand I doubt that it is sensible to reserve 256 bytes> on the stack also if they are not used, or only a part of them are used.> What's bad about always using NEW? I think Modula-3's memory management> has optimizations for small amounts of memory.
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080128/23d479f9/attachment-0002.html>