SiCrane

I wouldn't go so far as to say that a base class implementing the copy/move operations or the destructor is a strong indication that a derived class should. The compiler generated defaults will call the base class versions. If your base class requires derived classes to do anything more than that then that's a pretty good indication that the base class versions are implemented incorrectly.

It is inherited. However, unlike other operators, a derived class will generate an implicitly defined assignment operator that will hide the base class version. However, with explicit qualification the derived class can access the base class version if it wants to.

std::shared_ptr works by creating a reference count object on the heap and storing the number of live shared_ptrs in that object. However, COM objects already do reference counting through AddRef() and Release(), so there's no need to create this extra object. Hence, it's generally better to use a smart pointer that knows about the AddRef() and Release() functions and use that. One example is the CComPtr class in ATL, though there are other smart pointers designed to work with COM out there.

First note: your Player class isn't POD. In order to be POD all the member variables also have to be POD and your Player class contains a std::string object. As for overloading the assignment operator, if you don't define an assignment operator the compiler will define an assignment operator that does a member by member assignment. If you want your assignment operator to do something different than calling the assignment operator for each of the member variables then you create your own assignment operator implementation.

Every time you use push_back() to put something in a vector, the vector makes a copy of the object you pass it. If you pass push_back() a temporary object, the vector will make a copy of the temporary and then the compiler will destroy the temporary. It's also possible that they way you're reading from the vector is also generating extra temporary objects.

 

How are you tracking your CUnit destruction? It's entirely possible that you aren't seeing matching construction and destruction counts because you aren't tracking copy constructor calls.

I don't really see the point. If you try calling a member function on a class that doesn't support it you'll get a compiler error even without any tricky base class usage.

If you create a pointer to a member function for a virtual function what you'll get is a member function pointer that always calls the most derived function implementation for that virtual function.

One way to debug heap corruption on Windows is to use Application Verifier, in particular the page heap functionality.

Rather than first creating a string and then parsing the contents to create an array, it would probably make more sense to create the array first and generate the string from the array (for example with String.Join()).

On Windows, I constantly use cygwin, which gives you the common *nix applications for Windows. This includes text tools like grep and tail as well as development tools like gcc, clang, make, git, svn, and so on.

It's possible, but a really bad idea. One way:

template <int i> struct BaseHelper : FBO2D {
  // add appropriate forwarding functions
};

struct FBOCube : BaseHelper<0>, BaseHelper<1>, BaseHelper<2>, BaseHelper<3>, BaseHelper<4>, BaseHelper<5> {
};

Are you sure that you're calling init() on a valid object?

As a side note, you're passing std::vector objects around by value which can be rather inefficient; you may want to switch to pass by reference instead.

You can form a valid C++ statement by placing a semi-colon after an expression. A string literal is a expression.

You probably want to read this article.

You might be able to use mbstowcs() to do so. If you gave more information, like what platform you are using then a more confident answer could be given.