fstream sh_read

[Simon Deeley]

Hi all.

I've been pulling my hair out over this, I hope you will all laugh at me and
tell me I am stupid for missing something or other:

-BEGIN CODE-
#include <fstream>
...
char* configFilename = "blah";
fstream configFile;
configFile.open( configFilename , std::ios::in , filebuf::sh_read );
...
-END CODE-

That doesn't work and gives the following errors
error C2039: 'sh_read' : is not a member of 'basic_filebuf<char,struct
std::char_traits<char> >'
error C2065: 'sh_read' : undeclared identifier

Now, this is quite interesting because there is an example containing
identical code in the MSDN library[Q92733]...but that's not all - looking up
the value for sh_read I found that it's 05000 so I to put that in and got

-BEGIN CODE-
m_dataFile.open( dataFilename , (std::ios::in | std::ios::out), 05000
/*filebuf::sh_read workaround*/ );
-END CODE-

error C2661: 'open' : no overloaded function takes 3 parameters
same goes for the constructor too

So, can anyone shed any light on this?
Thanks in advance.

Simon Deeley

[Pete Becker]

Simon Deeley wrote:
>
> So, can anyone shed any light on this?
> Thanks in advance.
>

You might try MS's non-standard <iostream.h>. I haven't looked, but
that's the most likely culprit.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)

[Simon Deeley]

>
> You might try MS's non-standard <iostream.h>. I haven't looked, but
> that's the most likely culprit.
>
> --
> Pete Becker

Instant reaction: I changed all occurences of <fstream> to <fstream.h> and
got this
: error C2872: 'fstream' : ambiguous symbol
: error C2027: use of undefined type 'basic_filebuf<char,struct
std::char_tra
: error C2065: 'sh_read' : undeclared identifier
: error C2872: 'ifstream' : ambiguous symbol
: error C2027: use of undefined type 'basic_filebuf<char,struct
std::char_tra
: error C2664: 'class istream &__thiscall istream::seekg(long,enum ios::seek

Hopefully this might give someone a clue (I'm out of ideas and have a
suspicion that I need to sleep on this one)...

[Simon Deeley]

OK, had a good night's sleep and a think...it's obvious that the immediate
problems were due to the global namespace pollution caused by #including
<fstream.h>. There is no such thing as std::ios::in etc they have become
::ios::in atc.
The problem is now solved because ::filebuf::sh_read does exist...I would
still like to know if the problem with the std::fstream has been addressed
before though.
Thanks pete for your help, I dount I would have found a solution so quickly
if it wasn't for your help.

Simon

[Stephen Howe]

Simon Deeley <simondeeley@__SPAM_GUARD__bigfoot.com> wrote in message
news:eZgjhqPbAHA.2108@tkmsftngp05...
>

Microsoft has 2 C++ libraries, the old legacy C++ library which uses header
files like

#include <fstream.h>
#include <iostream.h>
#include <strstream.h>

and the new C++ library which AFAICT, is conformant to ISO C++. Header files
used are

#include <fstream>
#include <iostream>
#include <sstream>

For the legacy library, all symbols are in the global namespace, for the new
library, symbols are in the std namespace. The new headers have new-style
string's and stringstream's. The old libraries provide Microsoft extensions
like sh_read which the new do not. The important point for you is not to mix
libraries. You can have extensions sh_read if you derive from streambuf, add
it and introduce your derived version in the constructor for your fstream
object.

You must decide which library to use. I would use the new libraries unless
you have a large body of legacy code to support.

Stephen Howe