Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Event default construction #60

Open
MrBurmark opened this issue May 11, 2021 · 6 comments
Open

Event default construction #60

MrBurmark opened this issue May 11, 2021 · 6 comments

Comments

@MrBurmark
Copy link
Member

Currently type erased Event can be default constructed but typed events can not. This makes it difficult to make something like a vector of events to record and use later. Does it make sense to allow all events to be default constructable?

@trws
Copy link
Member

trws commented May 11, 2021

That's a bit scary actually, type erased event shouldn't have been default constructible. Given that they are, we may end up doing that with the default state fulfilled I suppose, but it will take a bit of thought.

@MrBurmark
Copy link
Member Author

MrBurmark commented May 11, 2021

I'm not sure what's the best way to make events easier to use in containers without letting them end up in strange states. I probably should have made the issue about that rather than default constructibility. I can lose that as long as there is a way I can use them without resorting to placement new.

@trws
Copy link
Member

trws commented May 11, 2021

My preference would be that they are not default constructible, but that either:

  1. we provide, or require a std that provides, an option type to hold them so that doesn't matter
  2. we make them easy to emplace into a container

The second should work fine now as far as I know, building a vector of them by emplace_back for example. The former would be useful for other things as well, I just haven't prioritized it.

@trws
Copy link
Member

trws commented May 11, 2021

I should say that I'm not sure 2 is good enough, if you want to construct a full array (rather than reserve but not instantiate) it can be a pain to rework to that pattern. It would help to know how painful that would be for your use-cases.

@MrBurmark
Copy link
Member Author

The main reason I didn't mention emplace is the case where I allocate space for a full array and only actually use a subset of the objects. I have a std optional clone somewhere else for a similar use case so I don't mind case 1.

@trws
Copy link
Member

trws commented May 11, 2021

Right, that's where you need uninitialized objects, and it's kinda painful. If you're using vector you can use reserve to get there, but it's not necessarily ergonomic.

Do you have the optional clone somewhere where we could consider including it in camp?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants