Hi all,

We all know it's good to inline Get function :

inline float GetData() const
{
  return m_Data;
}

Now my question is : Is it good to inline clone function ?

inline IBase* Clone() const
{
  return new ThisClass;
}

Thanks

Both of those functions look like they would be declared within a class definition in an example that compiled - they do not look written to compile without being inside of a class - and if they are inside of a class definition, they are inline functions by default.

Now my question is : Is it good to inline clone function ?

inline IBase* Clone() const
{
return new ThisClass;
}

I'm going on a stretch by saying that this won't give you any advantage here in 99% of the cases really. Think about one possible usage, like in such a method:

void DoSomethingWithBase(const IBase& base)
{
       // do some other stuff
       auto pNew = base.Clone();
       // do something with pNew
}

The compiler won't be able to inline this function at all, since you could pass in every possible class that overrides the clone method in every way imaginable, so that method might differ here based on the type of object passed in here. The compiler, in most cases, can only inline the function if it knows the type of the object for sure, and this is valid for most/all virtual methods.

There is nothing inherently wrong with it, but returning a raw pointer can lead to memory leaks. Would be safer to return a unique_ptr or shared_ptr (assuming C++).

The clone is used for load/save from file based on a factory, the factory is global and cleared on shutdown of the engine.

But you right that it's one thing to be safe when using it outside this scope.

I'm going on a stretch by saying that this won't give you any advantage here in 99% of the cases really.

That mean that should be avoided and have the Clone() inside a .cpp ?

That mean that should be avoided and have the Clone() inside a .cpp ?

It means that it is not worth doing so for reasons of performance and (especially permature) inlining optimization. Its as Apoch has pointed out. In that regard, yes, you should define Clone() in the cpp, because this gives better code readability, and unless it proves by profiling that 1.) the Clone()-function call itself is a major bottleneck and 2.) inlining it manually by putting it into the .h file and adding the "inline" keyword/compiler hint solves that, always prefer the code that is more readable. This does not only apply here, but for the rest of your code also.

Every sane version of clone() would be a virtual method (or there would be no point having a clone() method) in which case, assuming you are calling through a base pointer, it can't be inlined anyway.

Ok if a function is always called from base class (virtual) so it can't be inlined and must be in .cpp.

What's about destructor ? Has it a problem about inline ?