From 2954869591908303654 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,2340bb60e0f0f248 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-02-14 11:04:01 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!t-online.de!colt.net!dispose.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: tom_usenet@hotmail.com (tom_usenet) Newsgroups: comp.std.c++ Subject: Re: proposal for resolution of "valarray operator[] const returning value" (closed isuue 77) Date: Thu, 14 Feb 2002 19:03:28 GMT Organization: [posted via Easynet] Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <3c6c03e9.287237645@news.easynet.co.uk> References: X-Trace: mail2news.demon.co.uk 1013713418 mail2news:9037 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) X-Newsreader: Forte Free Agent 1.21/32.243 NNTP-Posting-Date: Thu, 14 Feb 2002 18:50:13 GMT Lines: 64 Xref: archiver1.google.com comp.std.c++:9636 On Thu, 14 Feb 2002 18:13:39 GMT, Gabriel Dos Reis wrote: >Markus Werle writes: > >[...] > >| But here we have it: premature optimization. > >Or: speculative optimization :-) But it might be a big optimisation. There is no way to get a pointer or reference to an element in a const valarray, hence there is no way to alias an element in a const valarray, hence the compiler can generate code that assumes no aliasing, which means that valarray has a hope in hell of matching Fortran performance. > >| Again and again people who first used std::vector >| fall into the trap of a defect which can be easily avoided. > >More importantly, it makes valarray<> unusable in most real world >programs. There are plenty of numerical routines out there written in >C and passing valarray<> data to them for inspection is not as trivial >as it should have been or intented :-( > >FYI, the GCC/g++ changed that operator to return a const reference. Why didn't they just use the __restrict__ extension keyword inside all the const valarray methods, allowing their valarray to be faster than anyone elses, assuming gcc is good at using its own __restrict__ keyword? Or are compilers good enough without this? > >| 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. > >I have trouble to conceive a real-world program which would be broken >if that operator's return type were changed to const reference. So >let keep it simple and straight. But any implementation that already uses inline assembler or extensions like __restrict__ and assumes no aliasing will have to be rewritten and will slow down horribly in the process. Perhaps some compilers have been written to know that const valarrays can't be aliased? OTOH, I am unaware of any implementaton that does optimise valarray in this manner. Which is a shame. Obviously, if the optimisation has been attempted and shown to have little benefit, then we should definitely shift to the const reference return, since that has greater utility. Tom --- [ 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 ]