On 5-ott-09, at 16:02, Jeff Squyres wrote:
On Oct 5, 2009, at 9:23 AM, Fawzi Mohamed wrote:
yes you are right, I was unclear, I meant that I would pass a cpu_set
struct by value (not always pass a pointer).
If one wants to later migrate to passing just a pointer, then
internally this struct can have just a single pointer as field.
Ah, gotcha.
But if that struct contains a dynamically-malloced pointer, then we
might get issues about confusion of ownership of the sub-data...
well the situation is exactly the same as with handles, I am used to
have struct for arrays (that know their length), and still have to be
allocaded/freed, but maybe for others it is indeed strange.
indeed, if you alloc, and it is fixed size (no sparse structure) then
one can just call free, but in general having a structure specific
free function gives just a lot more flexibility for the future (and
is
needed to copy unknown size structs).
I agree about the future, but it would seem weird if we have alloc/
free functions for public structs. No one will use them, and then
when/if we *do* change to opaque handles (or equiv), they *will*
have to change their code. Kinda defeats the point.
So I think we can't go half-n-half -- it's either public structs
until 2.0 or something opaque (where you *have* to use hwloc alloc/
free functions).
ok as I said to me it is not so strange (maybe init/clear would be a
better name though), but indeed it might confuse people, so probably
better avoid it.
Force the user to to the right thing is better.
So the question remains, opaque + functions, or public...
Fawzi
