I've been avoiding advanced use of auto_ptr (such as in function interfaces) because the standard on it was finalized at a late date and as a result many compilers has non-standard implementations. I think VC6 still has a non-standard implementaiton of auto_ptr. When Crypto++ stops supporting VC6, maybe I'll switch at that point.
On Fri, Mar 21, 2003 at 10:11:18PM -0800, Michael Hunley wrote: > 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
