You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This one hit me with a bit of surprise but I guess there might be a rationale (caching related), but couldn't find the answer.
I have some list items containing weak pointers that I would like to transform (weak.lock()) then filter (!= nullptr) where it may be destructed by another thread simultaneously, but I noticed a race condition where it passed the filtering but was still null.
auto items = std::vector<std::weak_ptr<my_type>>{};
// [..] - fill with itemsauto range = items |
views::transform(
[](autoconst& w)
{
return w.lock();
}) |
views::filter(
[](autoconst& s)
{
return s != nullptr;
});
// while filtering the owner might have released the object.auto res = std::vector<std::shared_ptr<my_type>>{std::begin(range), std::end(range)};
I might be totally wrong here, but conceptually I imagine it as transform extracting the instance of interest, forward (as-is, lifetime intact) to the filter which again maintains the lifetime so the end result can only be a non-null shared pointer.
Is this a bug or have I just misunderstood it?
The text was updated successfully, but these errors were encountered:
helmesjo
changed the title
vector<weak_ptr> returns null-pointer after filtering: ... = items | transform(/* ptr.lock() */) | filter(/* ptr != nullptr*/)vector<weak_ptr> null after filtering: ... = items | transform(<lock()>) | filter(<not nullptr>)Aug 22, 2024
helmesjo
changed the title
vector<weak_ptr> null after filtering: ... = items | transform(<lock()>) | filter(<not nullptr>)vector<weak_ptr> null after filtering: items | transform(<lock()>) | filter(<not nullptr>)Aug 22, 2024
helmesjo
changed the title
vector<weak_ptr> null after filtering: items | transform(<lock()>) | filter(<not nullptr>)vector<weak_ptr> null after filtering: items | transform(<lock()>) | filter(<not null>)Aug 22, 2024
This one hit me with a bit of surprise but I guess there might be a rationale (caching related), but couldn't find the answer.
I have some list
items
containing weak pointers that I would like totransform
(weak.lock()
) thenfilter
(!= nullptr
) where it may be destructed by another thread simultaneously, but I noticed a race condition where it passed the filtering but was still null.I might be totally wrong here, but conceptually I imagine it as
transform
extracting the instance of interest, forward (as-is, lifetime intact) to thefilter
which again maintains the lifetime so the end result can only be a non-null shared pointer.Is this a bug or have I just misunderstood it?
The text was updated successfully, but these errors were encountered: