ReRef : Reseatable Reference

[JKop]

Having decided not to use macros at all in designing my reseatable
references, and having looked through the list of overloadable operators and
combinations of them, I've settled on the following syntax:

Reseat >> kref = moon;

Where "kref" is the reseatable reference and "moon" is the new object it'll
refer to.

Overall, once a reseatable reference has been defined, I want it to act
exactly as would a normal reference... but so far it doesn't seem like I'll
be able to achieve this, especially since I won't be able to access members
after the dot.

Anyway, to achieve the above syntax, I've declared a global object called
"Reseat" (sort of like "cout"). This "Reseat" global object is of type
"Reseat_Class". The "Reseat_Class" class has an operator>> defined which
returns by value an intialized object of type "RefReseater". The class
"RefReseater" is a friend of the "ReRef" and so has access to its "Reseat"
member function (not to be confused with the "Reseat" global object). The
"RefReseater" class has operator= defined which changes what's referred to.
Here's the code so far:

template<class T> class RefReseater;

template<class T>
class ReRef
{
private:

T* p_t;

ReRef& Reseat(T& in)
{
p_t = &in;

return *this;
}

public:

explicit ReRef() : p_t(0) {}

explicit ReRef(T& in)
{
Reseat(in);
}

/*
T& operator. ()
{
return *p_t;
}
*/

operator T&()
{
return *p_t;
}

friend class RefReseater<T>;
};

class Reseat_Class
{
public:

template<class T>
RefReseater<T> operator>> (ReRef<T>& in) const
{
return RefReseater<T>(in);
}
} Reseat;

template<class T>
class RefReseater
{
private:

ReRef<T>& reref_object;

public:

RefReseater(ReRef<T>& in) : reref_object(in)
{

}

ReRef<T>& operator= (T &object_in)
{
return reref_object.Reseat(object_in);
}
};
int main()
{
ReRef<int> j;

int a = 1;
int b = 2;
int c = 3;
int d = 4;

Reseat >> j = a;

//j = 9;

Reseat >> j = b;

//j = 8;

Reseat >> j = c;

//j = 7;

Reseat >> j = d;

//j = 6;
};
Any comments, questions, suggestions welcomed.
-JKop

[Dave Townsend]

"JKop" <NU**@NULL.NULL> wrote in message
news:Kn******************@news.indigo.ie...

Having decided not to use macros at all in designing my reseatable
references, and having looked through the list of overloadable operators and combinations of them, I've settled on the following syntax:

Reseat >> kref = moon;

Where "kref" is the reseatable reference and "moon" is the new object it'll refer to.

Overall, once a reseatable reference has been defined, I want it to act
exactly as would a normal reference... but so far it doesn't seem like I'll be able to achieve this, especially since I won't be able to access members after the dot.

Anyway, to achieve the above syntax, I've declared a global object called
"Reseat" (sort of like "cout"). This "Reseat" global object is of type
"Reseat_Class". The "Reseat_Class" class has an operator>> defined which
returns by value an intialized object of type "RefReseater". The class
"RefReseater" is a friend of the "ReRef" and so has access to its "Reseat"
member function (not to be confused with the "Reseat" global object). The
"RefReseater" class has operator= defined which changes what's referred to. Here's the code so far:

template<class T> class RefReseater;

template<class T>
class ReRef
{
private:

T* p_t;

ReRef& Reseat(T& in)
{
p_t = &in;

return *this;
}

public:

explicit ReRef() : p_t(0) {}

explicit ReRef(T& in)
{
Reseat(in);
}

/*
T& operator. ()
{
return *p_t;
}
*/

operator T&()
{
return *p_t;
}

friend class RefReseater<T>;
};

class Reseat_Class
{
public:

template<class T>
RefReseater<T> operator>> (ReRef<T>& in) const
{
return RefReseater<T>(in);
}
} Reseat;

template<class T>
class RefReseater
{
private:

ReRef<T>& reref_object;

public:

RefReseater(ReRef<T>& in) : reref_object(in)
{

}

ReRef<T>& operator= (T &object_in)
{
return reref_object.Reseat(object_in);
}
};
int main()
{
ReRef<int> j;

int a = 1;
int b = 2;
int c = 3;
int d = 4;

Reseat >> j = a;

//j = 9;

Reseat >> j = b;

//j = 8;

Reseat >> j = c;

//j = 7;

Reseat >> j = d;

//j = 6;
};
Any comments, questions, suggestions welcomed.
-JKop

It doesn't work! One of the important things about having a reference is
you
can be somewhat sure that its refering to a valid object , however, in the
following
code, the line int z = i; crashes because i doesn't represent anything, you
have to
manually set i before it an be used.

Also, there was no way to initialize values using the construct such as
ReRef<int> i(0); or ReRef<int> i=0, the compiler wouldn't accept it.

dave
#include <string>
using namespace std;

template<class T> class RefReseater;

template<class T>
class ReRef
{
private:

T* p_t;

ReRef& Reseat(T& in)
{
p_t = &in;

return *this;
}

public:

explicit ReRef() : p_t(0) {}

explicit ReRef(T& in)
{
Reseat(in);
}

/*
T& operator. ()
{
return *p_t;
}
*/

operator T&()
{
return *p_t;
}

friend class RefReseater<T>;
};

class Reseat_Class
{
public:

template<class T>
RefReseater<T> operator>> (ReRef<T>& in) const
{
return RefReseater<T>(in);
}
} Reseat;

template<class T>
class RefReseater
{
private:

ReRef<T>& reref_object;

public:

RefReseater(ReRef<T>& in) : reref_object(in)
{

}

ReRef<T>& operator= (T &object_in)
{
return reref_object.Reseat(object_in);
}
};
int main()
{
ReRef<string> j ;
ReRef<string> k ;
ReRef<char> ch ;
ReRef<int> i ;

int z = i;

string a = "into";
string b = "the";
string c = "valley";
string d = "ofdeath";

Reseat >> j = a;

string x = j;

Reseat >> j = b;

x = j;

Reseat >> j = c;

x = j;

Reseat >> j = d;
x = j;

return 0;

};

[JKop]

It doesn't work!

It's not complete! That's only a draft.
-JKop

[Aguilar, James]

"JKop" <NU**@NULL.NULL> wrote in message
news:Kn******************@news.indigo.ie...

[snip]

It's a noble goal. I'm not exactly sure if it's really -that- useful, but I
admire you for trying. I wonder if it is really possible to do it, given
enough work?

[Howard]

"JKop" <NU**@NULL.NULL> wrote in message
news:Kn******************@news.indigo.ie...

Just curious (perhaps you've mentioned it elsewhere before)...

Why do you want a "reseatable" reference? You have pointers which are
assignable to other objects. Why do you need to be able to re-assign
references too? What advantage over pointers would it provide? (Especially
given the pointer-like problems that might be introduced!)

-Howard

[JKop]

Howard posted:

"JKop" <NU**@NULL.NULL> wrote in message
news:Kn******************@news.indigo.ie...

Just curious (perhaps you've mentioned it elsewhere before)...
Why do you want a "reseatable" reference? You have pointers which are assignable to other objects. Why do you need to be able to re-assign references too? What advantage over pointers would it provide? (Especially given the pointer-like problems that might be introduced!)
-Howard

Consider you have a business. There's an owner, a
chairperson, 3 managers and 12 employees.

class Business
{
public:

Owner& owner;
Chairperson& chairperson;
Manager& manager[3];
Employee& employees[12];

Business(Owner& in_owner, ...) : owner(in_owner),...
};
People come and go. Maybe one day one of the empoyees gets
hit by a bus. Or a manager gets fired for bullying
employees. The first solution would be pointers:

class Business
{
public:

Owner* p_owner;
Chairperson* p_chairperson;
Manager* p_manager[3];
Employee* p_employees[12];

Business(Owner* in_p_owner, ...) : p_owner
(in_p_owner),...
};
While there's nothing wrong with it, I want it to be nicer
and more simplistic than that, as it is in Visual Basic.
With the pointer version, you'll always have to use the
asterisk:

int main()
{
...

Business k(....);

k.*p_owner.AnnouncePressConference();

//owner gets killed

k.p_owner = Owner();

k.*p_owner.AnnounceNewOwner();
}

In its place, I'd prefer:

int main()
{
....

Business k(....);

k.owner.AnnouncePressConference();

//owner gets killed

Reseat >> k.owner = Owner();

k.owner.AnnounceNewOwner();
}
Or something along those lines.
-JKop

[Howard]

"JKop" <NU**@NULL.NULL> wrote in message
news:vK******************@news.indigo.ie...

Howard posted:

"JKop" <NU**@NULL.NULL> wrote in message
news:Kn******************@news.indigo.ie...

Just curious (perhaps you've mentioned it elsewhere

before)...

Why do you want a "reseatable" reference? You have

pointers which are

assignable to other objects. Why do you need to be able

to re-assign

references too? What advantage over pointers would it

provide?

(Especially given the pointer-like problems that might be

introduced!)

-Howard

Consider you have a business. There's an owner, a
chairperson, 3 managers and 12 employees.

class Business
{
public:

Owner& owner;
Chairperson& chairperson;
Manager& manager[3];
Employee& employees[12];

Business(Owner& in_owner, ...) : owner(in_owner),...
};
People come and go. Maybe one day one of the empoyees gets
hit by a bus. Or a manager gets fired for bullying
employees. The first solution would be pointers:

class Business
{
public:

Owner* p_owner;
Chairperson* p_chairperson;
Manager* p_manager[3];
Employee* p_employees[12];

Business(Owner* in_p_owner, ...) : p_owner
(in_p_owner),...
};
While there's nothing wrong with it, I want it to be nicer
and more simplistic than that, as it is in Visual Basic.
With the pointer version, you'll always have to use the
asterisk:

int main()
{
...

Business k(....);

k.*p_owner.AnnouncePressConference();

//owner gets killed

k.p_owner = Owner();

k.*p_owner.AnnounceNewOwner();
}

In its place, I'd prefer:

int main()
{
...

Business k(....);

k.owner.AnnouncePressConference();

//owner gets killed

Reseat >> k.owner = Owner();

k.owner.AnnounceNewOwner();
}
Or something along those lines.
-JKop

[Howard]

"JKop" <NU**@NULL.NULL> wrote in message
news:vK******************@news.indigo.ie...

Howard posted:

"JKop" <NU**@NULL.NULL> wrote in message
news:Kn******************@news.indigo.ie...

Just curious (perhaps you've mentioned it elsewhere before)...

Why do you want a "reseatable" reference? You have

pointers which are

assignable to other objects. Why do you need to be able

to re-assign

references too? What advantage over pointers would it

provide?

(Especially given the pointer-like problems that might be

introduced!)

-Howard

Consider you have a business. There's an owner, a
chairperson, 3 managers and 12 employees.

class Business
{
public:

Owner& owner;
Chairperson& chairperson;
Manager& manager[3];
Employee& employees[12];

Business(Owner& in_owner, ...) : owner(in_owner),...
};
People come and go. Maybe one day one of the empoyees gets
hit by a bus. Or a manager gets fired for bullying
employees. The first solution would be pointers:

class Business
{
public:

Owner* p_owner;
Chairperson* p_chairperson;
Manager* p_manager[3];
Employee* p_employees[12];

Business(Owner* in_p_owner, ...) : p_owner
(in_p_owner),...
};
While there's nothing wrong with it, I want it to be nicer
and more simplistic than that, as it is in Visual Basic.
With the pointer version, you'll always have to use the
asterisk:

int main()
{
...

Business k(....);

k.*p_owner.AnnouncePressConference();

Is that legal syntax? It looks strange to me, using the dereference
operator after the member (.) operator.
If you choose to dereference, shouldn't it be

*(k.p_owner).AnnouncePressConference();

? But, why dereference? Why not:

k.p_owner->AnnouncePressConference();

That's the usual pointer syntax.

Or better still, k.AnnouncePressConference();

where Business announces the press conference, possibly via a call on its
Owner member. I almost never call a function belonging to another object's
member, preferring to let the containing object decide who should handle
such details for me. Also, that way I can have private or protected members
if I so desire.

//owner gets killed

k.p_owner = Owner();
I'm not sure what you meant here. Owner is a type, right? But here you're
assigning it to a pointer-to-type.

k.*p_owner.AnnounceNewOwner();
Again, why not use the -> operator?
}

In its place, I'd prefer:

int main()
{
...

Business k(....);

k.owner.AnnouncePressConference();

//owner gets killed

Reseat >> k.owner = Owner();

k.owner.AnnounceNewOwner();
}
Or something along those lines.
-JKop

I fail to see any advantage here at all. One less character (*) to type?
Surely that's not you sole motivation for this!?!

(Not to mention, I think your Owner is not going to be happy that you've
hard-coded his impending death like that! :-))

-Howard

[Ioannis Vranos]

JKop wrote:

Howard posted:

"JKop" <NU**@NULL.NULL> wrote in message
news:Kn******************@news.indigo.ie...

Just curious (perhaps you've mentioned it elsewhere
before)...

Why do you want a "reseatable" reference? You have

pointers which are

assignable to other objects. Why do you need to be able

to re-assign

references too? What advantage over pointers would it

provide?

(Especially given the pointer-like problems that might be

introduced!)

-Howard

Consider you have a business. There's an owner, a
chairperson, 3 managers and 12 employees.

class Business
{
public:

Owner& owner;
Chairperson& chairperson;
Manager& manager[3];
Employee& employees[12];

Business(Owner& in_owner, ...) : owner(in_owner),...
};
People come and go. Maybe one day one of the empoyees gets
hit by a bus. Or a manager gets fired for bullying
employees. The first solution would be pointers:

class Business
{
public:

Owner* p_owner;
Chairperson* p_chairperson;
Manager* p_manager[3];
Employee* p_employees[12];

Business(Owner* in_p_owner, ...) : p_owner
(in_p_owner),...
};
While there's nothing wrong with it, I want it to be nicer
and more simplistic than that, as it is in Visual Basic.
With the pointer version, you'll always have to use the
asterisk:

int main()
{
...

Business k(....);

k.*p_owner.AnnouncePressConference();

A better syntax in overall:

k.pOwner->AnnouncePressConference();

//owner gets killed

k.p_owner = Owner();

That doesn't look right.Perhaps you mean:
k.pOwner = new Owner;

k.*p_owner.AnnounceNewOwner();

k.pOwner->AnnounceNewOwner();


}

In its place, I'd prefer:

int main()
{
...

Business k(....);

k.owner.AnnouncePressConference();

//owner gets killed

Reseat >> k.owner = Owner();

k.owner.AnnounceNewOwner();
}
Or something along those lines.

VB "reseating references" as you mentioned them, are pointers with the
difference that instead of -> they use . (and not being able to do
pointer arithmetic etc).
Does it really bother you to use ->?

This one is the answer to your question:
http://www.research.att.com/~bs/bs_f...and-references


Ioannis Vranos

http://www23.brinkster.com/noicys