I disagree. Elimination of temporaries is the whole point of the placement operator. Otherwise, you might as well write it as Box::new(try!(make_value()))
Box::new
was never supposed to exist.
Sadly, it might be a bit late for universal placement, but the goal was to have a single way to allocate/emplace, with maximal efficiency and minimal syntactical overhead.
If successful, Box::new
, Vec::push
etc. will be deprecated.
Vec::push
cannot be deprecated because there are two possible semantics here - push to the vector and fail if there is no more capacity, or push and reallocate the entire vector if necessary. Unless the API will dictate to replace the latter semantics, arguably the common case atm, with a capacity check before pushing to the vector. Seems to me that such a choice will make for a bad API experience. The former is really an âemplaceâ as itâs called in C++ land, or better yet, âtry_pushâ.
In C++ land, emplace_back
most certainly will reallocate the vector if it is currently at capacity.
Even plain emplace
will reallocate as needed. Itâs just insert
with running the constructor in-place.
Ok, Iâm confused⌠Why than does C++ need to have both push_back() and emplace_back()? Whatâs the difference?
In any case, shouldnât there be at least some method to indicate where to push/emplace to, e.g. push_front vs. push_back?
This avoids calling an object's copy constructor or move constructor by simply constructing it in place. Since Rust doesn't have move constructors this isn't as much of an issue.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.