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