> I encountered one pitfall that I did not find a reference to anywhere
> (there's a bad pun in this I'm sure), which may be implicitly obvious to
> C programmers but escaped my C++-string oriented brain until I'd
> reassured myself I wasn't botching reference counting in Python. I was
> accessing the 'atom type' and 'atom element' members of the
> mod_coordinates struct using the "mod_coordinates_xxxx_get" methods, and
> passing this to a C++ string. My humble program was consuming vast
> quantities of memory. Eventually I realised that this method must be
> "mallocing" the char* rather than simply returning a reference to static
> data. So I replaced:
> string ele = mod_coordinates_atmnam_get(&mod.cd, idx)
> with
> char* buf = mod_coordinates_atmnam_get(&mod.cd, idx)
> string ele=buf
> free(buf)
> and this seemed to do the trick.
>
> Am I on the right track? If so, it might be useful to include a comment
> to this effect either in the API section of the modeller manual or in
> the header file itself.
That is correct - most of the API functions return a malloc'd buffer
rather than a pointer to the structures themselves because 1) the actual
data is Fortran strings, which are not null-terminated (so we have to
make a copy anyway which is) and 2) this should avoid any thread safety
problems (although Modeller as a whole has not been well tested for
thread safety). In the few cases where a pointer to static data *is*
returned, the return type is const char * to indicate that 1) you
shouldn't try to write into that data and 2) you don't need to free it.
All of the argument and return types are documented in the main header
file, modeller.h.
Ben Webb, Modeller Caretaker
--
http://www.salilab.org/modeller/
Modeller mail list: http://salilab.org/mailman/listinfo/modeller_usage