Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
User-defined access operator?
32 views
Skip to first unread message
bitrex
Dec 8, 2016, 5:53:31 PM12/8/16
to
Suppose I have a class wrapper which allocates POD objects of some type
T to a memory pool. And I have a static factory function which takes a
temporary object from the stack and a reference to the pool, and returns
a user-defined type alias for that class, say pool_object_t<T>, which
has a member variable that holds a pointer to the newly allocated block
of memory in the pool on the heap containing the persistent object.
I know I can define a conversion operator which will allow me to use
this type as say, the argument to a function which is expecting type T.
I also know that I can overload the * and -> operators to work with the
underlying pointer.
Am I correct in understanding that there's no way to treat this
pool-allocated wrapper type as if it were a "regular" object
instantiated on the stack? That is to say, something like:
struct MyPODStruct {
int x;
int y;
int z;
}
MemoryPool<MyPODStruct> pool;
pool.resize(10); //create 10 blocks on the heap big enouh to fit the struct
auto obj = pool_object<MyPODStruct>::make_pool_object(pool, MyPODStruct());
obj->x = 7; //okay, if operator "->" is appropriately overloaded
void my_func(const MyPODStruct& obj) { ...
my_func(obj) //okay, if user-defined conversion operator for that
obj.x = 7; //not okay, pool_object_t<MyPODStruct> has no member named "x"
Maybe I should just make the pool_object_t more like a smart pointer,
and return managed references to the blocks on the heap, rather than try
to return wrapped objects by value?
T to a memory pool. And I have a static factory function which takes a
temporary object from the stack and a reference to the pool, and returns
a user-defined type alias for that class, say pool_object_t<T>, which
has a member variable that holds a pointer to the newly allocated block
of memory in the pool on the heap containing the persistent object.
I know I can define a conversion operator which will allow me to use
this type as say, the argument to a function which is expecting type T.
I also know that I can overload the * and -> operators to work with the
underlying pointer.
Am I correct in understanding that there's no way to treat this
pool-allocated wrapper type as if it were a "regular" object
instantiated on the stack? That is to say, something like:
struct MyPODStruct {
int x;
int y;
int z;
}
MemoryPool<MyPODStruct> pool;
pool.resize(10); //create 10 blocks on the heap big enouh to fit the struct
auto obj = pool_object<MyPODStruct>::make_pool_object(pool, MyPODStruct());
obj->x = 7; //okay, if operator "->" is appropriately overloaded
void my_func(const MyPODStruct& obj) { ...
my_func(obj) //okay, if user-defined conversion operator for that
obj.x = 7; //not okay, pool_object_t<MyPODStruct> has no member named "x"
Maybe I should just make the pool_object_t more like a smart pointer,
and return managed references to the blocks on the heap, rather than try
to return wrapped objects by value?
Marcel Mueller
Dec 9, 2016, 3:32:51 PM12/9/16
to
On 08.12.16 23.53, bitrex wrote:
> I know I can define a conversion operator which will allow me to use
> this type as say, the argument to a function which is expecting type T.
> I also know that I can overload the * and -> operators to work with the
> underlying pointer.
>
> Am I correct in understanding that there's no way to treat this
> pool-allocated wrapper type as if it were a "regular" object
> instantiated on the stack?
Exactly. You cannot override the "operator.".
> I know I can define a conversion operator which will allow me to use
> this type as say, the argument to a function which is expecting type T.
> I also know that I can overload the * and -> operators to work with the
> underlying pointer.
>
> Am I correct in understanding that there's no way to treat this
> pool-allocated wrapper type as if it were a "regular" object
> instantiated on the stack?
> obj.x = 7; //not okay, pool_object_t<MyPODStruct> has no member named "x"
>
> Maybe I should just make the pool_object_t more like a smart pointer,
In fact your type /is/ a reference type.
Marcel
bitrex
Dec 9, 2016, 5:27:35 PM12/9/16
to
conform to the "custom allocator" standard for C++11, and then I could
use it with STL containers. I could also write a smart pointer-like
wrapper around it to return lone reference objects.
0 new messages