POV-Ray : Newsgroups : povray.off-topic : This is the sort of brokenness... : Re: This is the sort of brokenness... Server Time
6 Sep 2024 11:20:01 EDT (-0400)
  Re: This is the sort of brokenness...  
From: Warp
Date: 21 Mar 2009 12:14:20
Message: <49c5125c@news.povray.org>
Darren New <dne### [at] sanrrcom> wrote:
> In any case, yes, you're breaking modularity. That's what we're saying, yes? 
> Accessing private variables without the permission of the class breaks 
> modularity?  Accessing private variables by address in a 
> standards-conforming way breaks modularity. Given that you're agreeing with 
> me, I'm not sure what the "however" in your sentence is supposed to imply.

  The breaking of modularity in this case has little to do with accessing
private members, and more to do with bypassing the normal copy constructor
or assignment operator semantics through reinterpret-casting pointers.

  "a = b;" and "memcpy(&a, &b, sizeof(a));" might in fact produce almost,
if not exactly identical machine code by the compiler, if the class in
question only has scalar types as members (and doesn't define an assignment
operator the compiler cannot see at this point). Thus at machine code
level the two expressions might in fact be completely identical.

  With this I mean that with the memcpy() you are not accessing the private
members any more than you are with "a = b;". 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.

  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.

  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.

  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.

-- 
                                                          - Warp


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.