This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Deque::fill
- From: Paolo Carlini <pcarlini at suse dot de>
- To: chris jefferson <caj at cs dot york dot ac dot uk>
- Cc: Howard Hinnant <hhinnant at apple dot com>, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Mon, 12 Dec 2005 16:03:08 +0100
- Subject: Re: Deque::fill
- References: <43677340.4060106@suse.de> <2F8AA632-0250-42FD-8BAD-495D598B1569@apple.com> <436B2C08.2020903@suse.de> <436B327D.1020707@suse.de> <27F806E6-A70B-4663-8C25-31BAD11BF2C8@apple.com> <4385BAA5.7080806@suse.de> <4385BDF1.1070004@suse.de> <E6973414-F993-4466-A3DD-7FDA11A83410@apple.com> <43875F50.6030200@suse.de> <7711BD77-3E6D-457F-9CAC-6681D28792A7@apple.com> <439D8998.6060008@suse.de> <439D8F39.4080205@cs.york.ac.uk>
chris jefferson wrote:
> On a similar note to some simplifications in vector, would it be
> better to "admit" that the size of a buffer is a compile-time
> constant, and make it a static const, rather than a function call?
You mean, we don't need anymore compiler kludges:
* This function started off as a compiler kludge from SGI, but seems to
* be a useful wrapper around a repeated constant expression.
:)
Yes, I think so.
> I mainly ask as I had a look a while ago at simplifying deque in the
> case that the objects are big enough it "degrades" into a vector of
> pointers to pointers. While the best simplifications would require
> ABI-breaking, it's possible to overload things like operator++,
> operator+, etc on _Deque_iterators with simpler versions which the
> compiler doesn't seem capable of deducing by itself.
I guess Howard has something especially relevant to say here, because
once I heard him talking about customers using very big objects (rvalue
references were of course part of the subject...)
Paolo.