const valarray question
Gabriel Dos Reis
gdr@cs.tamu.edu
Tue Jan 10 17:17:00 GMT 2006
Paolo Carlini <pcarlini@suse.de> writes:
| Gabriel Dos Reis wrote:
|
| >| Why doesn't 26.3.1.3 apply for operator[](slice)const here? Or, why
| >| doesn't g++ choose that method?
| >
| >Implementor error. Fixed with this.
| >
| >-- Gaby
| >
| >2005-12-17 Gabriel Dos Reis <gdr@integrable-solutions.net>
| >
| > * include/bits/valarray_after.h (_Expr<>::operator[](slice)):
| > Don't assume the closure implements general indexing, as a matter
| > of fact, most of them don't.
| > (_Expr<>::operator[](const gslice&)): Likewise.
| > (_Expr<>::operator[](const valarray<bool>&)): Likewise.
| > (_Expr<>::operator[](const valarray<size_t>&)): Likewise.
| > (_Expr<>::shift): Fix thinko.
| > (_Expr<>::cshift): Likewise.
| > (_Expr<>::apply): Likewise.
| >
| >
| Gaby, can we have this patch in 4_1-branch too?
Yes.
| Also, about the POD issue (now tracked as libstdc++/25626) I think is
| sufficiently serious from the conformance point of view to warrant a
| rather urgent action: do you want me to extract a minimal fix from your
| large draft of a few weeks ago? I think I understand the problem
| sufficiently well.
the non-POD stuff + valarray is not as serious as you might think; but
yes, it is a bug in the implementation that should be fixed. I would
really like to make some cleanups; but I guess that cleanup does not
need to go with the bug fixing. The bug fixing without the cleanup
just looks weird to me.
-- Gaby
More information about the Libstdc++
mailing list