I'd like to add my vote to this -- it would be a great improvement to the interface.
Chris -----Original Message----- From: Michael Hunley [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2003 10:11 PM To: [EMAIL PROTECTED] Subject: RE: I'm confused. Actually, I think many people get tripped up by that (and other similar constructs); I know I did the first time. Wei, wouldn't it be more clear to have those functions/constructors that take pointers to objects that they expect to come from the heap, which they will later free for you, take them as auto_ptr's? Then it would be clear that you are giving up control of that memory (and responsibility) and that it had to come from the heap by default. Furthermore, it would also let client code use it's own allocator's if it really wanted to without adding any hassle to the core Crypto++ code. Am I missing something? michael At 03:30 PM 3/19/2003 -0800, you wrote: >Yeh. I finally figured out that passing an encoder that's not allocated >from the heap is a bad idea. Nice little hidden gotcha, that. > >-----Original Message----- >From: Walton, Jeffrey [mailto:[EMAIL PROTECTED] >Sent: Wednesday, March 19, 2003 3:27 PM >To: '[EMAIL PROTECTED]' >Subject: RE: I'm confused. > > >| -----Original Message----- >| From: Julia Smith [mailto:[EMAIL PROTECTED] >| Sent: Wednesday, March 19, 2003 6:04 PM >| To: [EMAIL PROTECTED] >| Subject: I'm confused. >| >| >| void foo() >| { >| string sstr( "asdfasfsafd" ); >| string dstr; >| StringSink sink( dstr ); >| Base64Encoder encoder( &sink ); >| StringSource src( sstr, true, &encoder ); >| } >| >| causes vc++ to trap on some break point I never set. Why >| doesn't this work when I try to step out of the function? > >Hi Julia, > >I think some of the objects are being deleted twice. The breakpoint in the >debugger (as you are describing) usually means heap corruption. > > >From the readme: >1. If a constructor for A takes a pointer to an object B (except primitive >types such as int and char), then A owns B and will delete B at A's >destruction. If a constructor for A takes a reference to an object B, >then the caller retains ownership of B and should not destroy it until >A no longer needs it. > >2. Crypto++ is thread safe at the class level. This means you can use >Crypto++ safely in a multithreaded application, but you must provide >synchronization when multiple threads access a common Crypto++ object. > >That's why you will see a lot of code like: >FileSource f(filename, true, new HexDecoder()); > >Jeff
