RDE STL - fixed vector, first draft

Uploaded first draft of fixed_vector class to RDESTL (well, right now it’s just a different storage type, to increase code reuse). It needs some cleaning up and I’m not really satisfied with the shape of final interface for the moment, but the general idea seems to work. Basically, it’s exact equivalent of vector class, but all the memory is allocated statically on the stack. Capacity is generally fixed and shouldnt really grow (TODO: add methods to record watermarks). There’s an option to fall-back to user allocator on overflow, but in most cases it shouldnt happen in final builds. Result is much smaller memory fragmentation.

[Edit] PS. I finally got X360. Some days later Microsoft announced they would cut the price. Go me.

Old comments

Maciej Miasik 2008-03-12 23:02:22

D:>svn checkout http://rdestl.googlecode.com/svn/trunk/ rdestl-read-only
svn: URL ‘http://rdestl.googlecode.com/svn/trunk' nie istnieje
Hm…

admin 2008-03-12 23:23:24

Try without ‘trunk’. Google documentation seems to be wrong here.

Lee Winder 2008-03-15 14:53:54

It’s interesting to see that you have gone down the route of inheriting from rde::vector for your fixed_vector object. I take it that means the majority of the stack based allocation will be done in the allocator?
Why not just provided a rde::fixed_allocator which would then allow the basic fde::vector to be used?
In my own work with STL ports, I have provided a fixed vector and not gone down the route of inheritance to keep the interface as clean as possible. While this has resulted in more work, it tends to be a bit simpler to read and maintain.

admin 2008-03-15 19:16:52

Rationale for that was that I wanted to make syntax as simple as possible, ie something like: rde::fixed_vector<int, 64> v (as it’s now), instead of rde::vector<int, rde::fixed_allocator<int, 64> > v. So, if I had to provide separate class anyway, I decided to go with “storage” policy. This way I can also block additional allocations on overflow (in reallocate() method of TStorage), record watermarks and so on (see latest version). In the final version fixed_vector isnt supposed to do any allocations at all.
I definitelly didnt want two separated classes as I didnt want to implement all those insert/remove/erase/push_back etc methods 2 times.