Not per se - it depends on how you implement it.
Unless the compiler can optimise that away, it sounds bad. Allocating the object, running its constructor (even if allocated on the stack), copying over the data, finally running the deconstructor and deallocating (heap is much worse than stack).Suppose I have the position in a class. In order to check a move, I create a new instance/object and that happens recursively. Woeld this somehow impact performance negatively?
If, however, you hand over your object by reference (i.e. basically handing around pointers to the object) and modify / unmodify it, then you don't instantiate anything during search. Obviously, you then need to think about how to manage your move stack - instead of piling up that stack in the form of position objects, you could have that as object member. Like, current position and move stack inside the object. You'd also have a make_move() member function that takes the move to make on the board member. It would modify the board member and push this move on the stack member. Then also an move_unmake() function that pops the top move from the stack and reverts that move in the board member.
