3D Modeling

[emilio_c]

Hi,

In one of our custom attributes (derived from ATTRIB) we have a data member which is a std::list. I'm experiencing crashes and runtime errors when accessing the the list after a rollback has been done.

After debugging I realized that during the rollback mechanism the attribute is not restored to its previous state using the copy assignement, but using a plain memcpy() operation in BULLETIN::swap(...). This might break any complex data member within an attribute, such as a std::list member. The most common runtime error I get is "list iterators incompatible" when I access the attribute's list member.

Is the rollback supposed to copy plain memory?

If yes, is there a way to do my own swapping instead of BULLETIN::swap()?

We are using VS 2010 and ACIS R21SP2.

Thanks,

emilio

[asdf]

Dear Emilio

Certain ACIS operations (e.g., tolerizing edges and vertices) can delete ENTITY's and replace them with others.  If you std::list contains pointers to entites, this could cause trouble for you.  You may want to consider using SPACOLLECTION (please see http://doc.spatial.com/index.php/SPACOLLECTION for a detailed discussion) to store your pointers of ENTITY objects instead: a SPACOLLECTION is notified when any of its members are modified or deleted, so the pointers can be updated.  We do this to make sure the pointers do not go stale.

If the list contains pointers to things which are not entities, (e.g., lower case curves and surfaces) you may need to consider a more detailed attribute.  

Alternatively, if the pointers on the list are related to the object the attribute is attached to, you may be able to use notifications (implemented by virtual methods of attribute) to notify you when something has changed, so that you can update the list yourself.

best regards

Eric Zenk

[emilio_c]

Hi Eric,

Thanks for your reply.

I've replaced the std::list member in our attribute by a pointer to it. This seems to solve the problem.

I still don't fully understand, how ACIS restores attributes to a different state in the history stream, until now I've always assumed that a copy was performed using the copy assignment. But according to my debugger the memory of the attribute is overwritten using a memcpy.

Is it right to assume then, that it is not safe to have complex class members in attributes, but one should rather use pointers?

Emilio