Game Development

« first day (3001 days earlier) ← previous day next day → last day (2004 days later) »

doppelspooker

8:54 AM

@Almo i for one am shocked

5 hours later…

Almo

1:58 PM

doppelspooker

precisely

2 hours later…

user92578

3:49 PM

LevelScene owns a private std::vector<std::unique_ptr<Entity>>

user92578

The destructor of LevelScene in the source file: LevelScene::~LevelScene() = default

user92578

I include Entity.h in LevelScene.cpp

user92578

Level inherits LevelScene

user92578

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"

user92578

Is it not enough that the definition of Entity is available in LevelScene.cpp, where the destruction takes place?

Almo

3:51 PM

I don't think so

wait

forget I said it

got confused, sorry

user92578

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

Almo

user4704

@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?

user92578

yup, only a forward declaration

user92578

How would I make the destructor of LevelScene happen effectively in the source file then?

user4704

4:04 PM

Declare it in the header: ~LevelScene();

user4704

Implement it in the source file: LevelScene::~LevelScene(){}

user92578

So it's the = default that fucked me up huh?

user4704

Basically yeah.

user92578

I was under the impression that it was equivalent to {} in the source file

user92578

Well that's sort of annoying I guess, thanks a ton once again though

user4704

4:06 PM

It's a little wonky

user4704

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

user4704

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

user92578

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

user92578

Ugh, still getting the same errors in <memory> :(

user4704

There's some other complexity around it too, because the simple case works:

user4704

4:12 PM

godbolt.org/z/0bOXRq

Gabriele Vierti

hello everyone!

doppelspooker

ahoy! o/

user4704

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

user92578

pastebin.com/ahJd3RGE

user92578

Here's the full error, this is still after I made LevelScene have an empty destructor instead of a default one

user92578

4:17 PM

Something about LevelEntityData, which does also hold a std::unique_ptr<Entity>, but that has an empty destructor in a source file too?

user4704

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?)

user92578

The line 30 in Level.h is a forward declaration of Entity

user92578

The actual level in StateLoad is inside another type, CStateMainMenuBackground m_Background;

user92578

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

user4704

Yeah I dunno. It's, ime, hard to diagnose them entirely without seeing the full code.

user92578

Yeah I totally understand that

user92578

I am not also in the sharpest mood while I'm stuck here, I'm much more productive at home during the weekends

Free Internet Points

6:41 PM

Q: Object made of cubes looks different based on the distance in Unity3D?

I 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: ...