Pointer to member data problems

[Bob Hairgrove]

The following class contains start and end points of a range of
values. The range can have a direction which is implied from the
relative order of start and end, or it can be without direction. IOW
if start is greater than end, and direction == true, then the range
has reverse direction. If direction == false, the starting point is
always less than the end point.

To make getting the intersection of two ranges easier, for example, I
also want to keep a "normalized" start and end for which start < end
even if the real start is greater than the end. Since the template
parameter E (for element type) can be anything, I don't want to
generate possibly expensive copies of the start and end elements if
they are user-defined types. Therefore, I decided to try storing this
information in pointers to members.

Most of the time this works OK. But for ranges with negative
direction, although the elem_ptr members are apparently pointing to
the correct members (i.e. reversed), when I dereference them I get the
wrong data: e.g. this->*m_pNormalizedStart will return m_start instead
of m_end, although the debugger is showing "&Range<int,int>::m_end"
for m_pNormalizedStart.

I know I can just use a member function to return the normalized data
and only need to compare m_start to m_end. That wouldn't be a problem,
also since it could be inlined, but I want to know in general if using
pointers to members like this is OK.

Is there something "fishy" about how I am setting the member pointers
in the constructor? I know that the object isn't fully constructed yet
at member initialization time; however, the member data is initialized
first and therefore should have a valid address.

I also thought that the compiler might be treating the pointers to
memebers like static data (since that is the syntax for setting their
value) and overwriting them when a new Range is created with a
different direction. However, I assume that each Range object would
have a distinct set of pointers to member. Maybe this isn't a valid
assumption?

I hope I am just making some other stupid mistake, but I have looked
hard and not yet found anything. I don't think it is a compiler bug
because I get the same behavior when running my test code compiled on
GCC and Borland.

Here is some skeleton code:

// declarations:

template<typename E, typename D = E>
class Range
{
typedef E Range::*elem_ptr;
public:
Range<E,D>::Range()
: m_start()
, m_end()
, m_directed(false)
, m_pNormalizedStart(&Range::m_start)
, m_pNormalizedEnd(&Range::m_end){;}

Range<E,D>::Range(const E & startElem
, const E & endElem
, bool directed)
: m_start( directed ?
startElem : (startElem > endElem ? endElem : startElem))
, m_end ( directed ?
endElem : (startElem < endElem ? endElem : startElem))
, m_directed(directed)
, m_pNormalizedStart(m_start <= m_end ?
&Range::m_start : &Range::m_end)
, m_pNormalizedEnd(m_start <= m_end ?
&Range::m_end : &Range::m_start){;}
// etc.
private:
E m_start;
E m_end;
bool m_directed;
elem_ptr m_pNormalizedStart;
elem_ptr m_pNormalizedEnd;
};

TIA

--
Bob Hairgrove
No**********@Home.com

[Bob Hairgrove]

On Sat, 03 Jul 2004 16:40:45 +0200, Bob Hairgrove
<wo**************@to.know> wrote:

oops ... constructors were copied and pasted from a different file.
Here's how they should look:

template<typename E, typename D = E>
class Range
{
typedef E Range::*elem_ptr;
public:
Range()
: m_start()
, m_end()
, m_directed(false)
, m_pNormalizedStart(&Range::m_start)
, m_pNormalizedEnd(&Range::m_end){;}

Range(const E & startElem
, const E & endElem
, bool directed)
: m_start( directed ?
startElem : (startElem > endElem ? endElem : startElem))
, m_end ( directed ?
endElem : (startElem < endElem ? endElem : startElem))
, m_directed(directed)
, m_pNormalizedStart(m_start <= m_end ?
&Range::m_start : &Range::m_end)
, m_pNormalizedEnd(m_start <= m_end ?
&Range::m_end : &Range::m_start){;}
// etc.
private:
E m_start;
E m_end;
bool m_directed;
elem_ptr m_pNormalizedStart;
elem_ptr m_pNormalizedEnd;
};

--
Bob Hairgrove
No**********@Home.com

[John Harrison]

On Sat, 03 Jul 2004 16:40:45 +0200, Bob Hairgrove
<wo**************@to.know> wrote:

The following class contains start and end points of a range of
values. The range can have a direction which is implied from the
relative order of start and end, or it can be without direction. IOW
if start is greater than end, and direction == true, then the range
has reverse direction. If direction == false, the starting point is
always less than the end point.

To make getting the intersection of two ranges easier, for example, I
also want to keep a "normalized" start and end for which start < end
even if the real start is greater than the end. Since the template
parameter E (for element type) can be anything, I don't want to
generate possibly expensive copies of the start and end elements if
they are user-defined types. Therefore, I decided to try storing this
information in pointers to members.

Most of the time this works OK. But for ranges with negative
direction, although the elem_ptr members are apparently pointing to
the correct members (i.e. reversed), when I dereference them I get the
wrong data: e.g. this->*m_pNormalizedStart will return m_start instead
of m_end, although the debugger is showing "&Range<int,int>::m_end"
for m_pNormalizedStart.

I know I can just use a member function to return the normalized data
and only need to compare m_start to m_end. That wouldn't be a problem,
also since it could be inlined, but I want to know in general if using
pointers to members like this is OK.

Is there something "fishy" about how I am setting the member pointers
in the constructor? I know that the object isn't fully constructed yet
at member initialization time; however, the member data is initialized
first and therefore should have a valid address.

I also thought that the compiler might be treating the pointers to
memebers like static data (since that is the syntax for setting their
value) and overwriting them when a new Range is created with a
different direction. However, I assume that each Range object would
have a distinct set of pointers to member. Maybe this isn't a valid
assumption?

I hope I am just making some other stupid mistake, but I have looked
hard and not yet found anything. I don't think it is a compiler bug
because I get the same behavior when running my test code compiled on
GCC and Borland.

Here is some skeleton code:

Works for me, can't see anything wrong.

#include <iostream>
using namespace std;

template<typename E, typename D = E>
class Range
{
typedef E Range::*elem_ptr;
public:
Range()
: m_start()
, m_end()
, m_directed(false)
, m_pNormalizedStart(&Range::m_start)
, m_pNormalizedEnd(&Range::m_end){;}

Range(const E & startElem
, const E & endElem
, bool directed)
: m_start( directed ?
startElem : (startElem > endElem ? endElem : startElem))
, m_end ( directed ?
endElem : (startElem < endElem ? endElem : startElem))
, m_directed(directed)
, m_pNormalizedStart(m_start <= m_end ?
&Range::m_start : &Range::m_end)
, m_pNormalizedEnd(m_start <= m_end ?
&Range::m_end : &Range::m_start){;}
// etc.
void dump()
{
cout << this->*m_pNormalizedStart << '\n';
cout << this->*m_pNormalizedEnd << '\n';
}
private:
E m_start;
E m_end;
bool m_directed;
elem_ptr m_pNormalizedStart;
elem_ptr m_pNormalizedEnd;
};

int main()
{
Range<int> r(20, 10, true);
Range<int> s(10, 20, true);
r.dump();
s.dump();
}

Output

10
20
10
20

john

[John Harrison]

On Sat, 03 Jul 2004 16:40:45 +0200, Bob Hairgrove
<wo**************@to.know> wrote:

The following class contains start and end points of a range of
values. The range can have a direction which is implied from the
relative order of start and end, or it can be without direction. IOW
if start is greater than end, and direction == true, then the range
has reverse direction. If direction == false, the starting point is
always less than the end point.

To make getting the intersection of two ranges easier, for example, I
also want to keep a "normalized" start and end for which start < end
even if the real start is greater than the end. Since the template
parameter E (for element type) can be anything, I don't want to
generate possibly expensive copies of the start and end elements if
they are user-defined types. Therefore, I decided to try storing this
information in pointers to members.

You could just use ordinary pointers, or maybe even references.

john

[Bob Hairgrove]

On Sat, 03 Jul 2004 16:45:04 +0100, "John Harrison"
<jo*************@hotmail.com> wrote:

On Sat, 03 Jul 2004 16:40:45 +0200, Bob Hairgrove
<wo**************@to.know> wrote:

The following class contains start and end points of a range of
values. The range can have a direction which is implied from the
relative order of start and end, or it can be without direction. IOW
if start is greater than end, and direction == true, then the range
has reverse direction. If direction == false, the starting point is
always less than the end point.

To make getting the intersection of two ranges easier, for example, I
also want to keep a "normalized" start and end for which start < end
even if the real start is greater than the end. Since the template
parameter E (for element type) can be anything, I don't want to
generate possibly expensive copies of the start and end elements if
they are user-defined types. Therefore, I decided to try storing this
information in pointers to members.

Thanks for the feedback, John...
You could just use ordinary pointers, or maybe even references.

How could I use an ordinary pointer or a reference for member data?
Don't I need pointer to member here?

--
Bob Hairgrove
No**********@Home.com

[Bob Hairgrove]

On Sat, 03 Jul 2004 16:41:08 +0100, "John Harrison"
<jo*************@hotmail.com> wrote:

Works for me, can't see anything wrong.

I added a member function "encloses()" and expanded the main()
function to illustrate my problem.

===

#include <iostream>
using namespace std;

template<typename E, typename D = E>
class Range
{
typedef E Range::*elem_ptr;
public:
Range()
: m_start()
, m_end()
, m_directed(false)
, m_pNormalizedStart(&Range::m_start)
, m_pNormalizedEnd(&Range::m_end){;}

Range(const E & startElem
, const E & endElem
, bool directed)
: m_start( directed ?
startElem : (startElem > endElem ? endElem : startElem))
, m_end ( directed ?
endElem : (startElem < endElem ? endElem : startElem))
, m_directed(directed)
, m_pNormalizedStart(m_start <= m_end ?
&Range::m_start : &Range::m_end)
, m_pNormalizedEnd(m_start <= m_end ?
&Range::m_end : &Range::m_start){;}
//------------------
void dump()
{
cout << "Normalized start:\t"
<< this->*m_pNormalizedStart << '\n';
cout << "Normalized end:\t"
<< this->*m_pNormalizedEnd << '\n';
cout << "==============\n";
}
//------------------
bool encloses(const Range & other) const
{
#ifdef _DEBUG
E el_start_this(this->*m_pNormalizedStart);
E el_start_other(other.*m_pNormalizedStart);
E el_end_this(this->*m_pNormalizedEnd);
E el_end_other(other.*m_pNormalizedEnd);
E real_start_this(this->m_start);
E real_start_other(other.m_start);
E real_end_this(this->m_end);
E real_end_other(other.m_end);
#endif
bool retval
= (this->*m_pNormalizedStart < other.*m_pNormalizedStart)
&& (this->*m_pNormalizedEnd > other.*m_pNormalizedEnd );
return retval;
}
//------------------
// etc.
private:
E m_start;
E m_end;
bool m_directed;
elem_ptr m_pNormalizedStart;
elem_ptr m_pNormalizedEnd;
};

int main()
{
Range<int> a(1,-2,true);
Range<int> b(-3,5,true);
Range<int> c(10,20,true);
cout << "a.dump():\n";
a.dump();
cout << "b.dump():\n";
b.dump();
cout << "c.dump():\n";
c.dump();
//-------------------
// b should enclose a:
//-------------------
if (a.encloses(b))
cout << "a encloses b\n";
else if (b.encloses(a))
cout << "b encloses a\n";
// std::cin.get();
return 0;
}

And this is what my program outputs:

a.dump():
Normalized start: -2
Normalized end: 1
==============
b.dump():
Normalized start: -3
Normalized end: 5
==============
c.dump():
Normalized start: 10
Normalized end: 20
==============
a encloses b
--
Bob Hairgrove
No**********@Home.com

[Bob Hairgrove]

On Sat, 03 Jul 2004 18:44:21 +0200, Bob Hairgrove
<wo**************@to.know> wrote:

a encloses b

Note that if I write:

Range<int> a(-2,1,true);

instead of

Range<int> a(1,-2,true);

then I get the correct answer.
--
Bob Hairgrove
No**********@Home.com

[Rob Williscroft]

Bob Hairgrove wrote in news:i8********************************@4ax.com in
comp.lang.c++:

#endif
bool retval
= (this->*m_pNormalizedStart < other.*m_pNormalizedStart)
&& (this->*m_pNormalizedEnd > other.*m_pNormalizedEnd );
return retval;
}

bool retval
= (this->*m_pNormalizedStart < other.*(other.m_pNormalizedStart))
&& (this->*m_pNormalizedEnd > other.*(other.m_pNormalizedEnd));

Don't you just love member pointers :)

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[John Harrison]

On Sat, 03 Jul 2004 17:46:25 +0200, Bob Hairgrove
<wo**************@to.know> wrote:

On Sat, 03 Jul 2004 16:45:04 +0100, "John Harrison"
<jo*************@hotmail.com> wrote:

On Sat, 03 Jul 2004 16:40:45 +0200, Bob Hairgrove
<wo**************@to.know> wrote:

The following class contains start and end points of a range of
values. The range can have a direction which is implied from the
relative order of start and end, or it can be without direction. IOW
if start is greater than end, and direction == true, then the range
has reverse direction. If direction == false, the starting point is
always less than the end point.

To make getting the intersection of two ranges easier, for example, I
also want to keep a "normalized" start and end for which start < end
even if the real start is greater than the end. Since the template
parameter E (for element type) can be anything, I don't want to
generate possibly expensive copies of the start and end elements if
they are user-defined types. Therefore, I decided to try storing this
information in pointers to members.

Thanks for the feedback, John...

You could just use ordinary pointers, or maybe even references.

How could I use an ordinary pointer or a reference for member data?
Don't I need pointer to member here?

Not at all, there nothing to stop a pointer pointing to a member of its
own class.

template<typename E, typename D = E>
class Range
{
public:
Range()
: m_start()
, m_end()
, m_directed(false)
, m_pNormalizedStart(&m_start)
, m_pNormalizedEnd(&m_end){;}

Range(const E & startElem
, const E & endElem
, bool directed)
: m_start( directed ?
startElem : (startElem > endElem ? endElem : startElem))
, m_end ( directed ?
endElem : (startElem < endElem ? endElem : startElem))
, m_directed(directed)
, m_pNormalizedStart(m_start <= m_end ?
&m_start : &m_end)
, m_pNormalizedEnd(m_start <= m_end ?
&m_end : &m_start){;}
// etc.
private:
E m_start;
E m_end;
bool m_directed;
E* m_pNormalizedStart;
E* m_pNormalizedEnd;
};

The point about pointers to members is that they can be used independently
of any particular object. So you could have one pointer to member and use
it on several different objects. But that's not your requirement, so I
would just use a regular pointer.

john

[Julián Albo]

Bob Hairgrove wrote:

I added a member function "encloses()" and expanded the main()
function to illustrate my problem.
(snip)

bool encloses(const Range & other) const
{
#ifdef _DEBUG
E el_start_this(this->*m_pNormalizedStart);
E el_start_other(other.*m_pNormalizedStart);
E el_end_this(this->*m_pNormalizedEnd);
E el_end_other(other.*m_pNormalizedEnd);
E real_start_this(this->m_start);
E real_start_other(other.m_start);
E real_end_this(this->m_end);
E real_end_other(other.m_end);
#endif
bool retval
= (this->*m_pNormalizedStart < other.*m_pNormalizedStart)
&& (this->*m_pNormalizedEnd > other.*m_pNormalizedEnd );
return retval;
}

Must be:

bool retval
= (this->*m_pNormalizedStart < other.*other.m_pNormalizedStart)
&& (this->*m_pNormalizedEnd > other.*other.m_pNormalizedEnd);

--
Salu2

[John Harrison]

The point about pointers to members is that they can be used
independently of any particular object. So you could have one pointer to
member and use it on several different objects. But that's not your
requirement, so I would just use a regular pointer.

This is well illustrated by the mistake you were making in your code. You
we're inadvertently applying the pointer to member stored in one object to
a different object, hence the bug.

I have never seen a realistic use for pointers to data members and you
don't need them for what you are trying to do.

john

[Bob Hairgrove]

On Sat, 03 Jul 2004 18:48:38 +0100, "John Harrison"
<jo*************@hotmail.com> wrote:

I have never seen a realistic use for pointers to data members and you
don't need them for what you are trying to do.

Thanks, John, Rob and Julián.

It was an interesting experiment, at least!

--
Bob Hairgrove
No**********@Home.com