18 replies to this topic

[343GS]

Hi, I was just wondering if I there is another alternative to /n. It seems that using /n will not produced the desired result in my case.

Thanks!

[Moudi]

its \n not /n
anyway if you're doing C++ i think there's
cout<<"Hello world"<<endl;

aka " end line " will take you to a new line

[MeTh0Dz]

Not sure what you're doing, but you may need \r\n.

[instantcake]

Moudi said:

its \n not /n
anyway if you're doing C++ i think there's
cout<<"Hello world"<<endl;

aka " end line " will take you to a new line

exactly you can use endl (pronounced END-ELL), witch also flushes the stream. but I think you problom is you have the slash the wrong way :)

[Ancient Dragon]

MeTh0Dz said:

Not sure what you're doing, but you may need \r\n.

No. Whether you are on *nix, MS-Windows, MAC, or anything else, it will always be '\n' because the c standards say so. Its only in the file system that you will find '\r\n' on MS-Windows, '\n' on *nix iand '\r' on MAC (I don't know if that is true any more since MAC is just running on top of *nix nowdays.) For all cases in C programs all you have to specify is '\n'.

I have gotten rid if using endl in programs. Why? Because it does more than just add '\n' to the end of the stream. It also flushes the output to the file system, such is unnecessary on most computers today. It does nothing more than slow down the program when it contains lots of endl statements.

[MeTh0Dz]

Ancient Dragon said:

No. Whether you are on *nix, MS-Windows, MAC, or anything else, it will always be '\n' because the c standards say so. Its only in the file system that you will find '\r\n' on MS-Windows, '\n' on *nix iand '\r' on MAC (I don't know if that is true any more since MAC is just running on top of *nix nowdays.) For all cases in C programs all you have to specify is '\n'.

I have gotten rid if using endl in programs. Why? Because it does more than just add '\n' to the end of the stream. It also flushes the output to the file system, such is unnecessary on most computers today. It does nothing more than slow down the program when it contains lots of endl statements.

Did you consider that he may be sending data in an HTTP request? How do you know he isn't implementing a multiline ToolTip? Make sure you are considering all of the possibilities.

Creating Multiline ToolTips
Using Tooltip Controls (Windows)

[Ancient Dragon]

MeTh0Dz said:

Did you consider that he may be sending data in an HTTP request? How do you know he isn't implementing a multiline ToolTip? Make sure you are considering all of the possibilities.

Creating Multiline ToolTips
Using Tooltip Controls (Windows)

Not relevant. He could be doing any number of a million things. C by any other name is still C. When something needs "\r\n" then its documentation will tell you so. Standard C does not.

[MeTh0Dz]

Ancient Dragon said:

Not relevant. He could be doing any number of a million things. C by any other name is still C. When something needs "\r\n" then its documentation will tell you so. Standard C does not.

This is very relevant. We literally had _no_idea what he was doing. These are two fairly common places where a newbie programmer would expect to use \n but would need \r\n. Did I ever say that standard C would tell you to use \r\n here? No.

[Ancient Dragon]

In your own words "we have no idea what he was doing.". So how is that statement in the least relevant? Don't you see the paradox? How can you say something is relevant if you don't know the question? The most we can say about it is what standard C standards have to say. Anything else is just guessing.

[MeTh0Dz]

Ancient Dragon said:

In your own words "we have no idea what he was doing.". So how is that statement in the least relevant? Don't you see the paradox? How can you say something is relevant if you don't know the question? The most we can say about it is what standard C standards have to say. Anything else is just guessing.

If we have no idea what he is doing (the OP provides us with no other information about his intent), then it is worthwhile to suggest a couple pitfalls that newbies might have with \n. It's not a paradox at all. Are you familiar with the idea of making an inference?

Everything else is not just guessing. The RFC on HTTP is not guessing, information by compiler writers is not guessing, information from MSDN on their functions/structures is not guessing.

[Ancient Dragon]

That is true that those specific cases is not guessing. But what you are guessing about is what is useful information to the OP. We could post millions of cases that are total unrelated but relevant to the specific cases. Until he says what he wants there is no point to continuing this stupid discussion.

[MeTh0Dz]

Ancient Dragon said:

That is true that those specific cases is not guessing. But what you are guessing about is what is useful information to the OP. We could post millions of cases that are total unrelated but relevant to the specific cases. Until he says what he wants there is no point to continuing this stupid discussion.

Are you actually contesting that we can't take some estimated guesses at what problems a newbie programmer is likely to run into with \n? Because believe it or not some of us have assisted enough newbies and read enough **** code to understand what problems people are likely to run into with different features of the language.