two questions:
* what's the use of the size_t argument in freebytes?
* what's the use of the t_symbol argument in outlet_new?
thanks.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Both are there for future possible optimizations. The "size" parameter would allow for much more space-optimized memory allocation than malloc() can offer (and I've also used it to trace memory corruption bugs once or twice).
The "t_symbol" field could be used to pre-determine data type conversions, in case the type system gets richer...
cheers Miller
On Thu, Jan 04, 2007 at 01:30:42PM -0500, Mathieu Bouchard wrote:
two questions:
what's the use of the size_t argument in freebytes?
what's the use of the t_symbol argument in outlet_new?
thanks.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr?al QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Thu, 4 Jan 2007, Miller Puckette wrote:
Both are there for future possible optimizations. The "size" parameter would allow for much more space-optimized memory allocation than malloc() can offer
I can think of ways to make space-optimised allocators without any such size parameter. Actually I have no idea what kind of worthwhile space-optimisation you'd be able to do with that, because every technique I can think of, is replaceable by a technique that doesn't need that info.
(and I've also used it to trace memory corruption bugs once or twice).
How can you do it better with a simple homebrew system than with a professional quality tool like Valgrind? (or the non-free Purify)
I ask because I've made my own allocation verifiers several times and they hardly caught any significant amount of bugs. 99% of the memory corruption bugs I've had, have been dangling pointer bugs. Valgrind is able to find much more than all of the bugs that my homebrew systems has been able to find.
The "t_symbol" field could be used to pre-determine data type conversions, in case the type system gets richer...
What's the likelihood of that ever happening? Then what happens to code that currently makes misleading declarations?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
Mathieu Bouchard -
Miller Puckette