-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Copy constructor for C++ Object API #5783
Comments
I agree that generating an explicit copy contructor would make sense.. care to create a PR for that? |
This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days. |
Commenting to prevent the issue from automatically closing. Looks like a fix is imminent though still pending with #5988. |
Thanks. Sorry for the lack of updates, I've been busy. Will get to it... |
This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days. |
Augment the C++ generator to emit a C++ copy constructor and a by-value copy assignment operator. This is enabled by default when the C++ standard is C++11 or later. These additional functions are only emitted for objects that need it, typically tables containing other tables. These new functions are declared in the object table type and are defined as inline functions after table declarations. When these new functions are declared, a user-defined explicitly-defaulted default constructor and move constructor are also emitted. The copy assignment operator uses the copy-and-swap idiom to provide strong exception safety, at the expense of keeping 2 full table copies in memory temporarily. fixes #5783
Flatbuffer objects in the C++ Object API cannot be copied if they include other tables as elements due to the use of std::unique_ptr to reference the other tables.
For example, the schema
compiles to
noting that
std::unique_ptr
disallows copying. Thus, I cannot copy instances ofFooT
without considerable code verbosity (e.g., packing and unpacking theFooT
instance).My understanding is that the Object API is designed to increase convenience in instances where non-copy constraints are relaxed, and so it seems a bug not to bless them with a copy constructor.
The text was updated successfully, but these errors were encountered: