Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...)

Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...)

[Magnus Kempe]

Taft showed how a package allows one to encapsulate _several_ types
and their operations, providing such natural and efficient notations
as "A := 2 + 3 * i;" ("A" is of type Complex and "i" is of type
Imaginary; "+" and "*" are the operations).

The crux of Taft's example is that Ada allows one to declare
_several_ types _together_ and thus be able to easily provide
an efficient subprogram operating on _several_ objects of
_different_ types.  All this can be achieved within a package
with the safety provided by private types (since no one else is
allowed to proclaim itself so "friendly" as to see the private
parts of your package...).

To achieve this, operators would have to be "friends" in C++,
because of its equation "module = class"; however, the problem
with such an approach is that _anyone_ can then claim to be a
"friend", and therefore _anyone_ can break the abstraction of
the class.

C++ "friends" break the encapsulation and its equation becomes
an approximation: "a class with friends is almost a module".


wicklund@intellistor.com (Tom Wicklund) answered Taft with
an irrelevant example:
: 
: I suggest you look at the GNU g++ library implementation of complex,
: which I summarize below.  Note that there are NO friend functions.

Of course, there are no friends in your C++ code (not repeated here),
since the C++ class you included does _not_ propose _two_ types
and operations working on objects of both types.  (BTW, I'd rather
see a discussion of principles with approriate examples; pouring
hundreds of lines of C++ code in comp.lang.ada is uninteresting.
Thank you.)


To summarize, the crucial concepts involved are the following: we want
a natural notation to declare several types and associated, efficient
subprograms operating on several parameters of different types, and we
want all this while preserving the abstraction in its encapsulation and
type safety.  Ada satisfies such software engineering requirements, and
Ada 9X will soon provide still more programming power to satisfy still
more software engineering requirements.  (How great!)

-- 
Magnus Kempe                "No nation was ever drunk when wine was cheap."
magnus@lglsun.epfl.ch                                   -- Thomas Jefferson

Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...)

[Dag Bruck]

In <comp.lang.ada> magnus@lglsun.epfl.ch (Magnus Kempe) writes:
>
>To achieve this, operators would have to be "friends" in C++,
>because of its equation "module = class"; however, the problem
>with such an approach is that _anyone_ can then claim to be a
>"friend", and therefore _anyone_ can break the abstraction of
>the class.

This is incorrect.

A class grants friendship to other functions or classes, which means
that the author of a class controls who gets access to the private
members of the class.  You cannot grant yourself access to any random
class.

			-- Dag Bruck

Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...)

[Magnus Kempe]

dag@control.lth.se (Dag Bruck) writes:
: A [C++] class grants friendship to other functions or classes, which means
: that the author of a class controls who gets access to the private
: members of the class.  You cannot grant yourself access to any random
: class.

If your class Foo grants "friendship" to a function/class Bar, _anyone_
can write such a function/class and, having granted itself "friendliness",
will have access to the internals of Foo.

To repeat: contrary to Ada, C++ does not provide a safe means to create
subprograms acting on parameters of two or more types (classes).  In
C++, either you write an unsafe class because the language lacks the
concept of a module, or you twist around with .h files and say good-bye
to limited, separate recompilations.

-- 
Magnus Kempe                "No nation was ever drunk when wine was cheap."
magnus@lglsun.epfl.ch                                   -- Thomas Jefferson

Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...)

[Dag Bruck]

In <comp.lang.ada> magnus@lglsun.epfl.ch (Magnus Kempe) writes:
>dag@control.lth.se (Dag Bruck) writes:
>: A [C++] class grants friendship to other functions or classes, which means
>: that the author of a class controls who gets access to the private
>: members of the class.  You cannot grant yourself access to any random
>: class.
>
>If your class Foo grants "friendship" to a function/class Bar, _anyone_
>can write such a function/class and, having granted itself "friendliness",
>will have access to the internals of Foo.

If we assume that the author of a class also writes the
classes/functions he/she grants friendship, the "one definition rule"
prohibits you from writing a second function or class with the same
name.

The alternative, that the author grants friendship without actually
writing the friend classes/functions, seems highly unlikely.

If you manipulate library files, for example, replace standard
functions with functions you have written yourself, then you can of
course get access to anything.  You may also patch the symboltable or
the objectcode itself.  However, I doubt that Ada is safer in this
respect.

There is a much simpler way to break encapsulation (and I'm sure
Magnus Kempe wants to hear it): write a your own class with the same
contents and copy the bits from the protected object to a look-alike
object with standard C function "memcpy".

I doubt that "unsafe" features of this nature is of any real interest.
Can anyone give a plausible example?


			-- Dag

Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...)

[John Goodsen]

magnus@lglsun.epfl.ch (Magnus Kempe) writes:
>
>If your class Foo grants "friendship" to a function/class Bar, _anyone_
>can write such a function/class and, having granted itself "friendliness",
>will have access to the internals of Foo.
>
Oh my!  And shame, shame, shame on you for even thinking imitating
my "BAR".  This argument is remeniscent of the facist arguments which
have the common theme of "you might use it wrong, therefore I want
to keep you from using it at all".  BTW, you won't get too far in
the link stage with both "BAR"s in the system (multiply defined identifiers
and such..)

>
>To repeat: contrary to Ada, C++ does not provide a safe means to create
>subprograms acting on parameters of two or more types (classes).  In
>C++, either you write an unsafe class because the language lacks the
>concept of a module, or you twist around with .h files and say good-bye
>to limited, separate recompilations.
>

"UNSAFE CLASS" ???
Huh?  Come now!  "friendship" is not necessarily unsafe.  Only if you use
it wrong.  True, Ada packaging and "classtypes" (I refuse to use
tagged type syntax anymore ;-) overcome this *perceived* defect
in C++, but to *twist* the truth in suggesting that you lose separate
recompilations is not responsible.  In fact to the contrary, the *friend*
concept allows for separate recompilation of these related classes
and functions.  Ada packages *REQUIRE* recompilation of all related 
"classtypes" (there it is again, isn't it a pretty syntax ;-), since they're
in the same package.  


-- 
John Goodsen
Software Process & Environments
EVB Software Engineering
jgg@evb.com