Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: Region-based dynamic memory management idea Date: Tue, 10 Jun 2014 17:36:08 -0400 Organization: Aioe.org NNTP Server Lines: 87 Message-ID: References: <2014Jun8.152357@mips.complang.tuwien.ac.at> <2014Jun8.170536@mips.complang.tuwien.ac.at> <2014Jun10.185032@mips.complang.tuwien.ac.at> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:31381 On Tue, 10 Jun 2014 12:50:32 -0400, Anton Ertl wrote: > "Rod Pemberton" writes: >> On Sun, 08 Jun 2014 11:05:36 -0400, Anton Ertl >> wrote: >>> str+ ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 ) >>> It has to allocate memory for the result. >> >> Wow, that really looks like the C way of string concatenation to me ... > > Really? *The* C way of string concatenation is strcat(), and a Forth > stack effect for that function would be: > > ( dest src -- dest ) > > where dest and src represent zero-terminated strings. Yes, you must disregard the termination method to compare the two. So, we drop the length from Forth: str+ ( c-addr1 c-addr2 -- c-addr3 ) Now, they look much closer. If c-addr1 is sufficiently large, then c-addr1 could be equal to c-addr3, i.e., no allocation required. str+ ( dest src -- dest ) In which case, they're now equal except for termination. Of course, Forth complicates string termination, so we must provide additional information to the Forth word, re-complicating things: str+ ( dest u1 src u2 -- dest u3 ) > I think you > could not get much farther from STR+ than with strcat(), and still > have a string concatenation word/function. They're both concatenation, so they're closer than not ... > In particular and relevant > to the original topic, STR+ allocates memory, and strcat does not. So, STR+ is not identical and comprises roughly about five C function calls ... 2 strlen's, 1 malloc, 1 strcpy, 1 strcat and some miscellaneous arithmetic. It's still much closer to the C way of doing things. The point was it doesn't appear to be the Forth way. The Forth way would be colon definitions or some manipulation of the parser and/or writing into the input stream/buffer to use ." to define the concatenated string. >> I'm not >> sure how you'd go about freeing and re-using the space for the >> original two strings. > > Than maybe you should give up on C and convert to Java. You snipped so much, I think you replied to something else here... I was talking about the space already allocated in a typical Forth dictionary for "c-addr1 u1" and "c-addr2 u2". AFAIK, using the standard HERE DP ALLOT Forth mechanism, there is no way in Forth to reclaim just the space for those two strings. Those two strings will be packed inbetween other Forth words. So, you'd need extra functionality, i.e., a garbage collector or paging, to reclaim the space. So, without the ability to reclaim that space, the best you can do is add another string to the dictionary, i.e., "c-addr3 u3", causing additional consumption of stack space, which could be considered a memory leak. > Or do you > know how you free and reuse the src operand when using strcat()? It's not needed. As you pointed out, C's allocation and concatenation mechanisms are purely separate. I.e., the src operand is assumed to be sufficiently large than strcat can safely append. It's the programmer's job to make sure that it is large enough. Of course, some programmers fail to take care of the details in C, which is also a strong argument against using Forth. If you were to do the same thing in Forth using STR+, i.e., extra large allocation for "c-addr1 u1", then I'd claim that's even stronger support that you've embraced the C way. Rod Pemberton