This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project. See the libstdc++ home page for more information.


[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

valarrays broken



>>>>> «TK», Thomas Kunert <kunert@physik.tu-dresden.de> écrit :

TK> Consider the following code from std_valarray.h:
TK>  template<typename _Tp>						
TK>   inline _Meta								
TK>     <_BinaryExpression<valarray<_Tp>, _Constant<_Tp>, name##<_Tp> >,
_Tp> 
TK>   operator##op (const valarray<_Tp> &__v, const _Tp &__t)		
TK>   {									
TK>       typedef _BinaryExpression						
TK>         <valarray<_Tp>, _Constant<_Tp>, name##<_Tp> > _Expr;		
TK>       return _Meta<_Expr, _Tp> (_Expr (__v, _Constant<_Tp> (__t)));	
TK>   }									

TK> What happens? A temporary of type _Constant<_Tp> will be created. With
TK> that temporary a _BinaryExpression is constructed. The _BinaryExpression
TK> stores just *references* to its arguments. After return from the
TK> function the temporary _Constant will be destroyed, rendering the
TK> reference invalid.


Actually that was an oversight. I'll send you a patch as soon as I'm
back (I'm currently out for one week).


TK> The bug is triggered only if the temporary on the stack actually has
TK> been overwritten by anything else, and that depends on too many factors.
TK> That's why I can't provide example code that triggers the bug reliably.

In fact the bug does not show up (in most cases) with optimization
option -Ox (x>1) turned on. You can trigger it with -O0.


TK> BTW, reading the code is unnecessary complicated because of the cryptic
TK> identifier names. Why don't you use readable names, at least for local
TK> variables, at least during the development? I know, ugly names are
TK> necessary for standard compliance, but that is less important than
TK> making the code robust. And this latter task is complicated enough, one
TK> doesn't need to make it even more difficult. After finishing the code
TK> `uglifying' is a matter of just some hours.

I don't know how long it took to Nathan to uglify the complete code. 


I'm afraid I don't clearly understand your point. My initial version
was not uglified. But I strongly agree with the uglification policy as
it enables one to use snapshots of the library in user applications
(for testing purposes). 

(Please keap in mind that names lookup in templated code is done in
*two* stages).

Best,

-- 
Gabriel Dos Reis                   |  Centre de Mathématiques et de 
dosreis@cmla.ens-cachan.fr         |         Leurs Applications
Fax : (33) 01 47 40 21 69          |   ENS de Cachan -- CNRS (URA 1611)
               61, Avenue du Pdt Wilson, 94235 Cachan - Cedex