Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

problem with iostream.h?

Status
Not open for further replies.

Kiehlster

MIS
Aug 14, 2000
147
US
can anyone tell me why this code:

#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <fstream.h>

using namespace std;

int main (int argc, char *argv[]) {
if (argc < 2) {
printf (&quot;adduser usage:\n&quot;);
printf (&quot; adduser <user-name>\n&quot;);
exit(1);
} else {
ifstream in;
char input[500];
in.open(&quot;dcusers.dat&quot;);
in >> input;
printf (input);
in.close();
exit(0);
}

}

gives this compile issue:

/tmp/ccbAO9EC.o: In function `main':
/tmp/ccbAO9EC.o(.text+0x49): undefined reference to `ifstream::ifstream(int)'
/tmp/ccbAO9EC.o(.text+0x66): undefined reference to `ifstream::eek:pen(char const *, int, int)'
/tmp/ccbAO9EC.o(.text+0x84): undefined reference to `istream::eek:perator>>(char *)'
/tmp/ccbAO9EC.o(.text+0xa8): undefined reference to `fstreambase::close(void)'
/tmp/ccbAO9EC.o(.text+0xc9): undefined reference to `ifstream::~ifstream(void)'
collect2: ld returned 1 exit status

???
I'm stumped, and very rusty at c++ programming.
Steve Kiehl
webmaster@nanovox.com
 
Try #include <ifstream.h> //for input
#include <ofstream.h> //for output
 
There's no <ifstream.h> or <ofstream.h>. Your plain old <fstream.h> is right... although you really should be using the version of <fstream> without the h.

As for your errors, it compiled just fine, but it didn't link. Are you sure you're using the C++ version of your compiler and not the C version (i.e. g++ instead of gcc)? What compiler are you using?
 
fstream.h has the constructors for ifstreams and ofstreams (which are derived from istream and ostream, respectivly).

It does indeed have an .h (although certian implementations of g++ use various shortcuts where certian libraries, in that you don't have to type the &quot;.h&quot; or if you do it can't find it...).

Yes, symbolrefrencing errors aren't from compiliation, but from linking, however if you type
Code:
g++ code.cc
you will see the linking errors... so you see his confussion.

Additionally,
Code:
exit()
is typically reserved to return on an error condition or end the program from a function other than main (which isn't the best programming stlye), you should just return 0 given that there are no errors. As compiling the program (showing all warnings:
Code:
g++ -Wall
) would result in an error saying &quot;No return in non-void function main().&quot; More over, mixing C/C++ insertion and extraction makes for slopy code. try changing your printf()'s to
Code:
cout << &quot;adduser:&quot; <<endl;
. Also, why not take advantage of the string library instead of a char array?

Sorry to knit pick, but just a few pet peves all grouped together... Don't mean to be mean, just making a few suggestions.
 
iostream.h and fstream.h are kept for backwards compatibilty. You should be using iostream and fstream i.e. drop the .h
 
Indeed. <iostream.h> and <fstream.h> are completely different files from <iostream> and <fstream>. The former are old, classic-style streams, an artifact of pre-Standard C++. While typical users probably won't notice the differences (a good thing), there are subtle implementation details that have changed in the Standard versions.

In fact, none of the Standard headers should have a .h on the end anymore. <iostream.h> is <iostream>, <fstream.h> is <fstream>, <vector.h> is <vector>... even the old C headers got a facelift: <string.h> is <cstring>, <stdlib.h> is <cstdlib>.

jstreich, you might have an older version of g++. I know they used to have a non-Standard conforming <iostream> file that just looked like:

[tt]// iostream

#ifndef IOSTREAM
#define IOSTREAM
#include <iostream.h>
#endif
[/tt]

They should have fixed their evil ways by now, though.


As for combining C/C++ insertion/extraction... there's no accounting for taste, but one of the things in the &quot;new&quot; <iostream> that I don't think was in the classic version is synchronization (or the option thereof) with the C input/output library. There's no real reason you can't use both methods in one program. (Aesthetic reasons notwithstanding).
 
Heh, you know universities... old everything... :p

That, and my programs are often written for DJGPP which follows ANASI standards of old (as no one has updated it in a while).

And as for mixing old C statements and new C++ statments, like I said, it is just a pet peeve of mine. As I am often bothered in the lab by people who have unreadable code... One of the reasons that I prefer deep tabs to Emacs' two space tabs.
 
Yes, I do know universities. Where do you think I saw that nonstandard iostream file? :p

And point taken about people in the lab with unreadable code. It's nice when your code is consistent. (No &quot;printf(this), cin >> that&quot;).

But that's more a coding style issue than anything else... to each his own.
 
Well, not to each his own. Imagine comming into a company where the last guy wrote (uncommented) code full of both, where STDIN and STDOUT where pointing at something other than the current terminal window. Granted that it is a style issue, as I said before, but it is still a big pet peeve.

Heh, I suppose
 
Heh heh. Agreed. It's &quot;just&quot; a style issue until it starts obfuscating code.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top