iostream and getline

[ernst.stiegler]

Hello,

I just want to read a whole line from a console input. What I don't
understand is that I always have to press ENTER twice in order to see
the line I've entered.

Here's my code :

#include <string>
#include <iostream>

int main(void)
{
string input = "";
while ( input != "exit")
{
cout <<"\n$"; // show prompt for operator input
getline(cin, input, '\n');
cout << input;
}

cout << "\nBye";
return 0;
}


After starting the program the console output is as follows

$hello world <ENTER>
<ENTER>
hello world
$hello world again <ENTER>

$ <ENTER>
hello world again
$


What I want is entering the line, pressing ENTER and having it again
as an output to my console. Can anyone explain why this doesn't work ?
I've played around with printf and scanf which had the same effect.

I use Windows NT4 Sp6a and Visual C++ 6

thanks
Erich

 

[Karl Heinz Buchegger]

Hello,

I just want to read a whole line from a console input. What I don't
understand is that I always have to press ENTER twice in order to see
the line I've entered.

Any chance you are using VC++ 6.0

This is a documented big in their implementation.
Go to http://www.dinkumware.com/vc_fixes.html
and apply the patches.

 

[Jeff Schwab]

Hello,

I just want to read a whole line from a console input. What I don't
understand is that I always have to press ENTER twice in order to see
the line I've entered.

Here's my code :

#include <string>
#include <iostream>

int main(void)
{
string input = "";
while ( input != "exit")
{
cout <<"\n$"; // show prompt for operator input
getline(cin, input, '\n');
cout << input;
}

cout << "\nBye";
return 0;
}


After starting the program the console output is as follows

$hello world <ENTER>
<ENTER>
hello world
$hello world again <ENTER>

$ <ENTER>
hello world again
$


What I want is entering the line, pressing ENTER and having it again
as an output to my console. Can anyone explain why this doesn't work ?
I've played around with printf and scanf which had the same effect.

I use Windows NT4 Sp6a and Visual C++ 6

thanks
Erich

Sounds like:

1) Your compiler blows.
2) Your program is getting confused by carriage returns.

Please try this, and say whether it works as you expect:

#include <string>
#include <iomanip>
#include <iostream>

int main(void)
{
std::string input;

std::cout << "$ " << std::flush; // Prompt.

while( getline( std::cin, input ) and input != "exit" )
{
std::cout << input;
std::cout << "\n$ " << std::flush;
}

std::cout << "\nBye\n";
}

 

[Sharad Kala]

Any chance you are using VC++ 6.0

Yes, he is using VC++ 6.0 (He mentions in the last line of his post)
Verified..the code works just fine on VC++ 7.0.

Best wishes,
Sharad

 

[/dev/null]

I'm not familiar with string data type in C++ (unless its own implemented ), but this should work fine:

# include <iostream.h>
# include <string.h>

void main()
{
char input[256] = "";
while(strcmp(input,"exit")){
cout <<"\n$"; // show prompt for operator input
cin>>input;
cout<<input<<endl;
}
cout<<"\nBye";
}

 

[Martijn Lievaart]

It iz I, Karl Heinz Buchegger, I will zay zis only onze:

This is a documented big in their implementation.

Sorry, couldn't resist.

M4

 

[Karl Heinz Buchegger]

I'm not familiar with string data type in C++ (unless its own implemented ), but this should work fine:

It's just a documented bug in his compiler system.
Once the patch is applied it will work fine.

 

[Sumit Rajan]

I'm not familiar with string data type in C++ (unless its own implemented

), but this should work fine:

# include <iostream.h>
# include <string.h>

void main()
{
char input[256] = "";
while(strcmp(input,"exit")){
cout <<"\n$"; // show prompt for operator input
cin>>input;
cout<<input<<endl;
}
cout<<"\nBye";
}

Looks like C++ code from a bygone era.

Sumit.

 

[/dev/null]

Looks like C++ code from a bygone era.

:'(

Ok lets try something better:
-------------------------CMyString.h-----------------------------
# if !defined __CMYSTRING_H
# define __CMYSTRING_H

#include <windows.h>

Class CMyString
{
int size;
LPCTSTR string;
public:
CString()
{
size=0;
string=NULL;
}
~CMyString()
{
if(string)
delete[] string;
}
CMyString& operator=(const CMyString&);
CMyString& operator=(const LPSTR);
BOOL operator==(const CMyString&);
BOOL operator==(const LPSTR);
BOOL operator!=(const CMyString&);
BOOL operator!=(const LPSTR);
friend CMyString operator+(const CMyString&, const CMyString&);
friend CMyString operator+(const CMyString&, const LPSTR);
friend CMyString operator+(const LPSTR, const CMyString&);
friend CMyString operator+(const LPSTR, const LPSTR);
friend ostream& operator<<(ostream&, const CMyString&);
friend istream& operator>>(ifstream&, CMyString&);
};

# endif //__CMYSTRING_H
-------------------------------------------------------------------------------

-----------------------------------------main.h--------------------------------
# include <iostream.h>
# include "CMyString.h"
void main()
{
CMyString string="";
while(string!="exit"){
cout <<"\n$"; // show prompt for operator input
cin>>string;
cout<<string<<endl;
}
cout<<"\nBye";
}

 

[Jeff Schwab]

Looks like C++ code from a bygone era.

:'(

Ok lets try something better:
-------------------------CMyString.h-----------------------------
# if !defined __CMYSTRING_H
# define __CMYSTRING_H

#include <windows.h>

Class CMyString
{
int size;
LPCTSTR string;
public:
CString()
{ size=0;
string=NULL;
}
~CMyString()
{
if(string)
delete[] string;
}
CMyString& operator=(const CMyString&);
CMyString& operator=(const LPSTR);
BOOL operator==(const CMyString&);
BOOL operator==(const LPSTR);
BOOL operator!=(const CMyString&);
BOOL operator!=(const LPSTR);
friend CMyString operator+(const CMyString&, const CMyString&);
friend CMyString operator+(const CMyString&, const LPSTR);
friend CMyString operator+(const LPSTR, const CMyString&);
friend CMyString operator+(const LPSTR, const LPSTR);
friend ostream& operator<<(ostream&, const CMyString&);
friend istream& operator>>(ifstream&, CMyString&);
};

# endif //__CMYSTRING_H
-------------------------------------------------------------------------------


-----------------------------------------main.h--------------------------------

# include <iostream.h>
# include "CMyString.h"
void main()
{
CMyString string="";
while(string!="exit"){
cout <<"\n$"; // show prompt for operator input
cin>>string;
cout<<string<<endl;
}
cout<<"\nBye";
}
--------------------------------------------------------------------------------


Better now?
Now one need to write CMyString.cpp

Um... How is this better than using std::string?

 

[Kevin Goodsell]

/dev/[email protected] wrote:

Please don't top-post. It's annoying and violates usenet standards and
rule of netiquette. Please see RFC 1855, or consult one of the groups
for new usenet users.

I'm not familiar with string data type in C++ (unless its own
implemented ), but this should work fine:

You mean other than the blatant errors and non-standard parts?

# include <iostream.h>

This is an old, pre-standard header and not part of the standard C++

# include <string.h>

This is deprecated, but otherwise OK.

void main()

The C++ standard is quite explicit about the fact that main must return int.

{
char input[256] = "";

std::strings are usually preferable to char arrays.

while(strcmp(input,"exit")){
cout <<"\n$"; // show prompt for operator input

cout's full name is std::cout. You need to either fully qualify it, or
introduce the name with a "using" statement or declaration.

cin>>input;

It's called std::cin.

And congratulations on reinventing gets(). Your program is now
hopelessly broken, easy to crash, and may be exploited to compromise
system security.

You might want to consider what happens when someone enters more than
255 characters (accidentally or maliciously), and read up on buffer
overflow attacks. You could start your research by reading about the
Morris worm. This single instance of a program that exploited a buffer
overflow vulnerability is estimated to have caused between 10 and 100
MILLION dollars in damages. That was in 1988. Since then, I can't even
begin to imagine how much money has been wasted because of security
holes due to lazy programmers writing lazy code like this.

cout<<input<<endl;

std::cout and std::endl.

}
cout<<"\nBye";

std::cout

return 0; here wouldn't hurt.

}

-Kevin

 

[Kevin Goodsell]

:'(

Ok lets try something better:

Because the original question was about C++, not Windows programming,
and because I'm reading & replying in comp.lang.c++, This reply assumes
nothing beyond standard C++. Some of the non-standard things may be
topical and make sense in comp.os.ms-windows.programmer.win32, but I'm
ignoring that since they are not standard and not topical in comp.lang.c++.

(The OP probably shouldn't have cross-posted to
comp.os.ms-windows.programmer.win32. The question does not seem to be
relevant to that group.)

-------------------------CMyString.h-----------------------------
# if !defined __CMYSTRING_H
# define __CMYSTRING_H

This violates the implementation's namespace. Identifiers that begin
with an underscore, followed by either an uppercase letter or another
underscore are reserved for the implementation for any purpose.

#include <windows.h>

This is not a standard header.

Class CMyString

What is 'Class'?

{
int size;
LPCTSTR string;

What is 'LPCTSTR'?

public:
CString()

Missing return type.

{ size=0;
string=NULL;

Has NULL been #defined? No standard header that defines it has been
included.

}
~CMyString()
{
if(string)
delete[] string;
}
CMyString& operator=(const CMyString&);
CMyString& operator=(const LPSTR);

What is LPSTR?

BOOL operator==(const CMyString&);

What is BOOL? (And why would anyone use this mysterious type when the
language already provides a well-behaved built-in boolean type?)

BOOL operator==(const LPSTR);
BOOL operator!=(const CMyString&);
BOOL operator!=(const LPSTR);
friend CMyString operator+(const CMyString&, const CMyString&);
friend CMyString operator+(const CMyString&, const LPSTR);
friend CMyString operator+(const LPSTR, const CMyString&);
friend CMyString operator+(const LPSTR, const LPSTR);
friend ostream& operator<<(ostream&, const CMyString&);

ostream is undeclared. If you mean std:stream then you should #include

friend istream& operator>>(ifstream&, CMyString&);

istream and ifstream have the same problem as ostream above. Presumably
istream would be a better choice than ifstream here, also. The

};

# endif //__CMYSTRING_H
-------------------------------------------------------------------------------


-----------------------------------------main.h--------------------------------

# include <iostream.h>

Old, pre-standard header. Doesn't exist in standard C++.

# include "CMyString.h"
void main()

void is not and never has been an acceptable return type for main().
It's also a little strange to put main in a .h file, but not strictly wrong.

{
CMyString string="";
while(string!="exit"){
cout <<"\n$"; // show prompt for operator input
cin>>string;
cout<<string<<endl;
}
cout<<"\nBye";
}
--------------------------------------------------------------------------------


Better now?
Now one need to write CMyString.cpp

I'd rather use the standard library, myself. Much less effort, more
convenient, and fewer bugs.

-Kevin

 

[/dev/null]

void main()

The C++ standard is quite explicit about the fact that main must return
int. false

{
char input[256] = "";

std::strings are usually preferable to char arrays.

while(strcmp(input,"exit")){
cout <<"\n$"; // show prompt for operator input

cout's full name is std::cout. You need to either fully qualify it, or
introduce the name with a "using" statement or declaration. ???
false

cin>>input;

It's called std::cin. so?

And congratulations on reinventing gets(). Your program is now

reinventing? both cin and cout are standard in C++!

hopelessly broken, easy to crash, and may be exploited to compromise
system security.

blah (want some cheese to that whine?)

You might want to consider what happens when someone enters more than
255 characters (accidentally or maliciously), and read up on buffer
overflow attacks. You could start your research by reading about the
Morris worm. This single instance of a program that exploited a buffer
overflow vulnerability is estimated to have caused between 10 and 100
MILLION dollars in damages. That was in 1988. Since then, I can't even
begin to imagine how much money has been wasted because of security
holes due to lazy programmers writing lazy code like this.

command line lenght is limited, if I'm not wrong to 256 chars, so I can bear that in simple test console program (sorry haven't noticed a crosspost)

return 0; here wouldn't hurt.

it would generate compiler error since main was defined as void! you cannot return value for void function!

 

[/dev/null]

Because the original question was about C++, not Windows programming,
and because I'm reading & replying in comp.lang.c++, This reply assumes
nothing beyond standard C++. Some of the non-standard things may be
topical and make sense in comp.os.ms-windows.programmer.win32, but I'm
ignoring that since they are not standard and not topical in comp.lang.c++.

(The OP probably shouldn't have cross-posted to
comp.os.ms-windows.programmer.win32. The question does not seem to be
relevant to that group.)

Ah sorry haven't seen crosspost :s (I'm reading and replying in comp.os.ms-windows.programmer.win32)

This violates the implementation's namespace. Identifiers that begin
with an underscore, followed by either an uppercase letter or another
underscore are reserved for the implementation for any purpose. ???? are you certain of that?



This is not a standard header.

As I wrote above I'm reading and replying in comp.os.ms-windows.programmer.win32
- in win32 it is

What is 'Class'?

of couse should be class (typo)

What is 'LPCTSTR'?

again: comp.os.ms-windows.programmer.win32

Missing return type.



Has NULL been #defined? No standard header that defines it has been
included.

}
~CMyString()
{
if(string)
delete[] string;
}
CMyString& operator=(const CMyString&);
CMyString& operator=(const LPSTR);

What is LPSTR?

BOOL operator==(const CMyString&);

again: comp.os.ms-windows.programmer.win32

What is BOOL? (And why would anyone use this mysterious type when the
language already provides a well-behaved built-in boolean type?)



ostream is undeclared. If you mean std:stream then you should #include
<ostream> or possibly <iosfwd>, and fully qualify it.

istream and ifstream have the same problem as ostream above. Presumably
istream would be a better choice than ifstream here, also. The
respective headers are <istream> and <fstream>, or <iosfwd>.

ifstream is typo! - should be istream of course!

Old, pre-standard header. Doesn't exist in standard C++.


void is not and never has been an acceptable return type for main(). false!
It's also a little strange to put main in a .h file, but not strictly
wrong.

typo again - of course it should be main.cpp

I'd rather use the standard library, myself. Much less effort, more
convenient, and fewer bugs.

I have a feeling that you have problems with distinguish between C an C++ :s
Anyway it was posted to com.lang.c++ not comp.lang.c.

I allow myself to recommend you great book about C++ if you want learn it: "C++ Language", author: Bjarne Stroustrup
Good luck!

 

[Kevin Goodsell]

Ah sorry haven't seen crosspost :s (I'm reading and replying in
comp.os.ms-windows.programmer.win32)

Understood. We don't speak precisely the same language here as you do
there, but some things are common.

???? are you certain of that?

Yes I am. Quote from the standard follows (actually this and all quotes
I use are from a draft of the standard, not the final version, but the
differences are relatively trivial):

17.4.3.1.2 Global names [lib.global.names]

1 Certain sets of names and function signatures are always reserved to
the implementation:

--Each name that contains a double underscore __) or begins with an
underscore followed by an uppercase letter (_lex.key_) is reserved
to the implementation for any use.

of couse should be class (typo)

Of course.

false! I have included <iostream.h> and that is far enough!

But <iostream.h> has not been part of C since 1998 when the standard was
finalized. If you feel like debating this point, you should get a copy
of the standard and tell me what chapter and verse mentions

ifstream is typo! - should be istream of course!
OK.



man, <iostream.h> it is standard C++ header!

No, it's not. From the standard:

17.4.1.2 Headers [lib.headers]

1 The elements of the C++ Standard Library are declared or defined (as
appropriate) in a header.158)

2 The C++ Standard Library provides 32 C++ headers, as shown in Table
11:

Table 11--C++ Library Headers

+------------------------------------------------------------------+
|<algorithm> <iomanip> <list> <ostream> <streambuf> |
|<bitset> <ios> <locale> <queue> <string> |
|<complex> <iosfwd> <map> <set> <typeinfo> |
|<deque> <iostream> <memory> <sstream> <utility> |
|<exception> <istream> <new> <stack> <valarray> |
|<fstream> <iterator> <numeric> <stdexcept> <vector> |
|<functional> <limits> |
+------------------------------------------------------------------+

3 The facilities of the Standard C Library are provided in 18 additional
headers, as shown in Table 12:

Table 12--C++ Headers for C Library Facilities

+--------------------------------------------------+
|<cassert> <ciso646> <csetjmp> <cstdio> <ctime> |
|<cctype> <climits> <csignal> <cstdlib> <cwchar> |
|<cerrno> <clocale> <cstdarg> <cstring> <cwctype> |
|<cfloat> <cmath> <cstddef> |
+--------------------------------------------------+


Footnote 158:

158) A header is not necessarily a source file, nor are the sequences
delimited by < and > in header names necessarily valid source file
names (_cpp.include_).

false!

If you want to make that claim then you should back it up, but I warn
you that it will make you look like a fool. From the standard:

3.6.1 Main function [basic.start.main]

1 A program shall contain a global function called main, which is the
designated start of the program. It is implementation-defined whether
a program in a freestanding environment is required to define a main
function. [Note: in a freestanding environment, start-up and termina-
tion is implementation-defined; start-up contains the execution of
constructors for objects of namespace scope with static storage dura-
tion; termination contains the execution of destructors for objects
with static storage duration. ]

2 An implementation shall not predefine the main function. This func-
tion shall not be overloaded. It shall have a return type of type
int, but otherwise its type is implementation-defined. All implemen-
tations shall allow both of the following definitions of main:
int main() { /* ... */ }
and
int main(int argc, char* argv[]) { /* ... */ }


See the part where it says "it shall have a return type of type int"? I
don't see any way that this can be interpreted as "may have a return
type of void".

For the record, no version of C or C++ has ever required 'void' to be
accepted as main's return type. 'void main' is a complete myth. Some
implementations accept it (illegally in the case of C++), but this is
mainly because the false belief that 'void main' is valid is so widespread.

typo again - of course it should be main.cpp
OK.

I have a feeling that you have problems with distinguish between C an
C++ :s
Anyway it was posted to com.lang.c++ not comp.lang.c.

I never said anything about C in this thread, and I don't understand
this comment. I assure you that I'm reasonably well-versed in both C and
C++, and don't tend to confuse them (though I certainly wouldn't claim
that I never confuse them).

I allow myself to recommend you great book about C++ if you want learn
it: "C++ Language", author: Bjarne Stroustrup
Good luck!

You mean "The C++ Programming Language"? I have 2 well-worn copies (3rd
edition and special edition). That book backs up pretty much everything
I've said in this thread, but the Standard gets the final say.

-Kevin

 

[Kevin Goodsell]

false

Have you ever considered backing up the claims you make? I supplied a
quote from the standard else-thread to back up mine.

{
char input[256] = "";

std::strings are usually preferable to char arrays.

while(strcmp(input,"exit")){
cout <<"\n$"; // show prompt for operator input

cout's full name is std::cout. You need to either fully qualify it, or
introduce the name with a "using" statement or declaration.

???
false
# <include iostream.h> is enough!

No, that's a syntax error. But even with that fixed, <iostream.h> is not
part of the C++ language and hasn't been for a very long time.

You mention Stroustrup's book. Maybe you should open that puppy up to
page 46 (section 3.2 "Hello, world!") and read a little. The next
section is good also - it talks about the fact that (most) standard
library names appear in namespace std.

Also, you should check section B.3.1 (page 821) which talks about the
fact that standard C++ headers no longer end in .h.

so?

So... if you don't specify in some way that you want std::cin, the
implementation will assume you want some other cin, probably fail to
locate it, and give an error.

reinventing? both cin and cout are standard in C++!

Not the point. The point is that you did something very unsafe.

blah (want some cheese to that whine?)

10 million dollars. At least. One instance. You think this is a minor
detail? You'd better educate yourself a bit about safe and secure
programming, or else stay away from any real programming.

command line lenght is limited, if I'm not wrong to 256 chars, so I can
bear that in simple test console program (sorry haven't noticed a
crosspost)

I don't see how that's relevant, even if it is true. cin is not
necessarily console input, even in Windows.

it would generate compiler error since main was defined as void! you
cannot return value for void function!

You cannot (correctly) define main as a void function. I was assuming
you'd fix that error.

-Kevin

 

[/dev/null]

Understood. We don't speak precisely the same language here as you do
there, but some things are common.

Yeah, OP definately shouldn't crosspost and choose 1 group. (He choosed comp.os.ms-windows.programmer.win32 cause of his programming enviroment)

???? are you certain of that?

Yes I am. Quote from the standard follows (actually this and all quotes
I use are from a draft of the standard, not the final version, but the
differences are relatively trivial):

17.4.3.1.2 Global names [lib.global.names]

1 Certain sets of names and function signatures are always reserved to
the implementation:

--Each name that contains a double underscore __) or begins with an
underscore followed by an uppercase letter (_lex.key_) is reserved
to the implementation for any use.

Guess I'll have to live with that: all my headers have __"filename"_H.

of couse should be class (typo)

Of course.

false! I have included <iostream.h> and that is far enough!

But <iostream.h> has not been part of C since 1998 when the standard was
finalized. If you feel like debating this point, you should get a copy
of the standard and tell me what chapter and verse mentions
<iostream.h>. I can't find a single occurrence of the token 'iostream.h'
in the standard.

ifstream is typo! - should be istream of course!

OK.



man, <iostream.h> it is standard C++ header!

No, it's not. From the standard:

17.4.1.2 Headers [lib.headers]

1 The elements of the C++ Standard Library are declared or defined (as
appropriate) in a header.158)

2 The C++ Standard Library provides 32 C++ headers, as shown in Table
11:

Table 11--C++ Library Headers

+------------------------------------------------------------------+
|<algorithm> <iomanip> <list> <ostream> <streambuf> |
|<bitset> <ios> <locale> <queue> <string> |
|<complex> <iosfwd> <map> <set> <typeinfo> |
|<deque> <iostream> <memory> <sstream> <utility> |
|<exception> <istream> <new> <stack> <valarray> |
|<fstream> <iterator> <numeric> <stdexcept> <vector> |
|<functional> <limits> |
+------------------------------------------------------------------+

3 The facilities of the Standard C Library are provided in 18 additional
headers, as shown in Table 12:

Table 12--C++ Headers for C Library Facilities

+--------------------------------------------------+
|<cassert> <ciso646> <csetjmp> <cstdio> <ctime> |
|<cctype> <climits> <csignal> <cstdlib> <cwchar> |
|<cerrno> <clocale> <cstdarg> <cstring> <cwctype> |
|<cfloat> <cmath> <cstddef> |
+--------------------------------------------------+


Footnote 158:

158) A header is not necessarily a source file, nor are the sequences
delimited by < and > in header names necessarily valid source file
names (_cpp.include_).

I see no mention of <iostream.h> here

I typed taht header in netscape messenger, so I might forgot it, that also explains typos (for example: CString() was supposed to be constructor: CMyString(), so of course no missing return type (haven't noticed that earlier) )

If you want to make that claim then you should back it up, but I warn
you that it will make you look like a fool. From the standard: ....
....
For the record, no version of C or C++ has ever required 'void' to be
accepted as main's return type. 'void main' is a complete myth. Some
implementations accept it (illegally in the case of C++), but this is
mainly because the false belief that 'void main' is valid is so widespread.

Well, I always used void main() for small programs (just to save that one line). I saw that also in many books (I think also includins Stroustrup's but I'm not sure). I never met any compiler that wouldn't accept that, so it's something new for me! (Never bothered to read some paper specification).

I never said anything about C in this thread, and I don't understand
this comment. I assure you that I'm reasonably well-versed in both C and
C++, and don't tend to confuse them (though I certainly wouldn't claim
that I never confuse them).

I was little confused by offensing tone of your post, like if u tried to find errors where there were none so it was first explanation that came to my mind.
Btw RFC 1855 does not contain term like "top-post".

 

[/dev/null]

No, that's a syntax error. But even with that fixed, <iostream.h> is not
part of the C++ language and hasn't been for a very long time.

You mention Stroustrup's book. Maybe you should open that puppy up to
page 46 (section 3.2 "Hello, world!") and read a little. The next
section is good also - it talks about the fact that (most) standard
library names appear in namespace std.

Also, you should check section B.3.1 (page 821) which talks about the
fact that standard C++ headers no longer end in .h.

So, you do make me feel like dinosour.

So... if you don't specify in some way that you want std::cin, the
implementation will assume you want some other cin, probably fail to
locate it, and give an error.

Not the point. The point is that you did something very unsafe.



10 million dollars. At least. One instance. You think this is a minor
detail? You'd better educate yourself a bit about safe and secure
programming, or else stay away from any real programming.

I know of that, I used buffer overflows to obtain root years ago when unix sytems was full of such security holes.
I do not treat it as minor detail ... in real programming. But in small test program I will not bother with some boundary check, exception handling, etc. I can make some assumption to simplify program, but this of course will disqualify that program from wide-purpose use.
But perhaps you right I shouln't even post such code, someone who learn should't ever watch it

 

[Buster]

It iz I, Karl Heinz Buchegger, I will zay zis only onze:

Sorry, couldn't resist.

That's three different characters! Le Clerk says "It is I, Le
Clerk",
Maria (?) says "I will zay zis only once", and that idiot Englishman
who thinks he can speak French would call a bug a big.

Hell, they don't make'em like that any more. Probably thanks to
race relations legislation ...

B

 

[Kevin Goodsell]

Kevin Goodsell wrote:

I think <iostream.h> was never part of C, it was C++ library!

Grrr, of course. I meant C++.

I don't write real console applications for years anymore but I always
used that library. I still use it when I have a need to write some
simple console program. Don't make me feel like dinosour.

Don't use archaic language features.

Well, I always used void main() for small programs (just to save that
one line). I saw that also in many books (I think also includins
Stroustrup's but I'm not sure).

Absolutely NOT in Stroustrup's. He invented the language, he knows better.

There are a lot bad books out there. Some incorrectly declare main().
That makes the books wrong, it doesn't make void main right.

I never met any compiler that wouldn't
accept that, so it's something new for me! (Never bothered to read some
paper specification).

Many compilers in strict mode will diagnose it, but this is not required.

Weird, I program in C++ for about 8 years and never used strings in this
language (I mean other than char* or that mysterious LPCTSTR - its
windows type - if UNICODE is defined it points to string of 16 bit
Unicode characters, otherwise to string of 8 bit ANSI caharacters).

It would be wise for you to familiarize yourself with the library that
C++ provides. std::string is very nice to have. std::wstring is probably
a Unicode version of the same on your implementation. Technically it's
the wide-character version. It's not required that wide-characters be
unicode, but they probably are on you implementation.

I was little confused by offensing tone of your post, like if u tried to
find errors where there were none so it was first explanation that came
to my mind. Btw RFC 1855 does not contain term like "top-post".

I do my best to find errors where they exist and *not* find them where
they don't exist.

RFC 1855 doesn't use that term, but it does discuss the issue in section
3.1.1, 10th bullet point.

-Kevin