STL By object reference container to support real-time specs

[OuaisBla]

What I'd like to do and what I tought possible was to have a deque of string when the string was a reference (not a pointer)

Then I simply tried:

std::deque<std: :string const &> mFifo;

But, the compiler have some trouble with this at the first try.

From what I know, template is a powerful mecanism an STL a well programmed library. I'm using VS2005 but STLPort seems with a quick look to suffer the same problem I will discuss shortly.

The thing is that I have a program running on Windows CE 5.0 which have some real-time specs. So, heap allocation in most case must be avoided. But I still want to use STL.

So. I tried to fix that with a user defined partial specialization of the allocator like this:

template<class _Ty>
class allocator<_Ty const &>

leaving the rest exactly the same. This should have work ... but ...

The deque contructor declared like this is making me wrong.
deque(size_type _Count, const _Ty& _Val)

This output: warning C4181: qualifier applied to reference type; ignored
and : //error C2529: '_Val' : reference to reference is illegal

Having coded the constructor like this would have fix the problem:
deque(size_type _Count, const_reference _Val)

where:
typedef typename _Alloc::const_r eference const_reference ;

and where:
typedef const value_type _FARQ& const_reference ;

I wonder why I wasn't done like this. This would have make the STL library equivalent to .NET generics because with .NET the string class is readonly first and only references to it are used. So no copy, no heap allocation, then better runtime performance.

Unless I'm missing something important. After those many years STL, even though massively used, cannot offers much in the realtime world. Too much heap allocation, impossible to have object by reference containers. The complexity of algorithm is garantied but at the cost of a big constant time basic operations.

If some STL guru (like PJ Plauger) are somewhere out there and reading this, please help me with that or think about it in next version.

(Of course I can rewrite my own deque fixing those things, but that not point. user defined STL like container is not stanrard STL)

[weaknessforcats]

See my post on your later thread.

[OuaisBla]

Ok. I saw it. But you don't understand.

In .NET, if you have a string object. The useful content is place somewhere in memory and referenced many many times.

List<string> is a list of reference to strings.

Also List<int> is a list of value type of int.

You then have best of both world. In C# you have pointer too in a unsafe context making possible miracles of runtime performance when needed. A programmer is then equipped with great tools to perform great tasks. Also the dispose pattern can bypass the garbage collector non deterministic behavior problems.

But, for those who still want more control, C++ is still the best solution. But STL, as it is right now, is far from useful.

std::deque<std: :string> is a deque of COPY of strings. Not references.

So I tought this possible:

std::deque<std: :string const &> .

This would have be what I wanted. My string are static const object allocated at the startup of the application and it is useless to create copies over and over during the live of the application.

But because the how the std::allocator is designed, it is impossible to do.

Allocator is and only is a HEAP allocator. You CAN'T create a reference by using the HEAP. So you can't have deque of reference. Point proven.

So far, unless a miracle occurs, I'm force to remove every STL reference in my apps and use C structure like container (fixed arrays, pointer and so on.)

More and more C++ community will be shadowed by .NET community because the people you propose standard use limiting set of rules and for the sake of pureness never wants to question them.

I used to be one of those.