On 2015/01/12 22:46, Philip Chee wrote:
""
One large difference between C and most other programming languages is
that in C, you have to handle memory yourself rather than having a
garbage collector do it for you. Ensuring that memory is allocated at
the correct moment is not very difficult (and something that needs to be
done manually in pretty much every language); the hard part is to ensure
that enough memory is allocated, and to ensure that the memory is
deallocated when it is no longer in use.
There are several techniques available for memory management in C. Many
of them are used in NetHack 3.4.3; and even more are used somewhere in
NetHack 4. In this blog post, I'd like to look at them and discuss their
advantages and disadvantages. I'm mostly concerned about correctness,
rather than efficiency, here; that means that unless the performance
difference is very large, I care more about clean code than I do about
fast code.
""
<http://nethack4.org/blog/memory.html>
Phil
Nethack? That nethack?
I looked at the web page.
Yes, *that* nethack.
Do people still play it? It seems so
and on a UTF-8 capable terminal (?)
We have come a long way from vt100.
Anyway, a surprise that there are so memory allocation issues under the
hood even for nethack! It now even has an interface for JSON library (?)
Written on "Sun Mar 16 19:10:57 UTC 2014" it is a good summary, and
something good old DDJ would carry.
But after all, the author of the page states in a section
titled 'Avoiding allocations in the first place':
As can be seen above, memory allocation in C is something of a mess ...
So we are better off with more modern languages although at
low-level we DO need to deal with issues mentioned in the blog.
Hmm, the author seems to be rewriting nethack using some modern memory
handling approach
using contorted C. Long live nethack.
I am not sure if he or anybody will rewrite nethack
in more modern languages. Nethack in haskel may be an interesting Google
summer intern programming topic (?)
Moral of the story:
This blog has a bearing on mozilla software. too.
I am struggling to clean up a mess of stream handling in TB's message
download code: it is not entirely clear who owns the stream in the sense
that who should close an open stream. Because of the confusion, TB
currently closes already closed stream left and right.
Also, it must have broken subtle handling regarding stream and buffering
cannot be enabled without causing a strange message corruption.
So topic of who frees the allocated memory hits home (hard to done
correctly in C.)
At least we use C++ for mozilla software, so we are better off. I notice
there have been tricks to make sure
some allocated objects not released accidentally, etc. to make memory
management more robust automatically.
Unfortunately, stream handling in the current TB code
suffers from the similar issue suffered from C programs. Maybe we can
tweak the stream class more robust, but I think in the current case, TB
ought to be re-coded somewhat to show us its handling of stream in an
explicit accountable manner.)
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
