From 2017584207582461297 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,8e45f00ca435d49d X-Google-Attributes: gidf78e5,public From: "David Abrahams" Subject: Re: fundamental allocator design question. Date: 2000/05/26 Message-ID: #1/1 X-Deja-AN: 627577847 Approved: Fergus Henderson , moderator of comp.std.c++ References: X-Priority: 3 X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Trace: mail2news.demon.co.uk 959347277 mail2news:24878 mail2news mail2news.demon.co.uk Organization: Road Runner X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-MSMail-Priority: Normal NNTP-Posting-Date: Thu, 25 May 2000 23:23:52 EDT Newsgroups: comp.std.c++ Hi Marc, "Marc D Bumble" wrote in message news:m3wvkj4lva.fsf@cadence.glidepath.org... > > Is there an oversight in the allocator definitions? Allocators take > one template type parameter. The allocator then provides memory > having the same type as specified by its single parameter. And all of > this works well. However, it might be beneficial if the allocator > also took a second parameter which described the type of the allocator > itself. For instance, a user could specify: > > allocator > allocator > allocator How would that be beneficial? > I realize that the user could just provide different allocators as in: > > shared_allocator > pooled_allocator > persistent_allocator > > but designing multiple allocators seems somewhat less elegant. Code > reuse may impaired. How? > Perhaps it might be easier for users to simply > provide types to the interface as in the first case, as opposed to > entirely separate classes. I don't see how it would be easier... you'd end up writing vector > instead of vector >. You could always call pooled_allocator simply "pooled". Then you have vector >. That's easier to type, FWIW. Think for a moment how the interface you propose would be implemented. Would the allocator template itself be able to take _any_ action at all without consulting its 2nd type parameter (shared, pooled, persistent...)? I think for real genericity, the answer is no. That means you've just made the allocator template an empty shell which just forwards its arguments to members of the 2nd type parameter. What's the point? -Dave --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]