Warp wrote:
>   With this I mean that with the memcpy() you are not accessing the private
> members any more than you are with "a = b;".

I would disagree for the following reason:

Altho {a = b;} *might* do the same thing as memcpy(), the author of the 
class has the ability to make it do something different, or to declare 
operator= to be private, preventing it altogether.

memcpy() can not be "defended against" in that sense.

"Can I change the values of private variables without invoking a class 
method or friend function?"  "Yes."  I'd say that's breaking modularity.

I think at this point we each understand what the other is saying, and now 
we're just having an argument about whether to call it "really" unmodular or 
only "kinda" unmodular. :-)

> They are both copying the
> state of the entire object to another instance. You could say that with
> memcpy() you still don't know *what* you are copying (what type of members,
> how they are padded inside the class, etc), only that you are copying
> everything verbatim.

Note, too, that even in this case, if you change your pixel example to be 
HSV instead of RGB, the memcpy() approach still works for moving pixels 
around. :-)

>   The difference, and what makes the memcpy() version non-modular, is that
> the memcpy() version bypasses the normal class assignment semantics and
> instead goes to the "raw hardware level". If the class would need a more
> complex copying semantics than a bit-by-bit copy, then the copy is broken.

Sure. I'm just arguing that the ability to use memcpy() *is* non-modular. 
The fact that it breaks or is non-portable in some cases would not seem to 
counter that fact. It would just seem to say "it's a bad way of doing 
things." :-) Which we both agree with.

>   I understand your argument to be that memcpy() could be used in this
> way to *access* the private members of the object. However, it can't,
> not in a portable way anyways, because you still can't know the internal
> structure the compiler has generated for the class, and you can't point
> to individual private elements.

Agreed. Not that it's difficult to figure out. I can think of at least 3 
easy ways to figure out where individual variables are: 1) use a debugger, 
2) look at the generated asm code, 3) stick a friend function into the 
header that returns the offset of the private instance. None of those are 
particularly portable, except the last, assuming that adding a friend 
function declaration doesn't rearrange the actual structure members.

I agree it's a concern in CLOS that someone will read your source code and 
access the internals of your class by learning the names of private 
variables and then you'll have to support it. I also contend it's about the 
same level of concern that someone will look at your header file, see it's 
POD, and write code that uses memcpy() to move POD-structs around (perhaps 
to different address spaces or into files or something), and you'll wind up 
having to support that.  Neither is really common enough to worry about, and 
both are trivial to avoid if you can change the module you're talking about 
or avoid the need to do that altogether in the caller.

>   Perhaps this could be compared to calling the CopyFile() function of
> the Windows API: Even though it copies the entire contents of a file to
> another file, I'm still not *accessing* the contents of the file with
> that function in my program. I'm just telling the system to copy it.

Sure. And my comparison would be that "Anything you can call CopyFile() on, 
you can open and read and write, possibly messing up the program that uses 
the file, or possibly for the purpose of bypassing DRM."

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message