From 3129495055341009798 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,2340bb60e0f0f248,start X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-02-14 08:27:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!dispose.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: Markus Werle Newsgroups: comp.std.c++ Subject: proposal for resolution of "valarray operator[] const returning value" (closed isuue 77) Date: Thu, 14 Feb 2002 16:26:46 GMT Organization: Aachen University of Technology (RWTH) Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: X-Trace: mail2news.demon.co.uk 1013704015 mail2news:7511 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit NNTP-Posting-Date: 14 Feb 2002 16:24:42 GMT User-Agent: KNode/0.6.1 Lines: 94 Xref: archiver1.google.com comp.std.c++:9620 Hi! I refer to http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-closed.html#77 a closed issue I would like to see reopened. The return type of valarray::operator[](size_t) const; is - in constrast to std::vector:::operator[](size_t) const; a _value_ and not a const reference, which makes pretty much sense when SomeClass is an integral type or something small to fit into registers. But here we have it: premature optimization. Again and again people who first used std::vector fall into the trap of a defect which can be easily avoided. I for myself can think of a lot of cases in which I wished to have all the functionality of valarray, but a return type of const reference, (e.g. valarray > for compressed matrices) and so I propose an extension of valarray which I think does not break existing, conformant code. The proposal may also fit for other containers. I may be wrong, this is why I post it here, so do not hesitate to kill my proposal immediately :-) Proposal: add to valarray an additional template parameter with a default value, that allows fine grain control on the behaviour regarding return types of const member functions: ------------------------------------------------------------- template class valarray { // [...] typedef typename DecisionOnReturnType::Type ConstRetType; ConstRetType operator[](size_t) const; T& operator[](size_t); // [...] }; -------------------------------------------------------------- with the default case being something like ------------------------------------------------------------- template class IntegralTypesReturnByValue { private: //maybe use sth. like (!Loki::TypeTraits::isStdIntegral) static const bool criterion_ = (sizeof(T) > sizeof(double)); template struct Decision { typedef const C& Type; }; template struct Decision { typedef C Type; }; public: typedef typename IntegralTypesReturnByValue::Decision::Type Type; }; --------------------------------------------------------------- Maybe namespace std; could also contain 2 other Policy classes 1. template AlwaysReturnByValueLikeInANSI1998; 2. template AlwaysReturnByReferenceLikeInFortran; Number 1 is a hot candidate as default policy, because no existing code should break then. What I like most with this approach is that it satisfies both, me and You, no matter which way we need it. No pressure on the user in any direction, isn't that fine? Btw: It takes half an hour for every vendor to adapt his/her library while it enhances valarray's usefulness in (most STL vendors really have to look at their valarray implementation anyway :-) ). What do You think? Markus --- [ 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://www.research.att.com/~austern/csc/faq.html ]