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
struct point_t {
int x, y = 1;
};
std::vector<point_t> vec(N);
assert(vec[0].y == 1); // succeeds
dash::Array<point_t> arr(N);
assert(vec[0].y == 1); // may or may not succeed
Point to make: Contrary to the STL, elements in DASH container are not initialized with their default value. Now, there is a good argument for this: performance! Many times users might want to skip implicit initialization because they perform the initialization themselves, e.g., using dash::fill.
However, since we aim to be compatible with STL behavior and because I tapped into this trap myself (see b67c065) I decided to raise this issue. What's more, this is mostly only relevant for derived types in DASH container because it is all too tempting to rely on the default values specified in the type definition.
As far as I can see this behavior is not documented anywhere.
Should we change the behavior to provide default initialization or make it optional (one way or another)? Or just document this deviation from the STL behavior?
The text was updated successfully, but these errors were encountered:
Hey here some input from my side:
Wouldn't it be failsafer for new developer if it behaves like in STL?
I suggest offering a constructor without initialization for performance aware programmers.
Is this a option? Or am I fooling myself anywhere?
Consider the following code snippet:
Point to make: Contrary to the STL, elements in DASH container are not initialized with their default value. Now, there is a good argument for this: performance! Many times users might want to skip implicit initialization because they perform the initialization themselves, e.g., using
dash::fill
.However, since we aim to be compatible with STL behavior and because I tapped into this trap myself (see b67c065) I decided to raise this issue. What's more, this is mostly only relevant for derived types in DASH container because it is all too tempting to rely on the default values specified in the type definition.
As far as I can see this behavior is not documented anywhere.
Should we change the behavior to provide default initialization or make it optional (one way or another)? Or just document this deviation from the STL behavior?
The text was updated successfully, but these errors were encountered: