1 ******************************************************************** 2 * This document describe the STLport container pointer * 3 * specialization feature. * 4 ******************************************************************** 5 6 What is it for: 7 8 The major problem of template code is the potentialy huge binary 9 size that can result from the compilation. Each template type 10 instanciation is a new type from the compiler point of view even if 11 the generated binaries are identicals. To avoid this binary duplication 12 STLport grant the partial pointer specialization for 4 containers: 13 - vector 14 - deque 15 - list 16 - slist 17 18 How does it work: 19 20 The pointer specialization consists in using a void* container 21 instanciation for any container of pointers, including pointers 22 to cv qualified types. So the container pointer specializations 23 are only bridges that forward all the method calls to the 24 underlying void* container instanciation. The bridge job is to 25 cast the pointer type to and from the void* type. 26 27 Why only those 4 containers: 28 29 Some of you might wonder why none of the associative containers 30 or hash containers has been specialized. Lets take the set container 31 as an example. Its declaration is 32 33 template <class _Tp, 34 class _Compare = less<_Tp>, 35 class _Alloc = allocator<_Tp> > 36 class set; 37 38 In a first thought you can imagine a partial specialization like 39 the following: 40 41 template <class _Tp, class _Compare, class _Alloc> 42 class set<_Tp*, _Compare, _Alloc> 43 44 What would be the underlying container for such a partial 45 specialization? The _Alloc type is supposed to have a rebind member 46 method so you can easily find the _VoidAlloc type. The _Compare type, 47 on the other hand, do not have this kind of Standard requirements. 48 So you need to wrap the _Compare type within a _WrapCompare type 49 that will take care of all the cast work. The underlying container 50 type will be: 51 52 set<void*, _WrapCompare<_Tp, _Compare>, _VoidAlloc> 53 54 The problem of such a type is that it is still dependent on the 55 original _Tp type for the _WrapCompare instanciation. So each set 56 instanciation will have a distinct underlying void* container and 57 we fall back on a binary duplication trouble. 58 59 On a second thought a possible solution is to limit the partial 60 specialization like that: 61 62 template <class _Tp, class _Alloc> 63 class set<_Tp*, less<_Tp*>, _Alloc> 64 65 We only specialized the set container if the comparison functor 66 is the Standard less struct. The underlying container would be: 67 68 set<void*, less<void*>, _VoidAlloc> 69 70 It looks fine but it is wrong. Actually a STL user is free to 71 specialized the less struct for any pointer type even the basic one. 72 In such a situation the client would think that the set is ordered 73 according its own functor but will finally have a set ordered according 74 the less<void*> functor. The less specialization issue also show that 75 the underlying cannot be a 76 77 set<void*, less<void*>, _VoidAlloc> 78 79 but will have to be a 80 81 set<void*, __less<void*>, _VoidAlloc> 82 83 where __less would be equivalent to the standard less functor but 84 would not be specializable because unreachable from the client code. 85 86 There is of course a solution for this specialization issue. We 87 need to be able to detect the less specialization. The partial set 88 specialization would have to be used only if the less functor is 89 the default STLport implementation based on the strict ordering operator. 90 No doubt that a solution to this problem will be soon found. 91
