Boost logo

Boost Users :

From: Paul Giaccone (paulg_at_[hidden])
Date: 2007-04-20 13:16:00


Michael Fawcett wrote:

>On 4/20/07, Paul Giaccone <paulg_at_[hidden]> wrote:
>
>
>><code snip>
>>
>>
>
>I don't see anything really wrong off hand.
>
>
>
>> boost::scoped_ptr<Info> info;
>> std::pair<double, std::valarray<double> > position;
>> boost::shared_array<double> orientation;
>> std::valarray<double> previous_position_parameter;
>>
>>
>
>Why is orientation a shared_array when MyNode is not copyable?
>Shouldn't orientation be a scoped_array, or alternatively, info be a
>shared_ptr? I didn't see the copy-constructor or assignment operator,
>so maybe you are manually doing a deep copy of info?
>
>
Hm, interesting point. The variable info is a scoped_ptr because it is
used only in MyNode::compute() - it is a wrapper around information that
is passed in MyNode::compute() to the (stand-alone) function that does
all the work. The variable orientation is also passed to this function,
hence it needs to be a shared_array. So it is not that I am copying
MyNode or thinking that it will be copied. (I take it that MPxNode, from
which MyNode is inherited publicly, is non-copyable, then?) There is
therefore no copy constructor or operator= for MyNode, nor for Info, as
it is its contents that are passed to the function that does any copying.

The copy constructors and operator=() functions do deep copies, yes,
with their own reset()s for any smart pointers that are members, and
then explicit per-element copying.

>>Info is a class that contains further shared_arrays of simple types. The
>>variable info is initialised in MyNode::initialize() because the sizes
>>of the arrays are not known until that point.
>>
>>
>
>I didn't see initialize listed, so I can't comment.
>
>
>
My mistake - it's initialised in readData():

MStatus MyNode::readData(void)
{
    //read other attributes here

    handle = data.inputValue(maya_variable, &stat);
    variable = handle.asDouble();

    const int num_frames = 1; //info is required for only one frame
    info.reset(new Info(num_frames, variable));

    return MS::kSuccess;
}

>>I don't know how helpful this is, but thanks for anything you might spot
>>that I have not.
>>
>>
>
>Unfortunately I doubt I have been very helpful. Have you had any luck
>on the MEL forums?
>
>

Thanks for your help. I have had some feedback on the HighEnd 3D Maya
API forum which suggests that you shouldn't use smart pointers:

    "Well inside your plugin your free to use memory as you wish.
However the fundamental rule about maya api is that *maya owns
everything and you own none of it*."

and

    "[I]n general when you program with maya you don't store pointers at
all, you just ask for a handle to a mdatablock which returns you a
usable data handle which acts as a temporary pointer to your data. You
then flush the pointer and ask it again when you come to next cycle of
compute. This si akin to using smart pointers, maya just calls them
datahandles.

    "(remember you have no data at all you have just pointers that point
int a space that does not stay constant)

    "However the smart pointers dont really work like you expect, you do
need to unallocated them when you no longer use them, they will
offcourse in normal apps get terminated on exit and if you run the same
strand of code later thet will do flush eventually. But maya wont, it
just terminates al code that the smart pointers are using for possible
cleanup.

    "So basically you never really get to allocate memory anyway, maya
does it for you and incidentally frees it for you too. As long as you
use a data block as your intended. (if you don't then maya wont save the
info).

So it looks like these datablocks are the way to go. I'll have a look at
using those.

One of my colleagues is using Boost in his Maya plug-in. Currently it is
crashing in Linux too, but that might be for a different reason.

Thanks for your help - it looks like I might have found the answer now,
namely, "don't use smart pointers in Maya; use datablocks instead".


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net