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
>> 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...