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

Weak exception safety for flat_{set,map}::assign*() #3

Open
Gregory-Meyer opened this issue Jul 12, 2018 · 1 comment
Open

Weak exception safety for flat_{set,map}::assign*() #3

Gregory-Meyer opened this issue Jul 12, 2018 · 1 comment

Comments

@Gregory-Meyer
Copy link

In flat_set::assign, the container only provides the basic exception guarantee if memory cannot be stolen from the input and the ::reserve() allocation throws. In addition, since input_view does not specify that its value_type is nothrow move or copyable, the operation may again fail during the translation of elements from the view into the set.

array_.clear();
array_.reserve(input.size()); // <-- might throw here, leaving the container empty

// insert all elements individually
for (auto& element : input.view())
{
    if (input.will_copy())
        insert(element); // <-- could also throw here, leaving a partially filled container
    else
    {
        // safe, according to precondition of input view,
        // we're allowed to move them
        auto& non_const = const_cast<Key&>(element);
        insert(std::move(non_const)); // <-- or here
    }
}

It looks like you are already aware of this, given the TODO comments in flat_map's assign* functions:

template <typename InputIt>
void assign_pair_range(InputIt begin, InputIt end)
{
    // TODO: exception safety
    clear();
    insert_pair_range(begin, end);
}

A simple solution to add strong exception safety would be to create a new flat_set from the input range and swap if there was no exception thrown.

@foonathan
Copy link
Owner

Yes, I'm aware of the issues.

I need to think about my exception safety policy for this library first, before fixing it. Right now I'm tending to providing the strong exception safety if a type has nothrow move constructors.

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