Custom deletion vs 'scope deletion'

[BasV]

Hi,

Sorry for the vague title, but I couldn't think of better terms.

I was wondering; is there a specific difference between these two deletions:

{
  std::string myString();
}
{
  std::string* myString = new std::string();
  delete myString;
}

I'm not asking about the difference in wether it's saved on the stack or the heap, etcetera, but rather: Are different pieces of code (constructors, destructors) used?
I'm asking because I'm using a library (libnoise) that causes an error whenever I delete an object made with a new statement. However, when I have objects temporarily in a scope, they don't cause errors. But their destructors are called implicitly aren't they?

Thanks!

[Dy7SLyTq]

yes. the first one is deleted with a deconstructor. the second one is dynamically allocated and then garbage collected with delete. i didnt explain it well, but they are different. while ~basic_char() probably has *'s so it would use delete, your second example doesnt use a deconstructor

[Cubbi]

is there a specific difference between these two deletions:

the first one is what you'd normally see in C++, the second one is exception-unsafe, Java-esque (what's with those parentheses after new std::string?) oddity.

Are different pieces of code (constructors, destructors) used?

The same default constructor and the same destructor for std::string is called, but the second example also calls operator new and operator delete, which are user-replaceable functions. Also, they may be calling lower-level memory allocation functions, which a library can replace as well.

Although, if that's the same library I see in google, it doesn't seem to do that. It's more likely that you've used memory allocation improperly earlier in the program and damaged system memory, so that now the delete happens to hit the damaged block and fails.

[MikeyBoy]

yes. the first one is deleted with a deconstructor. the second one is dynamically allocated and then garbage collected with delete. i didnt explain it well, but they are different. while ~basic_char() probably has *'s so it would use delete, your second example doesnt use a deconstructor

Firstly, the word is "destructor", not "deconstructor".

Secondly, you're completely wrong. In both code snippets, the default constructor is called, and then the destructor is called.

[Dy7SLyTq]

Firstly, the word is "destructor", not "deconstructor".

your right my mistake. i dont know what i was thinking. i had two prefixes that would cancel each other out, making it just structor :P.

secondly didnt mean to mislead the op, so sorry if i did, but im a little confused. is delete a destructor then? looking back i see that the constructor is called at new std::string();. however i didnt think that the destructor was called at delete, only if its gone out of scope?

[Disch]

I'm surprised nobody mentioned this...

std::string myString();

This is wrong. You are not creating an object here, but are prototyping a function which takes no parameters and returns a string.

If you want to create a string object you do this:

std::string myString;  // <- note:  no parenthesis 

[Dy7SLyTq]

cubbi wrote:

one is exception-unsafe, Java-esque (what's with those parentheses after new std::string?) oddity.

[MikeyBoy]

secondly didnt mean to mislead the op, so sorry if i did, but im a little confused. is delete a destructor then?

No, delete isn't a destructor. A destructor has a name like:

MyClass::~Myclass().

The destructor is called automatically whenever an object is destroyed. This occurs when an object on the stack falls out of scope - as in the OP's first example - or when an object on the heap is deleted - as in the second example.

[Dy7SLyTq]

No, delete isn't a destructor. A destructor has a name like:

MyClass::~Myclass().

yeah thats what i thought. however what you said below makes sense. thanks for that

[Disch]

DTSCode wrote:

cubbi wrote:

Cubbi was talking about the 2nd example, where the parenthesis are unnecessary (but not code-breaking). Whereas he did not mention anything regarding the first example, where the parenthesis actually break the code.

[BasV]

I will look into the possibility of the new and delete operators causing something.

I'm sure it's not a memory bug elsewhere, I've already tried recreating this behavior in an empty project that only had the new and delete statements.