From 7850688149040577931 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,8e45f00ca435d49d X-Google-Attributes: gidf78e5,public From: Marc D Bumble Subject: Re: fundamental allocator design question. Date: 2000/05/29 Message-ID: #1/1 X-Deja-AN: 628434432 Approved: Fergus Henderson , moderator of comp.std.c++ References: X-Original-NNTP-Posting-Host: 216.126.160.147 X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Trace: mail2news.demon.co.uk 959563460 mail2news:25070 mail2news mail2news.demon.co.uk Organization: PSU CSE http://www.cse.psu.edu X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) Newsgroups: comp.std.c++ >>>>> "David" == David Abrahams writes: Hi Dave, Thanks for the reply. When I tested an allocator of the type my_alloc, it didn't seem to work with the STL vector class. However, that may have been a bug in my attempt. My code is currently in the middle of its second generation, and not testable at the moment. In checking Stroustrup's text further to reply to your questions, I found that the my_alloc form is implied in section 19.4.3 on page 573 of the 3rd edition. The standard allocator definition in section 19.4.1 on page 567 does only have one type as in my_alloc? I am slightly confused at the moment and need to examine this further. But I also wanted to get you an immediate reply and thank you for your followup. >> allocator allocator >> allocator David> How would that be beneficial? its beneficial in the same way that allocator is better than allocator. It is easier to maintain one general coder version than many separate specific instances. So in theory it would be better to work with one: alloc than with alloc_int, alloc_char, alloc_double, etc. Plus you can use alloc for an anticipated type. So it is better to have: alloc instead of shared_alloc, persistent_alloc, pooled_alloc, etc. >> >> but designing multiple allocators seems somewhat less elegant. >> Code reuse may impaired. David> How? Its the same answer as above. If you use multiple type parameters, then only one alloc would have to be debugged, instead of shared_alloc, persistent_alloc, pooled_alloc, etc. Plus handling unanticipated secondary types is more difficult. The whole point of my line of questioning is that it would be nice to get these various allocators incorporated into the STL. >> 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. David> Think for a moment how the interface you propose would be David> implemented. Would the allocator template itself be able to David> take _any_ action at all without consulting its 2nd type David> parameter (shared, pooled, persistent...)? I think for real David> genericity, the answer is no. That means you've just made David> the allocator template an empty shell which just forwards David> its arguments to members of the 2nd type parameter. What's David> the point? If here you mean, could there be a default type for the second parameter which specifies the type of the allocator, I believe the answer is yes, it could assume a default type. Maybe, however, I am wrong, and, of course, that it why I'm asking. :) Thanks again for the thoughts. marc --- [ 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 ]