Batch malloc
in [General Programming]
|
Prev: hacking
Next: How get percentage of use of cpu
From: robertwessel2 on 28 Jan 2010 13:45 On Jan 27, 10:59 pm, websnarf <websn...(a)gmail.com> wrote: > Your question is quite interesting. But it should be fairly obvious > that such things do not exist (insert my standard old EMOing about how > the C language standard committee is too dull to consider > functionality improvements to the C library). To implement a malloc > that does what you suggest indeed should be quite straight-forward, > but would have to be some kind of implementation specific extension. In defense of the C committee, they have a definite preference (sure they stray from that at times) for prior art. And especially for a feature like this, there should be no technical problem for someone to have actually implemented it, and have it out in the real world for a while. I'm not really aware of anyone actually having implemented this.
From: websnarf on 28 Jan 2010 18:53
On Jan 28, 10:45 am, "robertwess...(a)yahoo.com" <robertwess...(a)yahoo.com> wrote: > On Jan 27, 10:59 pm, websnarf <websn...(a)gmail.com> wrote: > > Your question is quite interesting. But it should be fairly obvious > > that such things do not exist (insert my standard old EMOing about how > > the C language standard committee is too dull to consider > > functionality improvements to the C library). To implement a malloc > > that does what you suggest indeed should be quite straight-forward, > > but would have to be some kind of implementation specific extension. > > In defense of the C committee, they have a definite preference (sure > they stray from that at times) for prior art. How is that a defense of the C committee? In the history of humanity, prior art includes ritualistic virgin sacrifice and cannibalism. Even if you want to make the claim that C++ is the only path to futuristic ideas, this ignores the fact that C++ still relies entirely on C for system level interfaces (which includes malloc()). Also you are obviously wrong in very large cases like the complex arithmetic functions, these new "security enhanced" functions from Microsoft (which they were editting to the very last minute -- evidence that they clearly were not using them in final form within the company) and stdint.h. The committee clearly saw fit to exercise some creativity there with all of that. > [...] And especially for a > feature like this, there should be no technical problem for someone to > have actually implemented it, and have it out in the real world for a > while. I'm not really aware of anyone actually having implemented > this. Well its a chicken and egg problem. Other compiler vendors *HAVE* implemented functions like expand(), _mlen(), strdup(), various "heap walkers" and leak detection/debug-enhanced implementations. The concept of memory pools is also well known and used in a wide variety of applications. You don't see the standards committee do anything about that do you? Had they started looking at memory allocation interfaces more seriously, the set of events that have lead up to Jon Harrop wanting a multi-allocator might be a triviality, or may be solvable as a side-effect of other actions taken. The fact is that there is no help for him because he wants to use facilities designed 35 years ago to solve a problem he encountered a few weeks ago. The facilities have not been upgraded. There's nothing to defend here -- just realize what has happened and move on. That means you treat C like its a non-portable language like assembly language (even my solution requires that you are be able to construct pointers with malloc compatible alignment) and just hack your own implementation specific-solution or go find another programming language or live with the limitations that the C language imposes. -- Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/ |