Darren New <dne### [at] sanrrcom> wrote:
> >> Or just using compiler-specific hackage to access the variables. 
> > 
> >   That has been made rather difficult in practice.

> Err, has it? I can't say something like
>    int * p = (int*) ((void*)(&yourInstance) + 32);
> if I want access to whatever integer is 32 past the start of your class?

  You call that "easy"? To me it looks like garbage. You can't write code
like that by mistake. You are deliberately writing non-standard code which
triggers undefined behavior. You are not accessing a member variable, you
are trashing memory.

  Let's talk about *standard-conforming* C++.

> > If you are *intentionally*
> > trying to break your program, then that's your choice, of course. However,
> > in normal usage it's useful if the compiler checks that you don't make
> > mistakes.

> While I agree, I fail to see why using reflection as intended isn't "normal 
> usage" and not "a mistake". It's not something you accidentally do. You know 
> very well you're bypassing encapsulation. Not the least of which is that you 
> need to give the name of the variable you want to access as a string.

  Well, if you want to intentionally break the modularity of your code with
something like reflection, at the risk of breaking tons of code in the future,
that's your choice.

  (If you use reflection to, for example, save the state of an object to
a database to be retrieved later, haven't you kind of locked up the
structure of that object? You can't make *any* changes whatsoever to it
without breaking all the stored objects in the database. Doesn't sound
very enhanceable to me.)

> >   Whether your program will link after that can depend on the compiler.
> > It's certainly not standard-conforming. And again, you are hacking on
> > purpose, trying to bypass the compiler checks, rather than using those
> > checks to catch your mistakes.

> Right. Since you said reflection violates encapsulation hard enough to make 
> a program not "OO", I'm trying to figure out allowing type casts and 
> assignment of arbitrary memory addresses to pointers doesn't.

  If you trash memory, you are writing non-portable, non-standard-conforming
code. All bets are off. If you want to write code like that, you might as
well not use classes at all. What's the point?

> If the statement is "the compiler should error out on external access to 
> private variables, but there should be a non-portable hacky and error-prone 
> way to bypass it anyway, so you can't rely in your debugging efforts on what 
> your code actually says," I'll just have to disagree with you there. :-)

  Where have I said "there should be a non-portable way to bypass it"?

  There may be a non-portable way of bypassing it. That's different from
"there should be".

-- 
                                                          - Warp

Post a reply to this message