<gonidelis[m]>
question: on this sample code the author says that they achieve what they want "but there are no partial funciton template specializations, so this does not solve the problem" https://wandbox.org/permlink/dOSUJjfHb4ndPzQS . But there are no partial specializations here... ?
<gonidelis[m]>
The problem is to integrate two libraries in a single program
<hkaiser>
it's not partial specialization, but full function specialization
<gonidelis[m]>
ok but they have managed to make the `framework` lib work along with the `boost` lib without the end-user being concerned
<gonidelis[m]>
He has created the desired customization point... what's the problem in this implementation?
<gonidelis[m]>
The procedure is like: `process` func sees the base template when parsed and then when it is instantiated it looks for the specialization
<gonidelis[m]>
But that for some reason is a problem...
<K-ballo>
partial function template specializations don't exist in the language, so of course there woudln't be any
<gonidelis[m]>
K-ballo: yup... that's what I am saying
<gonidelis[m]>
He might missed his point... does partial specialization has to do anything with the fact that parsing takes place independently from instantiation?
<K-ballo>
I don't actually know what you are saying then
<K-ballo>
due to the lack of partial function template specializations, the specialization approach does not solve the problem.. it's missing the optional<T> case
<gonidelis[m]>
grr.. yeah it makes sense now... He messed up this paragraph ¯_(ツ)_/¯
<K-ballo>
did he? where?
<gonidelis[m]>
I mean... he says "it works!" but he does not cover the `optional<T>` case...
<gonidelis[m]>
isn't line 56 here a partial specialization?
<gonidelis[m]>
and line 68 too?
<K-ballo>
no, no, those are overloads
<gonidelis[m]>
ahhhh.... right! got it! thanks
hkaiser has quit [Quit: bye]
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
bita_ has quit [Ping timeout: 260 seconds]
kale[m] has quit [Ping timeout: 244 seconds]
kale[m] has joined #ste||ar
alexandros[m] has quit [Quit: Idle for 30+ days]
jerry[m]3 has joined #ste||ar
Yorlik has joined #ste||ar
kale[m] has quit [Ping timeout: 244 seconds]
kale[m] has joined #ste||ar
Yorlik has quit [Ping timeout: 264 seconds]
Yorlik has joined #ste||ar
Yorlik has quit [Ping timeout: 240 seconds]
hkaiser has joined #ste||ar
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
Yorlik has joined #ste||ar
<hkaiser>
gnikunj[m]: thanks for looking into #4877, nice oslution
<hkaiser>
*solution*
<hkaiser>
gnikunj[m]: there is another issue with hpx_main, though: #4880
<gonidelis[m]>
hkaiser: why is it that when we create a CPO we inherit from `hpx::functional::tag<foo_algo>` ?
<hkaiser>
gonidelis[m]: all cpos essentially do the same thing, the inheritance allows to have this functionality written once (the necessary operator()())
<hkaiser>
without that inheritance every CPO would have to define the operator()() directly
<hkaiser>
gonidelis[m]: in case you didn't notice, this uses the CRTP technique (see lectures)
kale[m] has quit [Ping timeout: 256 seconds]
kale[m] has joined #ste||ar
<gonidelis[m]>
hkaiser: operator()() means -> operator()(args) right?
<hkaiser>
yes
kale[m] has quit [Ping timeout: 240 seconds]
kale[m] has joined #ste||ar
<gonidelis[m]>
hkaiser: wow didn't know about CRTP actually... don't remember menioning it in the lectures. But it's really mindblowing. The advantage of CRTP is that we have a base functionallity and then adapt it according to each specialization?
<gonidelis[m]>
plus on the `tag` codebase I don't understand what these lines are doing
<hkaiser>
a) make the operator()() noexcept if the function called is noexcept and b) define the return type
<gonidelis[m]>
oh ok thanks! hkaiser on the advantage thing I would like to rephrase: the main functionallity is that base classes can access members of derived classes
<hkaiser>
gonidelis[m]: and yes, CRTP allows to implement static polymorphism (i.e. polymorphism without virtual functions)
<K-ballo>
btw that's an odd line, decltype(args) rather than `Args&&` (or simply `Args`).. it was giving trouble on some recent msvc version
<hkaiser>
yes, that's exactly what it's doing
<hkaiser>
K-ballo: yah, that's heller1's code
<hkaiser>
but I can change it, it's used in other spots in this file as well, I believe
<hkaiser>
actually, I looks like I fixed it everywhere else, forgot this place :/
<gonidelis[m]>
hkaiser: on more thing: why do we name the cpo `copy_t`? in this way written, could the user use `copy_t(sth)`?
<gonidelis[m]>
hkaiser: I 'll fix it for you...
<hkaiser>
gonidelis[m]: copy_t is the type, while copy is the variable name of that type
<hkaiser>
struct copy_t : tag<copy_t> {...} copy;
<gonidelis[m]>
yeah yeah sorry.... right. Still, the user could use copy_t() though, right? It's an rvalue
<hkaiser>
no
<gonidelis[m]>
damn...
<hkaiser>
the user writes copy(...)
<gonidelis[m]>
I mean like we use `int(11)`
<hkaiser>
you can't 'invoke' a type, only an instance of some type
<hkaiser>
gonidelis[m]: int(11) is a type conversion
<hkaiser>
it results in a temporary instance of an 'int'
<K-ballo>
ok
<gonidelis[m]>
exactly
<K-ballo>
a user may, but that's just not the exposed interface
<hkaiser>
but copy() invokes the operator()()
<hkaiser>
it's the same as copy.operator()()
<gonidelis[m]>
K-ballo: ok that's what I am saying. Just to be sure that I get that right. hkaiser Yeah you are right...
<hkaiser>
gonidelis[m]: sure, the user could write copy_t()(...), but why?
<gonidelis[m]>
hkaiser: yeah for sure there is no reason. It's a just a mini exercise for comprehension for me :)
<hkaiser>
tag_invoke expects the type of the CPO as its first argument
<hkaiser>
just writing tag_invoke(*this, ...) would do the wrong thing, as it resolves to tag<Tag>() instead of Tag()
<hkaiser>
gonidelis[m]: you correctly said, that CRTP can be used to call functions on the derived class, so you need to tell the compiler to actually use the derived class, i.e. Tag
<gonidelis[m]>
hmm ok good. So we use `tag_invoke` from the base `tag` class, where it is just declared without a body. And then we define the body inside our `copy_t` specialized class
<gonidelis[m]>
is that right?
<hkaiser>
that's one way of doing it, yes
<hkaiser>
that tag_incoke implementation has to be found by the compiler based on usual function overloading rules, making it a friend of the CPO does that nicely
<hkaiser>
any other means of applying ADL would do the trick as well
<gonidelis[m]>
ok. that's a very very smart and convoluted way. The cpo has the operator() overload because of the base class and when it is actually called like `copy(sth)` it uses tag_invoke which by its way lies on the base class but is actually defined in the cpo body...
<gonidelis[m]>
ADL rules!
<hkaiser>
exactly
<hkaiser>
read wg21.link/p1895 for the full story
<gonidelis[m]>
believe me this page is always open on my browser along with anything else
<gonidelis[m]>
I keep diggin into it but it's quite technical... quite strict but I think I 'll get it
<gonidelis[m]>
do the functions that are inside the DOXYGEN part have to match any of the functions outside DOXYGEN part? Or do I just copy them from the standard?
<hkaiser>
they don't, but the documentation is generated from it, so it better be correct ;-)
<gonidelis[m]>
they don't? you mean they don't match our code?
<hkaiser>
they don't have to (it's not enforced), but they better do
<gonidelis[m]>
oh ok
<gonidelis[m]>
is there any case that our functions are a little bit different?
<gonidelis[m]>
declaration-wise
<hkaiser>
the concept requires are not in the docs
<gonidelis[m]>
that's the reason I asked
<gonidelis[m]>
it doesn't have to be
<gonidelis[m]>
right?
<hkaiser>
doxygen would get confused by the concepts
<gonidelis[m]>
ok great
<gonidelis[m]>
but it is mandatory that they match the std right?
<hkaiser>
gonidelis[m]: that's what we would like to achieve, yes
<gonidelis[m]>
ok
<gonidelis[m]>
I can't see any proj argument on the non-ranges declaration here
<gonidelis[m]>
Does this decl exist in the std? I just can't find it...
<gonidelis[m]>
hkaiser: Now the adaptations that I made here on /algorithms/transform.hpp stay here and I just readd the deprecated ones? Or I need to move those adaptations on the /container_algorithms/transform.hpp
<gonidelis[m]>
?
<K-ballo>
execution policies are from non-ranges, projections are from ranges, you won't see a declaration with both execution policies and projections in the standard
<gnikunj[m]>
hkaiser: you're welcome :) looking into #4880 now
<hkaiser>
gonidelis[m]: leave the 'old' algorithms unchanged and add CPO based new ones that conform to the standard
<hkaiser>
also add range based overloads that support execution policies
kale[m] has quit [Ping timeout: 256 seconds]
kale[m] has joined #ste||ar
<gonidelis[m]>
range overloads are the iterB iterE ones?