Re: I'm confused.

[Michael Hunley]

I've been using auto_ptr for exactly this purpose on my current project in 
VC6 and cross-compiled under GCC 3.2.2 on Linux.  The only issue with 
auto_ptr was that MSVC6 allowed you to be lazy about the conversion from a 
pointer to an auto_ptr, but otherwise work as expected.  I am no expert 
about the standard, so if there are specific requirements against such that 
VC6 does not support then they've never affected me.  The lazy cast can 
look like:
auto_ptr<foo> CreateFoo( void ) {
        return new foo; // works on VC6, GCC 3.2.2 complains and wants 
return auto_ptr<foo>(new foo);
}

What would Crypto++ require from the standard that VC6 does not support?

michael

At 05:34 PM 3/22/2003 -0500, you wrote:
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