In article <790640862snz@thone.demon.co.uk> andys@thone.demon.co.uk writes:
>In article <1995Jan13.155558.4483@rcmcon.com>
>           rmartin@rcmcon.com "Robert Martin" writes:
>
>[snip]
>>
>> Friendship cannot be stolen, only given. Its use is
>> to expose privates to a priviledged few, so that those privates do not
>> have to exposed to the world.
>>
>how about:
>
>"x.h"
>class X {
>   static int si_XVal;
>   friend void TheFriend();
>};
>
>"file1.cpp"
>static void TheFriend();
>#include "x.h"
>
>static void TheFriend()
>{
> si_XVal = 0;
>}
>
>"file2.cpp"
>static void TheFriend();
>#include "x.h"

 Undiagnosed violation of the One Definition Rule.
A non-local class name has two inequivalent definitions
(there are _two_ functions "TheFriend", so the class
definitions in file1.cpp and file2.cpp are not equivalent)

 BTW: don't look for the rule in the ARM or WP.
It is in my paper on the ODR, which has not yet been
considered by the committee.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <1995Jan13.155558.4483@rcmcon.com>
           rmartin@rcmcon.com "Robert Martin" writes:

[snip]
>
> Friendship cannot be stolen, only given. Its use is
> to expose privates to a priviledged few, so that those privates do not
> have to exposed to the world.
>
how about:

"x.h"
class X {
   static int si_XVal;
   friend void TheFriend();
};

"file1.cpp"
static void TheFriend();
#include "x.h"

static void TheFriend()
{
 si_XVal = 0;
}

"file2.cpp"
static void TheFriend();
#include "x.h"

static void TheFriend()
{
 si_XVal = 1;
}

 Someone has stolen the friendship there!

An even more worrying case (depending more on your linker than anything else)
is that if TheFriend lies in a external library, the following is possible:

"example.cpp"
#include "x.h"

void TheFriend()
{
  // Do what ya want in here!
}

May linkers would not attempt to resolve TheFriend in external libraries in
this case....

Regards,
 Andy
--
* Andy Sawyer ** e-mail:andys@thone.demon.co.uk ** Compu$erve:100432,1713 **
 The opinions expressed above are my own, but you are granted the right to
 use and freely distribute them. I accept no responsibility for any injury,
 harm or damage arising from their use.                --   The Management.

andys@thone.demon.co.uk (Andy Sawyer) writes:

>In article <1995Jan13.155558.4483@rcmcon.com>
>           rmartin@rcmcon.com "Robert Martin" writes:

>[snip]
>>
>> Friendship cannot be stolen, only given. Its use is
>> to expose privates to a priviledged few, so that those privates do not
>> have to exposed to the world.
>>
>how about:

>"x.h"
>class X {
>   static int si_XVal;
>   friend void TheFriend();
>};

[ code omitted showing different static functions called "TheFriend"
  in different translation units ]


The friend decl says there is one function. The program violates
the One-Definition Rule by providing different definitions. This
is an error which the compiler is not required to diagnose. The
program behavior is undefined.


>An even more worrying case (depending more on your linker than anything else)
>is that if TheFriend lies in a external library, the following is possible:

>"example.cpp"
>#include "x.h"

>void TheFriend()
>{
>  // Do what ya want in here!
>}

You can "hijack" any function this way, friend or not. It doesn't
violate any language rule. The declaration says there is one
function with a specified name and type. You provide one function
definition with that name and type. That satisfies the language
rules. If some other function with the same name and type exists
somewhere else in the world, that is not a C++ language issue,
as long as it doesn't get included in this program. (Then it
becomes a violation of the One-Definition Rule.)

The language rules do not specify how to build a program from
different translation units, or where to find external functions.

If as a library provider you wish to prevent hijacking, there
are various things you can do, from using hidden validation code
to putting the entire library in one object module. This is
all outside the C++ language definition.
--
Steve Clamage, stephen.clamage@eng.sun.com

I'm currently making the transition from C to C++ and I understand the
basics of classes but need help with some specifics.
Here's what I'm trying to do:
 I have a Matrix Class and a Vector Class

class Vector
{
 private:
  long pt[3];
 public:
  ReadVector();
  etc..
}

class Matrix
{
 private:
  long m[12];
 public:
  Matrix(); //default constructor
  Matrix(Vector rot,Vector trn);
  etc..
}

Matrix::Matrix(Vector rot,Vector trn)
{
 long cY = cAngles[rot[0]];
 long sY = sAngles[rot[0]];
 etc..
}

Obviously the problem is that the Matrix class tries to access the Vector
classes private members and this is illegal.

What I would like to know is what is the best way to make things like
this work. I know I could use friend functions but I am not to crazy
about friend functions because they seem to be a way to sidestep OOP
principles. I also don't like the idea of writing a function that
within the method class that simply returns an element of that class
because I'll be using these functions for 3d graphics where speed is
critical and this extra step seems to be inefficient. Should I just
make the Vector class a struct instead or is there a good way to do
this with classes.

Thanks John.


--
----------------------------------------------------------------------------
John Busfield
Reality Bytes Inc.
busfield@hurricane.ucla.edu

busfield@typhoon.seas.ucla.edu (John D. Busfield) writes:

>I'm currently making the transition from C to C++ and I understand the
>basics of classes but need help with some specifics.
>Here's what I'm trying to do:
> I have a Matrix Class and a Vector Class

>class Vector
>{
> private:
>  long pt[3];
> public:
>  ReadVector();
>  etc..
>}

>class Matrix
>{
> private:
>  long m[12];
> public:
>  Matrix(); //default constructor
>  Matrix(Vector rot,Vector trn);
>  etc..
>}

>Matrix::Matrix(Vector rot,Vector trn)
>{
> long cY = cAngles[rot[0]];
> long sY = sAngles[rot[0]];
> etc..
>}

>Obviously the problem is that the Matrix class tries to access the Vector
>classes private members and this is illegal.

>What I would like to know is what is the best way to make things like
>this work. I know I could use friend functions but I am not to crazy
>about friend functions because they seem to be a way to sidestep OOP
>principles. I also don't like the idea of writing a function that
>within the method class that simply returns an element of that class
>because I'll be using these functions for 3d graphics where speed is
>critical and this extra step seems to be inefficient. Should I just
>make the Vector class a struct instead or is there a good way to do
>this with classes.

First, friends do not sidestep OOP.  A friend is an enhanced
collaboration.  Friendship cannot be stolen, only given.  Its use is
to expose privates to a priviledged few, so that those privates do not
have to exposed to the world.

Second, if you use inline functions, you need not worry about the
overhead simply returning an element of a class.  There will be no
function call overhead.


--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++