Kritik an std::allocator
-
Unfortunately, the std allocator design and its use by std containers make it hard to work with and leads to suboptimal performance and code bloat. These are some serious charges, but in the realm of high performance game development they are real and significant. The following is a list of some of the issues of std allocators and std containers' use of std allocators:
* std allocators are class-based and not instance-based. This results in some awkward attempts to make them act as if instance-based.
* Allocators are virtually required to be templates, and rebind is required to be a member template. Unless the compiler is very good at inlining (and some compilers are not -- see Appendix item 15), this can result in an explosion of templates, code, and performance problems.
* Allocators are rebound by containers to one or more additional types -- types which the user cannot know in any portable way. Thus the author of an allocator cannot know what it will actually be asked to allocate and construct. It is ironic that user-supplied allocators to STL containers in practice don't allocate objects of the user-specified type. It is unfortunate that there is no portable way for the container user or allocator implementor to know what the allocator will be asked to allocator or what it will be rebound to. This somewhat defeats the purpose of the allocator being templated on some type.
* Allocators don't understand alignment requirements. Objects allocated by a std allocator are assumed to be of default alignment (usually equal to sizeof double) or it is assumed that the implementor of the allocator knows what the alignment is. Neither of these assumptions are satisfactory, as the former can be simply untrue and the latter can be impractical or impossible.
* Allocators are required to construct and destroy objects as well as allocate them. This forces the mixing of two separate concepts: allocation and construction.
* Containers require you to set an allocator at container construction time; you cannot set it later.
* Containers do not let you access their allocators; they only give you copies of their allocators.
* Current STL implementations such as libstdc++ (up to libstdc++ v4.1, apparently rectified with v4.2) copy allocators and create temporary allocators during empty construction and copy construction, which can result in performance problems in the case of expensive allocators. The user is thus steered towards making allocators lightweight classes which are references to the actual allocators in use, which results in unwanted indirection overhead and extra code.
-
Ich brauche mir den Text garnicht durchlesen. Die Kritik (egal welche!) ist unberechtigt. Denn es ist eine Standard-Allocator, der selbstverständlich nur ein Kompromiss sein kann und ist! Und man kann z.B. die Standard-Container anweisen, einen anderen Allocator zu benutzen. Warum? Weil man schon damals gewusst hat, das der Std-Allocator nicht jedem Gerecht sein kann.
Wenn einem der Std-Alloc nicht gefällt, implementiert man sich selber einen oder sucht sich einen aus, den vielleicht jemand anderes schon implementiert hat.
-
-
Bulli schrieb:
Ich brauche mir den Text garnicht durchlesen. Die Kritik (egal welche!) ist unberechtigt. Denn es ist eine Standard-Allocator, der selbstverständlich nur ein Kompromiss sein kann und ist! Und man kann z.B. die Standard-Container anweisen, einen anderen Allocator zu benutzen. Warum? Weil man schon damals gewusst hat, das der Std-Allocator nicht jedem Gerecht sein kann.
Wenn einem der Std-Alloc nicht gefällt, implementiert man sich selber einen oder sucht sich einen aus, den vielleicht jemand anderes schon implementiert hat.
ROFL. Was für ein Pfosten du bist
Es geht nicht um die Implementierung, es geht um das Interface. Und das Interface ist bekanntermassen Mist.
