Are these two statements not logical, semantic as well as binary clones?
char aggregation_key[250] = "";
char aggregation_key[250] = {0};
Are these two statements not logical, semantic as well as binary clones?
char aggregation_key[250] = "";
char aggregation_key[250] = {0};
Yes they are the same thing.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
From a theoretical point of view, they aren't, as '\0' doesn't need to equal 0. But it does in both ASCII and EBCDIC, so it's probably safe to assume that the two statements have the same effect. But beware: this may change as soon as we start communicating with an extraterrestrial intelligence on a regular basis.Are these two statements not logical, semantic as well as binary clones?
Greets,
Philip
All things begin as source code.
Source code begins with an empty file.
-- Tao Te Chip
Ah, in that case the two below are the same in any respect:
char aggregation_key[250] = "";
char aggregation_key[250] = {'\0'};
Exactly.
All things begin as source code.
Source code begins with an empty file.
-- Tao Te Chip
> From a theoretical point of view, they aren't, as '\0' doesn't need to equal 0
Yes it does.
The character encoding comes into it when you say 'A'. Whether that gets you 65 or 193 or whatever depends on your character encoding.
But if you write '\x41', then that is what you end up with. Maybe it's interpreted as 'A', and maybe it isn't. But look in memory, and that will be it's bit pattern for sure.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Salem,
Then why do we write '\0' instead of 0?
I know their internal representation is the same across UNIX and Windows, but is it written specifically so in the C standard anywhere that NULL terminator has to be 0?
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
Oops, Salem is right (though I wouldn't recommend looking in memory to determine the behaviour of some mechanism).
'\<num>' simply interprets <num> as an octal number. I was completely mistaken about this one, but I could have lived with it. What's more humiliating is this snippet from the C standard, §5.2.1, node 2:
"A byte with all bits set to 0, called the null character, shall exist in the basic execution character set; it is used to terminate a character string."
Salem: 1
Snafuist: 0
0 commies killed.
Insert next question.
Greets,
Philip
All things begin as source code.
Source code begins with an empty file.
-- Tao Te Chip
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
The null terminator cannot be anything but zero. This is because C is intended to be portable across encodings. If we declared that on such-and-such a platform, '\0' is (char)122, then that platform cannot support any encoding with a character at index 122.
On the other hand, nearly all encodings do not represent a character at index 0. It seems like a chicken-and-egg problem, but in reality C has influenced the charater encodings just as much as the encodings have influenced C.
I write '\0' not for the \0 part but for the single quotes, which indicate that I'm using a character literal. In a complex expression where a 0 appears, it makes it easier to figure out what data types are involved.
EDIT: Also, compare with the semantics of NULL. The actual hardware value of NULL is implementation-defined. However, at the source code level, we can always refer to NULL as (void *)0, even if the actual bit pattern of NULL is not all zero bits.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
I think that in C it really is more of readability than type correctness since character constants are of type int.Originally Posted by iMalc
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Could someone please explain "semantically equivalent"? My understanding of that statements makes me think that those two are not semantically equivalent, as the first example is clearly per usage of a string, whereas the second is a character array. What am I forgetting about semantics?
Environment: OS X, GCC / G++
Codes: Java, C#, C/C++
AOL IM: neandrake, Email: neandrake (at) gmail (dot) com
I suppose it depends on what you think "per usage of a string" means. My view is that the first one declares an array and initializes it to all zeroes (by specifying one zero character and using the "whatever I didn't specify is 0" rule), while the second one declares an array and initializes it to all zeroes (by specifying one zero character and using the "whatever I didn't specify is 0" rule).
Edit: I suppose your point might be that the string has the \0 terminator built-in, while it has to be specified in the second example?
Last edited by tabstop; 02-19-2009 at 08:29 PM.
I think my point was somewhere around that. That with a string there will be an implied ending null-terminator (not enforced), but the second one doesn't imply that at all, just an array of char's.
Environment: OS X, GCC / G++
Codes: Java, C#, C/C++
AOL IM: neandrake, Email: neandrake (at) gmail (dot) com