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 [*.net *.split]
jedi18[m] has quit [*.net *.split]
gdaiss[m] has quit [*.net *.split]
bhumit[m] has quit [*.net *.split]
gdaiss[m] has joined #ste||ar
jedi18[m] has joined #ste||ar
bhumit[m] has joined #ste||ar
hkaiser has joined #ste||ar
diehlpk has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
diehlpk has quit [Quit: Leaving.]
K-ballo has joined #ste||ar
diehlpk has joined #ste||ar
hkaiser has joined #ste||ar
diehlpk has quit [Client Quit]
<gonidelis[m]>
K-ballo: what's the purpose of a virtual function?
<K-ballo>
lol
<gonidelis[m]>
it allowes for the function to be overriden. but member functions were allowed to be overriden afaik even without using `virtual`
<K-ballo>
define "overriden"
<K-ballo>
note some functions, but not all, are indeed virtual functions even without using the `virtual` specifier
<gonidelis[m]>
huh
<gonidelis[m]>
ok
<gonidelis[m]>
overriden = redefine its behavior on a child class
<K-ballo>
can't redefine the behavior of a non-virtual function on a child class
<K-ballo>
at most you can hide the parent's function
<gonidelis[m]>
ok so virtual is "a more hardcore overriding"
<K-ballo>
show an example of "overriden" in a simple snippet in wandbox or godbolt
<gonidelis[m]>
radical*
<K-ballo>
no, it's just plain overriding... there's no other overriding
<zao>
A virtual member function is such that when the function is called via a pointer or reference type further up the inheritance tree that differs from the true dynamic type of the object, it calls the correct outermost implementation of that function.
<zao>
A non-virtual member function is always called with the static type of the object it's invoked through.
<zao>
The rules about hiding/shadowing are the same, as are the rules around function overloading.
<gonidelis[m]>
That's the only reason?!!? Really? just to facilitate simple examples?
<K-ballo>
gah
<K-ballo>
`Parent *p2 = new Child();` is something you'd only see in examples
<K-ballo>
dynamic polymorphism in general and liskov substitution principle in particular is a fundamental design principle
<zao>
A more real-world example would be the function call there, or like a `std::vector<std::shared_ptr<Parent>>` collection.
<zao>
There's many situations in which you end up with a reference/pointer to a parent class in with polymorphic inheritance.
<zao>
the purpose of an interface is that you should be able to treat all objects implementing the interface equally.
<gonidelis[m]>
wow
<gonidelis[m]>
just wow
<K-ballo>
std::vector<some_form_of_ptr<Enemy>> enemies; can then point to orcs, dragons, lions,
<zao>
That's (part of) the Liskov Substitution Principle.
<gonidelis[m]>
!!!!!!!!!!!!!!!!
<K-ballo>
worrysome how I struggled to come up with types of enemies
<K-ballo>
std::vector<some_form_of_ptr<Animal>> animals; can then point to dogs, cats, birds, penguins, lions,
<gonidelis[m]>
one final question: these all seem like they take care of Parent *p = new Parent() and Child *c = new Child() objects collections. there is no reason in declaring `Parent *p = new Child()` in my dragons application
<gonidelis[m]>
K-ballo: lol
<gonidelis[m]>
ah ah aahhh!!! no! don't answer
<zao>
I should make some popcorn :)
<gonidelis[m]>
so the case scenario (I stick with dragons) is that i declare Dragon *d = new Dragon() and Orc *o = new Orc() but my custom function that digests the `std::vector<pointers<Enemy>>` uses the `Enemy` class functions! rather than the specific orc and dragon ones
<gonidelis[m]>
now using virtual allows us to to override those functoins
<gonidelis[m]>
but no....
<zao>
For a regular member function, it will use the function from the static type of the object, in the case of that collection, it'll be Enemy's functions.
<zao>
For a virtual member function, even though it has a subobject of some base, it'll know to look in the true dynamic type of the object.
hkaiser has quit [Quit: Bye!]
<gonidelis[m]>
yes
<gonidelis[m]>
yes
<gonidelis[m]>
now it makes sense
<gonidelis[m]>
yeah i messed up in my previous msg
<gonidelis[m]>
so it's about using "the original" functions in cases like those pointer collections
<K-ballo>
on pointers and references in general
<gonidelis[m]>
yy
<gonidelis[m]>
hm... ok i learned sth
<gonidelis[m]>
thank you both guys!
<zao>
Some real-world use cases for inheritance polymorphism is when you want to have the ability to work with arbitrary derived types that conform to an interface. There's the RPG enemy design as above, or things like image views or file formats that you may want to work with via an ImageView interface that has functions like PixelAt(Coord), Width(), Height(). You could even load plugins at runtime and use types that never existed at your compile time.
<K-ballo>
nod, that's important, the code operating on Enemy doesn't even know that Dragon and Orc exist
hkaiser has joined #ste||ar
<gonidelis[m]>
great!
<gonidelis[m]>
got it
diehlpk has joined #ste||ar
diehlpk_work has joined #ste||ar
<diehlpk_work>
akheir, Can it be that the module files have some issue on rostam?
<diehlpk_work>
I get Lmod has detected the following error: Unable to load module because of error when evaluating modulefile:
<diehlpk_work>
is empty, it seems no defualt modules are loaded
<akheir>
marvin is not ready yet, coming soon
<diehlpk_work>
If you login to rostam you will get the error message about the modules
<hkaiser>
ms[m]: one last thing I'd like to see in the split PRs is a way of controlling the binary output directories for the local repository such that the binaries end up in the same place as the distributed binaries