• Advertisement
Sign in to follow this  

Unity Templated Smart Pointer - Implicit Casting?

This topic is 4653 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This thread where someone mentioned that smart pointers and casting is impossible. They were corrected - I cast my smart pointers all the time. The unfortunate thing is they can't be implicitly casted. I was also discussing this very thing the other night. Anyway. What I want to know, take your standard, every day shared-pointer style implementation of a smart pointer using templates. Is there a sensible way to allow the pointer to be implicitly cast like a normal pointer is? For reference, here is some code from my own pointer. It's just showing the relevent details of how I implement casting. The cast function will cause an implicit conversion (and will generate nice compilation errors if it is an illegal conversion).
template <class T>
class ASharedPtr
{
    T* ptr;
    size_t* count;
public:
    // various constructors:
    ASharedPtr() : ptr(0), count(new size_t(1)) {}
    ASharedPtr(const ASharedPtr& s) : ptr(s.ptr), count(s.count) {++(*count);}
    explicit ASharedPtr(T* p) : ptr(p), count(new size_t(1)) {}
    ASharedPtr(T* p, size_t* pcount) : ptr(p), count(pcount) {assert(count); ++(*count);}

    template <class U>
    ASharedPtr<U> Cast() { return ASharedPtr<U>(ptr, count); }
};
The idea I'm trying to get at is:
// some classes:
class CBase {};
class CChild : public CBase {};

// make some pointers
CChild* rawptr = new CChild;
ASharedPtr<CChild> smartptr(new CChild);

// Some functions
void DoStuffRaw(CBase* x);
void DoStuffSmart(const ASharedPtr<CBase>& x);

// The raw pointer is cast implicitly
DoStuffRaw(rawptr);
// The smart pointer can't
DoStuffSmart(smartptr); // <- error!

// The smart pointer must do this instead
DoStuffSmart(smartptr.Cast<CBase>());
Any sensible way to make the line marked as "error" actually work?

Share this post


Link to post
Share on other sites
Advertisement
Try something like


#include <boost/utility.hpp>
#include <boost/type_traits.hpp>

using boost::enable_if;
using boost::is_base_and_derived;

template <class T>
class ASharedPtr
{
public:
template<class U>
ASharedPtr( const AsharedPtr<U>& rhs,
typename enable_if< is_base_and_derived<T,U> >::type* dummy = 0 )
: ptr(s.ptr), count(s.count)
{
++(*count);
}

/* more crap */
};




(blah, bugs)

Share this post


Link to post
Share on other sites
You ought to check the compiler regression test look for boost::is_base_or_derived, if it works anything like the Loki equivalent, is it not easy to make it work on most compilers.

Share this post


Link to post
Share on other sites
Andrew - Look at the code that's there now, I've finally checked it on GCC 4, and fixed my errors :)
MKH - good point

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Why not implement some cast operators? Works perfectly for me...

template
class SmartPointer
{
.... usual stuff here...
inline _T* operator -> () const
{
return ptr;
}

inline _T& operator * () const
{
return *ptr;
}

inline operator _T* () const
{
return ptr;
}
private:
_T *ptr;
}

Share this post


Link to post
Share on other sites
Because implicit conversion operators unveil a slew of small but subtle problems. It's very easy for the pointer to "escape" from the smart pointer, which can mess up your reference count (someone writes a function/class that takes a raw pointer and then holds onto it, if you pass this entity a smart pointer it will still accept it due to the conversion, but now the ref count is borked). And, it's easily possible to do a "delete sp", which due to the implicit conversion, will result in your pointer being deleted(!). That is why most smart pointers provide an explicit conversion to the raw underlying type; yes, it's still possible to do the things mentioned above, but it's much more obvious that they are being done.

And Fruny, is the if_base_and_derived test really neccesary? Shouldn't implicit pointer conversion rules essentially take care of the conversion issue (though granted, using it doesn't hurt and ensures a little more type safety, as I guess T could be something like void*)

Share this post


Link to post
Share on other sites
Correct me if I'm wrong, but don't the boost smart pointers do this?

#include <boost/smart_ptr.hpp>
using namespace boost;

class A {};
class B : public A {};

void smart_by_value( shared_ptr< A > a ) {}
void smart_by_const_ref( const shared_ptr< A > & a ) {}

int main ( int argc , char ** argv )
{
shared_ptr< B > b ( new B ) ;
shared_ptr< A > a ( b ) ; //implicit cast?
smart_by_value( b ); //implicit cast?
smart_by_const_ref( b ); //implicit cast?
}


I think boost handles this by having templatized constructors... it's been awhile since I've looked at the source though.

EDIT: Yup, checked the 1.32 source:
    template<class Y>
shared_ptr(shared_ptr<Y> const & r): px(r.px), pn(r.pn) // never throws
{
}
Fruny: What's the purpouse of the enable_if in your example? More precise error if the pointer can't be cast (read: Y is neither T nor derived from T)?

[Edited by - MaulingMonkey on May 26, 2005 7:22:15 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Why not implement some cast operators? Works perfectly for me...


As somebody already mentioned, implicit casting via overloading cast operators can lead to unforeseen subtle issues which can cause headaches to fix. That is why std::basic_string does not overload cast operator to implicitly convert to C style string but instead make it explicit via c_str method.

Generally prefer conversion constructors and/or explicit conversion via named methods as it states your intent, just the reason why the family of C++ cast operators are ugly. They explicitly state your intent, and easy to find.

Share this post


Link to post
Share on other sites
I'd put an enable_if because I wasn't thinking about the implementation of the class, I just wanted to disable conversion from X<A> to X< B> if A didn't derive to B. It's true that without it you'll still get an error, but (*clings desperately to the notion that he is right*) it will come from the class's internals rather than being a "can't convert X<A> to X< B>" error.

[Edited by - Fruny on May 26, 2005 9:50:39 AM]

Share this post


Link to post
Share on other sites
Fruny: Ahh, okay :-).

GCC 3.4.2 at least seems to grok a templatized conversion-to-another-shared_ptr operator as well, which some may find preferable. Example bellow includes errors as reported when attempting an invalid upcast:

//#include <boost/shared_ptr.hpp>
//using namespace boost;

template < typename T >
struct shared_ptr
{
T * pointer;
public:
explicit shared_ptr( T * pointer )
: pointer( pointer )
{
}
shared_ptr( const shared_ptr & other )
: pointer( other.pointer )
{
}

template < typename downcast_t >
operator shared_ptr< downcast_t > ( void ) const
{
//../main.cc:21: error: invalid conversion from `A* const' to `B*'
//../main.cc:21: error: initializing argument 1 of `shared_ptr<T>::shared_ptr(T*) [with T = B]'
return shared_ptr< downcast_t >( pointer ); //line 21
}
};

class A{};
class B : public A {};

int main ( int argc , char ** argv )
{
shared_ptr< B > b ( new B );
shared_ptr< A > a ( b );
shared_ptr< B > b2( a ); //../main.cc:32: instantiated from here
}




Following this idea, we can take this:
template <class U>
ASharedPtr<U> Cast() { return ASharedPtr<U>(ptr, count); }
And go like this:
template <class U>
operator ASharedPtr<U> Cast() const { return ASharedPtr<U>(ptr, count); }
And implicit casts should then work :-). Seems blatently obvious in hindsight, why didn't I think of that first ^_^.

Edit: <U> -> &lt;U&gt; escaping... bad underlines, no biscuts!!!

[Edited by - MaulingMonkey on May 26, 2005 9:23:16 AM]

Share this post


Link to post
Share on other sites
I guess there's nothing *wrong* with that implicit conversion approach. I still prefer to perform the conversion in the constructor however, especially since it eliminates the need to pass the reference count pointer as a parameter to the constructor:


template <class U>
ASharedPtr(const ASharedPtr<U>& other)
: ptr_(other.ptr_), count_(other.count_) {++*count_;}



Note that you can also put an explicit in there and force the user to perform essentially an explicit cast to do the conversion

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By khawk
      Watch the latest from Unity.
       
    • By GytisDev
      Hello,
      without going into any details I am looking for any articles or blogs or advice about city building and RTS games in general. I tried to search for these on my own, but would like to see your input also. I want to make a very simple version of a game like Banished or Kingdoms and Castles,  where I would be able to place like two types of buildings, make farms and cut trees for resources while controlling a single worker. I have some problem understanding how these games works in the back-end: how various data can be stored about the map and objects, how grids works, implementing work system (like a little cube (human) walks to a tree and cuts it) and so on. I am also pretty confident in my programming capabilities for such a game. Sorry if I make any mistakes, English is not my native language.
      Thank you in advance.
    • By Ovicior
      Hey,
      So I'm currently working on a rogue-like top-down game that features melee combat. Getting basic weapon stats like power, weight, and range is not a problem. I am, however, having a problem with coming up with a flexible and dynamic system to allow me to quickly create unique effects for the weapons. I want to essentially create a sort of API that is called when appropriate and gives whatever information is necessary (For example, I could opt to use methods called OnPlayerHit() or IfPlayerBleeding() to implement behavior for each weapon). The issue is, I've never actually made a system as flexible as this.
      My current idea is to make a base abstract weapon class, and then have calls to all the methods when appropriate in there (OnPlayerHit() would be called whenever the player's health is subtracted from, for example). This would involve creating a sub-class for every weapon type and overriding each method to make sure the behavior works appropriately. This does not feel very efficient or clean at all. I was thinking of using interfaces to allow for the implementation of whatever "event" is needed (such as having an interface for OnPlayerAttack(), which would force the creation of a method that is called whenever the player attacks something).
       
      Here's a couple unique weapon ideas I have:
      Explosion sword: Create explosion in attack direction.
      Cold sword: Chance to freeze enemies when they are hit.
      Electric sword: On attack, electricity chains damage to nearby enemies.
       
      I'm basically trying to create a sort of API that'll allow me to easily inherit from a base weapon class and add additional behaviors somehow. One thing to know is that I'm on Unity, and swapping the weapon object's weapon component whenever the weapon changes is not at all a good idea. I need some way to contain all this varying data in one Unity component that can contain a Weapon field to hold all this data. Any ideas?
       
      I'm currently considering having a WeaponController class that can contain a Weapon class, which calls all the methods I use to create unique effects in the weapon (Such as OnPlayerAttack()) when appropriate.
    • By Vu Chi Thien
      Hi fellow game devs,
      First, I would like to apologize for the wall of text.
      As you may notice I have been digging in vehicle simulation for some times now through my clutch question posts. And thanks to the generous help of you guys, especially @CombatWombat I have finished my clutch model (Really CombatWombat you deserve much more than a post upvote, I would buy you a drink if I could ha ha). 
      Now the final piece in my vehicle physic model is the differential. For now I have an open-differential model working quite well by just outputting torque 50-50 to left and right wheel. Now I would like to implement a Limited Slip Differential. I have very limited knowledge about LSD, and what I know about LSD is through readings on racer.nl documentation, watching Youtube videos, and playing around with games like Assetto Corsa and Project Cars. So this is what I understand so far:
      - The LSD acts like an open-diff when there is no torque from engine applied to the input shaft of the diff. However, in clutch-type LSD there is still an amount of binding between the left and right wheel due to preload spring.
      - When there is torque to the input shaft (on power and off power in 2 ways LSD), in ramp LSD, the ramp will push the clutch patch together, creating binding force. The amount of binding force depends on the amount of clutch patch and ramp angle, so the diff will not completely locked up and there is still difference in wheel speed between left and right wheel, but when the locking force is enough the diff will lock.
      - There also something I'm not sure is the amount of torque ratio based on road resistance torque (rolling resistance I guess)., but since I cannot extract rolling resistance from the tire model I'm using (Unity wheelCollider), I think I would not use this approach. Instead I'm going to use the speed difference in left and right wheel, similar to torsen diff. Below is my rough model with the clutch type LSD:
      speedDiff = leftWheelSpeed - rightWheelSpeed; //torque to differential input shaft. //first treat the diff as an open diff with equal torque to both wheels inputTorque = gearBoxTorque * 0.5f; //then modify torque to each wheel based on wheel speed difference //the difference in torque depends on speed difference, throttleInput (on/off power) //amount of locking force wanted at different amount of speed difference, //and preload force //torque to left wheel leftWheelTorque = inputTorque - (speedDiff * preLoadForce + lockingForce * throttleInput); //torque to right wheel rightWheelTorque = inputTorque + (speedDiff * preLoadForce + lockingForce * throttleInput); I'm putting throttle input in because from what I've read the amount of locking also depends on the amount of throttle input (harder throttle -> higher  torque input -> stronger locking). The model is nowhere near good, so please jump in and correct me.
      Also I have a few questions:
      - In torsen/geared LSD, is it correct that the diff actually never lock but only split torque based on bias ratio, which also based on speed difference between wheels? And does the bias only happen when the speed difference reaches the ratio (say 2:1 or 3:1) and below that it will act like an open diff, which basically like an open diff with an if statement to switch state?
      - Is it correct that the amount of locking force in clutch LSD depends on amount of input torque? If so, what is the threshold of the input torque to "activate" the diff (start splitting torque)? How can I get the amount of torque bias ratio (in wheelTorque = inputTorque * biasRatio) based on the speed difference or rolling resistance at wheel?
      - Is the speed at the input shaft of the diff always equals to the average speed of 2 wheels ie (left + right) / 2?
      Please help me out with this. I haven't found any topic about this yet on gamedev, and this is my final piece of the puzzle. Thank you guys very very much.
  • Advertisement