array of char-newbie
-
you said::As a side note: you don't need to clear a buffer to overwrite it. It is more efficient to just overwrite it with the new data if your requirements allow for it. but if i overwrite and the new sequence of characters is smaller than the one before some values will still be in the array for example if the the first time i insert 30 characters and the second time only 10 i ll have a problem yes? Thanks for the help Zac Howland
If you are reading in character buffers as a whole, yes, you will have a problem. If you are using them as C-style strings, then no, you won't. The reasoning is that C-style strings have a null-terminator. Example:
const unsigned int ARRAY_SIZE = 20; char myBuffer[ARRAY_SIZE] = {0}; // Right now, the entire buffer is 0's strcpy(myBuffer, "My funny String"); cout << myBuffer << endl; cout << strlen(myBuffer) << endl; // Output will be: // My funny String // 15 // Now, replace the buffer strcpy(myBuffer, "Hello"); cout << myBuffer << endl; cout << strlen(myBuffer) << endl; // Output will be: // Hello // 5The only time you would run into problems doing this is when you will be looking at the entire character buffer (so all 20 characters) for information. However, in that case, you most likely will not be treating the buffer as a string, and will not be using the strXXX family of functions on it either (or their _tsc equivalents). If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac -
you said::As a side note: you don't need to clear a buffer to overwrite it. It is more efficient to just overwrite it with the new data if your requirements allow for it. but if i overwrite and the new sequence of characters is smaller than the one before some values will still be in the array for example if the the first time i insert 30 characters and the second time only 10 i ll have a problem yes? Thanks for the help Zac Howland
The standard string-handling functions like
strcpy(...),strcat(...),sprintf(...), etc. will write a terminatingNUL(not aNULL[^]) into the buffer you are using. So if you use them, you normally do not have to worry about previous data causing issues (unless you are concerned about security, but that is another issue). Here is an example:char caBuffer[ 50 ];
strcpy( caBuffer, "A Looooooooong String" );
strcpy( caBuffer, "A Short String" );
puts( caBuffer );After the first call to
strcpy(..)the buffer will contain (NULis represented byØ):0123456789012345678901-and after the second call to
strcpy(...), the buffer will likely contain:0123456789012345678901When the string is shown using
puts(...), it will displayA Short String, even though the actual memory for the buffer has the extra data in it. Since string-handling functions useNULas an end-of-string indicator,puts(...)stops when it gets to the firstNULit encounters. Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!) -
thanks toxcct but if i overwrite and the new sequence of characters is smaller than the one before some values will still be in the array for example if the the first time i insert 30 characters and the second time only 10 i ll have a problem yes? thanks again
antonaras wrote:
i ll have a problem yes?
Only if the presence of characters 10-29 are an issue. If you are dealing with nul-terminated strings, the string-related functions (e.g.,
strcpy(),strlen()) will terminate at the first\0character. Otherwise, no issue.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
-
// create a new character buffer initialized to 0's const unsigned int MAX_S_SIZE = 50; char s[MAX_S_SIZE] = {0}; // put some stuff in the buffer strcpy(s, "Hello, world!"); // clear the buffer memset(s, 0, MAX_S_SIZE); // NOTE: for an easier transition into UNICODE, the following works better const unsigned int MAX_S_SIZE = 50; TCHAR s[MAX_S_SIZE] = {0}; _tscpy(s, _T("Hello, World!")); memset(s, 0, MAX_S_SIZE * sizeof(TCHAR));As a side note: you don't need to clear a buffer to overwrite it. It is more efficient to just overwrite it with the new data if your requirements allow for it. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week ZacWhy is Zac's answer low-voted? It was an accurate answer, wasn't it? :confused: Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New) -
Why is Zac's answer low-voted? It was an accurate answer, wasn't it? :confused: Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)Nishant Sivakumar wrote:
Why is Zac's answer low-voted? It was an accurate answer, wasn't it?
Yes, it is accurate. Some people get hung up on the terminology (actually, just the spelling) of NUL vs NULL. In my opinion, as long as you know that you are talking about putting a 0 somewhere, it doesn't matter whether you call it a "nul-terminator" or a "null-terminator". If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
Why is Zac's answer low-voted? It was an accurate answer, wasn't it? :confused: Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New) -
Nishant Sivakumar wrote:
Why is Zac's answer low-voted? It was an accurate answer, wasn't it?
Yes, it is accurate. Some people get hung up on the terminology (actually, just the spelling) of NUL vs NULL. In my opinion, as long as you know that you are talking about putting a 0 somewhere, it doesn't matter whether you call it a "nul-terminator" or a "null-terminator". If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
Personally, I did not vote you down. Since you have no idea that I did or not, I have to guess that the mentioning my
NULvs.NULLpoint is but a coincidence - otherwise it would be a highly inappropriate assumption on your part. Also, you will note that even if I did vote you down, there are 4 other votes there as well. Did it ever occur to you that perhaps others know something that you do not? (And that just because you do not know what someone else is talking about, that does not mean that they do not?) For the record, I voted your two earlier posts a 4. The fact that the first is now below that value may be indicative of something else.NULis one thing,NULL(in uppercase) is another. They are not two ways to spell the same thing, even though they have the same value.NULis the name/mnemonic for an ASCII encoded character with a value of zero.BS,ACK, andNAKare similar characters. I am sure you (should?) know the history ofNULL, even inC. Consider this - my calling "C++" something else, like "G--; that C-ish language with the objects, and references, and virtual thingys" is not correct, even if I know that I am really talking about. Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!) -
Why is Zac's answer low-voted? It was an accurate answer, wasn't it? :confused: Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)It was mostly accurate, Nish... :P Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!) -
Personally, I did not vote you down. Since you have no idea that I did or not, I have to guess that the mentioning my
NULvs.NULLpoint is but a coincidence - otherwise it would be a highly inappropriate assumption on your part. Also, you will note that even if I did vote you down, there are 4 other votes there as well. Did it ever occur to you that perhaps others know something that you do not? (And that just because you do not know what someone else is talking about, that does not mean that they do not?) For the record, I voted your two earlier posts a 4. The fact that the first is now below that value may be indicative of something else.NULis one thing,NULL(in uppercase) is another. They are not two ways to spell the same thing, even though they have the same value.NULis the name/mnemonic for an ASCII encoded character with a value of zero.BS,ACK, andNAKare similar characters. I am sure you (should?) know the history ofNULL, even inC. Consider this - my calling "C++" something else, like "G--; that C-ish language with the objects, and references, and virtual thingys" is not correct, even if I know that I am really talking about. Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)Raymond Chen says null-terminated string here :- http://blogs.msdn.com/oldnewthing/archive/2004/08/24/219444.aspx[^] Most of MSDN documentation says null-terminated string too. Maybe that's why people use that (null I mean) more often. Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New) -
Personally, I did not vote you down. Since you have no idea that I did or not, I have to guess that the mentioning my
NULvs.NULLpoint is but a coincidence - otherwise it would be a highly inappropriate assumption on your part. Also, you will note that even if I did vote you down, there are 4 other votes there as well. Did it ever occur to you that perhaps others know something that you do not? (And that just because you do not know what someone else is talking about, that does not mean that they do not?) For the record, I voted your two earlier posts a 4. The fact that the first is now below that value may be indicative of something else.NULis one thing,NULL(in uppercase) is another. They are not two ways to spell the same thing, even though they have the same value.NULis the name/mnemonic for an ASCII encoded character with a value of zero.BS,ACK, andNAKare similar characters. I am sure you (should?) know the history ofNULL, even inC. Consider this - my calling "C++" something else, like "G--; that C-ish language with the objects, and references, and virtual thingys" is not correct, even if I know that I am really talking about. Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)I wasn't referring to you personally. I actually hadn't even read your response yet when I posted that. On similar topics in the past (not necessarily on this forum, but others), I've been flamed for the nul vs null argument. My point is that as long as the reader understands what you are saying, it doesn't matter how you spell it. And yes, I'm well aware of the history of ASCII characters ... use to have to use them all the time in my last job (ACK/NAK especially). If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
Raymond Chen says null-terminated string here :- http://blogs.msdn.com/oldnewthing/archive/2004/08/24/219444.aspx[^] Most of MSDN documentation says null-terminated string too. Maybe that's why people use that (null I mean) more often. Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)Yep - lots of people also do not come to a complete stop at a stop sign, and still manage to get someplace in one piece. :) And you should know by now that you should never use or site Microsoft as a model for anything software-related! :P :P :P Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!) -
The standard string-handling functions like
strcpy(...),strcat(...),sprintf(...), etc. will write a terminatingNUL(not aNULL[^]) into the buffer you are using. So if you use them, you normally do not have to worry about previous data causing issues (unless you are concerned about security, but that is another issue). Here is an example:char caBuffer[ 50 ];
strcpy( caBuffer, "A Looooooooong String" );
strcpy( caBuffer, "A Short String" );
puts( caBuffer );After the first call to
strcpy(..)the buffer will contain (NULis represented byØ):0123456789012345678901-and after the second call to
strcpy(...), the buffer will likely contain:0123456789012345678901When the string is shown using
puts(...), it will displayA Short String, even though the actual memory for the buffer has the extra data in it. Since string-handling functions useNULas an end-of-string indicator,puts(...)stops when it gets to the firstNULit encounters. Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)James R. Twine wrote:
write a terminating NUL (not a NULL[^])
You really got a obsession there, right? :-D
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
-
James R. Twine wrote:
write a terminating NUL (not a NULL[^])
You really got a obsession there, right? :-D
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
jhwurmbach wrote:
You really got a obsession there, right? :)
Yup! It is what separates the wheat from the chaff... :) Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)