Darren New wrote:
> No. Making it safe and not making everything public and not needing naming
> conventions is best. That's what CLOS does, modulo reading the source and
> invoking interpreter-internal routines with the names of private
> variables. That's what C# does, modulo the reflection libraries. That's
> what C++ does, modulo using pointers and UB.

That's not a good comparison.

C# has a way to access private data through reflection. Python has a way to
access private data by just doing it (but you'll know you're doing it
because there is an underscore).

C++ has no way to access private data. If you say pointers and UB are
a "valid" way to access private data, then I'd say attaching a debugger to
the .NET virtual machine and poking at its memory is a valid way too.

Post a reply to this message

Warp wrote:
>   It breaks modularity badly. The whole idea of data hiding is that the
> private part should be completely opaque to the outside. The second it
> isn't, outside code will start making assumptions, and you can't change
> the implementation of the class anymore.

You CAN change the implementation of the class. It's not your problem if you
break code that made assumptions.

Post a reply to this message

Nicolas Alvarez wrote:
> Darren New wrote:
>> No. Making it safe and not making everything public and not needing naming
>> conventions is best. That's what CLOS does, modulo reading the source and
>> invoking interpreter-internal routines with the names of private
>> variables. That's what C# does, modulo the reflection libraries. That's
>> what C++ does, modulo using pointers and UB.
> 
> That's not a good comparison.
> 
> C# has a way to access private data through reflection. Python has a way to
> access private data by just doing it (but you'll know you're doing it
> because there is an underscore).
> 
> C++ has no way to access private data.

memcpy. Check the standard under 3.9. It's therein defined how you can 
access and modify the private data of a class in C++ (and in a 
standards-conforming way if it's POD). Consider the case of "class alpha 
{int abc;}" for a counter-example - I know exactly how that's laid out due 
to the standard. It's perfectly standard-conforming to pass a pointer to an 
instance of class alpha to both memcpy and memset.

In any case, C++ *DOES* in *practice* have a way to access private data, 
even without that, because it's not safe. It's not clean and portable, but 
if there wasn't any way to access private data, we'd have far fewer sigsegv's.

I guess there's two ways you could argue it:
1) C++ in theory disallows access to private variables but in practice every 
known implementation allows it, because it's actually virtually impossible 
to follow the rules of the standard while disallowing said access.
2) LISP in theory allows access to private variables even though it's 
impossible to do by accident and you have to read the source for the 
implementation of the class (which you might not have) to learn the 
variables. (Actually, has anyone checked whether the Common Lisp standard 
actually guarantees you'll be able to get to private variables, or is that 
just the current implementations?)

Sure, in theory, great.

In practice, nobody uses a C++ compiler that prevents access (intentional or 
otherwise) to private variables, and in practice, nobody uses private 
variables of a class that haven't been exported except as a last resort.

Since we're talking about practical benefits (like being able to modify 
code), I was taking the latter approach.

In any case, even if we took reflection out of C# and Java, it's still 
possible to declare unsafe pointers in C# and "native code" in Java that can 
change private variables in a more-or-less well-defined way. Except you're 
now doing it exactly the same way as C++ would, except for the fact that 
again you've flagged your source code as "hey, I'm doing this on purpose". 
I'm not sure how that should "count".

-- 
   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

Warp wrote:
>   You always succeed in returning to your favorite subject: Bashing
> "unsafe" languages. And in your world there's only one such language: C++.

You know something?  It's getting "really tiresome and old" that every time 
I list problems with 5 or 6 different languages, you think I'm bashing on 
C++. It's getting "really tiresome and old" that every time I point out 
something that Windows does well, I'm told I'm bashing on Linux. It's 
getting "really tiresome and old" that every time I point out problems with 
unsafe languages in general, you think I'm bashing solely on C++. It's 
getting "really tiresome and old" that every time I talk about automatic 
resource management you think I'm bashing C++. It's getting "really tiresome 
and old" that most times you tell me I'm ignorant and I ask you for more 
information, you ignore that request, preferring just to insult me rather 
than actually provide information that might improve the conversation.

I think I've expressed my point of view, and I think you all understand what 
I'm saying but for some reason feel the need defend C++ instead of 
discussing the pros and cons rationally and conversationally. I can't add 
any further information by pursuing this conversation, altho I've left 
several questions open in various posts that could be productively answered.

-- 
   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

Darren New <dne### [at] sanrrcom> wrote:
> Consider the case of "class alpha 
> {int abc;}" for a counter-example - I know exactly how that's laid out due 
> to the standard.

  I don't think the standard specifies what kind of padding the compiler
will use between member elements.

  For example, if you have a "struct { char c; int i; };", how many bytes,
if at all, are there between 'c' and 'i'?
  Suppose you have "struct { int i; long l; };" in a 64-bit system. Will
the compiler put padding bytes between 'i' and 'l' or not?

  Suppose you have:

class A {};
class B: public A { int i; };

  sizeof(A) will be, per the C++ standard, at least 1. But what will be
sizeof(B), and consequently the offset of 'i' inside it? The standard
doesn't specify, and the compiler is free to optimize the empty base
class away or not, as it sees fit.

  Oh, and it becomes even more complicated:

class A { int i1; public: virtual ~A(); };
class B1: virtual public A { int i2; };
class B2: virtual public A { int i3; };
class C: public B1, public B2 { int i4; };

  Want to start guessing the offsets of the ints inside C? Good luck.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   You always succeed in returning to your favorite subject: Bashing
> > "unsafe" languages. And in your world there's only one such language: C++.

> You know something?  It's getting "really tiresome and old" that every time 
> I list problems with 5 or 6 different languages, you think I'm bashing on 
> C++.

  5 or 6 different languages? Really?

  You started by making a reference to "unsafe languages" within the subject
of modular programming as a reply to one of my posts (clearly as a reference
to C++), and later you said that C++ is the *only* unsafe OO language you
know of. After that you have been done nothing else than arguing why
modularity in C++ is broken and why Lisp, Java and C# are so great.

  It was certainly not me who brought up C++ into the conversation.

  Yeah, sure. You really have been pointing out problems in "5 or 6 different
languages", and I'm just being paranoid that you are concentrating a little
too much on C++.

> It's getting "really tiresome and old" that every time I point out 
> something that Windows does well, I'm told I'm bashing on Linux.

  Every time? When was the last time?

> It's 
> getting "really tiresome and old" that every time I point out problems with 
> unsafe languages in general, you think I'm bashing solely on C++.

  You explicitly wrote that C++ is the only unsafe OO language you know of.
You have been writing specifically about C++, not about "unsafe languages
in general".

> It's 
> getting "really tiresome and old" that every time I talk about automatic 
> resource management you think I'm bashing C++. It's getting "really tiresome 
> and old" that most times you tell me I'm ignorant and I ask you for more 
> information, you ignore that request, preferring just to insult me rather 
> than actually provide information that might improve the conversation.

  And it's getting really tiresome and old that you act all innocent after
a tirade of C++ bashing, saying that "I just wanted a serious discussion
and honestly wanted to know more", when it's rather clear that you didn't
really.

  It's also getting tiresome that every time I criticize some other language
you immediately assume I'm defending C++. For example, if I call some other
language "kludgey", you immediately assumed that I'm claiming that C++ is
not, even though I never said anything of the sorts. And of course you
immediately jumped to the opportunity of starting bashing.

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Warp wrote:
> >   It breaks modularity badly. The whole idea of data hiding is that the
> > private part should be completely opaque to the outside. The second it
> > isn't, outside code will start making assumptions, and you can't change
> > the implementation of the class anymore.

> You CAN change the implementation of the class. It's not your problem if you
> break code that made assumptions.

  I don't think that's a good programming principle.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> There are few other unsafe OOP languages I know enough about to discuss. Ada 
> and C++ are the only unsafe OOP languages I know

  Ok, here's a couple more:

- Objective-C. Regardless of the name, has nothing to do with C++.
- C#. Regardless of the name, has nothing to do with C++.

> >   The connection between my usage of the word "kludge" and your usage
> > of the words "unsafe" and "reflection" is purely your invention.

> OK. I was confused by the fact that your post had
> 1) A paragraph about how CLOS allows access to the private variables,
> 2) a comment about languages lacking data hiding aren't really OO,
> 3) a lack of specific support for hiding means the OO is kludgey.

  I still see no connection to "unsafe" languages and "reflection". Those
were your inventions.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >>>> I'm saying that C++ does not enforce that you don't change private instance 
> >>>> variables from outside the class.
> >>>   And this has exactly what to do with whether (compiler-enforced) data
> >>> hiding is a good thing or not?
> > 
> >> Because there's two reasons for data hiding: (1) allow more flexibility in 
> >> implementation, (2) allow easier debugging.
> > 
> >> If you can violate my encapsulation, I don't see the data as especially 
> >> encapsulated, is all.
> > 
> >   You didn't answer my question.

> You said the designs of C# and Java are badly broken because they let you 
> get to the private variables of an instance using reflection. You then said 
> C++ doesn't let you get to a private variable of an instance. I was 
> disputing that claim. That's what compiler-enforced data hiding has to do 
> with C++.

> >   "Is enforced data hiding a good thing or a bad thing?"
> >   "In C++ you can bypass the encapsulation, so it's a bad thing."

> You skipped a bunch of context in between that I thought still applied. 
> Maybe you're reading messages in a different order than I am. That's one of 
> the problems when a conversation really gets going online. :-)

> If you're not going to apply that context, see my other messages where I 
> explain the types of access and seem to be mostly in agreement with you.

> >>>   Every single discussion about programming with you turns into C++ bashing,
> >>> no matter what the subject.

> >> I'm happy to bash any other unsafe OO language you might want to name. :-)

> >   It's getting really tiresome and old.

> I didn't start out bashing C++ this time. We got pretty far until you 
> *seemed to* claim C++ was better at modularity than C# or Java or CLOS. I 
> merely listed C++ amongst a half-dozen languages I was criticizing for 
> different individual design choices.

  You are seriously claiming that when you wrote "like, in unsafe languages,
where a stray pointer can change private variables without going thru the
class methods? :-)" as a reply to my post you were not directly and
exclusively referencing C++, especially with that smiley?

  What other half-dozen "unsafe languages, where a stray pointer can change
private variables" were you talking about there?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Consider the case of "class alpha 
>> {int abc;}" for a counter-example - I know exactly how that's laid out due 
>> to the standard.
> 
>   I don't think the standard specifies what kind of padding the compiler
> will use between member elements.

It specifies that the first element has no padding before it.

>   For example, if you have a "struct { char c; int i; };", how many bytes,
> if at all, are there between 'c' and 'i'?

That's a different example, yes.  It's going to be compiler/architecture 
dependent.

>   Oh, and it becomes even more complicated:
> 
> class A { int i1; public: virtual ~A(); };
> class B1: virtual public A { int i2; };
> class B2: virtual public A { int i3; };
> class C: public B1, public B2 { int i4; };
> 
>   Want to start guessing the offsets of the ints inside C? Good luck.

I don't think the standard says what the offsets are for classes with 
virtual destructors.

-- 
   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