Sorry for not being clear, in what I said.
But in my opinion this behavior (and docu) should be extended that calls like this (set_pointer and operator= ) won't destruct the data.
I meant more precisely:
... won't destruct the data, if the user had set
So, it won't break the code, since set_free.. is default true. Therefore, it will only result in a memory leak, if the user had set this flag to true and resets the pointer, without taking care.
Additionally, this mentioned mal-function (imho), will occur at several locations within irrArray, if set_pointer was used (with shared data). This is everywhere, where data is destructed / deallocated.
As it is in my use case very useful, I won't recommend removing set_pointer.
Here is my use case, to illustrate why set_pointer can be useful:
I'm rendering regular tesselated quadratic meshes (up to several houndreds)
There are at most 16 possible indices combinations.
In order to use hardware vertex/index buffers (SVN tree) I use a SMeshbuffer structure.
The vertex data is complete static and won't change over time.
The index data can change over time, to any of the 16 combinations.
Since I don't want to rebuild this index structure everytime needed, I like to call indexDataArray.set_pointer(my_prebuild_indices). Therefore having a really cheap resetting of the held data.
Of course this has to be copied to hardware, if hardware indices are used, but at least this won't copy the data twice (one time from my_prebuild_indices to indexDataArray and another one to the hardware buffer).