Consider this simple C++ program:

#include <iostream.h>
int main(void) {

cout << "Hello, world!" << endl;
return 0; //This is optional
}

I can't get the UNIX compiler to recognize <iostream.h>

I know the file is there because I copied it into the same subdirectory
where the program I am trying to compile and run is.

Still, when I use cc myfile.c I get an error message saying <iostream.h>
cannot be found.

The iostream.h file is in /usr/ibmcxx/include/iostream.h

How do I make sure that directory is in my includes path?

In article <xd37b.186$NW3.175@news1.central.cox.net>, Les Coover <lcc66604@cox.net.spam> wrote:
> Consider this simple C++ program:
>
> #include <iostream.h>
> int main(void) {
>
> cout << "Hello, world!" << endl;
> return 0; //This is optional
> }
>
> I can't get the UNIX compiler to recognize <iostream.h>

1. The C++ standard now uses #include <iostream> rather than the .h form.

It will still work for backward compatibility for at least a while or
indefinitely but you should be using the modern form for anything new.

2. You're trying to use the C compiler to compile a C++ program. You want
to use the C++ compiler instead.

3. The file is test.c or whatever -- you may want to rename it to test.C

4. Then do:

$ xlC test.C -o <outputfilename>

That will work without any errors.

-Dan

Tried

$xlC test.C -o test.O

once with <iostream> and then again with <iostream.h>

Same result both times:

Preprocessor directive #include is not recognized.

One other thing -- on the C programs I use

$cc test.c
$./a.out

to compile and run programs. Is there a similar command like ./a.out to
run a C++ compiled program?


"Dan Foster" <dsf@globalcrossing.net> wrote in message
news:slrnblpgkc.9i3.dsf@gaia.roc2.gblx.net...
> In article <xd37b.186$NW3.175@news1.central.cox.net>, Les Coover
<lcc66604@cox.net.spam> wrote:
> > Consider this simple C++ program:
> >
> > #include <iostream.h>
> > int main(void) {
> >
> > cout << "Hello, world!" << endl;
> > return 0; //This is optional
> > }
> >
> > I can't get the UNIX compiler to recognize <iostream.h>
>
> 1. The C++ standard now uses #include <iostream> rather than the .h form.
>
> It will still work for backward compatibility for at least a while or
> indefinitely but you should be using the modern form for anything new.
>
> 2. You're trying to use the C compiler to compile a C++ program. You want
> to use the C++ compiler instead.
>
> 3. The file is test.c or whatever -- you may want to rename it to test.C
>
> 4. Then do:
>
> $ xlC test.C -o <outputfilename>
>
> That will work without any errors.
>
> -Dan

In article <PX37b.258$NW3.66@news1.central.cox.net>, Les Coover <lcc66604@cox.net.spam> wrote:
> Tried
>
> $xlC test.C -o test.O
>
> once with <iostream> and then again with <iostream.h>
>
> Same result both times:
>
> Preprocessor directive #include is not recognized.

Now that *is* interesting! I had tried it myself before I posted with the
original reply, and not a single error message... and also worked correctly
when I ran the generated binary.

What version/level are your compiler filesets at? Ie:

$ lslpp -l|grep xlC
$ lslpp -l|grep vacpp

Looks like I had tested it on a machine with xlC 4.0/4.3; I thought I had
run the test on the Visual Age (vacpp) 6.0 machine but apparently not.

My test failed with vacpp 5.0 only if I used <iostream> instead of
<iostream.h>.

With 6.0, it complains if you use <iostream.h> instead of <iostream> as I
seem to recall.

It would have to be something *really* odd for it to not parse #include
correctly... just really odd.

> One other thing -- on the C programs I use
>
> $cc test.c
> $./a.out
>
> to compile and run programs. Is there a similar command like ./a.out to
> run a C++ compiled program?

Looks like it defaults to a file named a.out for C++ compilers if no -o
parameter is given, as well. (I used 'xlC test.C' and checked to see what
file was created.)

-Dan

-a Displays additional ("all") information when combined with
other flags. (Not valid with -f, only valid with -B when
combined with -h)
-B Permits PTF ID input. (Not valid with -L)
-c Colon-separated output. (Not valid with -La)
-d Dependents (filesets for which this is a requisite).
-f Files that belong to this fileset.
-h History information.
-I Limits listings to base level filesets (no updates displayed).
-i Product Identification information (requested per fileset).
-J Use list as the output format. (Valid with -l and -L)
-L Lists fileset names, latest level, states, and descriptions.
(Consolidates usr, root and share part information.)
-l Lists fileset names, latest level, states, and descriptions.
(Separates usr, root and share part information.)
-O Data comes from [r] root and/or [s] share and/or [u] usr.
(Not valid with -L)
-p Requisites of installed filesets.
-q Quiet (no column headers).
-w List fileset that owns this file.

One of the following mutually exclusive flags: d,f,h,i,L,l,p,w
must be specified.

One of the system administrators sent me this message:

the iostream.h file is in /usr/ibmcxx/include/iostream.h. make sure that
that directory is in your includes path.

I copied the file into the same subdirectory where the file is that I want
to compile. Is there something else
I need to do to make sure it is in the includes path?


"Dan Foster" <dsf@globalcrossing.net> wrote in message
news:slrnblpjn0.9i3.dsf@gaia.roc2.gblx.net...
> In article <PX37b.258$NW3.66@news1.central.cox.net>, Les Coover
<lcc66604@cox.net.spam> wrote:
> > Tried
> >
> > $xlC test.C -o test.O
> >
> > once with <iostream> and then again with <iostream.h>
> >
> > Same result both times:
> >
> > Preprocessor directive #include is not recognized.
>
> Now that *is* interesting! I had tried it myself before I posted with the
> original reply, and not a single error message... and also worked
correctly
> when I ran the generated binary.
>
> What version/level are your compiler filesets at? Ie:
>
> $ lslpp -l|grep xlC
> $ lslpp -l|grep vacpp
>
> Looks like I had tested it on a machine with xlC 4.0/4.3; I thought I had
> run the test on the Visual Age (vacpp) 6.0 machine but apparently not.
>
> My test failed with vacpp 5.0 only if I used <iostream> instead of
> <iostream.h>.
>
> With 6.0, it complains if you use <iostream.h> instead of <iostream> as I
> seem to recall.
>
> It would have to be something *really* odd for it to not parse #include
> correctly... just really odd.
>
> > One other thing -- on the C programs I use
> >
> > $cc test.c
> > $./a.out
> >
> > to compile and run programs. Is there a similar command like ./a.out
to
> > run a C++ compiled program?
>
> Looks like it defaults to a file named a.out for C++ compilers if no -o
> parameter is given, as well. (I used 'xlC test.C' and checked to see what
> file was created.)
>
> -Dan

Dan, got it to work using

$xlC test.C
$./a.out

The problem--a syntax error in my source code. I sincerely appreciate your
help.

Les


"Les Coover" <lcc66604@cox.net.spam> wrote in message
news:hn67b.519$NW3.230@news1.central.cox.net...
> -a Displays additional ("all") information when combined with
> other flags. (Not valid with -f, only valid with -B when
> combined with -h)
> -B Permits PTF ID input. (Not valid with -L)
> -c Colon-separated output. (Not valid with -La)
> -d Dependents (filesets for which this is a requisite).
> -f Files that belong to this fileset.
> -h History information.
> -I Limits listings to base level filesets (no updates displayed).
> -i Product Identification information (requested per fileset).
> -J Use list as the output format. (Valid with -l and -L)
> -L Lists fileset names, latest level, states, and descriptions.
> (Consolidates usr, root and share part information.)
> -l Lists fileset names, latest level, states, and descriptions.
> (Separates usr, root and share part information.)
> -O Data comes from [r] root and/or [s] share and/or [u] usr.
> (Not valid with -L)
> -p Requisites of installed filesets.
> -q Quiet (no column headers).
> -w List fileset that owns this file.
>
> One of the following mutually exclusive flags: d,f,h,i,L,l,p,w
> must be specified.
>
> One of the system administrators sent me this message:
>
> the iostream.h file is in /usr/ibmcxx/include/iostream.h. make sure that
> that directory is in your includes path.
>
> I copied the file into the same subdirectory where the file is that I want
> to compile. Is there something else
> I need to do to make sure it is in the includes path?
>
>
> "Dan Foster" <dsf@globalcrossing.net> wrote in message
> news:slrnblpjn0.9i3.dsf@gaia.roc2.gblx.net...
> > In article <PX37b.258$NW3.66@news1.central.cox.net>, Les Coover
> <lcc66604@cox.net.spam> wrote:
> > > Tried
> > >
> > > $xlC test.C -o test.O
> > >
> > > once with <iostream> and then again with <iostream.h>
> > >
> > > Same result both times:
> > >
> > > Preprocessor directive #include is not recognized.
> >
> > Now that *is* interesting! I had tried it myself before I posted with
the
> > original reply, and not a single error message... and also worked
> correctly
> > when I ran the generated binary.
> >
> > What version/level are your compiler filesets at? Ie:
> >
> > $ lslpp -l|grep xlC
> > $ lslpp -l|grep vacpp
> >
> > Looks like I had tested it on a machine with xlC 4.0/4.3; I thought I
had
> > run the test on the Visual Age (vacpp) 6.0 machine but apparently not.
> >
> > My test failed with vacpp 5.0 only if I used <iostream> instead of
> > <iostream.h>.
> >
> > With 6.0, it complains if you use <iostream.h> instead of <iostream> as
I
> > seem to recall.
> >
> > It would have to be something *really* odd for it to not parse #include
> > correctly... just really odd.
> >
> > > One other thing -- on the C programs I use
> > >
> > > $cc test.c
> > > $./a.out
> > >
> > > to compile and run programs. Is there a similar command like ./a.out
> to
> > > run a C++ compiled program?
> >
> > Looks like it defaults to a file named a.out for C++ compilers if no -o
> > parameter is given, as well. (I used 'xlC test.C' and checked to see
what
> > file was created.)
> >
> > -Dan
>
>