Thanks guys.
Chris - yeah deriving from CMaterial is another option which I guess is a
bit cleaner.
Anyway, I'll probably use CRef as Marc-Andre suggested. My only problem
with that is that if I want to sort by object ID, I need a predicate like
this:
struct ProjectItem_less
{
inline bool operator() (const CRef& lhs, const CRef& rhs) const
{
assert(lhs.IsA(siProjectItemID) && rhs.IsA(siProjectItemID));
return ProjectItem(lhs).GetObjectID() < ProjectItem(rhs).GetObjectID();
}
};
the on-the-fly construction of 2 ProjectItems to do the comparison is a lot
slower than if I had those ProjectItems (or Materials or whatever) already.
Slow is a relative term so let me be more specific - on my machine,
constructing 100 Materials from 100 CRefs and calling GetObjectID takes
about 0.16ms whereas simply calling GetObjectID on 100 Materials take only
about 0.001ms. Probably not a big deal :)
Thanks again Marc-Andre and Chris!
-Nicolas
On Thu, May 3, 2012 at 4:31 AM, Marc-Andre Belzile <
marc-andre.belz...@autodesk.com> wrote:
> 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: softimage-boun...@listproc.autodesk.com [
> softimage-boun...@listproc.autodesk.com] on behalf of Chris Chia
> Sent: Thursday, May 03, 2012 5:16 AM
> To: softimage@listproc.autodesk.com
> 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: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of Nicolas Burtnyk
> Sent: Thursday, May 03, 2012 8:10 AM
> To: softimage@listproc.autodesk.com
> 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
>
