<hkaiser>
just with the addition to be able create an 'empty' wrapper
<Yorlik>
I am using lazy initialization quite a bit to avoid writing tons of constructors and other stuff.
<hkaiser>
Yorlik: you still see c++ and it's features as your enemy
<hkaiser>
embrace things like constructprs, they (the features) are your fried
<hkaiser>
friend
<Yorlik>
I tend to do thing in code when I really need them and not earlier. But I see where it's biting me now.
<Yorlik>
This whole "Rule of zero" doesn't work half as often as I wished it woulkd.
<Yorlik>
The underlying idea was to keep the data as simple structs without any intelligence whatsoever. Basically PODs. But that blows up at places where I need references, and they're coming.
<hkaiser>
Yorlik: PODs are nice if the members of the struct are semantically independent
<hkaiser>
but they are most likely not in your case, i.e. changing one member means changing another one as well
<hkaiser>
constructors are important and not something you should avoid
<Yorlik>
I think I'll just write the special functions for the entity and keep the components at default where possible.
<Yorlik>
But the so-called base component has these backlinks
<Yorlik>
I put them into a component, because we might introduce entities which are not directly managed by a hpx component / gameobject
<Yorlik>
I need to rethink the entire type logic a little bit, because I just realized we might have different types of backlinks
<Yorlik>
Either to an hpx component or another entity
<Yorlik>
Back to the drawing board.
<Yorlik>
However - today I did my first versioned commit: v0.0.1-rc1 :)
<Yorlik>
Time to bring some order into way how we use git.
<Yorlik>
hkaiser: How about just making the default ctor explicit instead of a function?
<hkaiser>
huh?
<Yorlik>
Impossible?
<hkaiser>
a) a constructor is always a function, b) a default constructor can't be explicit
<hkaiser>
it is always explicit in a sense as you can't invoke it without being explicit
<Yorlik>
OK. make_default_ref<>() then
<hkaiser>
well, you can have a public default constructor, but this is dangerous as you might forget to initialize it
<hkaiser>
using something like empty_ref() makes it harder to forget
<Yorlik>
Makes sense.
<K-ballo>
a default constructor can be explicit, but it has weird unexpected consequences
<hkaiser>
nod, I didn't want to go into those here
<hkaiser>
;-)
<Yorlik>
I'll go with empty_ref then - it's clear and explicit.
Yorlik has quit [Ping timeout: 272 seconds]
diehlpk_work has quit [Remote host closed the connection]
hkaiser has quit [Quit: bye]
bita__ has quit [Quit: Leaving]
Yorlik has joined #ste||ar
nikunj97 has joined #ste||ar
<nikunj97>
zao, did you face any problems while installing hpx with boost 1.73?
<K-ballo>
boost.iostreams in particular probably hasn't changed in a decade
<Yorlik>
Damned. Sorry nikunj97 ^^
<nikunj97>
ok, it seems like layout=tagged fixes the issue
nikunj97 has quit [Read error: Connection reset by peer]
Nikunj__ has joined #ste||ar
<zao>
nikunj: Only on Windows with prebuilt Boost, and there it's fine.
nikunj97 has joined #ste||ar
Nikunj__ has quit [Ping timeout: 246 seconds]
hkaiser has joined #ste||ar
<Yorlik>
I'm working on this (very simple) modification of std::reference_wrapper, to be default constructible for lazy initializations scenarios. But line 152 currently gives me headaches. How can I fix this weird string truncation? https://godbolt.org/z/SLyTJs My guess is, that the templated constructor somehow reduces the string to an optimized short string. Ideas?
<hkaiser>
I wouldn't let it segfault, btw
<hkaiser>
I would explicitly throw
<K-ballo>
mpl::eval_if is now showing as #1 responsible for compile time on master, indicates it was introduced recently as it wasn't there on my first tests
<hkaiser>
also, in line 101, why don't you use the available constructor ?
<hkaiser>
Yorlik: ^^
<hkaiser>
K-ballo: hmmm
<hkaiser>
we don't use it explicitly, iirc
<Yorlik>
hkaiser: I was thinking the same concerning the segfault, but then realized I'd have to add a check.
<K-ballo>
it has to be some boost thing dragging it
<hkaiser>
Yorlik: sure, add a check
<hkaiser>
K-ballo: spirit?
<Yorlik>
Thats a check in a VERY tight loop
<hkaiser>
but that's included in certain places only
<hkaiser>
Yorlik: so what?
<Yorlik>
I'd rather like to keep it hard crash. because that would show up immediately in development
<hkaiser>
you have to load it into a register anyways, so an additiona JNZ doesn't hurt you at all
<Yorlik>
True
<K-ballo>
counter_parser.cpp and parse_affinity_options.cpp show up as top components where it is being used, yes
<hkaiser>
an unhandled exception will show immediatly as well ;-)
<Yorlik>
Its cheap, like really cheap
<hkaiser>
Yorlik: whatever
<hkaiser>
it will bite your ass
<hkaiser>
Yorlik: but you not using the constructor is a bigger issue
<hkaiser>
line 101
<hkaiser>
also, line 100 is where things break
<hkaiser>
you bind the address of the local t to the returned wrapper
<K-ballo>
hkaiser: where's the CI for those (nvcc)? pycycle?
<hkaiser>
K-ballo: right, didn't notice the deleted FUN(T&&)
<hkaiser>
K-ballo: yah, one of the pycicle builders - not sure if it's up now, however
<Yorlik>
Oh I see - so in the example they allowed wrapping rvalues?
<hkaiser>
Yorlik: no, they deleted ref(T&&)
<Yorlik>
OK - now I see they did the FUN(T&&) delete.
<Yorlik>
But I had that too in my copy - Honestly I'm still tryingh to understand like 50% of it.
<Yorlik>
OK - and nullref could ve fixed by explicitely moving out the new wrapper
<Yorlik>
hkaiser: Thanks a lot for fixing this. I'm still chewing on trying to understand everything. Also thanks K-Ballo for that link to the HPX implementation.
<K-ballo>
that's not hpx's implementation, but sure
<K-ballo>
if hpx had an implementation it would be that one
<Yorlik>
Yes - I saw its pretty close to that example from cppreference
<Yorlik>
Whereever that one comes from
<K-ballo>
I did have TC review my implementation, he was behind the FUN changes
<Yorlik>
TC?
<K-ballo>
one of the main persons behind cppreference, also responsible for the reference_wrapper changes in the standard that brought the FUN
<Yorlik>
OMG ... took me all this time to see the changes fully - lol
<Yorlik>
So hkaiser - I saw you moved the remove_reference_t from the SFINAE monstrosity in the move ctor. In the example impl they used remove_cvref_t which I had to replace, since it's c++20 and we are still at c++17. Why is the remove_reference not need or why would it be needed?
<Yorlik>
Also I'm a little bit concerned about the type of ptr_ being a T* and not a T const* in the case of cref.
<K-ballo>
cref yields reference_wrapper<X const>, so T would already be const
<Yorlik>
Oh I see: auto r = nullable_wrapper<T const>( t ); so the "T" inside the template actually is a T const
<Yorlik>
Probably shouldn't have used "T" for the name
nikunj97 has quit [Read error: Connection reset by peer]
nikunj has quit [Ping timeout: 246 seconds]
nikunj has joined #ste||ar
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
<hkaiser>
Yorlik: you had remove_cvref_t<remove_reference<>::type> which was superfluous
<Yorlik>
Wasn't it remove_cv_t<remove_reference<>::type> ? Then it was a bug. remove_cvref_t is c++ 20 - but I might have messe something up
<Yorlik>
But that was the background - to have it C++17 compatible.
<hkaiser>
sure, didn't know that
<Yorlik>
Just cipied from the original link: std::remove_cv_t<std::remove_reference_t<U>>::type>
<hkaiser>
ok
<Yorlik>
However - thankls a ton for fixing this.
<Yorlik>
I also was running into that trap that lured in some assignment
<hkaiser>
btw, if you use _t, then no need to use ::type as well
<Yorlik>
Tricky to get it all correct.
<Yorlik>
I think there was one of them not working with _t
<Yorlik>
remove_refrerence I think
<Yorlik>
STarnge - it's there - need to re-check this
<Yorlik>
Seems I overlooked it before.
<Yorlik>
hkaiser: replaced a bunch of raw ptrs with the new nullable ref - works like a charm with minor changes in the lua interop API.
<hkaiser>
nice
<Yorlik>
Still having default constructibility is really a big relief.
<Yorlik>
People in other places recommended methods like using a castrated unique_ptr (without deleter) but that would have crippled copy semantics.
<Yorlik>
I like this wrapper better.
<K-ballo>
build time and debug bloat had degraded considerably since last I check
<hkaiser>
K-ballo: that is good
<hkaiser>
it's the modularization, I presume
<K-ballo>
my mistake then
<hkaiser>
uhh, I might have misunderstood - what mistake?
<K-ballo>
I meant to say it got worse, not better
<hkaiser>
ahh
<hkaiser>
not good
<K-ballo>
unrelated, has there been any consideration to packing modules as object libraries?
<hkaiser>
I was hoping the modularization would help with that, apparently it doesn't
<hkaiser>
K-ballo: cmake object libraries?
<K-ballo>
yes
<hkaiser>
we tried
<hkaiser>
that caused cmake configure times to go through the roof
<K-ballo>
really? surprising
<hkaiser>
factor of 10 and more
<hkaiser>
it took more than 20 minutes to configure things
<K-ballo>
any branch that survived to this day?
<hkaiser>
K-ballo: probably, sec
<hkaiser>
K-ballo: talk to Mikael, he was doing the work