• "Jim Jennings" <jwjenn mindspring.com> Mar 09 2003
• "Walter" <walter digitalmars.com> Mar 10 2003
• "Jim Jennings" <jwjenn mindspring.com> Mar 11 2003
• "Walter" <walter digitalmars.com> Mar 11 2003
• "Jim Jennings" <jwjenn mindspring.com> Mar 11 2003
• "Walter" <walter digitalmars.com> Mar 11 2003

The in_file.bad() instruction in the code below does not return true if a
bad file name is entered on the command line. The cerr message and the
return are skipped. The two commented lines return true, and the error
message and the return statement execute for both of them. I am using the
stlport library with dmc.
According to N. Josuttis, C++ Standard Library, p.598, bad() is supposed to
return true if  a fatal error has occurred (badbit is set). I have compiled
this program with dmc and another compiler with identical results.

    std::ifstream in_file(argv[1]);
//    if (in_file.fail())
//    if (!in_file)
    if (in_file.bad())
    {
         std::cerr << "Cannot open " << argv[1] << '\n';
         return -1;
    }

I can find bad() in dm\include\iostream.h and some dll's in dm\bin
iostream.h says this:
inline int      ios::fail() { return state & (failbit | badbit |
hardfail); }
inline int      ios::bad() { return state & (badbit | hardfail); }

Am I correct in concluding that trying to open a non-existing input file
does not turn on either the badbit or the hardfail, but only the failbit?
Jim W. J.

Try the version of <iostream> in \dm\stlport\stlport, the older <iostream.h>
in \dm\include is obsolete (but included for backwards compabitility).

"Jim Jennings" <jwjenn mindspring.com> wrote in message
news:b4harj$2fmg$1 digitaldaemon.com...
 The in_file.bad() instruction in the code below does not return true if a
 bad file name is entered on the command line. The cerr message and the
 return are skipped. The two commented lines return true, and the error
 message and the return statement execute for both of them. I am using the
 stlport library with dmc.
 According to N. Josuttis, C++ Standard Library, p.598, bad() is supposed


 return true if  a fatal error has occurred (badbit is set). I have


 this program with dmc and another compiler with identical results.

     std::ifstream in_file(argv[1]);
 //    if (in_file.fail())
 //    if (!in_file)
     if (in_file.bad())
     {
          std::cerr << "Cannot open " << argv[1] << '\n';
          return -1;
     }

 I can find bad() in dm\include\iostream.h and some dll's in dm\bin
 iostream.h says this:
 inline int      ios::fail() { return state & (failbit | badbit |
 hardfail); }
 inline int      ios::bad() { return state & (badbit | hardfail); }

 Am I correct in concluding that trying to open a non-existing input file
 does not turn on either the badbit or the hardfail, but only the failbit?
 Jim W. J.

Walter,
I believe I am using <iostream> in \dm\stlport\stlport. I #include
<iostream> in the program. I have
also, per instructions in the dm\stlport\readme.txt file, replaced a line in
sc.ini:

Quote : To use STLport without iostreams, simply add \dm\stlport\stlport to
the
INCLUDE search path before \dm\include. Or, modify the INCLUDE entry
in \dm\bin\sc.ini to be:

INCLUDE="% P%\..\stlport\stlport";"% P%\..\include";"% P%\..\mfc\include";%I
NCLUDE%
Unquote:
Making a wild guess, in sc.ini, I have replaced
INCLUDE="% P%\..\include";"% P%\..\mfc\include";"% P%\..\stl";%INCLUDE%
with:
INCLUDE="% P%\..\stlport\stlport";"% P%\..\include";"% P%\..\mfc\include";%I
NCLUDE%

This change works (I do not have to say -I\dm\stlport\stlport on the command
line anymore), but I am confused by the phrase "To use STLport without
iostreams, . . ." when later in the readme.txt file it says:
Quote: To compile a program using STLport's <iostreams> with the static
library:
 sc hello -I\dm\stlport\stlport
Unquote. Which is it? The statements are contradictory. Are these two
statements referring to two different iostreams, STLport's and some other
one, or do they both refer to the STLport iostream? What is the "static
library"?

Following Christof's instructions I have:
(built) the STLport libraries and dll's with: smake -f dm.mak

bye, bye,
Jim J.

"Walter" <walter digitalmars.com> wrote in message
news:b4jotn$bfo$2 digitaldaemon.com...
 Try the version of <iostream> in \dm\stlport\stlport, the older


 in \dm\include is obsolete (but included for backwards compabitility).

 "Jim Jennings" <jwjenn mindspring.com> wrote in message
 news:b4harj$2fmg$1 digitaldaemon.com...
 The in_file.bad() instruction in the code below does not return true if




 bad file name is entered on the command line. The cerr message and the
 return are skipped. The two commented lines return true, and the error
 message and the return statement execute for both of them. I am using




 stlport library with dmc.
 According to N. Josuttis, C++ Standard Library, p.598, bad() is supposed


 return true if  a fatal error has occurred (badbit is set). I have


 this program with dmc and another compiler with identical results.

     std::ifstream in_file(argv[1]);
 //    if (in_file.fail())
 //    if (!in_file)
     if (in_file.bad())
     {
          std::cerr << "Cannot open " << argv[1] << '\n';
          return -1;
     }

 I can find bad() in dm\include\iostream.h and some dll's in dm\bin
 iostream.h says this:
 inline int      ios::fail() { return state & (failbit | badbit |
 hardfail); }
 inline int      ios::bad() { return state & (badbit | hardfail); }

 Am I correct in concluding that trying to open a non-existing input file
 does not turn on either the badbit or the hardfail, but only the




 Jim W. J.

stlport can be used with and without iostreams. To use the iostreams, you'll
need to link with the stlport static library. If using stlport without
iostreams, you don't need to link with that library. Sorry about the
confusion. -Walter

"Jim Jennings" <jwjenn mindspring.com> wrote in message
news:b4l1p6$12bc$1 digitaldaemon.com...
 Walter,
 I believe I am using <iostream> in \dm\stlport\stlport. I #include
 <iostream> in the program. I have
 also, per instructions in the dm\stlport\readme.txt file, replaced a line


 sc.ini:

 Quote : To use STLport without iostreams, simply add \dm\stlport\stlport


 the
 INCLUDE search path before \dm\include. Or, modify the INCLUDE entry
 in \dm\bin\sc.ini to be:


 NCLUDE%
 Unquote:
 Making a wild guess, in sc.ini, I have replaced
 INCLUDE="% P%\..\include";"% P%\..\mfc\include";"% P%\..\stl";%INCLUDE%
 with:


 NCLUDE%

 This change works (I do not have to say -I\dm\stlport\stlport on the


 line anymore), but I am confused by the phrase "To use STLport without
 iostreams, . . ." when later in the readme.txt file it says:
 Quote: To compile a program using STLport's <iostreams> with the static
 library:
  sc hello -I\dm\stlport\stlport
 Unquote. Which is it? The statements are contradictory. Are these two
 statements referring to two different iostreams, STLport's and some other
 one, or do they both refer to the STLport iostream? What is the "static
 library"?

 Following Christof's instructions I have:
 (built) the STLport libraries and dll's with: smake -f dm.mak

 bye, bye,
 Jim J.

 "Walter" <walter digitalmars.com> wrote in message
 news:b4jotn$bfo$2 digitaldaemon.com...
 Try the version of <iostream> in \dm\stlport\stlport, the older


 in \dm\include is obsolete (but included for backwards compabitility).

 "Jim Jennings" <jwjenn mindspring.com> wrote in message
 news:b4harj$2fmg$1 digitaldaemon.com...
 The in_file.bad() instruction in the code below does not return true






 a
 bad file name is entered on the command line. The cerr message and the
 return are skipped. The two commented lines return true, and the error
 message and the return statement execute for both of them. I am using




 stlport library with dmc.
 According to N. Josuttis, C++ Standard Library, p.598, bad() is






 to
 return true if  a fatal error has occurred (badbit is set). I have


 this program with dmc and another compiler with identical results.

     std::ifstream in_file(argv[1]);
 //    if (in_file.fail())
 //    if (!in_file)
     if (in_file.bad())
     {
          std::cerr << "Cannot open " << argv[1] << '\n';
          return -1;
     }

 I can find bad() in dm\include\iostream.h and some dll's in dm\bin
 iostream.h says this:
 inline int      ios::fail() { return state & (failbit | badbit |
 hardfail); }
 inline int      ios::bad() { return state & (badbit | hardfail); }

 Am I correct in concluding that trying to open a non-existing input






 does not turn on either the badbit or the hardfail, but only the




 Jim W. J.

I am still confused. I will read the stlport docs to see if I can make sense
of it.
I have gone back to the original sc.ini file, and I am
using -I\dm\stlport\stlport when compiling. The way I read the stlport
readme.txt file, that will allow me to link with the stlport static library,
and use the stlport iostreams.
No matter how I do it, the iostream bad() function does not work. But it
does not work for g++, or Borland either. You have to use the fail()
function to detect a file-open error.
I do not want to bother you with this anymore.

jwj.

"Walter" <walter digitalmars.com> wrote in message
news:b4l4im$2ae3$1 digitaldaemon.com...
 stlport can be used with and without iostreams. To use the iostreams,


 need to link with the stlport static library. If using stlport without
 iostreams, you don't need to link with that library. Sorry about the
 confusion. -Walter

"Jim Jennings" <jwjenn mindspring.com> wrote in message
news:b4ldg4$2huh$1 digitaldaemon.com...
 I am still confused. I will read the stlport docs to see if I can make


 of it.
 I have gone back to the original sc.ini file, and I am
 using -I\dm\stlport\stlport when compiling. The way I read the stlport
 readme.txt file, that will allow me to link with the stlport static


 and use the stlport iostreams.
 No matter how I do it, the iostream bad() function does not work. But it
 does not work for g++, or Borland either. You have to use the fail()
 function to detect a file-open error.
 I do not want to bother you with this anymore.


I am also trying to use stlport as generically as possible with as few
changes to the source code in it as possible. I'm a bit reluctant to change
the semantics of it as several compilers use it, and programmers tend to
expect it to work the same on each.