Re: Creating a reference to an object
- From: "Doug Semler" <dougsemler@xxxxxxxxx>
- Date: Sun, 30 Sep 2007 10:34:41 -0400
"raylopez99" <raylopez99@xxxxxxxxx> makes me want to either laugh or cry by writing in message news:1191099377.292570.249180@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Sep 28, 1:51 pm, "Doug Semler" <dougsem...@xxxxxxxxx> wrote:>> > I think Clone is just shorthand for what is known as a "copy
>> > constructor" in C++.
>> Well, it's not. Clone is a specific reference to the Clone() method
>> found in the ICloneable interface.
> Analogy, not exact definition.
Not to hijack, but it's even a ban analogy. Clone means something
completely different than a copy constructor. Clone doesn't necessarily
have to return the type of object being cloned. Just a compatible type.
OK, but you're over my head here--I don't know what 'compatible type'
means. Perhaps an exception to the rule (that proves the rule).
No. Not it's not an exception. Two completely different paradigms. Clone loosens the restrictions on what is required to be returned. Since a constructor (copy or otherwise) doesn't "return" anything, it's always of the type being constructed.
Copy constructors are actually constructors of the specific object type.
You can't return a "compatible" type from a copy constructor....because the
constructor doesn't return anything.
OK, again, you're trying to make an exception (this 'compatible type'
business) into the general rule. Not good form, but I see your point
(that you found an exception).
No, I am not. You're making a general rule where there is none.
From the lurking i've done in this group in the past 3 years or so, I'm
probably one of maybe 2 people here that uses Clone() on a regular basis.
But that's because I have specific support requirements for it dealing with
revertability and serialization (don't look at me....i wans't the original
author <g>)
Perhaps. Or it could be that with tracking pointers (references) in
C#, you don't really need a copy constructor aka clone--you just pass
the pointer/ reference.
No. That would be very bad in the cases to which i am referring. I need copies of the object so that I can revert them back to the original form. I also need copies because in some cases the serialization routine is being completed asynchronously, but it the block it is accessing can be locked. It's faster to make a copy and work with that copy in a differnt thread than block the caller. When these copies are made I need them to follow specific rules as well.
You are NEVER cloning when you use new. In either C# or C++. You are
creating a new memory instance and calling the constructor. Now whether the
constructors have been declared to accept a parameter and copy data from the
parameter's instance is different story.
I think you're being too clever by half here. First you say "NEVER",
then you essentially acknowledge my point, that you clone using new
(and doing other things as well, but using new).
No, you don't clone using new. You are calling a specific constructor when you use new. But "new" in and of itself just allocates memory (well, ok, exception: placement new in C++<g>). It is the semantics of the constructor that is specified that actually does the work. However, C++ defines a specific constructor that is called in certain situations (called the "copy constructor"). By default, this basically does what the object.MemberwiseClone() does. However, I can explicitly create one and have it do NOTHING if I want it to.
>> > The only advantage in C# using :ICloneable is that the base
>> > class :ICloneable makes replicating a duplicate class (a clone) much
>> > easier
>> The advantage to ICloneable is that the object provides a defined
>> interface to clone itself. In many cases, this would be the _only_ >> way
>> to clone an object, as the user of the object has no direct access to
>> private members that also have to be cloned as part of the cloning
>> process.
Well, you could expose a function that retunrs the results of
MemberwiseClone(), but that only ever makes a shallow copy. Depending on
the requirements, a cloned copy may be required to be a deep copy. In
addition, there are certain situations where the object is managing
unmanaged memory...
I see that you pointed out a contradiction in Pete's post (the words
quoted with ">" are Pete's not mine)--good for you, as it shows Pete
is not like the Pope, infallible! :-) But again, seems like you're
taking a weird exception "Well, you could..." into a general rule.
After all, in fairness to Pete, Pete said "In MANY cases" (emphasis
added).
Take a chill pill...it was a JOKE.
There are four advantages to IClonable that i can think of. Nothing to do
with making it "easier" to actually copy the object. Zeroth is that it is a
well documented common framework interface that all .net programmers have
access to.
OK, I got that, thanks, it makes sense.
First is it allows you to override the behavior of
MemberwiseClone() to make deep copies of an object.
Uh, are you aware (I think not) that ICloneable can have TWO
variants? A shallow copy (MemberwiseClone) and a deep copy
([Serializable] then use BinaryFormatter()?). I take it you are, but
from your posts you seem to not understand this, unless I'm misreading
you, which may be the case.
What the hell are you talking about? There is no variance. MemberwiseClone() makes a shallow copy (for blittable members, they are bitwise copies, for references they are just the same reference). It returns an object of the type being cloned. IClonable leaves the implementation up to the object. It can return a shallow copy, a deep copy. The only other requirement is that the function returns a COMPATIBLE type of the object being cloned (which, in all cases that i can think of, is the type)
I don't know what you're talking about with the serialize/binaryformatter thing, unless you are saying that makes a deep copy. But try doing that trick on an object that's holding a pointer to unmanaged memory and see how well that works...
The second is to return
a object that is type compable rather than of the type itself.
Sorry but I don't understand what "type compable" is. Let's table
this one.
Let's not. Look it up, it's important. And let's not try to claim to be a C# MVP or otherwise until you know what this means.
The third is
when your objects are holding unmanaged references that have to be handled
in very specific (and sometimes very ODD) manners. I'm sure Jon and Pete
can and a couple others can think of other more esoteric reasons or even non
esoteric reasons...
ODD means nothing. Metaphysics.
Odd. Meaning not normal. Nothing metaphysical about it. Some of the code I have to deal with is translated from hardware microcode implementations, which means I end up having to deal with memory in very odd manners. And some of these objects are required to be cloneable (for reasons irrelevant to this discussion)
> Usually, but a lot of people don't use ICloneable and simply "do it by
> hand", the long way. That was my point.
Huh? Do what the long way? Copy the object? How can I make a complete
copy from outside the object without access to private fields?
From inside the object. WOrk with me Doug! :-)
Well, if I only wanted to do it from inside the object (shallow), I'd just call MemberwiseClone(). If i needed a deep copy I'd create a private member function. If I wanted to expose it to the outside world, I'd just implement the interface IClonable and exposed the already written functionality. Until I do that last part, the object is unclonable from the outside world (either shallow or deep).
Cloning of large objects is a PITA and error prone. I would ALWAYS provide
a "one stop" clone method of some sort if requirements of the object
dictate...and never leave it up to the user of the object.
That's nice. Makes sense, kind of like (analogy here) always using
error correction 'try/catch' everywhere.
No way, it's called code reuse. If I want the users of my object to be able to clone it, I'll give them that opportunity by implementing the IClonable interface. Otherwise, they can't. That doesn't stop me from writing a "one-stop-shop" that implements a private clone method.
(and i don't know what exactly your "analogy" means..)
--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?
.
- References:
- Creating a reference to an object
- From: mark . norgate
- Re: Creating a reference to an object
- From: Peter Duniho
- Re: Creating a reference to an object
- From: raylopez99
- Re: Creating a reference to an object
- From: Bill Butler
- Re: Creating a reference to an object
- From: raylopez99
- Re: Creating a reference to an object
- From: Peter Duniho
- Re: Creating a reference to an object
- From: raylopez99
- Re: Creating a reference to an object
- From: Doug Semler
- Re: Creating a reference to an object
- From: raylopez99
- Creating a reference to an object
- Prev by Date: Re: Preserve State
- Next by Date: Vista application
- Previous by thread: Re: Creating a reference to an object
- Next by thread: How Can I remove all row from a gridView
- Index(es):
Relevant Pages
|
