Its a design decision to avoid the use of pointers in the API. I understand it's restricting the use of stl at some point but you can probably use CRef in your container declaration instead.
e.g. std::vector< CRef > -mab ________________________________ From: [email protected] [[email protected]] on behalf of Chris Chia Sent: Thursday, May 03, 2012 5:16 AM To: [email protected] Subject: RE: Why is Material::operator& private? Hi Nicolas, If I were you, I will have a super class which extends the Material so that I will always maintain the integrity of Material itself. I am not sure whether my approach is the standard way. But I won’t use your method of wrapping the material with another class. Let’s hear from others what they will do. Regards, Chris Chia QA Analyst / ICE, FaceRobot and General Specialist, Autodesk Media and Entertainment From: [email protected] [mailto:[email protected]] On Behalf Of Nicolas Burtnyk Sent: Thursday, May 03, 2012 8:10 AM To: [email protected] Subject: Why is Material::operator& private? Hey guys, I'm wondering if anyone here knows why Material's operator& is private. This is preventing me from doing something like this: struct Material_less { bool operator() (const Material& lhs, const Material& rhs) const { return lhs.GetObjectID() < rhs.GetObjectID(); } } void SortMyMaterialsByObjectId(std::vector<Material>& materials) { std::sort( materials.begin(), materials.end(), Material_less() ); } I can get around this by wrapping Material inside a struct like so: struct _Material { explicit _Material(const CRef& rhs) : m(rhs) { } Material m; }; and modifying the code above to use _Material instead of Material, but I'm worried that there's a good reason not to take the address of a Material. Anyone know such a reason? Thanks, -Nicolas
<<attachment: winmail.dat>>
