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

[Jay]

  > consider that (on Unix systems at least) '..' does not back out of a   > symbolic link, but may go somewhere else entirely.  Whether you want  > this behaviour is, of course, up to you.
 
cm3 does this. Not up to me or you probably.
 
See m3-sys/cm3/src/M3Path.m3
 
PROCEDURE FixPath (VAR p: ARRAY OF CHAR;  host: BOOLEAN): TEXT =  (* remove redundant "/arc/../" and "/./" segments *)  VAR os := os_map [host];  len, x, s0, s1, s2: INTEGER;  info: SepInfo;
 
 - Jay



> Date: Mon, 28 Jan 2008 09:46:29 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] heap vs. stack? (sort of)> > On Mon, Jan 28, 2008 at 02:00:46PM +0000, Jay wrote:> > Both.> > In thinking about how to write the code, there is no point in splitting the code into two functions.> > They are each small and the one is only called once.> > The language should in general not force me to write functions merely to work over the type system.> > <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined.> > > > > Functions can return pointers to open arrays - isn't this enough?> > > > Yes that might help.> > I had tried like> > > > PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR => > BEGIN> > IF len <= NUMBER(buf) RETURN buf;> > END;> > RETURN NEW ARRAY OF CHAR (len);> > END PickBuffer;> > > > PROCEDURE Parse(...)> > VAR> > stack: ARRAY [0..255] OF CHAR;> > BEGIN> > ...> > WITH buf = PickBuffer(stack, len) DO use buf> > END;> > END Parse> > > > but I couldn't come up with a PickBuffer that the compiler liked.> > > > PickBuffer is still a bit iffy.> > > > 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.> > > > Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over.> > > > The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write.> > > > Another example is that it definitely appears that if I try to compile code with a path like> > \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3> > > > that has more than around 32 path separators, I'll just get some random failures since the code just "gives up".> > M3Path has an array of 32 to store the positions of path separators.> > That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits.> > For \.\ it is trivial.> > 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.> > If you are talking about paths for naming files, you might want to > consider that (on Unix systems at least) '..' does not back out of a > symbolic link, but may go somewhere else entirely. Whether you want > this behaviour is, of course, up to you.> > -- hendrik
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080128/b50a7886/attachment-0002.html>