Question about pointers #2

As promised here is my next question about pointers as strings. This question relates to how to properly free memory when deleting a pointer or exiting a program.

Code:

---

char* string = new char[8];
strcpy(string, "letters");
delete string;

---

Will this work? No memory leaks, other problems etc...?

Code:

---

char* function (void)
{
    char* string = new char[8];
    strcpy(string, "letters");
    return string;
}

char* astring = new char[8];
astring = function();
delete astring;

---

Will this work? Will this delete both string and astring? Could I just set astring equal to the return of function without allocating memory first?

One more question, what does setting a pointer equal to NULL do? I know that NULL is just a #define 0, but does it just clear the address that the pointer points to? Or is there more? Thanks again for the help

I believe that you would have to do this-> delete string[]. if you dont inlcude the [], you will just delete the first element and not the remaining ones.

Alright, so if I use the delete [] operator instead of the delete operator everything will work? Including the function return example? What about setting the string equal to NULL?

The correct syntax is :

Code:

---

delete [] string;

---

Anytime you use operator new with [] you must use delete with []. Simple as that. Setting it to NULL isn't required afterwards but it may help you detect errors if you try to use that pointer again for something else.

>char* function (void)
>{
> char* string = new char[8];
> strcpy(string, "letters");
> return string;
>}

>char* astring = new char[8];

This should be:
char* astring;

Swoopy: so you're telling me that I don't need to allocate memory if I am recieving a string from a function return? If I delete astring after recieving the data from function, will that free the memory of string as well?

You seem to have a handle on it maxhavoc. However, swoopy's code will only work if astring is global.

With the code you first posted, you allocated memory for astring. Then you set that pointer equal to another block of memory, so you lost that first block you allocated. If you initialize it to NULL instead, there wouldn't be any leaks at all.

Quote:

---

char* string = new char[8];
strcpy(string, "letters");
delete string;

Will this work? No memory leaks, other problems etc...?

---

Yes.

follow with a:

string = 0; // or NULL, but not '\0'

Quote:

---

char* function (void)
{
char* string = new char[8];
strcpy(string, "letters");
return string;
}

char* astring = new char[8];
astring = function();
delete astring;

Will this work? Will this delete both string and astring? Could I just set astring equal to the return of function without allocating memory first?

---

No. It is almost always bad to do things like astring = function() - who owns the memory and who is responsible for freeing it? It can get really complicated!

Quote:

---

One more question, what does setting a pointer equal to NULL do? I know that NULL is just a #define 0, but does it just clear the address that the pointer points to? Or is there more?

---

The very first memory address of ram (0) is classified as off-limits, meaning that any application that accesses this address causes the termination of the program with an access violation! very handy for debugging - which is precisely why it is so important to set unused pointers to NULL.

Quote:

---

Originally Posted by maxhavoc

Swoopy: so you're telling me that I don't need to allocate memory if I am recieving a string from a function return? If I delete astring after recieving the data from function, will that free the memory of string as well?

---

That's right. Since you allocated it in function(), there's no need to allocate it in main(). I guess I was answering your question:
>Could I just set astring equal to the return of function without allocating memory first?

And yes, if you delete astring after receiving data from function(), it will free the memory of string.

Code:

---

delete []astring;

---

>One more question, what does setting a pointer equal to NULL do?
It assures the pointer no longer points to memory. It's a good idea to do after delete, just in case you tried to use that pointer again by mistake.

Code:

---

delete []astring;
astring = NULL;

---

Of course if it's at the end of the program, it doesn't matter.

Remember that 'string' is a bad variable name to use, as it is already part of the std namepsace of the header <string>. You should use a more descriptive name too, such as:

Code:

---

char *lpchString; //Indicates that the variable is a pointer to a char

---

>You should use a more descriptive name too, such as: <snip godawful hungarian notation>
The name string or str or anything similar is silly anyway. A more descriptive name can easily be found, such as buffer or line or name, so that it more readily depicts how the string is going to be used. The code makes it obvious that the simulated array is to be used as a C-style string, the name should tell readers what the string is logically going to be used for.

>>Will this work? No memory leaks, other problems etc...?
>Yes.
No, it won't. Mixing new[] with delete is undefined, delete[] should be used instead.

>The very first memory address of ram (0) is classified as off-limits
A null pointer doesn't have to be address 0, it just has to be some value that would not be a valid pointer.

In response to those who said my variable names were bad or misleading, I know, this was just an example I wrote to ask my question, I don't actually use names like this in my real programs, but thanks for pointing it out ;)

Thanks to all of you for helping me with my problem, this is a great community and I'm glad I stumbled across it, thanks all!

Quote:

---

this is a great community

---

Oh we're the best.

Related to the topic of better variable names, can anyone point me to a guide that explains all the prefixes used in variables like 'n' and 'p' and 'lp' and so forth? I've heard the term hungarian notation tossed around, is that what this naming scheme is called?

>I've heard the term hungarian notation tossed around, is that what this naming scheme is called?
Yes, but it isn't widely used outside of Windows programming. The disadvantages far outweigh any advantages that hungarian notation has. You can read more about it here.

"The disadvantages far outweigh any advantages that hungarian notation has."

What disadvantages are you referring to? It seems like a good idea to me, it allows someone to identify what type a variable is just by looking at the name.

I also think it is a good idea. How could there possibly be any disadvantages to adding a prefix?

><snip godawful hungarian notation>

I was scared to say anything when I saw that suggestion for a descriptive name, but that's close to what I was thinking. It's bad enough to see it in a Windows program, but I sure don't want to see it in a non-Windows program.

It's one of those style issues: some love it, some hate it! I wonder if we've had a Poll on it here. I know I've seen threads discussing it in the past.

Quote:

---

but I sure don't want to see it in a non-Windows program.

---

GIVE A REASON WHY NOT

From my very preliminary research on Hungarian Notation it seems that there is no set standard, every individual or organization has its own version, but if there was one official standard for variable prefixing that EVERYONE used, well, I cannot see any downsides to it.

I can't see a downside to prefixing a variable name with it's type. It's certainly made things easier for me. I'd really like to see some disadvantages.

>I'd really like to see some disadvantages.
Okay.

1) It hurts abstraction to encode the type in everything. Let's say I have a C program that needs to be ported to C++. One of the variables is pszUserName. Well, we know that the variable contains a name, so it's probably a string, and the hungarian notation tells us that it's a pointer to a C-style string. All is well, right? No, not really. Abstraction says that we shouldn't care about the type as long as it's used according to the correct interface. There's no point in prefixing psz.

2) Okay, on to the port. Because any wise programmer will try to use std::string instead of C-style strings, the definition of pszUserName is changed to

Code:

---

std::string pszUserName;

---

At this point the programmer must make a decision. The type has changed, so she can change every occurance of pszUserName to some house standard for std::string, or leave the name unchanged and incorrect. Global changes are relatively easy these days, but there are snags for sweeping changes. Was hungarian notation really worth it if it requires so much effort to maintain?

A more realistic example is const. Say you use a pointer for a while and then later decide that it would be safer to make it const. I do this all of the time because it's convenient during development. Well, using hungarian notation you would have to change the name of every occurance of that pointer to reflect its const-ness. Can you remember to do that without fail? I can't. :p

3) Hungarian notation keeps track of types, but in a typed language such as C++ it's redundant. A well written C++ program will either have a declaration of the variable close at hand, or hidden by proper object-oriented techniques. With the former it's trivial to check the type and with the latter the type shouldn't matter (not to mention that hungarian notation has no prefix for such types). If a well structured program makes hungarian notation redundant, why cling to it?

4) One should be able to pronounce a variable name. This makes sense as programmers aren't left in a void to work their magic, they communicate with other programmers, often face to face. Hungarian notation makes this more difficult in a good many languages besides English.

5) Sheer obscurity. Even if you know hungarian notation, many find that reading code that uses it is harder than reading code that doesn't. You obscure the purpose by embedding information that shouldn't be necessary.

6) Inaccuracy. Hungarian notation is simply a way of commenting code. A lot of people recognize that comments aren't always kept up-to-date and are inaccurate. This is because they aren't policed by the compiler for correctness. The same goes with hungarian notation. When reading code that uses it, how can you be sure that it's correct?

7) By writing code that uses hungarian notation, you make the job of a maintenance programmer harder. But you also make your job harder (also for little gain, see above) by forcing yourself to type awkward prefixes for every name. This has a twofold effect: First, you spend extra time embedding types that could be used more effectively elsewhere and second, you focus on the type of a variable so much that it's possible to forget its use and mess something up. In this, and a few other points, hungarian notation breeds bugs.

This list is off the top of my head and far from exhaustive, BTW. :eek:

Argument from the microsoft site in favor of hungarian notation:

Quote:

---

Speed of the decision—we cannot spend too much time pondering the name of a single quantity, nor is there time for typing and editing extremely long variable names.

---

Hehe.

Kudos Prelude! I've always wanted to bring my ideas into concise statements, but it always came down to "well...um...if you...when something like this happens....It's just fricken annoying!"

It's great for windows stuff where I would most likely write out things like handle in a variable name for clearness anyway. And having a tag infront of global and member variables is convenient...sometimes =)

> Speed of the decision—we cannot spend too much time pondering the name of a single quantity
If you spent any reasonable time actually designing what you wanted before writing it, the names become obvious. Perhaps the "patch-a-week" brigade would do well to learn this lesson.

Also, code is read much more often than it is written. If it's done well, it gets written exactly once. That code should be first and foremost readable is paramount to me. Anything which compromises readability (that would be HN), then its a "bad thing" in my book.

Just to add to Prelude's excellent comment
Why not just get rid of the cryptographic nature of hungarian and say what you mean
const char *pszName;
would become
const char *const_char_pointer_Name;
It is at this point you realise that the type declaration is essentially repeated information. So why not just say
const_char_pointer_Name;
and let the compiler figure out what you meant. Unfortunately, this language is no longer 'C'. If you want to write a compiler for this new language, that's up to you.

> 2) Okay, on to the port
Yes, because the 'L' in LPSTR is now completely meaningless in a 32 bit context.
But no you can't get rid of it, it's just some meme virus that will refuse to go away for many many years to come. New generations of programmers will wonder what it means and various folklore tales will emerge to explain it.

A couple of more reasons
1. Primitive types are first class, everything else is second class.
So pointers, ints, chars etc all get their own special letter. But what about all your structs, classes and typedefs?
Do you go with something meaningless like say 'C' for all classes (that's really informative)
Or do you smash your way through the abstraction and reveal the underlying types.

2. No-one can seem to agree on all the letter combinations, even within a local organisation. Common letters get reused for all sorts of purposes. Depending on context (which you can only really get by going and looking at the actual declaration - oops, we wanted to avoid that), 's' could mean say 'signed' 'struct' 'string'

Having read Simonyi's original description, I came to the conclusion that the whole idea was akin to training wheels on a child's bycicle. Fine when you're learning not to fall over, but utterly useless once you're experienced enough - they simply get in the way!!!

Ok, I see where you're coming from. However, in my experience those disadvantages have not had any effect on my programming. It takes little to no effort to put in hungarian notation in the way that I do, and I firmly believe that it increases the readability of my code. I think it takes a bit of pedantacy to really care.

To whoever gave me the bad reputation for my capitalized post earlier, I was annoyed that Prelude and other people were making bold statements without providing any examples or proof.

>It takes little to no effort to put in hungarian notation in the way that I do, and I firmly believe that it increases the readability of my code.
We weren't trying to force you not to use hungarian notation, just explaining why many people disapprove of it. :) If it works for you then so be it, but it never hurts to hear the other side's arguments so that you can better defend your own position. Rest assured that in a serious code review, you'll probably be called on your naming scheme and have to give a detailed account of why you use it. ;)

>To whoever gave me the bad reputation for my capitalized post earlier

Now why didn't I think of that? :p