473,320 Members | 1,825 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

shared_ptr; derived classes; ambiguitity in overloaded functions

Hello all,

please consider the following code:

--------------------------------------------------
#include <tr1/memory>

struct BaseA
{
int x;
};

struct BaseB
{
double x;
};
struct DerivA : public BaseA
{
int y;
};

struct DerivB : public BaseB
{
double y;
};

struct S
{
S(std::tr1::shared_ptr<BaseApa_) : pa(pa_) {}
S(std::tr1::shared_ptr<BaseBpb_) : pb(pb_) {}

std::tr1::shared_ptr<BaseApa;
std::tr1::shared_ptr<BaseBpb;
};

int main()
{
// S s(std::tr1::shared_ptr<BaseA>(new DerivA()) ); // works
// S s( new DerivA() ); // Doesn't work, SP constructor is explicit
S s(std::tr1::shared_ptr<DerivA>(new DerivA()) ); // breaks

return 0;
}
--------------------------------------------------

As you see, there are 3 possibilities in main(). #1 uses
std::tr1::shared_ptr<BaseA>, which works, like I would expect it to.
Then, #2 tries to pass a pointer where a shared_ptr is required, so that
doesn't work - I can understand that too, pointers cannot be implicitly
converted to shared_ptr.

My question:
Option #3, using a std::tr1::shared_ptr<DerivA>, does NOT work:
$ g++ -Wall ambiguousSP.cpp
ambiguousSP.cpp: In function ‘int main()’:
ambiguousSP.cpp:37: error: call of overloaded
‘S(std::tr1::shared_ptr<DerivA>)’ is ambiguous
ambiguousSP.cpp:28: note: candidates are: S::S(std::tr1::shared_ptr<BaseB>)
ambiguousSP.cpp:27: note: S:S(std::tr1::shared_ptr<BaseA>)

If I use "regular" pointers, it would works fine:
---------------------------------------------
struct BaseA
{
int x;
};

struct BaseB
{
double x;
};
struct DerivA : public BaseA
{
int y;
};

struct DerivB : public BaseB
{
double y;
};
struct S
{
S(BaseA * pa_) : pa(pa_), pb(0) {}
S(BaseB * pb_) : pa(0), pb(pb_) {}

BaseA * pa;
BaseB * pb;
};

int main()
{
S s(new DerivA()); // works fine
delete s.pa;

return 0;
}
---------------------------------------------

Could anyone comment on this ? Should option #3 with shared_ptr<DerivA>
work or not ?

Conceptually, I believe so. I can understand that the platform could
have some trouble with it, if it doesn't recognize that the template
parameter DerivA in shared_ptr<DerivAis derived of BaseA.

Thanks for any comments,

F. Beekhof
Aug 26 '08 #1
5 3149
On Aug 26, 8:19 am, Fokko Beekhof <Fokko.Beek...@cui.unige.chwrote:
Hello all,

please consider the following code:

--------------------------------------------------
#include <tr1/memory>

struct BaseA
{
int x;

};

struct BaseB
{
double x;

};

struct DerivA : public BaseA
{
int y;

};

struct DerivB : public BaseB
{
double y;

};

struct S
{
S(std::tr1::shared_ptr<BaseApa_) : pa(pa_) {}
S(std::tr1::shared_ptr<BaseBpb_) : pb(pb_) {}

std::tr1::shared_ptr<BaseApa;
std::tr1::shared_ptr<BaseBpb;

};

int main()
{
// S s(std::tr1::shared_ptr<BaseA>(new DerivA()) ); // works
// S s( new DerivA() ); // Doesn't work, SP constructor is explicit
S s(std::tr1::shared_ptr<DerivA>(new DerivA()) ); // breaks

return 0;}

--------------------------------------------------

As you see, there are 3 possibilities in main(). #1 uses
std::tr1::shared_ptr<BaseA>, which works, like I would expect it to.
Then, #2 tries to pass a pointer where a shared_ptr is required, so that
doesn't work - I can understand that too, pointers cannot be implicitly
converted to shared_ptr.

My question:
Option #3, using a std::tr1::shared_ptr<DerivA>, does NOT work:
$ g++ -Wall ambiguousSP.cpp
ambiguousSP.cpp: In function ‘int main()’:
ambiguousSP.cpp:37: error: call of overloaded
‘S(std::tr1::shared_ptr<DerivA>)’ is ambiguous
ambiguousSP.cpp:28: note: candidates are: S::S(std::tr1::shared_ptr<BaseB>)
ambiguousSP.cpp:27: note: S:S(std::tr1::shared_ptr<BaseA>)

If I use "regular" pointers, it would works fine:
---------------------------------------------
struct BaseA
{
int x;

};

struct BaseB
{
double x;

};

struct DerivA : public BaseA
{
int y;

};

struct DerivB : public BaseB
{
double y;

};

struct S
{
S(BaseA * pa_) : pa(pa_), pb(0) {}
S(BaseB * pb_) : pa(0), pb(pb_) {}

BaseA * pa;
BaseB * pb;

};

int main()
{
S s(new DerivA()); // works fine
delete s.pa;

return 0;}

---------------------------------------------

Could anyone comment on this ? Should option #3 with shared_ptr<DerivA>
work or not ?

Conceptually, I believe so. I can understand that the platform could
have some trouble with it, if it doesn't recognize that the template
parameter DerivA in shared_ptr<DerivAis derived of BaseA.

Thanks for any comments,

F. Beekhof
Since a conversion would be required...

S s(std::tr1::shared_ptr<DerivA>(new DerivA()) );

fails. This works:

struct S
{
...
S(std::tr1::shared_ptr<DerivApa_) : pa(pa_) {}
...
};

its the same as:

void f(unsigned u) { }
void f(char c) { }

int main()
{
f(0); // call of overload is ambiguous, 0 is of type int
}

Aug 26 '08 #2
Salt_Peter wrote:
On Aug 26, 8:19 am, Fokko Beekhof <Fokko.Beek...@cui.unige.chwrote:
>Hello all,

please consider the following code:

--------------------------------------------------
#include <tr1/memory>

struct BaseA
{
int x;

};

struct BaseB
{
double x;

};

struct DerivA : public BaseA
{
int y;

};

struct DerivB : public BaseB
{
double y;

};

struct S
{
S(std::tr1::shared_ptr<BaseApa_) : pa(pa_) {}
S(std::tr1::shared_ptr<BaseBpb_) : pb(pb_) {}

std::tr1::shared_ptr<BaseApa;
std::tr1::shared_ptr<BaseBpb;

};

int main()
{
// S s(std::tr1::shared_ptr<BaseA>(new DerivA()) ); // works
// S s( new DerivA() ); // Doesn't work, SP constructor is explicit
S s(std::tr1::shared_ptr<DerivA>(new DerivA()) ); // breaks

return 0;}

--------------------------------------------------

As you see, there are 3 possibilities in main(). #1 uses
std::tr1::shared_ptr<BaseA>, which works, like I would expect it to.
Then, #2 tries to pass a pointer where a shared_ptr is required, so that
doesn't work - I can understand that too, pointers cannot be implicitly
converted to shared_ptr.

My question:
Option #3, using a std::tr1::shared_ptr<DerivA>, does NOT work:
$ g++ -Wall ambiguousSP.cpp
ambiguousSP.cpp: In function ‘int main()’:
ambiguousSP.cpp:37: error: call of overloaded
‘S(std::tr1::shared_ptr<DerivA>)’ is ambiguous
ambiguousSP.cpp:28: note: candidates are: S::S(std::tr1::shared_ptr<BaseB>)
ambiguousSP.cpp:27: note: S:S(std::tr1::shared_ptr<BaseA>)

If I use "regular" pointers, it would works fine:
---------------------------------------------
struct BaseA
{
int x;

};

struct BaseB
{
double x;

};

struct DerivA : public BaseA
{
int y;

};

struct DerivB : public BaseB
{
double y;

};

struct S
{
S(BaseA * pa_) : pa(pa_), pb(0) {}
S(BaseB * pb_) : pa(0), pb(pb_) {}

BaseA * pa;
BaseB * pb;

};

int main()
{
S s(new DerivA()); // works fine
delete s.pa;

return 0;}

---------------------------------------------

Could anyone comment on this ? Should option #3 with shared_ptr<DerivA>
work or not ?

Conceptually, I believe so. I can understand that the platform could
have some trouble with it, if it doesn't recognize that the template
parameter DerivA in shared_ptr<DerivAis derived of BaseA.

Thanks for any comments,

F. Beekhof

Since a conversion would be required...

S s(std::tr1::shared_ptr<DerivA>(new DerivA()) );

fails. This works:

struct S
{
...
S(std::tr1::shared_ptr<DerivApa_) : pa(pa_) {}
...
};

its the same as:

void f(unsigned u) { }
void f(char c) { }

int main()
{
f(0); // call of overload is ambiguous, 0 is of type int
}
Yes, but this:
struct S
{
...
S(std::tr1::shared_ptr<DerivApa_) : pa(pa_) {}
...
};
might work, but is conceptually completely different from the pointer
version:
struct S {
...
S(BaseA * pa_) : pa(pa_), pb(0) {}
...
};

because in the latter, there is polymorphism - any pointer to a derived
class is-a base class too. When I move the code to shared_ptrs, that breaks.

Shouldn't there be some sort of polymorphism-awareness in the template
arguments ? I.e., a shared_ptr<DerivAis also a shared_ptr<BaseA?
Aug 28 '08 #3
Fokko Beekhof wrote:
Hello all,

please consider the following code:

--------------------------------------------------
#include <tr1/memory>

struct BaseA
{
int x;
};

struct BaseB
{
double x;
};
struct DerivA : public BaseA
{
int y;
};

struct DerivB : public BaseB
{
double y;
};

struct S
{
S(std::tr1::shared_ptr<BaseApa_) : pa(pa_) {}
S(std::tr1::shared_ptr<BaseBpb_) : pb(pb_) {}

std::tr1::shared_ptr<BaseApa;
std::tr1::shared_ptr<BaseBpb;
};

int main()
{
// S s(std::tr1::shared_ptr<BaseA>(new DerivA()) ); // works
// S s( new DerivA() ); // Doesn't work, SP constructor is explicit
S s(std::tr1::shared_ptr<DerivA>(new DerivA()) ); // breaks

return 0;
}
--------------------------------------------------

As you see, there are 3 possibilities in main(). #1 uses
std::tr1::shared_ptr<BaseA>, which works, like I would expect it to.
Then, #2 tries to pass a pointer where a shared_ptr is required, so that
doesn't work - I can understand that too, pointers cannot be implicitly
converted to shared_ptr.

My question:
Option #3, using a std::tr1::shared_ptr<DerivA>, does NOT work:
$ g++ -Wall ambiguousSP.cpp
ambiguousSP.cpp: In function ?int main()?:
ambiguousSP.cpp:37: error: call of overloaded
?S(std::tr1::shared_ptr<DerivA>)? is ambiguous
ambiguousSP.cpp:28: note: candidates are:
S::S(std::tr1::shared_ptr<BaseB>) ambiguousSP.cpp:27: note:
S:S(std::tr1::shared_ptr<BaseA>)

If I use "regular" pointers, it would works fine:
---------------------------------------------
struct BaseA
{
int x;
};

struct BaseB
{
double x;
};
struct DerivA : public BaseA
{
int y;
};

struct DerivB : public BaseB
{
double y;
};
struct S
{
S(BaseA * pa_) : pa(pa_), pb(0) {}
S(BaseB * pb_) : pa(0), pb(pb_) {}

BaseA * pa;
BaseB * pb;
};

int main()
{
S s(new DerivA()); // works fine
delete s.pa;

return 0;
}
---------------------------------------------

Could anyone comment on this ? Should option #3 with shared_ptr<DerivA>
work or not ?
According to the technical report TR1, it should not work.

Conceptually, I believe so. I can understand that the platform could
have some trouble with it, if it doesn't recognize that the template
parameter DerivA in shared_ptr<DerivAis derived of BaseA.
You have a point, but it would require changing the specs of shared_ptr.

To simplify the exposition, let us consider the following class:

template < typename T >
struct pointer_to {

T * the_ptr;

pointer_to ( T * ptr )
: the_ptr ( ptr )
{}

T & operator* ( void ) const {
return ( *the_ptr );
}

T * operator-( void ) const {
return ( the_ptr );
}

template < typename D >
pointer_to ( pointer_to<Dconst & d_pointer )
: the_ptr ( d_pointer.the_ptr )
{}

};

There is a conversion operator that allows to copy construct a pointer_to<T>
from a pointer to any derived class. Attempts to copy construct from
non-derived classes will fail when the compiler encounters the body of the
conversion operator. With this setup, the following will be ambiguous:

struct X {};
struct XD : public X {};
struct Y {};
struct YD : public Y {};

void f ( pointer_to<Xxp ) {}
void f ( pointer_to<Yyp ) {}

int main ( void ) {
pointer_to<YDydp ( new YD );
f( ydp );
}

The reason is that the compiler sees two possible conversions and it is not
supposed to check whether only one of them can be compiled cleanly.
Now, there is a way to guide the compiler in these issues. But it requires
some serious scaffolding:

struct yes_type { char dummy; };
struct no_type { yes_type a; yes_type b; };

template < typename From, typename To >
class is_convertible {

static
From* dummy ( void );

static
yes_type check ( To );

static
no_type check ( ... );

public:

static bool const value =
sizeof( check( *dummy() ) ) == sizeof( yes_type );

}; // is_convertible

template < bool b, typename T >
struct enable_if;

template < typename T >
struct enable_if<true,T{ typedef T type; };

template < typename T >
struct pointer_to {

T * the_ptr;

pointer_to ( T * ptr )
: the_ptr ( ptr )
{}

T & operator* ( void ) const {
return ( *the_ptr );
}

T * operator-( void ) const {
return ( the_ptr );
}

template < typename D >
pointer_to ( pointer_to<Dconst & d_pointer,
typename enable_if< is_convertible<D*,T*>::value, void* >::type
p = 0 )
: the_ptr ( d_pointer.the_ptr )
{}

};

With this setup, the above snippet will compile cleanly since the signature
of the conversion operator is enough to tell the compiler that there is
only one possible conversion.

Best

Kai-Uwe Bux

Aug 28 '08 #4
>
>
>Conceptually, I believe so. I can understand that the platform could
have some trouble with it, if it doesn't recognize that the template
parameter DerivA in shared_ptr<DerivAis derived of BaseA.

You have a point, but it would require changing the specs of shared_ptr.

To simplify the exposition, let us consider the following class:

template < typename T >
struct pointer_to {

T * the_ptr;

pointer_to ( T * ptr )
: the_ptr ( ptr )
{}

T & operator* ( void ) const {
return ( *the_ptr );
}

T * operator-( void ) const {
return ( the_ptr );
}

template < typename D >
pointer_to ( pointer_to<Dconst & d_pointer )
: the_ptr ( d_pointer.the_ptr )
{}

};

There is a conversion operator that allows to copy construct a pointer_to<T>
from a pointer to any derived class. Attempts to copy construct from
non-derived classes will fail when the compiler encounters the body of the
conversion operator. With this setup, the following will be ambiguous:

struct X {};
struct XD : public X {};
struct Y {};
struct YD : public Y {};

void f ( pointer_to<Xxp ) {}
void f ( pointer_to<Yyp ) {}

int main ( void ) {
pointer_to<YDydp ( new YD );
f( ydp );
}

The reason is that the compiler sees two possible conversions and it is not
supposed to check whether only one of them can be compiled cleanly.
Now, there is a way to guide the compiler in these issues. But it requires
some serious scaffolding:

struct yes_type { char dummy; };
struct no_type { yes_type a; yes_type b; };

template < typename From, typename To >
class is_convertible {

static
From* dummy ( void );

static
yes_type check ( To );

static
no_type check ( ... );

public:

static bool const value =
sizeof( check( *dummy() ) ) == sizeof( yes_type );

}; // is_convertible

template < bool b, typename T >
struct enable_if;

template < typename T >
struct enable_if<true,T{ typedef T type; };

template < typename T >
struct pointer_to {

T * the_ptr;

pointer_to ( T * ptr )
: the_ptr ( ptr )
{}

T & operator* ( void ) const {
return ( *the_ptr );
}

T * operator-( void ) const {
return ( the_ptr );
}

template < typename D >
pointer_to ( pointer_to<Dconst & d_pointer,
typename enable_if< is_convertible<D*,T*>::value, void* >::type
p = 0 )
: the_ptr ( d_pointer.the_ptr )
{}

};

With this setup, the above snippet will compile cleanly since the signature
of the conversion operator is enough to tell the compiler that there is
only one possible conversion.

Best

Kai-Uwe Bux
That is quite impressive...

Anyway, to conclude:
- A solution to my problem is possible,
- but it not in the specs of shared_ptr.
- The specs of shared_ptr are probably not going to change anytime soon,
- and trying rewrite/override parts of the standard is not smart either.

Should I post this problem + solution anywhere so that maybe one day the
specs of shared_ptr will be improved to better reflect the behavior of
regular pointers ? If so, where ?

Many thanks,
Fokko Beekhof
Aug 28 '08 #5
Fokko Beekhof wrote:

[snip]
[about how the constructors in shared_ptr<can lead to ambiguous
conversion where raw pointer conversions would be unique.]
>
Anyway, to conclude:
- A solution to my problem is possible,
- but it not in the specs of shared_ptr.
- The specs of shared_ptr are probably not going to change anytime soon,
- and trying rewrite/override parts of the standard is not smart either.

Should I post this problem + solution anywhere so that maybe one day the
specs of shared_ptr will be improved to better reflect the behavior of
regular pointers ? If so, where ?
Well, there was comp.std.c++; but is has been defunct for a while. Some of
the discussion of standardization issues has since moved to the moderated
list comp.lang.c++.moderated.
Best

Kai-Uwe Bux
Aug 29 '08 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

24
by: Brad Marts | last post by:
I would like to have a function that takes as an argument a base class but performs differently depending on which type of derived class is passed. Can I tell which derived class is passed? For...
4
by: Ernst Murnleitner | last post by:
Hello, in 2 other threads I had questions partly related to shared_ptr. I changed my normal pointers to a class to shared_ptr. (i.e. boost::shared_ptr). I thought, the use of shared_ptr is...
6
by: Ryan Mitchley | last post by:
Hi all Given bool bResult; shared_ptr<cSampleData> pNewData; shared_ptr<cBase> pNewBase; where cSampleData is descended from cBase, the following gives me a valid pNewData to the correct...
7
by: Tron Thomas | last post by:
Under the right compiler the following code: class Base { public: virtual void Method(int){} }; class Derived: public Base {
5
by: Dimitry | last post by:
I am trying to make the following: struct Base { char param; }; class Derived1 : public Base { public:
2
by: Marcin Gil | last post by:
First of all thanks for your patience and good pointers for Visitor and Curiously Recurring Template patterns last time :) Now another problem of mine. THE CODE #include <iostream>...
12
by: bgold | last post by:
Hey. I have a base class (SPRITE), and using this base class I have derived a large number of derived classes (PERSON, BULLET, MISSILE, etc.). Now, at a certain point in my program, I have a pair...
4
by: EnsGabe | last post by:
Suppose you have a class heirarchy as such: class Base{ .... }; class Mid1 : public Base{ ....
7
by: Random.Coder | last post by:
The output of this simple program below differs if it's compiled in Visual Studio 2005 and 2008. Is one the correct output, and if so, why? using System; namespace DerivedTestApp { class...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.