The docs use the term "assign" because that's the C++ assignment operator. Assigning value types is not supposed to create a reference.
Simplest example is: int a = 0; int b = a; a = 1; At this point, b is obviously still 0 even though you "assigned" a to it. Or a better example: std::vector<CRef> a1; a1.push_back(CRef()); a1.push_back(CRef()); std::vector<CRef> a2(a1); a2.push_back(CRef()); size_t n1 = a1.size(); //n1 == 2 size_t n2 = a2.size(); //n2 == 3 The problem is they're treating CRefArray like it's a reference to an array of CRefs rather than just a straight-up array of CRefs. I would expect that behavior if a2 was a reference to a CRefArray, e.g. CRefArray a1; a1.Add(CRef()); a1.Add(CRef()); CRefArray*&* a2(a1); a2.Add(CRef()); Now a1.GetCount() == a2.GetCount() makes sense. It gets even more evil if you do this: CRefArray a1; a1.Add(CRef()); a1.Add(CRef()); const CRefArray a2(a1); a1.Add(CRef()); Even though a2 is declared const, the last line doesn't respect its constness (or at least the constness I expected). On Mon, Apr 30, 2012 at 4:41 PM, piotrek marczak <[email protected]>wrote: > Maybe a2.Set(a1) or a2+=a1 would work? > > newbie question > isn’t “const” keyword a hint that we won’t change input array? > *From:* Alok Gandhi <[email protected]> > *Sent:* Tuesday, May 01, 2012 1:31 AM > *To:* [email protected] > *Subject:* Re: CRefArray doesn't respect C++ copy semantics > > The docs say that: > > > CRefArray<http://download.autodesk.com/global/docs/softimage2012/en_us/sdkguide/si_cpp/classXSI_1_1CRefArray.html>& > operator= ( const > CRefArray<http://download.autodesk.com/global/docs/softimage2012/en_us/sdkguide/si_cpp/classXSI_1_1CRefArray.html>& > *in_refArray* ) > > *Assigns* a > CRefArray<http://download.autodesk.com/global/docs/softimage2012/en_us/sdkguide/si_cpp/classXSI_1_1CRefArray.html>object > to this one. > *Parameters:* in_refArray A constant > CRefArray<http://download.autodesk.com/global/docs/softimage2012/en_us/sdkguide/si_cpp/classXSI_1_1CRefArray.html>object. > *Returns:* A new reference object. > > So what I think is happening is that the copy constructor is doing exactly > what it is supposed to do and returns the new CRefArray object which still > points to a1, 'assigns' is the operative word here. To keep them separate I > would rather do: > > > CRefArray a1; > a1.Add(CRef()); > a1.Add(CRef()); > CRefArray a2; > > for(int i=0; i<a1.GetCount(); i++) > { > a2.Add(a1[i]); > } > > a2.Add(CRef()); > > //a2.Add(CRef()); > LONG n1 = a1.GetCount(); // expected n1 == 2 > LONG n2 = a2.GetCount(); // expected n2 == 3 > > which gives me correctly: > > # VERBOSE : cRefArrayTest_Execute called > # VERBOSE : Count a1: 2 > # VERBOSE : Count a2: 3 > > > > On 4/30/2012 7:13 PM, Nicolas Burtnyk wrote: > > Yeah, exactly as I unfortunately discovered :( > > On Mon, Apr 30, 2012 at 3:49 PM, Alok Gandhi <[email protected]>wrote: > >> A quick test gives me following result: >> >> # VERBOSE : cRefArrayTest_Execute called >> # VERBOSE : Count a1: 3 >> # VERBOSE : Count a2: 3 >> >> >> On 4/30/2012 6:24 PM, Nicolas Burtnyk wrote: >> >> I ran into this today while trying to figure out why my code was >> broken. >> Thought I'd pass this along and hopefully save someone some wasted time >> in the future... >> >> CRefArray a1; >> a1.Add(CRef()); >> a1.Add(CRef()); >> CRefArray a2(a1); >> a2.Add(CRef()); >> LONG n1 = a1.GetCount(); // expected n1 == 2 >> LONG n2 = a2.GetCount(); // expected n2 == 3 >> >> I expected a2 to be a copy of a1 before the last add and so I assumed a1 >> would have 2 elements. >> Instead, I was surprised to find that n1 == n2 == 3! >> >> >> >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2012.0.1831 / Virus Database: 2090/4557 - Release Date: 10/17/11 >> Internal Virus Database is out of date. >> >> > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1831 / Virus Database: 2090/4557 - Release Date: 10/17/11 > Internal Virus Database is out of date. > >
