<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Both.<BR>
In thinking about how to write the code, there is no point in splitting the code into two functions.<BR>
They are each small and the one is only called once.<BR>
The language should in general not force me to write functions merely to work over the type system.<BR>
<*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined.<BR>
<BR>
> Functions can return pointers to open arrays - isn't this enough?<BR>
<BR>
Yes that might help.<BR>
I had tried like<BR>
<BR>
PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR =<BR>
BEGIN<BR>
IF len <= NUMBER(buf)<BR> RETURN buf;<BR>
END;<BR>
RETURN NEW ARRAY OF CHAR (len);<BR>
END PickBuffer;<BR>
<BR>
PROCEDURE Parse(...)<BR>
VAR<BR>
stack: ARRAY [0..255] OF CHAR;<BR>
BEGIN<BR>
...<BR>
WITH buf = PickBuffer(stack, len) DO<BR> use buf<BR>
END;<BR>
END Parse<BR>
<BR>
but I couldn't come up with a PickBuffer that the compiler liked.<BR>
<BR>
PickBuffer is still a bit iffy.<BR>
<BR>
More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size.<BR>
<BR>
Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over.<BR>
<BR>
The Modula-3 code I see around the system is way more low level and <EM>repetitive</EM> than seems appropriate, more so than C code that I write.<BR>
<BR>
Another example is that it definitely appears that if I try to compile code with a path like<BR>
\a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3<BR>
<BR>
that has more than around 32 path separators, I'll just get some random failures since the code just "gives up".<BR>
M3Path has an array of 32 to store the positions of path separators.<BR>
That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits.<BR>
For \.\ it is trivial.<BR>
For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly.<BR>
<BR>
Of course...maybe better here...count the slashes, if there are more than ~30, do the heap alloc, as in the previous pattern. Though it'd be nice, since it is possible, to handle arbitrarily long paths without the heap alloc.<BR>
<BR>
In a compacting garbage collection system, heap alloc can be roughly the cost of incrementing an integer.<BR>
I do not assume Modula-3 has that, though maybe, and I do not assume it has particularly fast heap allocation.<BR>
I have seen heap allocation just be very slow in general and I avoid it whenever possible/easy/correct.<BR>
<BR>
There are competing desires here of course.<BR>
1 Be fast. <BR>
2 Don't have fixed sized limits. (and esp. don't crash when you go past them! as I complained about recently..) <BR>
3 Don't use "too much" stack, however much that is. <BR>
<BR>
The easiest way to do #2 and #3 is always heap alloc exactly how much you need, but that kills #1.<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Mon, 28 Jan 2008 14:38:37 +0100<BR>> From: lemming@henning-thielemann.de<BR>> Subject: RE: [M3devel] heap vs. stack? (sort of)<BR>> To: jayk123@hotmail.com<BR>> CC: m3devel@elegosoft.com<BR>> <BR>> <BR>> On Mon, 28 Jan 2008, Jay wrote:<BR>> <BR>> > I totally want common code, there's just no point in moving it into a separate function.<BR>> <BR>> Are you concerned about efficiency or about readability? In the first case<BR>> maybe <* INLINE *> helps?<BR>> <BR>> > I also tried WITH that got its value from "PickBuffer", also a useless<BR>> > function but at least small, but functions can't return open arrays.<BR>> <BR>> Functions can return pointers to open arrays - isn't this enough?<BR><BR><br /><hr />Connect and share in new ways with Windows Live. <a href='http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008' target='_new'>Get it now!</a></body>
</html>