Consider the following two cases:
CCandyBox obj;

str will be pointing to "Candy"
May I know "Candy" is on heap or stack?
If it is on heap, is the
delete[] str; //delete the Candy to avoid memory leak
line below necessary?

CCandyBox(char* str = "Candy") // Constructor
{
    if (str == NULL)
    {
         m_Contents = new char[1];   // will be an empty string
         *m_Contents = 0;  //terminate string
    }
    else
    {
        m_Contents = new char[ strlen(str) + 1 ];
        strcpy_s(m_Contents, strlen(str) + 1, str);
        delete[] str; //delete the Candy to avoid memory leak
    }
}

>May I know "Candy" is on heap or stack?
Probably neither, and it doesn't matter as the compiler manages the memory for string literals. Trying to delete memory that you didn't explicitly allocate would be most unwise.

you delete[] m_Contents; since it was allocated onto the heap not str.

>> delete[] str; //delete the Candy to avoid memory leak

Don't do that because you don't know where str is allocated. The caller may call that function several ways, so its best to leave it up to the caller to delete the string when necessary. Any of the following sanerios are possible, and the CCandyBox constructure has no clue which one was used.

CCandyBox box; // use default constructor, in this case the string will be in the heap so its not necessary to delete it.

CCandyBox box("Candy"); // same as above

char str[] = "Candy";
CCandyBox box(str); str is on the stack but its not a pointer which was allocated by new, so delete will fail.

char* str = new char[10];
strcpy(str,"Candy");
CCandyBox box(str); // str was allocated by new, and must use delete[]
delete[] str;

>you delete[] m_Contents; since it was allocated onto the heap not str.
I think it's safe to assume that the point of this constructor is to allocate memory to m_Contents and initialize it. Releasing m_Contents seems kind of counter-productive at this particular point in execution. :icon_rolleyes:

>you delete[] m_Contents; since it was allocated onto the heap not str.
I think it's safe to assume that the point of this constructor is to allocate memory to m_Contents and initialize it. Releasing m_Contents seems kind of counter-productive at this particular point in execution. :icon_rolleyes:

oh, right... sorry about that I don't see the bigger picture in anything :P

Hi Narue,
Just curious, if not on heap and stack..where will it be?

Hi Ancient Dragon,
CCandyBox box; // use default constructor, in this case the string will be in the heap so its not necessary to delete it.

Will the compiler delete those string literals on heap for us?
Or else will it cause memory leak if not deleting it explicitly?

>>Will the compiler delete those string literals on heap for us?
Yes, similar that it deletes all the code when the program quits. Depending on the compiler and options you choose string literals may not be on the heap but reside in read-only memory along with executable code. So the only thing you can assume about string literals is that you should not attempt to change or delete them.

string literals can never be deleted -- they remain in memory for the lifetime of the program. This is not counted as or the same as a memory leak.

I heard heap in c++ lexicon is freestore

>Just curious, if not on heap and stack..where will it be?
String literals could be stored in the static data areas of the executable since they're known and can be completely resolved at compile-time.

>Or else will it cause memory leak if not deleting it explicitly?
Generally, you shouldn't delete something explicitly if you didn't allocate it explicitly.

>I heard heap in c++ lexicon is freestore
It's called a lot of things, but "dynamic storage" is probably closest to the language standard.

Thanks, I am clear now:)

And don't forget to supply this class with non-trivial copy constructor and assignment operator - or (better) use std::string to keep a copy of a text literal. In the last case no need in own copy constructor and assignment op because of default member by member semantics is OK (std::string has essential storage control capabilities).

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.