By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,214 Members | 2,072 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,214 IT Pros & Developers. It's quick & easy.

iostream and getline

P: n/a
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
Jul 22 '05 #1
Share this Question
Share on Google+
19 Replies


P: n/a
"er************@gmx.net" wrote:

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.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #2

P: n/a

"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:40***************@gascad.at...
"er************@gmx.net" wrote:

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


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
Jul 22 '05 #3

P: n/a
er************@gmx.net wrote:
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";
}
Jul 22 '05 #4

P: n/a
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";
}

er************@gmx.net wrote:
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


Jul 22 '05 #5

P: n/a
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

Jul 22 '05 #6

P: n/a
"/dev/nu**@localhost.ld" wrote:

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.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #7

P: n/a

"/dev/nu**@localhost.ld" <"/dev/nu**@localhost.ld"> wrote in message
news:bu**********@atlantis.news.tpi.pl...
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.
Jul 22 '05 #8

P: n/a
Sumit Rajan wrote:
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 :)

Jul 22 '05 #9

P: n/a
/dev/nu**@localhost.ld wrote:
Sumit Rajan wrote:
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?

Jul 22 '05 #10

P: n/a
/dev/nu**@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.
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++
language. Standard C++ uses <iostream>
# 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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #11

P: n/a
/dev/nu**@localhost.ld wrote:
Sumit Rajan wrote:
Looks like C++ code from a bygone era. :-)
:'(

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::ostream then you should #include
<ostream> or possibly <iosfwd>, and fully qualify it.
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
respective headers are <istream> and <fstream>, or <iosfwd>.
};

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

P: n/a
Kevin Goodsell wrote:
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
# <include iostream.h> is enough!
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!

Jul 22 '05 #13

P: n/a
Kevin Goodsell 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.) Ah sorry haven't seen crosspost :s (I'm reading and replying in comp.os.ms-windows.programmer.win32)
-------------------------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.

???? are you certain of that?

#include <windows.h>

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

Class CMyString

What is 'Class'?

of couse should be class (typo)
{
int size;
LPCTSTR string;

What is 'LPCTSTR'?

again: comp.os.ms-windows.programmer.win32
public:
CString()

Missing return type.
{ size=0;
string=NULL;

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

yes, I've included <windows.h>
}
~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?)
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::ostream then you should #include
<ostream> or possibly <iosfwd>, and fully qualify it.

false! I have included <iostream.h> and that is far enough!
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
respective headers are <istream> and <fstream>, or <iosfwd>.

ifstream is typo! - should be istream of course!
};

# endif //__CMYSTRING_H
-------------------------------------------------------------------------------
-----------------------------------------main.h--------------------------------

# include <iostream.h>

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

man, <iostream.h> it is standard C++ header!
# include "CMyString.h"
void main()

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!

Jul 22 '05 #14

P: n/a
/dev/nu**@localhost.ld wrote:

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


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

What is 'Class'?


of couse should be class (typo)


Of course.

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


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.

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!


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.
# include "CMyString.h"
void main()
void is not and never has been an acceptable return type for main().


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


OK.

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

P: n/a
/dev/nu**@localhost.ld wrote:
Kevin Goodsell wrote:
void main()
The C++ standard is quite explicit about the fact that main must
return int.


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.
cin>>input;
It's called std::cin.


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.

And congratulations on reinventing gets(). Your program is now
reinventing? both cin and cout are standard in C++!


Not the point. The point is that you did something very unsafe.
hopelessly broken, easy to crash, and may be exploited to compromise
system security.
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.

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)


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

return 0; here wouldn't hurt.


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

P: n/a
Kevin Goodsell wrote:
/dev/nu**@localhost.ld wrote:

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.

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

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

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

What is 'Class'?

of couse should be class (typo)

Of course.

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

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.

I think <iostream.h> was never part of C, it was C++ library!
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.

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!

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

# include "CMyString.h"
void main()


void is not and never has been an acceptable return type for main().

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:

....
.... 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'd rather use the standard library, myself. Much less effort, more
convenient, and fewer bugs. 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).

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

Jul 22 '05 #17

P: n/a
Kevin Goodsell wrote:
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.

cin>>input;


It's called std::cin.

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.

I meant that with <iostream.h> it's working fine.

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

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

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

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

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.

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.

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

Yep, but look above.

return 0; here wouldn't hurt.

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


Jul 22 '05 #18

P: n/a
> It iz I, Karl Heinz Buchegger, I will zay zis only onze:
This is a documented big in their implementation.


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
Jul 22 '05 #19

P: n/a
/dev/nu**@localhost.ld wrote:
Kevin Goodsell wrote:

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.

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

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


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


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.
Jul 22 '05 #20

This discussion thread is closed

Replies have been disabled for this discussion.