-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
<deque> : A deque<T> where T is move-only, when nested in vector, does not compile #1036
Comments
I believe this is the "constrained copy constructor" problem. Technically, our implementation is conformant, but the result is a terrible user experience; see my explanation on reddit for the tale of misery. While the root cause is the Standard's inability to constrain container copy/moves, our implementation's longstanding choice to dynamically allocate sentinel nodes (and proxies) makes this a more common problem with our STL than libstdc++ or libc++. My thinking on this has evolved somewhat over the years; while we certainly can't do anything for v19 due to ABI, for vNext we should probably consider each container independently:
|
What is the problem with sentinel nodes that is solved by making them heap allocated? Is this the validity of
|
How about this, have two incarnations of sentinel node:
This way:
|
How would we implement decrement for this |
I see, apparently there's no good solution without heap-allocated sentinel node. Then what is the problem with moving? Can't sentinel nodes of source and destination of move be just swapped? |
For move assignments, yes, but for move constructions the newly-constructed container doesn't have a node to swap until it allocates one. Allocation means that move constructor cannot be |
The newly allocated node in move constructor may go to either new container or to the old one. Can null pointer go to the old one instead of valid sentinel? Old container is going to be re-assigned or deleted anyway. Or, more generally, can it be allocated lazily? |
Lazy allocation isn't viable - A moved-from container must be in a "valid but unspecified state", supporting all preconditionless member function calls. During the final years of C++0x as it was finalized into C++11, as a junior implementer (who hadn't attended any Committee meetings), I partially understood the relevant issues and argued on the mailing lists that moved-from objects should be allowed to have an "emptier than empty" state, where only certain member functions would be permitted (obviously destruction; assignment destination would be desirable, possibly assignment source and swap, etc.). I was unable to persuade anyone, and it probably wasn't a great idea, but I tried. |
Describe the bug
A
deque<T>
whereT
is move-only, when nested invector
, does not compile.Command-line test case
Expected behavior
Should compile
STL version
Additional context
Other repro:
Yet another repro:
Also tracked as:
The text was updated successfully, but these errors were encountered: