hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
hkaiser has quit [Quit: Bye!]
diehlpk_work has quit [Ping timeout: 245 seconds]
zao has quit [*.net *.split]
zao has joined #ste||ar
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<gonidelis[m]> `struct Y{ auto operator<=>(const Y&) const = default;};`
<gonidelis[m]> what does this mean?
<gonidelis[m]> ` auto operator<=>(const Y&) const = default;` I mean
<gonidelis[m]> i get the `auto operator<=>(const Y&)` part...
<gonidelis[m]> but `const = default`?
<hkaiser> operator<=> - the spaceship operator generates all comparison operators
<hkaiser> default means to rely on the existing operators for Y's members
<gonidelis[m]> spaceship 😅. but what's `const =` the `default`
<gonidelis[m]> what's that equals?
<hkaiser> const means the operator does not change members of Y (i.e. the this pointer inside the operator is const)
<hkaiser> the '= default' means that the operator should be generated such as it would be generated if the declaration wasn't there ;-)
<hkaiser> well... not quite - in this case it means to rely on the corresponding operators for Y's members
<gonidelis[m]> what if we had `struct Y{ auto operator<=>(const Y&) = default;};`
<gonidelis[m]> (i missed the second const)
<hkaiser> this wouldn't be proper
<hkaiser> that would mean that you wouldn't be able to compare non-const objects
<hkaiser> const objects*
<gonidelis[m]> would it compile? but i thought `(const Y&)` allowed me to compare const objects
<gonidelis[m]> a.k.a. give const arguments
<hkaiser> sure, as long as the rhs is const - no problem, but if the lhs is const it wouldn't compile as the operator is not const anymore
<gonidelis[m]> so broadly speaking the parenthesis part regards the rhs (aka arguments?) and the part after the parenthesis regards the lhs (which I know is not the result, but sounds like it)?
<hkaiser> the second const refers to the constness of the 'this' pointer inside the member function
<gonidelis[m]> by member function you mean the operator overload?
<hkaiser> any member function
<gonidelis[m]> Taken from cppref: `The default operator<=> performs lexicographical comparison by successively comparing the base (left-to-right depth-first) ....`
<gonidelis[m]> what's the `base` and what does depth-first mean?
<gonidelis[m]> depth-first -> left to right?
<jedi18[m]> <gonidelis[m]> "what's the `base` and what..." <- I think base class
<jedi18[m]> Depth first so first it will call it on all the "childs" of the base class (so base of the base class plus non static members), then move on to it's non static members
<gonidelis[m]> ahhh..... base of the base class sounds like a parent rather than a child
<jedi18[m]> Yeah no by child I was referring to the tree terminoligy. I mean the parent of the class
<gonidelis[m]> how do you derive "non static members" ?
<jedi18[m]> They said that on the cppref page xD https://en.cppreference.com/w/cpp/language/default_comparisons
<gonidelis[m]> what about the "recursively expanding array members"
<gonidelis[m]> what's that supposed to mean
<K-ballo> struct Y {
<K-ballo> void fun();
<K-ballo> };
<K-ballo> void fun() const;
<gonidelis[m]> K-ballo: are these "array members"?
<hkaiser> no
<gonidelis[m]> what's this snippet about?
<hkaiser> a const and a non-const overload of fun()
<gonidelis[m]> ok? and what's the author's purpose?
<K-ballo> exactly same `const` as in struct Y{ auto operator<=>(const Y&) const = default;};
<gonidelis[m]> ah right! that's what i figured. It almost seems like I could write `struct Y{ auto operator<=>(const Y&) = default const;};`
<K-ballo> you can't, you need to know what to default before defaulting it
<gonidelis[m]> i am defaulting the operator
<gonidelis[m]> not the constness of its
<K-ballo> and then retroactively adding const to it?
<K-ballo> you are defaulting the (member) function `auto operator<=>(const Y&)`, not `auto operator<=>(const Y&) const`
<K-ballo> you can't say `auto operator<=>(const Y&) { return ...; } const`
<gonidelis[m]> nahhhhh!!!!!!
<gonidelis[m]> yy!
<gonidelis[m]> K-ballo: no I get it. You are right. Got it
<gonidelis[m]> Thanks
<gonidelis[m]> (meanwhile the fireworks in my head)
<pedro_barbosa[m]> I'm trying to copy the results back from the GPU to the temp arrays but I'm having some problem with the types, can someone help me understand how to do it?
<gonidelis[m]> K-ballo: so where do you stand on the following: "Projections could and should be subsituted by views"
<gonidelis[m]> ?
<hkaiser> : I don't think this is a generally true statement
<K-ballo> sort employees by last name
<hkaiser> r | sort(proj) could be certainly rewritten as r | project(proj) | sort(), but this changes the elements for everything after the project(), which might be undesireable
<gonidelis[m]> what hkaiser said ^^
<hkaiser> i.e. the first produces a sorted sequence of full employee records, the second one produces a sequence of sorted last names
<gonidelis[m]> it seems to me like we have two very closely bound facilities that almost do the same thing, but we keep them us are because of the very few more things that one can do over the other
<hkaiser> not really, the two are complementary
<gonidelis[m]> aren't we (C++ std) accused of being feature wh@res? isn't it to greedy?
<K-ballo> if you project employee to last name with a view, then sort... you'd get a list of last names, not a list of employees
<hkaiser> not sure what you mean, however the two constructs I listed above do different things and I don't see a way to do one using the other
<K-ballo> not to mention, you can't sort into such a projected view in the first place
<gonidelis[m]> K-ballo: what if `views::projection(&Employees::last_name)`
<gonidelis[m]> i think this sorts the employees, not just the names
<K-ballo> it can't possibly do that if it truly is a view
<K-ballo> it's elements are last names, not employees
<hkaiser> views::projection(&Employees::last_name) will produce a sequence of last names
<hkaiser> it's like a views::transform
<K-ballo> take a look at the original ranges proposal, from .. urbana-champain I think? it has an appendix on projections
<K-ballo> it explains what projections are, and why they make sense, in some detail
<K-ballo> and 13.2.1 Projections versus Range Transform View
<gonidelis[m]> hkaiser: ahh.... but if i sort my vector of employees object based on that, don't i get the employees sorted?
<gonidelis[m]> vector of employees objects^^
<hkaiser> gonidelis[m]: sort(r, proj) will sort the whole employees records and use proj to extract the key to compare
<gonidelis[m]> i am talking about `sort(r | views::proj)`
<hkaiser> gdaiss[m]: that will not work, you can't sort a view without materializing it
<hkaiser> gonidelis[m]: ^^
<gonidelis[m]> 0.0
diehlpk_work has joined #ste||ar
diehlpk has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
diehlpk_work has quit [Ping timeout: 264 seconds]
K-ballo has quit [Quit: K-ballo]
diehlpk_work has joined #ste||ar
K-ballo has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
diehlpk_work has quit [Ping timeout: 245 seconds]
hkaiser has quit [Quit: Bye!]