为什么成员函数中的“ this”指针为空？

Question

I don't want to show you a book so i am going to simplify. I have a class called "Tile" that looks similar to this:

class Tile{
public:
   struct Type{ unsigned int uvIndex; ... };
   Tile(Tile::Type* tt){ tt_ = tt; ... }
   Type tt_ = nullptr;
   Tile* getNorthEast(){
       printf("this %p\n", this); //for debugging purposes
       /* calculation; "this" pointer is need for that  */
       return northEastTilePtr;
   }
};

I want to allocate many of them in one big array that will never move again (no need for a ) so i do that allocation manually

//Manual allocation to prevent constructor from being called
Tile* tiles = (Tile*)malloc(numTiles*sizeof(Tile));
if(tiles == nullptr) throw std::bad_alloc();

Since the Tile type is not known at first i cannot call new to do that. Now i have memory allocated, but no constructors called. The world generator runs and calls for each tile

tiles[tileIndex] = Tile(tileTypePtr);

Now it should have created all objects with all types. If I render the scene and without calling getNorthEast(); I can see, that the types have been set correctly due to the uvIndex (that just specifies which section of the texture to render). So tt_ is set correctly and the constructor must have run correctly too. However! If i now call getNorthEast(); the printf statement tells me that the this pointer is 00000000 . This messes up the calculation and results in a crash.

It probably is due to undefined behaviour, but I do not see what I am doing wrong... I need your help for that.

EDIT 1: So I have now had a look at placement new. I have changed the allocation and assignment to:

//allocation 
tiles = (Tile*)new char[numTiles*sizeof(Tile)];
//assignment
new (&tiles[tileIndex]) Tile(tileTypePtr);

However this is still a nullptr. This time the assignment should be a complete overwrite without undefined behaviour. The allocation does essentially the same thing as std::vector.reserve() ;

Additional Info: the getNorthEast() is called much later in the main loop. Right now is just initialisation. It should therefore have no impact on wether the object is constructed or not.

Edit 2: I have just re-tried using a vector. same result.

std::vector<Tile> tiles;
//allocation
tiles_.reserve(numTiles);
//construction for each index
tiles.emplace_back(Tile(tileTypePtr)); 

Since neither vector nor doing it manually worked even with your input, i am starting to suspect the cause is some that I have not mentioned. I will keep looking until I find something else, that could cause trouble.

Answer 1

 tiles[tileIndex] = Tile(tileTypePtr); 

What this does is it creates a temporary Tile instance, and then (move-) assigns that temporary into the Tile instance that (is supposed to) exists in the array. But that Tile instance doesn't exist, so the behaviour of the program is undefined.

Here is a correct way to construct an object into a pre-existing memory buffer:

 // you can use malloc, but I see no reason to need it
 unsigned char *buffer = new unsigned char[numTiles*sizeof(Tile)];
 auto offset = sizeof(Tile) * tileIndex;
 Tile* tptr = new(buffer + offset) Tile(tileTypePtr);

This syntax that reuses the memory for a new object is called "placement new". You need to include the <new> header to use it.

However, there is no need to re-implement this buffer reuse yourself. std::vector<Tile> does it for you, in addition to taking care of the hazardous memory management as well as the subtleties of exception safety and pointer aliasing rules. You've already tripped onto one caveat. There is no need to jump onto the next one. std::vector is usually the ideal solution for dynamic arrays of non-default-constructible types.

---

Edit: The answer below is based on my initial interpretation that you intend to have objects of different types in your array. I now notice that you have a Type pointer in your object and figure that you might actually be storing only Tile instances with different internal Type pointer (I assume that tt_ is supposed to be a pointer).

However, your structure seems a bit shaky. Have you considered how does the user of the array know what type of Tile you have constructed in which index? Have you considered that all objects in the array must have identical sizes and alignment requirements? None of those considerations can be enforced by the compiler.

If you know the list of possible tile types beforehand, I suggest using:

// let Tile1, Tile2, Tile3 be the possible types
std::vector<std::variant<Tile1,Tile2,Tile3>>

If you cannot constrain the list of types, then you can use:

std::vector<std::any>