You are right Jo, I mentioned the wrong prototype, what I wanted to
quote was the Copy Constructor and the assignment operator. Sorry
about the confusion. I clicked on the wrong link. Of course what
Nicolas was using was a copy constructor, since both the class
methods one after another in the docs, I copy-pasted in haste the
wrong one. Anyways, yes Nicolas what you are saying is true
regarding the unexpected behavior.
>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.
That is exactly what is happening here for sure, I concur.
Maybe the new dev team could explain this better for the benefit of
all the developers as this could seriously cause big time debugging
headaches. Thanks for finding this out Nicolas !
On 4/30/2012 8:03 PM, jo benayoun wrote:
in this case,
"""
CRefArray a1;
a1.Add(CRef());
a1.Add(CRef());
CRefArray a2(a1);
a2.Add(CRef());
"""
The copy constructor is invoked and is not the one you mentioned
Alok but this one "CRefArray(const CRefArray &other)" which
have different behaviors and purposes than the overloaded
assignment operator.
"""Copy
constructor is called every time a copy of an object is
made. When you pass an object by value, either into a function
or as a function's return value, a temporary copy of that object
is made.
Assignment
operator is called whenever you assign to an object.
Assignment operator must check to see if the right-hand side
of the assignment operator is the object itself. It executes
only the two sides are not equal
"""
Referring to the docs : "Constructs a
CRefArray object from another
CRefArray object." which is the expected behavior.
For completeness, the copy constructor in the case of an array, a
string, a ptr or whatever container has a main purpose to "pass"
an implicit shared memory block to save memory specially in
the case of "passing arguments by value". A deep copy is done only
at the first call of a method non-const which should create a
brand new underlying object (concept called copy-on-write).
In this case, it seems its not what happens ... which is a bug in
all case unless its a wanted behavior and it should be specified
in the doc !
A more comprehensible example is the python "list" example:
doing an assignment "mylist = myotherlist" creates a shallow copy
and returns the "myotherlist" object to the mylist which is not
the case of calling the ctor directly with "mylist =
list(myotherlist)". That's a behavior that could be implemented
here.
"""
mylist = [1, 2]
print mylist
myotherlist = mylist
mylist.append(6)
print mylist
print myotherlist
myoolist = list(mylist)
mylist.append(9)
print mylist
print myotherlist
print myoolist
"""
"Set
(const CValueArray
&in_valarray)"
I dont see any overloaded cast method nor ctors for a CRefArray to
CValueArray. Even if there was, it would mean that your
CValueArray have to be built from a CRefArray before being passed
by reference. Which is an overhead instead of using the copy ctor.
"const" is a keyword that we use to assure to the compiler, we
will not try to modify the underlying memory block nor call any
procedures that could do this. Of course, the compiler takes this
as serious and do optimizations in consequences which is a good
thing for us.
jo
2012/4/30 piotrek marczak <piotrek.marc...@gmail.com>
Maybe a2.Set(a1) or a2+=a1 would work?
newbie question
isn’t “const” keyword a hint that we won’t change
input array?
Sent: Tuesday, May 01, 2012 1:31 AM
Subject: Re: CRefArray doesn't respect
C++ copy semantics
The
docs say that:
Assigns a CRefArray object to this
one.
- Parameters:
-
- 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 <alok.gan...@modusfx.com>
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.
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.
|
