ignore

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: daveangelQuote void f1A(const string* str){ cout << *str << endl; delete str; // should we? yes we can, but no }str is a pointer to a string allocated on the stack. this will crashNo, this is std string class. It had its own heap. Run the code and see Dave, you don't think I would post NON-MACHINE_READABLE code on Wilmott? Rule #2: Thou shallst not place pseudo-code on Wilmott you are right - str is a pointer to a string objdelete str invokes the destructor for str.

purged

n/a V3 is now leak-free.

Hi kevin,It looks like, because kevin called this a brainteaser, it became far more complicated than what it actually is. Also, everytime C++ guys talk about char* it's like taking care of the Devil itself. But without bothering what the heap or stack are or how and why we should use delete[], we could just say delete only what YOU allocated (either from a direct call to new or using a function that does so).When you call f1 using f1("will I leak?"), the system allocates a temporary variable, puts "will I leak?" in it, calls f1 with it, and deallocates it when f1 returns. So no memory leak issue here and you don't have the right to alter/delete str in f1.Now, for the reason why Cuch could (and did) call delete on str in f1A (V2 version) was not because it's a string which is a super-smart C++ thing that uses an internal heap and so and so: it was just because str was a pointer that Cuch allocated himself before calling f1A. No? Try calling f1A (in V2, with the call to delete) this way:{ string chh("dddddd"); f1A( &chh );}And mister Cuch was king enough, once he knew that now you know why you should not play with unwanted pointers, to provide the best version: V3.Cheers

I would have thought that this would cause a crash.delete should only be used on variables that are allocated on the heap. The string passed to the function isn't, it's built in to the executable (BSS section I think),so once the program exits the memory is automatically freed. There's some confusion about what's on the stack, the compiler will push a pointer to the string on the stack, not the string itself.The ownership argument is quite valid too. Where I work the convention is that a function that expects a pointer to something takesownership of that something, otherwise use a reference. A function that returns a pointer to something relinquishes owership of thatsomething to the caller. Any deviations (extremely rare) must be explicitly documented.Edit: I just saw daveangels post

My own coding rule is never code delete. If you need to delete things use a smart pointer.The only time to use delete is when you need to code a new smart pointer template class which is very rare.

Ok, now we know that deleting string literals via char pointers causes the program to crash. But how about this new example?

if you uncomment the delete my compiler doesn't like the delete name as its a const char*. i f you change everything to char* then it crashes as expected.its not a particularly clever string class - I suppose its not supposed to be.

well it's not really a smart pointer --it's just a rewrite of the standard dumb pointer

QuoteOriginally posted by: kevin08Ok, now we know that deleting string literals via char pointers causes the program to crash. But how about this new example?No no no, this has nothing to do with char*, it will crash for any data type. It crashes because you're trying to delete something that should not be deleted. Your new example will also crash if the string resides in the exe . If you change the SmartCharPtr ctor to clone the 'name_' argument and the dtor todelete the clone it will work as expected.

That is right. String literals are static. It is explained in section 5.2.2 of Stroustrup's "The C++ Programming Language"

QuoteOriginally posted by: kevin08That is right. String literals are static. It is explained in section 5.2.2 of Stroustrup's "The C++ Programming Language"I don't know if anyone is disagreeing here ...

this is a much safer "smart" String

What happens if you delete[] memory allocated with new, not new[]? Say,