hkaiser 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/
hkaiser has quit [Quit: bye]
K-ballo has quit [Remote host closed the connection]
hkaiser has joined #ste||ar
<Yorlik>
hkaiser: Would you have a moment for a tricky templating question?
<Yorlik>
I have an allocator template, which has a type T as parameter. T is the type of items stored with the allocator. I want the allocator to be a static member of T, so they can store themselves. Do I have to use CRTP for this and rather inherit from the allocator or are ther other, maybe better ways to resolve this?
<hkaiser>
Yorlik: I don't see a problem resolving this
<hkaiser>
just write struct A { static A a; };
<Yorlik>
my static allocator member is declared in the T like this:
<Yorlik>
I am now trying to write a deallocator for T which uses the CPA_.deallocate(T*) method and giving it the this pointer
<Yorlik>
and it tells me it cannot convert the this pointer and claims, that this is of type allocator and not Entity
K-ballo has joined #ste||ar
<Yorlik>
basically the destroy member function of Entity calls CPA_s deallocate
<Yorlik>
and this is seen as being an allocator and not an Entity
<hkaiser>
well this inside CPA_.deallocate will be of type ContiguousPoolAllocator<>*
<hkaiser>
why shouldn't it?
<Yorlik>
So - shoulkd I just make a copy of the pointer, like destructPtr?
<hkaiser>
what pointer?
<Yorlik>
like destructPtr = this and THEN call deallocate?
<Yorlik>
so this would not caus ambiguation
<hkaiser>
why do you want to deallocate the allocator?
<Yorlik>
Actually I start understanding - I gave this a wrong context
<Yorlik>
Not the allocator - the entity
<hkaiser>
isn't the entity passed to deallocate? like deallocate(Entity<>* p)?
<Yorlik>
bool d_result = Entity<Ts...>::CPA_.deallocate( this );
<Yorlik>
thats how I call it - or try
<hkaiser>
sure, looks good
<hkaiser>
and why does this not work?
<hkaiser>
just deallocate whatever pointer deallocate() is called with as its argument
<Yorlik>
I am getting this error from it: 'void ContiguousPoolAllocator<pecs::Entity<pecs::base_c,pecs::appearance_c,pecs::container_c>,FreelistType::set>::deallocate(T *)': cannot convert 'this' pointer from 'const ContiguousPoolAllocator<pecs::Entity<pecs::base_c,pecs::appearance_c,pecs::container_c>,FreelistType::set>' to 'ContiguousPoolAllocator<pecs::Entity<pecs::base_c,pecs::appearance_c,pecs::container_c>,FreelistType
<Yorlik>
::set> &'
<Yorlik>
This looks bogus to me
<hkaiser>
well, your static is const
<Yorlik>
It assumes a wrong type for this, imo
<hkaiser>
you can't modify it
<Yorlik>
I tried const casting this, but no success
<hkaiser>
deallocate() would have to be const itself
<hkaiser>
void deallocate(...) cons {...}
<Yorlik>
the type it assums for this in the error message looks wrong to me
<hkaiser>
void deallocate(...) const {...}
<hkaiser>
you are trying to call a non-const function (deallocate()) on a const object
<Yorlik>
Why does it think this is of type: 'const ContiguousPoolAllocator<pecs::Entity<pecs::base_c,pecs::appearance_c,pecs::container_c>,FreelistType::set>'
<Yorlik>
this is the Entity
<hkaiser>
no
<hkaiser>
this is the allocator
<Yorlik>
because I use the term "this" inside the allocator function?
<hkaiser>
no
<Yorlik>
So - should I just make a typed pointer as a copy and pass that ?
<hkaiser>
you write CPA_.deallocate(...) right?
<Yorlik>
I don't get it
<Yorlik>
yes
<hkaiser>
CPA_ is const
<hkaiser>
deallocate() is not
<Yorlik>
deallocate is a member function of the allocator
<hkaiser>
yes
<hkaiser>
but it is a _non-const_ member function
<Yorlik>
I think I am lacking some understanding here about const and non const functions. I only know about parameters and return values
<hkaiser>
member functions can be const, i.e. deallocate(...) const {}
<Yorlik>
What's the meaning or consequence of that ? Or: What should I read about?
<hkaiser>
that means that they don't modify any of the members of the object
<Yorlik>
Of the allocator in that case?
<hkaiser>
the consequence is that the this pointer inside the member function is const
<Yorlik>
But this is not pointing to the allocator, but the Entity
<Yorlik>
I'll read up ..
<hkaiser>
it's not your 'this' (the argument) the compiler is complaining about
<Yorlik>
Technically this is not a member of the allocator
<hkaiser>
it's the implicit 'this' inside the deallocate() the compiler is worried about
* Yorlik
mindblanks
<Yorlik>
You mean the this which would be the allocator
<Yorlik>
inside the function
<hkaiser>
you are using a const object (CPA_) to call a non-const member function which results in an attempt to convert a const * (to CPA_) to a non-const this (inside the deallocate())
<Yorlik>
Ohhh
<Yorlik>
So it doesn't even care if I actually use this inside dealolocate or not
<Yorlik>
It kjust tells me about an inconsistency it assumes
<Yorlik>
or sees
<Yorlik>
So - its mor a conceptual error, not a concrete implementation problem
<Yorlik>
something which ~might lead to an error
<Yorlik>
if I would use this inside deallocate
<Yorlik>
I think i can safely make deallocate const then
<hkaiser>
if it doesn't change the allocator itself - sure
<hkaiser>
but I doubt that
<hkaiser>
deallocate touches on the other members of the allocator for sure
<hkaiser>
Yorlik: look, if you access a member inside a member function, the 'this->' is implied
<Yorlik>
I'm currently checking and following the call chaoins
<hkaiser>
so struct A { int a; int foo() { return a; } }; is actually eqivalent to struct A { int a; int foo() { return this->a; } };
<Yorlik>
Fpound a call - I have to make CPA_ non const
<Yorlik>
It compiles now :)
<Yorlik>
hkaiser: Thanks a ton!
<hkaiser>
welcome, any time
<Yorlik>
Goiung to write some testcode ..
<Yorlik>
The allocator work nicely so far in general
<Yorlik>
Using an array like access for never moving objects and adding pages to reserved address space as needed.
<Yorlik>
But integrating with the other stuff made it more complicated - nice result now - time for a coffee :)
<hkaiser>
Yorlik: I have merged #3894, so VS2019 should work for you again
<Yorlik>
We can't yet really constrain template parameters, can we? That would be concepts in C++20 - correct? Just wondering what's the best way to restrict incorrect use of templates I write.
<Yorlik>
Especially wrong parameters
<K-ballo>
if you can just static_assert on wrong usage, that leads to the best results
<K-ballo>
if you need actual constrains you need sfinae, and it gets messy fast
<Yorlik>
IC - seems static_assert it is then - been using them before with good results.
Coldblackice_ has joined #ste||ar
Coldblackice has quit [Ping timeout: 246 seconds]
<Yorlik>
"default template arguments not allowed on a partial specialization" - templates always make me feel so stupid - lol :)
<K-ballo>
how did you end up with a defaulted argument there?
<Yorlik>
Thats really complicated - I am not usre I'd steal your time with this now. Basically I was messing with template functiuons used in a static assert (which already works)
<Yorlik>
But the background is more complicated
<Yorlik>
My non-templated GameObjects have a type erased pointer to a templated entity datastructure
<Yorlik>
If I want a default constructor for the GameObjects i am running into problems
<Yorlik>
Because i usually have to give a typed pointer as argument to create the type erased pointer from it
<Yorlik>
But sometimes i might want lazy initialization
<Yorlik>
So... to make it short .. there's a whole slew of stuff hanging on this
<Yorlik>
I still try to understand the problem better - I think it's more a design problem resulting in this mess
<Yorlik>
I feel i need to dig more bfore i can really ask a question - but with the templates I really hit a wall often - I find it really difficult to get my head around the more complex issues
<Yorlik>
Any idea why this: constexpr static const size_t mSize = sizeof ( ENT ); // (ENT is a template parameter, a class) raises this error: type 'const unsigned __int64' unexpected ??
<Yorlik>
So source mentioned limited constexpr support in BS, but that was 2015 or earlier
<Yorlik>
Its mutating into: pecs::TeePtr::model<ENT>::mSize': a static data member with an in-class initializer must have non-volatile const integral type or be specified as 'inline'
<Yorlik>
I wonder if my template param is bugged
<hkaiser>
what compiler is this?
<hkaiser>
does removing the constexpr work?
<Yorlik>
cl 2017
<Yorlik>
i think this is going to help me: typedef typename ENT::something_made_up X;
<hkaiser>
hmmm, should actually work
<Yorlik>
For some reason it tells me ENT is my type erased pointer
<Yorlik>
Which is wrong
<Yorlik>
So - template compile time debugging trick one works.
<Yorlik>
:)
<hkaiser>
K-ballo: alternatively we will have to make this a breaking change, I think people will have used teh same paradigm as the template_function_accumulator
<Yorlik>
If I override operator new in my class - will the default constructor use that new operator to allocate the memory for the class?
<Yorlik>
Basically I want the default constructor to use my allocator
<Yorlik>
also default copy , assignment etc constructors
<hkaiser>
Yorlik: yes, pls read Scott Meyers books
<Yorlik>
Thanks!
<hkaiser>
this is described in his very first book, I believe