print "Hi\n" \ "Hello\n"Anyone know about this random little feature of C?
Author
Well thats a surprise.
Absolutly no one I talked to knew about it, and everyone thought it was a bad idea. Yes it has uses, but it just 'feels' wrong, and while it may be correct memory wise (barly), if the strings really were char*'s, then it should be highly illegal code. (special cases of any sort are bad imo)
Maybe it's just because we are all used to strict managed languages I guess.
never mind then.
Absolutly no one I talked to knew about it, and everyone thought it was a bad idea. Yes it has uses, but it just 'feels' wrong, and while it may be correct memory wise (barly), if the strings really were char*'s, then it should be highly illegal code. (special cases of any sort are bad imo)
Maybe it's just because we are all used to strict managed languages I guess.
never mind then.
The only reason it appears wrong to anyone is that we're all so used to C and C++ being low-level. The idea of C++ doing something FOR us feels wrong. In reality, it's a perfectly practical feature. Why not have the ability to use a long-ass string without compromising code readability and/or CPU cycles?
I use that a feature alot. You want to see a strange feature, try
I have no idea how that creeped into the language.
int array[2];int first=0, second=1;first[array] = 42;second[array] = 54;I have no idea how that creeped into the language.
Quote:Original post by mattnewportQuote:Original post by cgoat
I knew about that. I think it's great for breaking apart long lines, to keep the code neat and readable. Don't remember how I first found out about it though.
Then again, I haven't really used it since I started using C++ streams, I just do something like this:
cout << "I"
<< " am "
<< " fine " << endl;
In order to break up any long character strings and keep things readable.
Fun stuff!
Not that this is something that really needs optimizing but still, using streams for this is horrendously inefficient by comparison since string literals are concatenated by the compiler at compile time and so there is no runtime cost whereas doing it this way requires a function call for every concatenation.
Are you sure the C++ compiler won't concatenate those string literals at compile time?
Quote:Original post by smart_idiot
I have no idea how that creeped into the language.
I think it has to do with the mechanic of the [] operator. It is valid for the array and index to be in either position. I don't see how it's of any use and would just make the code more confusing.
Quote:Original post by RipTorn
Well thats a surprise.
Absolutly no one I talked to knew about it, and everyone thought it was a bad idea. Yes it has uses, but it just 'feels' wrong, and while it may be correct memory wise (barly), if the strings really were char*'s, then it should be highly illegal code. (special cases of any sort are bad imo)
Maybe it's just because we are all used to strict managed languages I guess.
never mind then.
If you understand how string literals are treated by the compiler in C/C++ then it doesn't 'feel' wrong. When the compiler encounters a string literal it allocates space for the characters in a special section of the object file (usually either .text where the actual code lives or .rodata, the read-only data section) and copies the character data there. The string literal is then substituted for a const char* that points to the actual character data in the object file. All that happens when you have "two " "strings" with nothing but whitespace separating them is that your string literal is specified in several pieces which the compiler concatenates and the resulting concatenated string literal is placed in the object file. From that point on everything happens exactly the same as if you'd specified the string inside a single set of quotes - the string literal is substituted with a single const char* pointing to the character data and the resulting code is identical.
Quote:Original post by Boder
Are you sure the C++ compiler won't concatenate those string literals at compile time?
I wouldn't bet my life on it but I think it's highly unlikely any current compiler does it. When you use streams you're using library code, not a built in language construct. Unless the compiler has special case code for handling standard library classes (which I think is very unlikely) it would have to inline all those function calls and collapse all the concatenation code (which probably involves dynamic memory allocation) down to it's result. I'll give it a try in VC though - it has surprised me before with it's ability to eliminate redundant code.
There we go, not too hard to work that one out was it, now onto the real dodgy problem:
Quote:first[array]
Quote:Original post by mattnewport
I'll give it a try in VC though - it has surprised me before with it's ability to eliminate redundant code.
Nope, tried it out in VC.NET 2003 with optimizations cranked up to the max (including WPO/LTG) and it doesn't concatenate the strings. It doesn't even inline the function calls.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
