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

"ernst.stiegler@gmx.net" wrote:
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.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

ernst.stiegler@gmx.net wrote:

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";
}

"Karl Heinz Buchegger" <kbuchegg@gascad.at> wrote in message
news:400D4713.24D56B51@gascad.at...
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

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";
}

ernst.stiegler@gmx.net wrote:

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

Sorry, couldn't resist.

M4

"/dev/null@localhost.ld" wrote:
It's just a documented bug in his compiler system.
Once the patch is applied it will work fine.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

"/dev/null@localhost.ld" <"/dev/null@localhost.ld"> wrote in message
news:bujkr5$8ae$1@atlantis.news.tpi.pl...
Looks like C++ code from a bygone era. :-)

Sumit.

Sumit Rajan wrote:

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

/dev/null@localhost.ld wrote:
Um... How is this better than using std::string?

/dev/null@localhost.ld 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.

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

This is an old, pre-standard header and not part of the standard C++
language. Standard C++ uses <iostream>

This is deprecated, but otherwise OK.

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

std::strings are usually preferable to char arrays.

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

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.

std::cout and std::endl.

std::cout

return 0; here wouldn't hurt.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

/dev/null@localhost.ld wrote:

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.)

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.

This is not a standard header.

What is 'Class'?

What is 'LPCTSTR'?

Missing return type.

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

What is LPSTR?

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>.

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

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.

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

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Kevin Goodsell wrote:

false
# <include iostream.h> is enough!

Kevin Goodsell wrote:
- in win32 it is
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!

/dev/null@localhost.ld wrote:

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

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 course.

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.

OK.

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.

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.

OK.

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).

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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

/dev/null@localhost.ld wrote:

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

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... 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 don't see how that's relevant, even if it is true. cin is not
necessarily console input, even in Windows.

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

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Kevin Goodsell wrote:

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.

....
Btw RFC 1855 does not contain term like "top-post".

Kevin Goodsell wrote:

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

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

/dev/null@localhost.ld wrote:

Grrr, of course. I meant C++.

Don't use archaic language features.


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.

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

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 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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.