Is this bad code?

[RwGast]

[Malmer]

[Dan East]

There's nothing wrong with what you have, but that is not dynamic memory allocation. Anytime you have a string in your code (like "Hello" ) , that value is stored on the stack as a constant (which means it not not supposed to be modified). As Fredrick said, you're simply setting the pointer pString to point to the const string "Sample". You can have any number of pointers point to the same string. If the string is modified then it will appear that the string that all the pointers referred to was modified as well (because they are the same string). You have to explicitly set every single character to really copy a string. That is what the strcpy function does.<br><br>There's a huge difference between this and what you have:<br>[fixed]<br>char *pString=new char[10];<br>strcpy(pString, "Sample" ) ;<br>[/fixed]<br><br>Now that dynamically allocates a string 10 characters long, then fills it with the const string "Sample". Also, compilers can reuse the same const string value if it is found in multiple places in your code. For example:<br>[fixed]<br>char *pString1="Test string";<br>char *pString2="Test string";<br>[/fixed]<br>Since there are two identical const string values "Test string", the compiler may be smart enough to only create one const string and reuse it. Thus, depending on the type of compiler and build settings used, pString1 and pString2 may actually point to the same chunk of data. Thus if you were to modify one it will effect both. This may be true even across function bounderies. It is standard practice to never modify a const string, because there are many compiler and device specific issues that could be raised.<br><br>Now, this is also bad:<br>[fixed]<br>char *pString;<br>strcpy(pString, "Test" ) ;<br>[/fixed]<br>What does pString point to? That is unknown. So strcpy is filling bytes at an unknown location with "Test". Something like that will randomly crash, especially in release builds, because pString was not initialized and will "randomly" point to different chunks of memory.<br><br>Dan East<br><br>

[Digby]

Good points Dan.  There's more on string pooling optimizations in the compiler docs.  Look at the /Gf and /GF compiler options.<br><br>One thing to note, the following is not a constant:<br><br>char* pszName = "Hello";<br><br>You are free to change the the value of pszName and you are free to change what pszName points to.<br><br>Now this:<br><br>const char* pszName = "Hello";<br><br>Means that you can't change what pszName points to.  i.e. you can't change pszName[1] to 'u' to get "Hullo".<br><br>Now this:<br><br>char* const pszName = "Hello";<br><br>Means that the data is non-const but the pointer IS const.  This means that later in the program, you can't do something like this:<br><br>pszName = "Hillo";<br><br><br>Here's the rules (courtesy "Effective C++" by Scott Meyers):<br><br>char *p = "Hello"; // non-const data, non-const pointer<br><br>const char *p = "Hello"; // const data, non-const pointer<br><br>char * const p = "Hello"; // non-const data, const pointer<br><br>const char * const p = "Hello"; // const data, const pointer<br><br>The easy way to remember this is to draw a vertical line through the asterisk in any of the declarations above.  If 'const' appears to the left of the line, then what's pointed to is constant, if 'const' is to the right of the line the pointer itself is constant.  If it's on both sides of the line, then both the pointer and the data are constant.  Clear as mud?<br><br><br><br><br>

[RICoder]

I was gonna reply but Digby, Dan and Fredrik beat me too it...as always...and with good stuff.<br><br>Where were you guys when I was learning to code?

[Dan East]

I think Robert is now a-Gast. Sorry Robert, I get occasional puns about my last name too.<br>If you think that is a confusing mess, wait until you need to work with pointers to functions. The definitions are not very intuitive.<br><br>Dan East

[Malmer]

[RwGast]

Thanks alot guys, that acually answerd alot of questions but i guess ive got another<br><br>int main ()<br>{<br>        //This works fine<br>      char *szWord = "Cat";<br>      szWord = "Cut";<br>      //This does not<br>      char szSecondWord[] = "Dog";<br>      szSecondWord[] = "Dug";<br>      <br>      return 0;<br>}<br><br>What is wrong with the second method?<br><br>

[RwGast]

The board replaced my d's with faces that should read dog, dug.

[Paul]

but code in the {code}{/code} tags or just turn off smilies

[Malmer]

When you do:<br>char szSecondWord[] = "dog"; <br>it will automatically do it as if you had written:<br>char szSecondWord[3] = "dog"; <br><br>when you then later try to do:<br>szSecondWord[] = "dug"; <br><br>it will get quite mad, because then you try to change the length of the variable. Just remove the [] and it should work<br>

[RwGast]

Ya, but dog and dug are the same length. So why doesnt that code work?

[Dan East]

In the definition of an array you can specify an initial set of values to populate the array. In actuality that array should simply point to that chunk of data that you provided. In other words those values weren't copied into your array - your array occupies the stack memory where your default values were loaded when that function was called. Neither C nor C++ provides a built in mechanism to copy an array. That makes sense because the size of an array is not always apparent at runtime. Further some arrays, such as a string, are terminated by a null character. That is why you must use string functions such as strcpy to copy data into a string (or do it manually).<br>A correction to Fredrik's sample:<br>[fixed]char szSecondWord[3] = "dog";[/fixed]<br>Would read:<br>[fixed]char szSecondWord[4] = "dog";[/fixed]<br>Because of the null terminator. The compiler would error on that one "array bounds overflow".<br><br>Dan East<br>

[Digby]

First, <br><br>    char szFoo[] = "dog";<br><br>and...<br><br>    char szFoo[3] = "dog";<br><br>are not the same thing.  The first array is 4 chars in size and initialized as if you had done this:<br>    char szFoo[4] = {'d', 'o', 'g', '\0'};<br><br>The second array declaration will cause a compiler error because the array isn't big enough to contain the 4 chars.<br><br>Now, on to the other issue.  When you do this:<br><br>char szFoo[] = "dog";<br>    szFoo = "cat";<br><br>You're asking the compiler to convert szFoo to be a pointer to a char.<br><br>In the ANSI/ISO C++ spec, arrays cannot be converted to an l-value expression.  That means it can't be on the left hand side of the assignment operator ( = ).  This is covered in Clause 4 "Standard Conversion", paragraph 3.<br><br>They can be converted to an r-value expression though.  That's why you can do things like this:<br><br>    char *p = szFoo;<br><br>Here, szFoo is being converted to a char * on the right hand side of the assigment and that's OK by the spec.<br><br>Oh, and empty array brackets are only allowed when initializing an array at declaration time.<br><br>Hope that clears things up.<br><br>

[RwGast]

Ok, well check this out then is it bad code to lets say make a pointer <br><br>char* cChar = "Some Text"; <br><br>then increment the pointer<br><br>cChar++<br><br>then deincrement<br><br>cChar--<br><br>Becuase once it points to the next address, wich contains o, it frees the memomry that was used to hold the S of Some, doesn't it? And if thats true it means that the S could get overwritten and when you deincrement it, it may point to  (garbage)ome Text instead of Somr Text.