All right, service day is over, time for some smart pointers

Having to restructure quite a bit of code since previously I've just been allocating child entities before spawning the entity into the level, but now I can't really do that since the level must take ownership of any entity I allocate

So I end up having to save up a bunch of state that's required to initialize the child objects properly

I'm trying to avoid storing any std::unique_ptrs "temporarily" in the entity classes

it's very true, this stuff makes me excited while everything else here does not

I balance myself between those two positions

When I feel like doing massive refactorings of the codebase, I do those

And when I feel like implementing a new gameplay mode, I make one

Probably, but that just seems like a much larger refactor since I do not currently use ECS

Also don't really feel like redoing the whole entity/level code in the game

Also I don't necessarily currently need to get anything done

I have a patch that I need to test and release that uses a stable branch, this is stuff that I do while I procrastinate pushing the update live

My biggest annoyance currently is the fact that std::make_unique doesn't provide IntelliSense help for the constructor parameters

it also interferes with friending

and compiler errors when you screw up the parameters are poor

Yeah I already ran into the friend thing, sort of, with a singleton that had a private constructor

Well sort of into the friend thing

In general, compiler support around handling the "real" point of failure in forwarding functions via parameter packs could use some love, but it's a tough problem

Since ContentLoader::Create couldn't make_unique<ContentLoader> when the content loader has a private constructor

Yep.

I think I ended up using the trick where I inherit ContentLoader into a struct and make the constructor public with using inside Create

I just don't use make_unique in those cases, but that works too.

What do you use instead? std::unique_ptr(new ...)?

Yeah

Unlike make_shared, make_unique doesn't afford any optimizations.

It prevents (until recently) certain classes of bugs due to parameter evaluation order, but I generally don't end up needing it to protect me against that, so I just call new.

I'm sort of dreaming that once I'm done, I'll have a codebase with zero news, hence the struct trick

Dunno if that's really something to strive for, probably a better goal would be a codebase with zero deletes

I guess, I think once you know why you "shouldn't use new ever" you can be free to ignore it.

It's like of like "100% code coverage" in tests: okay, sure, doable, but at what cost and was that cost really worth it?

yeah

Down to 112 errors

These all come from <memory> though, and all are about deleting an incomplete type "CEntity"

No idea what's going on

Yeah so the <memory> errors happen inside a file that doesn't even use CEntity, wtf is going on?

Is the offending code on GitHub someplace?

It's on BitBucket where I could give you access to the project but I don't think you want to try building GunHero

Not a one-click build process? :D

Most likely not, that has not been my priority since it's just me working on it, some stuff (like the Steamworks API headers) aren't at all in the repo and then there's some build-step Python stuff happening and so on

std::vector<std::unique_ptr<CEntityBullet>> CEntityWeaponGunBehaviourCharge::CreateBullets(CLevel* level) const
{
	std::unique_ptr<CEntityBullet> bullet = m_BulletFactory->Create(level, m_Gun);
	static_cast<CEntityBulletPlasma*>(bullet.get())->SetSubdivisionCount(CalculateSubdivisionCount());
	return { std::move(bullet )};
}

So for an example this errors on the line with the opening curly brace?

With the error about "using undefined type CEntityBullet"?

No that's about attempting to reference a delete function

The undefined type stuff either doesn't give out a line, or just references a forward-declaration of CEntity in Level.h

A deleted function of CEntityBullet? Is there a cascade of other errors after the first talking about candidate functions?

pastebin.com/tb9X7Rk7

A deleted function of std::unique_ptr it seems

But why? And why on the brace?

Wait whoops wrong error

pastebin.com/WfTfJeyy

That one corresponds to the code I showed, line 60 is the method name, 61 is the curly brace

The beginning of that boils down to: unique_ptr<S>::unique_ptr(const unique_ptr<S>&) is explicitly deleted, I believe.

Which makes sense (that's the copy ct)

Is CEntityBullet movable?

I have no idea, so I'm guessing no?

Is this some sort of "cant put unique_ptrs in a vector" thing?

No, you can put them in a vector because they can be moved.

And they shuoldn't disable moving if their T can't be moved because you don't need to move T to move the pointer.

Yeah that's what I thought, it shouldn't really matter what's in the unique_ptr

what's Centitybuillet look like?

Bullet factory implements an interface that always return unique_ptr<CEntityBullet>

Here's CEntityBullet: pastebin.com/0xX23EWK

I don't see anything in CEntityBullet that would upset unique_ptr, offhand.

These are the two types of errors I have left, this one, and the one about CEntity being incomplete in bunch of super random places

ah

wow nice

because you can't copy a vector with a bunch of unique_ptrs in it

I think I might still be compiling in C++14

So... how do I fix this? std::unique_ptr<std::vector<std::unique_ptr<CEntityBullet>>>?

no outer unique_ptr

I'd don't think it's a "not eliding" issue

yep: std::vector<std::unique_ptr<CEntityBullet>> result{std::move(bullet)}; does the same thing, and you can then "return result" fine.

if you result; result.emplace_back(move crap here)

something about how the brace initialization parses is making it do something unexpected

yeah

seems viable

godbolt.org/z/rdXfEK

well that's kinda stupid

thank you so much once again guys

I vaguely recall reading something about this once, about how brace-init can interfere with constructors that take std::initializer_lists or some such

I never use brace-init, really, so I've never actually encountered it and I'm not clear on the details

I use it when it's handy, like this case

I'm not sure hair-pulling for hours constitutes "handy" but... :P

Well it was handy when it was just plain pointers and it just worked (tm)

:D

I so much appreciate the help, I gotta head off so that I can take a shower before they'll count us and make sure we're all still stuck here :D

good luck

@GabrieleVierti Except you wouldn't need to "reverse engineer" anything if you have the source code like that, and if you just have the executable none of that matters :P