RE: I'm confused.

[Michael Hunley]

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