> 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