shared_ptr in Error class

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

shared_ptr in Error class

Kakhkhor Abdijalilov
Any particular reason to use boost:shared_ptr to store the error
message. Just curious.


Regards,
Kakhkhor Abdijalilov.

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: shared_ptr in Error class

Luigi Ballabio

On Apr 9, 2011, at 11:16 AM, Kakhkhor Abdijalilov wrote:

> Any particular reason to use boost:shared_ptr to store the error
> message. Just curious.

It was to avoid copying strings when exceptions are passed.  Not for  
performance reasons, but rather to make it less likely that copying an  
exception raises another one.  It would not be likely, but it cost  
little to use the pointer instead.

Luigi


------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: shared_ptr in Error class

Kakhkhor Abdijalilov
I think smart pointer is not needed, since exception objects should be
passed by reference. Following "less is more" principle the shared
pointer to string could be replaced by a plain string.
Regards,
Kakhkhor Abdijalilov.

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: shared_ptr in Error class

Luigi Ballabio

On Apr 10, 2011, at 11:02 AM, Kakhkhor Abdijalilov wrote:
> I think smart pointer is not needed, since exception objects should be
> passed by reference. Following "less is more" principle the shared
> pointer to string could be replaced by a plain string.

They are caught by reference, but thrown by copy.  If you try compiling

class Foo {
   public:
     Foo() {}
   private:
     Foo(const Foo&);
};


int main() {
     try {
         throw Foo();
     catch (Foo&) {}
     return 0;
}

the compiler (well, gcc at least) will complain that the copy  
constructor is private at the "throw" line.

Luigi



------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: shared_ptr in Error class

Bojan Nikolic

Luigi Ballabio <[hidden email]> writes:

> the compiler (well, gcc at least) will complain that the copy  
> constructor is private at the "throw" line.

All compilers should do the same:

,---- From http://www.open-std.org/jtc1/sc22/open/n2356/except.html
|  When
|   the thrown object is a class object, and the copy constructor used  to
|   initialize  the  temporary copy is not accessible, the program is ill-
|   formed (even when the temporary object could otherwise be eliminated).
|   Similarly,  if  the  destructor for that object is not accessible, the
|   program is ill-formed (even when the temporary object could  otherwise
|   be eliminated).
|
`----

However, this is not the same as saying that the copy constructor is
actually always invoked because of the following statement

,---- From http://www.open-std.org/jtc1/sc22/open/n2356/except.html
| If the use of the temporary object can be eliminated without
|   changing the meaning of the program except for the execution  of  con-
|   structors  and  destructors  associated  with the use of the temporary
|   object (_class.temporary_), then the exception in the handler  can  be
|   initialized  directly with the argument of the throw expression.
`----

So, in this program the copy constructor is (I believe) not invoked:

#include <iostream>

class Foo {
public:
  Foo() {};
  Foo(const Foo&)
  {
    std::cout<<"copy ctr"<<std::endl;
  }
private:

};

int main() {
     try
     {
         
       throw Foo();
     }
     catch (const Foo &f)
     {
       std::cout<<"in the handler"<<std::endl;
     }
     return 0;
}



Best,
Bojan

--
Bojan Nikolic          ||          http://www.bnikolic.co.uk

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev