help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: porting error I don't understand


From: Jan van Mastbergen
Subject: Re: porting error I don't understand
Date: Fri, 13 May 2005 00:21:34 +0200

>From my somewhat dated experience with (Borland) C++: the essential problem
with your code imho is the
declaration of your function:

Matrix ProductMatrix( Matrix& A, Matrix& B )

as stated it creates a Matrix object on the call stack. To pass it by
reference to the overloaded assignment operator
means that its stack address is taken and passed. The compiler has no way to
prevent that (as a side effect of the operator=) the address passed may be
used long after the object has been discarded from the stack (i.e. after Y =
ProductMatrix( M, Y ) has completed) and considers this unsafe programming.
It deals with it by not automatically taking the address to match the
operator=.
I seem to recall that the Borland compilers provided more of these
convenience features as automatic type conversion than competing products,
which may explain your current problem.

As a matter of style, I would not write API's that return objects on the
call stack which may be of indeterminate size and/or where copy and
initialisation operations are non-trivial. In such cases I would pass an
additional object by reference to receive the result and let the caller take
responsability for construction/destruction.

Regards, Jan van Mastbergen


"mark" <m.somers@chem.leidenuniv.nl> wrote in message
1115900415.231735.154130@g44g2000cwa.googlegroups.com">news:1115900415.231735.154130@g44g2000cwa.googlegroups.com...
> Hi,
>
> recently I revisited some code I wrote a few years ago using the
> Borland c++ 3.0 compiler. I'm in the middle of porting the code to g++
> {gcc version 3.3.4 (pre 3.3.5 20040809)} and I'm stuck with a specific
> error I just don't seem to understand.
>
> The error I get is:
>
> mchpoly.cpp: In function `Vector CharacteristicPolynom(Matrix&)':
> mchpoly.cpp:71: error: no match for 'operator=' in 'Y =
> ProductMatrix(Matrix&,
>    Matrix&)((&Y))'
> matrix.h:142: error: candidates are: Matrix& Matrix::operator=(Matrix&)
>
> The corresponding line is:
>
>  ...
>  ...
>  ...
>
>  do {
>      for( R = 1; R <= N; R++ )    /* create random Y0 */
>       VectorElement( Y, R ) = complex( rand() % 10, rand() % 10 );
>
>      for( R = 1; R <= N; R++ )     /* for each row ... */
>      {
>       for( C = 1; C <= N; C++ )      /* add Yn to T */
>        MatrixElement( T, C, N - R + 1 ) = VectorElement( Y, C );
>
> =====>>>>      Y = ProductMatrix( M, Y );         /* calculate new Yn
> */
>      }
>
>      DoGaussJordan( T, Y );          /* solve the equation into Y */
>      I--;
>     } while( ( MatrixElement( T, N, N ) != ONE_CMPLX ) && ( I ) );
>
>  ...
>  ...
>  ...
>
>
> The definition of the ProductMatrix function is:
>
> Matrix ProductMatrix( Matrix& A, Matrix& B )
> {
>  Matrix Prod;
>  unsigned R, C, k;
>  unsigned PR, PC, AC;
>
>  ...
>  ...
>  ...
>
>  return( Prod );
> }
>
> Moreover, the class definition of Matrix contains:
>
> class Matrix { public:                      /* def of a matrix */
>
>                // constructors
>                Matrix( void );
>
>  ...
>  ...
>  ...
>                // overloaded operators
>                Matrix&  operator=( Matrix& A );
>
>  ...
>  ...
>  ...
>
> }
>
>
> The reason why in operator= the A matrix is passed as a reference is
> because the operator= is used to "pass-through" memory from A to *this
> by copying a pointer. In A however, the pointer should be set to 0 (or
> NULL) in order to make sure that the calling of the destructor of A
> doesn't free the memory. So in short the operator= changes Matrix *this
> as well as Matrix A.
>
> As far as I understand, the compiler is not able to find a correct
> operator= function, yet I think I've defined and implemented one.
> Moreover, I've noticed that the function reference in the error
> contains an "((&Y))" part, something I didn't expect. What's the deal
> with that?
>
> Could anyone give a clue on this?
>
> As a side note: the code compiled fine of course with Borland, Cray and
> MIPS c++ compilers three years ago. It doesn't however with g++ and the
> newly available Intel C++ compiler.
>
> best regards,
>
> mark somers.
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]