Archived

This topic is now archived and is closed to further replies.

capn_midnight

C++ Template Classes

Recommended Posts

okay, I have a class:
  
template <class T>
class c_MyClass{
   private:
      T a, b;

   public:
      T add(T,T);  //easy to implement

      c_MyClass &func(c_MyClass&);  //I have no clue how to implement

};

//I know this is right

template <class T>
T c_MyClass<T>::add(T da, T db){
   a+=da;
   b+=db;
}

//But I don''t think this is right

template <class T>
c_MyClass<T> &c_MyClass<T>::func(c_MyClass<T> &cmc_X){
   c_MyClass<T> temp;
   //operations on temp;

   return temp;
}
  
I tried www.cplusplus.com and all my books, but none of them have examples where you either return the class or have a parameter of the class.

Share this post


Link to post
Share on other sites
Like that, except the prototype needs to be defined as returning the full form, not the template.

[edited by - DrPizza on March 19, 2002 2:23:15 PM]

Share this post


Link to post
Share on other sites
I didn''t take a look in depth, but it''s best to do in-line definitions when you''re doing templated classes:


  
template <class T>
class foo{
T data;
public:
T func(T whatever){
return data;
}
}

Share this post


Link to post
Share on other sites
okay, so I should have:


  
template <class T>
class c_MyClass{
public:
c_MyClass<T> &func(c_MyClass<T>&);
};

template <class T>
c_MyClass<T> &func(c_MyClass<T> &cmc_X){
c_MyClass<T> temp;
//code for stuff on temp

return temp;
}


right?

Share this post


Link to post
Share on other sites
  
template <class T>
c_MyClass<T> &c_MyClass<T>::func(c_MyClass<T> &cmc_X){
c_MyClass<T> temp;
//code for stuff on temp
return temp;
}


Of course, you shouldn''t be returning a reference to a temporary, but that''s a different matter...

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
...a matter that can be resolved by removing the little ampersand symbol on the return-type. Cue complaints about "but that would be a performance problem"...

Share this post


Link to post
Share on other sites
It wouldn''t. That''s what I would recommend as well, unless the class was rediculously large/had a very expensive constructor and was called several (hundred) times so as to directly influence performance. My vector and matrix classes which generate a third value result use this convention without problem.

In short, I concur with SabreMan.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
My compiler doesn''t do named return value optimization , so it isn''t particularly desirable to do that, as it will require a copy.

Unnamed return values are optimized properly (i.e. constructed on the stack of the caller, not constructed on the stack of the callee and then copied to the stack of the caller), so are generally preferable, if possible.

Share this post


Link to post
Share on other sites
quote:
Original post by DrPizza
My compiler doesn''t do named return value optimization , so it isn''t particularly desirable to do that, as it will require a copy.

That''s a shame, but I still think the original intention should be kept intact until it is determined to be a problem. If you''re talking about MS, then I''ve just tried V6 and you''re right: it doesn''t do NRV. Bugger! Do you know if the new compiler implements this?

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
That''s a shame, but I still think the original intention should be kept intact until it is determined to be a problem. If you''re talking about MS, then I''ve just tried V6 and you''re right: it doesn''t do NRV. Bugger! Do you know if the new compiler implements this?


Unfortunately, it doesn''t seem to. It''s quite surprising (as it''s for most things the best x86 optimizing compiler I''ve used, this being the most obvious deficit) but there we go.

Maybe version 14 (or whatever the possible VS.NET 7.1 release will be called) will have it....

If that release materializes and does what is suggested, it should be very nice indeed.

Share this post


Link to post
Share on other sites