K-ballo changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
akheir1 has quit [Quit: Leaving]
bita has quit [Ping timeout: 264 seconds]
diehlpk_work_ has joined #ste||ar
diehlpk_work has quit [Ping timeout: 260 seconds]
K-ballo has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
shahrzad has joined #ste||ar
bita has joined #ste||ar
<tiagofg[m]>
Maybe a dumb question but, on hpx::for_loop, in each iteration of the circle is a task created?
<hkaiser>
tiagofg[m]: hopefully not
<hkaiser>
it should combine iterations based on the used chunking policy
<parsa>
hkaiser: do you have a minute?
<hkaiser>
parsa: here
<parsa>
please see pm
<diehlpk_work_>
hkaiser, Do we meet today?
<hkaiser>
do you want to?
<diehlpk_work_>
yes, birefly.
<hkaiser>
ok, sec
<diehlpk_work_>
15 min are sufficient
<gnikunj[m]>
really curious what the noexcept keyword does except for telling the compiler that the function doesn't throw?
<gnikunj[m]>
as in what true benefit does that keyword give to the user?
<hkaiser>
gnikunj[m]: less code generated as the compiler can omit generated code needed for exception handling
<gnikunj[m]>
what exception handling though?
<gnikunj[m]>
hkaiser: I mean we are not going to throw within the function so we probably don't have any code related to it anyway
<hkaiser>
every function needs to have separate code generated that would be used if an exception is thrown from inside itself or some function called by it
<gnikunj[m]>
what am I getting wrong?
<K-ballo>
most functions are exception-neutral.. they don't throw nor catch themselves, but do propagate whatever is thrown by functions they call, or functions those functions call, or functions those functions call, ...
<hkaiser>
gnikunj[m]: all destructors need to be called in case exceptions are being propagated
<gnikunj[m]>
K-ballo: could you help me visualize it with a code. How it would differ?
<gnikunj[m]>
hkaiser: aah, so there's one difference
<hkaiser>
differ what?
<gnikunj[m]>
as in how the generated code would differ
<K-ballo>
exception propagation requires unwinding "code" to be genreated
<gnikunj[m]>
or where the noexcept keyword should be used
<K-ballo>
it's mostly tables these days, not actual code, but still
<K-ballo>
maybe I can interest you in wg21.link/p1656
<gnikunj[m]>
so you mean if I call a function that throws, it is propagated to the function that first called it. The noexcept will ensure that code is not generated?
<hkaiser>
: yes
<hkaiser>
but that also means that no destructors would be called
<K-ballo>
kinda yes, it will still generate a std::terminate call (but not unwinding)
<K-ballo>
but now functions calling your function don't need any code at all
<hkaiser>
I had cases were it just swallowed exceptions without termination, btw
<gnikunj[m]>
so is it a good practice to mark functions as noexcept?
<K-ballo>
must be compiler bugs
<hkaiser>
msvc...
<K-ballo>
gnikunj[m]: only if they don't actually throw
<gnikunj[m]>
and that would mean that there are no function calls or instructions that would lead to exceptions
<K-ballo>
gnikunj[m]: and in case of interfaces, if you can promise the implementation will never actually throw (nor the current one nor future ones)
<gnikunj[m]>
got it! Really interesting.
<K-ballo>
the optimization improvements are there, but are not nearly as important as the benefits to human readers
<K-ballo>
and then there's the special cases, move and swap
<K-ballo>
you should make a strong effort to make those noexcept, if you can't you should seriously consider not providing them
<gnikunj[m]>
so move and swaps should always be noexcept. Is that what the standard recommend?
<K-ballo>
the standard makes no such recommendations
<K-ballo>
the standard library itself does have a policy for its own classes, which does treat move and swaps specially, but doesn't go as far
<K-ballo>
you can read all about that in the paper related to when to use noexcept
<gnikunj[m]>
where can I find the paper?
<K-ballo>
I cited it above
<K-ballo>
6:19:17 PM - K-ballo: maybe I can interest you in wg21.link/p1656
<gnikunj[m]>
aah got it. Reading it now
<gnikunj[m]>
thanks!!
<K-ballo>
it's probably more than you want to know
<gnikunj[m]>
more knowledge is never a bad thing, is it? :D
<gnikunj[m]>
K-ballo, hkaiser : should a copy constructor be defined explicit? Asking because cases of perfect forwarding may lead to compiler issues (compiler expecting foo const& as argument while getting a foo&)
<K-ballo>
not enough context to answer
<K-ballo>
if you can not define it, don't define it.. you may still want to declare it (=default)
<K-ballo>
if you need to define it then there's no way around it really
<gnikunj[m]>
so I've defined a copy constructor. What I meant to ask was: is there a need for it to be marked explicit using the keyword?
<K-ballo>
btw since you mention `foo&`, you shouldn't be defining a mutable copy constructor, but if for some misguided 98 reason you do you most definitely do not want to be defining a `foo const&` one
<K-ballo>
there's never a need to mark things explicit, that's a design decision depending on which interfaces you want to provide
<gnikunj[m]>
got it
<K-ballo>
gnikunj[m]: is that why you were writing a mutable copy constructor the other day? you were tripping over a forwarding constructor?
<gnikunj[m]>
K-ballo: yes :/
<gnikunj[m]>
and also the explicit keyword used on it that wouldn't take anything else
<K-ballo>
I'm confused
<K-ballo>
but the proper solution to a forwarding constructor, if you must have one, is to properly constrain it to not interfere with copy/move constructos
<K-ballo>
I don't understand what the "explicit keyword" remark is about
<gnikunj[m]>
as in marking a constructor explicit, something like:
<gnikunj[m]>
explicit foo(ArgType args) { // your definition }
<K-ballo>
what does "wouldn't take anything else" mean?
<K-ballo>
explicit only limits the contexts in which the constructor is a candidate
<gnikunj[m]>
I was getting a compiler error saying that there was no constructor foo::foo(ArgType&) when I defined `explicit foo(ArgType const&)`
<K-ballo>
?
<K-ballo>
and was there a `foo::foo(ArgType&)` constructor?
<gnikunj[m]>
nope
<gnikunj[m]>
the explicit keyword was blocking it from taking Argtype& I think
<K-ballo>
the explicit keyword may have prevented the constructor to participate at all
<K-ballo>
that's what the explicit keyword does: it makes the constructor not participate in implicit contexts
<gnikunj[m]>
exactly. Hence my question, should a copy constructor be ever marked explicit?
<K-ballo>
I don't follow
<K-ballo>
do you ever want to prevent it from being called implicitly? prevent copies from happening implicitly?
<gnikunj[m]>
yes, that's what I meant. What are the implications of preventing that.