"Arnd Hanses" <[EMAIL PROTECTED]> writes:
| For wizards:
| Does the *internal* implementation of those 'killer templates
| :)' or abstraction schemes eventually employ malloc()?
No. Not malloc. But you might see a new in there.
It is perfectly ok to use memory on the heap, but it should be hidden
down in the modules.
| Moreover I'd like to repeat my older suggestion: Please take your nice
| summaries (like this one!) out of this mass-grave of letters (aka mail
| archive) and resurrect them on-line. Or you could hack together a
| bsd-like TOUR text, introducing some concepts employed in the sources.
| (Don't try to make the texts perfect; it's impossible anyway ;)
A nice task for you :-) I'll give you write access to the cvs
repository if you do this. (at least that part of the repository)
You can even hunt in the mailing list archives to see if there has
been any other nice mails that could go into a document like that.
| And I'd suggest adding to the coding rule document a reminder that you
| can use in many cases (in figinset.C at least nearly everywhere) the
I will try to spell out my thoughs on figinset.C later, but in short:
Ditch It! De-couple figinset and insetfig. transformation of
eps (or others) into pixmap can be done by external programs.
Most (all?) GUI libs has support for graphics files and can do
transformations on them. Create a database api that insetfig
can ask for pixmaps. (one of the blackboxes that you want)
| most obvious solution so as to avoid malloc() hassle: Small static
| inline fns and local variables.
Then you are likely to get a lot of object copying in stead. (?)
It is ok to use new/delete (but not malloc/free), but if a automatic
object can be used in stead that is better.
Anyway memory handling should be done down in the modules and not show
up in api's.
Everything depends on what you are writing.
Lgb
