« first day (3001 days earlier)      last day (28 days later) » 

8:54 AM
@Almo i for one am shocked
 
 
5 hours later…
1:58 PM
:O
 
precisely
 
 
2 hours later…
3:49 PM
LevelScene owns a private std::vector<std::unique_ptr<Entity>>
The destructor of LevelScene in the source file: LevelScene::~LevelScene() = default
I include Entity.h in LevelScene.cpp
Level inherits LevelScene
Then if I have a unique_ptr of a Level inside MenuBackground, and a unique_ptr of MenuBackground in some other class, I get errors about deleting an undefined type "Entity"
Is it not enough that the definition of Entity is available in LevelScene.cpp, where the destruction takes place?
 
I don't think so
wait
forget I said it
got confused, sorry
 
yeah sorry I know it's not a very clear description of the problem, but I didn't want to skip an abstraction step in case that ends up being the dealbreaker
 
:)
 
@Tyyppi_77 The destruction takes place in the destructor of std::vector, which takes place is the destructor of LevelScene, which is effectively in the header file where you presumably only have "struct Entity;" forward declared?
 
yup, only a forward declaration
How would I make the destructor of LevelScene happen effectively in the source file then?
 
4:04 PM
Declare it in the header: ~LevelScene();
Implement it in the source file: LevelScene::~LevelScene(){}
 
So it's the = default that fucked me up huh?
 
Basically yeah.
 
I was under the impression that it was equivalent to {} in the source file
Well that's sort of annoying I guess, thanks a ton once again though
 
It's a little wonky
An implicitly declared destructor is an inline public member of the type. One that is defaulted but not deleted is implicitly defined when it is either odr-used or when it is explicitly defaulted after its first declaration
Which I think in theory allows you to do some dumb shenanigans to maybe make it work , but in my experience it's clearer to just define the stupid destructor as empty, even though it looks silly
 
Yeah I'm totally fine with doing that, not really sure where I even adopted the habbit of turning empty destructors in source files to =default
Ugh, still getting the same errors in <memory> :(
 
4:12 PM
There's some other complexity around it too, because the simple case works:
 
hello everyone!
 
ahoy! o/
 
Elsewhere, I was having a discussion with somebody else about this issue; he thinks this is wrong/and-or a bug and should be legit (and certainly the correct simple case proves that), but people still seem to run into it
 
Here's the full error, this is still after I made LevelScene have an empty destructor instead of a default one
Something about LevelEntityData, which does also hold a std::unique_ptr<Entity>, but that has an empty destructor in a source file too?
 
Hm, maybe this is different from what I was thinking. What's Level.h look like, and what are the top lines of StateLoad.cpp? (all the #includes basically?)
 
4:19 PM
The line 30 in Level.h is a forward declaration of Entity
The actual level in StateLoad is inside another type, CStateMainMenuBackground m_Background;
 
4:38 PM
yeah man I am just full of confusion, I think I'll fix all the trivial errors first and then come back to wondering what the fuck is going on with these <memory> errors
 
Yeah I dunno. It's, ime, hard to diagnose them entirely without seeing the full code.
 
Yeah I totally understand that
I am not also in the sharpest mood while I'm stuck here, I'm much more productive at home during the weekends
 
 
2 hours later…
6:41 PM
1
Q: Object made of cubes looks different based on the distance in Unity3D?

TudvariI made a "Wall" from basic Unity3D cubes. They are placed tightly so the wall looks like one big rectangular prism. If I look at it from close distance, it looks as it should be: one big rectangular prism. But if I start moving backwards, away from the wall, the cubes' edges become visible: ...

 

« first day (3001 days earlier)      last day (28 days later) »