Let A, B, C, and X be the dgematrix objects, and A, B, and C be the same size and initialized properly.
|CPPLapack||ordinary matrix libraries|
|operator*||calculate A*B, and put it to a local _dgematrix object P to return||calculate A*B, and put it to a local dgematrix object P to return|
|passing of returned object||make a temporary _dgematrix object Q as the shallow copy of P||make a temporary dgematrix object Q as the deep copy of P|
|destructor for local object||destruct local object P without deleting the array data||destruct local object P with deleting the array data|
|operator+||add C into Q, and return Q.||calculate C+Q and, put it to a local dgematrix object R to return.|
|passing of returned object||make a temporary _dgematrix object R as the shallow copy of Q||make a temporary dgematrix object S as the deep copy of R|
|destructor for local object||destruct local object Q without deleting the array data||destruct local object R with deleting the array data|
|operator=||set the array address of X to that of R||copy whole the data of S to X|
|implicit destructer (;)||destruct the temporary object R without deleting the array data||destruct the temporary objects Q and S with deleting the array data|
CPPLapack does not consume any extra memory space using its original "Smart-Temporary" system. On the other hand, ordinary matrix libraries always generate useless temporary objects implicitly and consume a lot of extra memory space. CPPLapack is efficient not only in computing speed but also in saving memory space.
[NOTE] Recent advanced compilers automatically optimize the way of passing returned objects. The steps shown above is the case of the most primitive compiler. The performance of ordinary matrix libraries using advanced compilers becomes close to the performance of CPPLapack. However, CPPLapack still has some advantages in terms of the stepwise elimination, minimization of the number of temporary objects, and so on.