<gnikunj[m]>
hkaiser: does async invokes copy constructors of a custom class?
<gnikunj[m]>
essentially I'm moving everything instead of copying, yet the error comes at the invocation of async where it says that use of deleted copy constructors
<gnikunj[m]>
/home/nk/src/hpx/libs/execution/include/hpx/execution/detail/async_launch_policy_dispatch.hpp:88:41: error: use of deleted function ‘partition_data::partition_data(const partition_data&)’
<gnikunj[m]>
I do not anything that may require the invocation of copy constructor, so I was curious if it is due to async
<hkaiser>
gnikunj[m]: only if you don't move the argument into async
<hkaiser>
async(f, std::move(data)) will not invoke a copy constructor
<gnikunj[m]>
I did not move the arguments to async. But that is because the invoked function takes a const reference
<hkaiser>
what do you expect async should do? it should launch a new thread
<hkaiser>
if it's a local async() then you can do async(f, std::ref(data)) to force passing a reference
<gnikunj[m]>
it should launch a new thread and honor the const reference paramaters of the invoked function
<gnikunj[m]>
aah right, let me try that
<hkaiser>
but then you are responsible for keeping data alive until the thread is done running
<gnikunj[m]>
aah it compiles now. Thanks! I do make sure that the data doesn't go out of scope or similar such mishaps
<gnikunj[m]>
hkaiser: I was able to find why HPX went out of memory. On my local machine I set up a debug environment and found that it is due to "tcmalloc: large alloc 753320341405696 bytes == (nil) @"
<hkaiser>
so why does this happen?
<hkaiser>
ABI problems?
<gnikunj[m]>
yea, debugging right now to figure exactly where it is localted. Yesterday was pretty frustrating trying to debug on loni
<gnikunj[m]>
but at least now ik it was actually because tcmalloc is trying to allocate large memory even though the program doesn't ever try to allocate such large sizes
<hkaiser>
sounds like either something went out of scope too early or an ABI problem
<gnikunj[m]>
hkaiser: sometimes I feel like taking a break from all this with the kind of mistakes I do. While removing the checksum related components for non-resilient version, I removed the initialization of size during the construction of partition_data. With random initialization, we were seeing those random behaviors.
<hkaiser>
gnikunj[m]: it's most difficult to learn to use the language to your advantage
<hkaiser>
these things can be avoided by following some simple rules
<hkaiser>
those require effort however which makes it easy to ignore them
<hkaiser>
no raw pointers, no raw loops, no raw threads
<gnikunj[m]>
I try to not use raw loops. But always end up using them.
<gnikunj[m]>
I make sure not to use raw pointers and raw threads
<hkaiser>
good
<hkaiser>
but you missed initializing some array telling me you used raw pointers
parsa has joined #ste||ar
<gnikunj[m]>
well its a wrapper for vector that I use. So I keep vector and vector size as its member. Now I should've simply used vect.size() to get size but me being lazy created a separate variable for it.
<hkaiser>
there you go
<gnikunj[m]>
and then I forgot to initialize that separate variable when the constructor was called.
<gnikunj[m]>
and hence, all the drama
<hkaiser>
well, there is that underlying rule, to be applied before you even start thinking about those three I mentioned: always initialize your variables ;-)
<gnikunj[m]>
yes! I make sure to initialize them. But then while deleting the checksum related stuff, idk how I deleted the size initialization as well :?
<gnikunj[m]>
*:/
<hkaiser>
bugs are always stupid
<gnikunj[m]>
true :D
<gnikunj[m]>
hkaiser: curious question. "= default" calls the constructor of each data member respectively, right?
<K-ballo>
gnikunj[m]: that depends, does each of the data member have a corresponding constructor?
<gnikunj[m]>
K- Oneballo One is a size_t and other is a std::vector
<K-ballo>
size_t doesn't have constructors
<K-ballo>
for a defaulted default constructor it will do value-init
<K-ballo>
for a defaulted copy/move constructor it will do a bitwise copy
<K-ballo>
the fact that a complete guide is needed is super sad
<gonidelis[m]>
K-ballo: why?
<K-ballo>
know of any other language that can produce an entire book on the subject?
<gonidelis[m]>
no?
<gonidelis[m]>
but why is that bad?
<K-ballo>
it's an indication that our move semantics are complex and convoluted
<K-ballo>
otherwise there would be no content to fill a book
<zao>
I reckon that there may be underlying complexity of the rest of the language that needs to be touched on to cover how it interacts with every other dumb thing?
<K-ballo>
may be part of it, there's plenty of stuff our move semantics are directly responsible for
<K-ballo>
like move not moving anything, moving things leaving stuff behind, the entire corollary of noexcept, the "universal reference" fiasco,
<zao>
I still don't know if I should move into emplaces.
<zao>
Got a vague idea that you shouldn't move into returns, but should into out parameters.
<K-ballo>
that's another gratuitous one, when move is a pessimization
<K-ballo>
all a consequence of the particular odd semantics moves got
<K-ballo>
in a model in which move moves, all those pain points disappear
weilewei has quit [Remote host closed the connection]
<gonidelis[m]>
K-ballo: zao for me... as a new commer to the language and the domain, move semantics is certainly a tricky part
<gonidelis[m]>
newcomer^^
<K-ballo>
gonidelis[m]: move doesn't move and rvalue references are not rvalues, that's about the most important things to know in order to understand move semantics
jbjnr_ has quit [Ping timeout: 272 seconds]
<gonidelis[m]>
K-ballo: ok now you got me more confused ;p
<gonidelis[m]>
K-ballo: i really thought that move was moving
<gonidelis[m]>
i think i already know that rvalues are not rvalues?
<K-ballo>
what? of course rvalues are rvalues
<K-ballo>
rvalue *references* aren't rvalues.. they are references, they are not even expressions
<gonidelis[m]>
what about moving then? K-ballo
<zao>
gonidelis[m]: std::move is a backdoor to get you from a `T&` to a `T&&`, via which someone can steal the internals of the object and leave it in an indeterminate state. e.g. actually moving.
<zao>
It's used when you've got something that won't naturally become a `T&&` in a context where a move-like operation would be appreciated.
<K-ballo>
struct X { std::string m; X(std::string&& v) : m(v) {} };
<K-ballo>
X x(std::move(some_string)); // no string has been moved in this example