Although STL container can't support object by reference as a template argument. To make thing worse, allocator can't support stack based allocation.
So:
std::deque<std: :string const &>
is impossible to declare.
But, it is also more than impossible to find a workaroung using a custom STL allocator because of the ugly and not object oriented design that was used. Thanks to many STL contributor for this, specially to PJ Plauger where his name is everywhere in the STL header/footer.
This is the reason why this is impossible:
class allocator
{
///...
pointer allocate(size_t ype _Count, const void _FARQ *)
{ // allocate array of _Count elements, ignore hint
return (allocate(_Coun t));
}
void construct(point er _Ptr, const _Ty& _Val)
{ // construct object at _Ptr with value _Val
_Construct(_Ptr , _Val);
}
}
If if was something like this:
class allocator
{
///...
_Ty construct(const _Ty& _Val)
{ // construct object at _Ptr with value _Val
return *(new _Ty( _Val)); //C++ optimizer will get rid of the copy call in the return statement so there is no performance loss with that approach
}
}
Then I could have made this:
class StackbasedAlloc ator
{
///...
_Ty construct(const _Ty& _Val)
{ // construct object at _Ptr with value _Val
return _Val;
}
}
Which is fully object oriented in C++ and I could have build my allocator to support object by reference in a deque container. The problem with the current implentation is a very major one and implies directly that references CANNOT be used in STL container. So STL container will never be able to meet realtime specs on embedded (even on desktop) computers. Memory heap allocation cost too much on those device specially for small object.
So with this:
pointer allocate(size_t ype _Count, const void _FARQ *)
{ // allocate array of _Count elements, ignore hint
return (allocate(_Coun t));
}
You can't do this:
pointer allocate(size_t ype _Count, const void _FARQ *)
{ // allocate array of _Count elements, ignore hint
return &_Ty(); //Compiler will warn this and most probably reject it
// If _Ty is a reference, then you can't have a pointer on a reference and can't have references uninitialized.
}
So I'm screwed. I can't use STL container in my apps. Though the allocator goal was to abstract the memory allocation, in that case, you can't. The STL allocator is unoptimized regarding memory alloaction and, worse, totally unoptimizable.
In .NET, generics have solve that issue by working either on value types and on reference types. STL have failed that completly. But only simple tricks or having followed object oriented rules form the beginning could have done the same thing.
I was a huge C++ fan and a STL user for long time. But for realtime apps, I can only warn everyone to never try to use it.
So:
std::deque<std: :string const &>
is impossible to declare.
But, it is also more than impossible to find a workaroung using a custom STL allocator because of the ugly and not object oriented design that was used. Thanks to many STL contributor for this, specially to PJ Plauger where his name is everywhere in the STL header/footer.
This is the reason why this is impossible:
class allocator
{
///...
pointer allocate(size_t ype _Count, const void _FARQ *)
{ // allocate array of _Count elements, ignore hint
return (allocate(_Coun t));
}
void construct(point er _Ptr, const _Ty& _Val)
{ // construct object at _Ptr with value _Val
_Construct(_Ptr , _Val);
}
}
If if was something like this:
class allocator
{
///...
_Ty construct(const _Ty& _Val)
{ // construct object at _Ptr with value _Val
return *(new _Ty( _Val)); //C++ optimizer will get rid of the copy call in the return statement so there is no performance loss with that approach
}
}
Then I could have made this:
class StackbasedAlloc ator
{
///...
_Ty construct(const _Ty& _Val)
{ // construct object at _Ptr with value _Val
return _Val;
}
}
Which is fully object oriented in C++ and I could have build my allocator to support object by reference in a deque container. The problem with the current implentation is a very major one and implies directly that references CANNOT be used in STL container. So STL container will never be able to meet realtime specs on embedded (even on desktop) computers. Memory heap allocation cost too much on those device specially for small object.
So with this:
pointer allocate(size_t ype _Count, const void _FARQ *)
{ // allocate array of _Count elements, ignore hint
return (allocate(_Coun t));
}
You can't do this:
pointer allocate(size_t ype _Count, const void _FARQ *)
{ // allocate array of _Count elements, ignore hint
return &_Ty(); //Compiler will warn this and most probably reject it
// If _Ty is a reference, then you can't have a pointer on a reference and can't have references uninitialized.
}
So I'm screwed. I can't use STL container in my apps. Though the allocator goal was to abstract the memory allocation, in that case, you can't. The STL allocator is unoptimized regarding memory alloaction and, worse, totally unoptimizable.
In .NET, generics have solve that issue by working either on value types and on reference types. STL have failed that completly. But only simple tricks or having followed object oriented rules form the beginning could have done the same thing.
I was a huge C++ fan and a STL user for long time. But for realtime apps, I can only warn everyone to never try to use it.
Comment