I recently started porting all my old C++  code into
ANSI/ISO C++ and I am facing some serious problems.

For locking  files, I was using the following method:

// lock 10 bytes of the file starting at offset 100
fstream input("filename.txt",ios::in|ios::out|ios::binary,SH_DENYNO);
file.seekp(100);
 _locking(input.rdbuf()->fd(),_LK_LOCK,10);    // in VC++

However, this doesn't work with standard C++ library.
There is no way to get the file descriptor from the std::fstream.
std::file_buf does not support fd() any more.

I couldn't find any other way to lock a file in ANSI/ISO C++.
So, I am stuck with the good old fstream for now. I somehow
can't believe that such a important feature can be left out of
the standards. So, how does one lock files using standard C++ ???

--
Thanks & Regards,
Sharath K Shetty




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sharath K Shetty <sharath@ilinknet.com> writes:

>I recently started porting all my old C++  code into
>ANSI/ISO C++ and I am facing some serious problems.
>For locking  files, I was using the following method:

>// lock 10 bytes of the file starting at offset 100
>fstream input("filename.txt",ios::in|ios::out|ios::binary,SH_DENYNO);
>file.seekp(100);
> _locking(input.rdbuf()->fd(),_LK_LOCK,10);    // in VC++

>However, this doesn't work with standard C++ library.
>There is no way to get the file descriptor from the std::fstream.
>std::file_buf does not support fd() any more.

>I couldn't find any other way to lock a file in ANSI/ISO C++.
>So, I am stuck with the good old fstream for now. I somehow
>can't believe that such a important feature can be left out of
>the standards. So, how does one lock files using standard C++ ???

File locking must have been a feature of the particular compiler
you were using. I've never seen it in any implemention I've used,
nor was it in the original implemention of "classic" iostreams
from AT&T.

Getting a file descriptor as a small integer is a common
extension. It is not part of standard C, for example, although
it was in the original iostreams. As far as I remember, no
version of the draft C++ standard supported it.

I would expect a compiler to continue to support extenstions
it used to provide, but you can't count on using such
extensions in portable code.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sharath K Shetty <sharath@ilinknet.com> wrote in article <35D9B0D4.A2879B8B@ilinknet.com>...
> There is no way to get the file descriptor from the std::fstream.
> std::file_buf does not support fd() any more.
>
> I couldn't find any other way to lock a file in ANSI/ISO C++.
> So, I am stuck with the good old fstream for now. I somehow
> can't believe that such a important feature can be left out of
> the standards. So, how does one lock files using standard C++ ???

I tried on more than one occasion to make visible the connection between
C FILE objects and C++ iostream objects in the C++ Standard, but each
time someone else insisted that no such visible link should exist. (The
connection between a FILE object and a file descriptor is a nonstandard
extension common to many Standard C libraries.)

VC++ does have one nonstandard (but conforming) extension you can
use to advantage. First open the file using fopen, then construct your
iostream object from that with an added constructor, as in:

FILE *pf = fopen("myfile", "r")
filebuf mybuf(pf);
istream mystream(&mybuf);

Hope this helps.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com/hot_news.html



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
P.J. Plauger (pjp@dinkumware.com) wrote:
> Sharath K Shetty <sharath@ilinknet.com> wrote in article
<35D9B0D4.A2879B8B@ilinknet.com>...
> > There is no way to get the file descriptor from the std::fstream.
> > std::file_buf does not support fd() any more.
> >
> > I couldn't find any other way to lock a file in ANSI/ISO C++.
> > So, I am stuck with the good old fstream for now. I somehow
> > can't believe that such a important feature can be left out of
> > the standards. So, how does one lock files using standard C++ ???
>
> I tried on more than one occasion to make visible the connection between
> C FILE objects and C++ iostream objects in the C++ Standard, but each
> time someone else insisted that no such visible link should exist.

In general, there is no connection between C files and C++ iostreams. The
only iostreams which are really connected in some way (namely after
calling 'ios_base::sync_with_stdio(true)') with stdio files are the
eight standard streams. Thus, it would be an additional restriction to
establish such a connection! Of course, your implementation would not
suffer from any problems since you are implementing IOStreams in terms
of stdio anyway. However, this is neither required nor necessarily the
best approach. For example, I think that it is reasonable to implement
it exactly the other way around: Implement stdio in terms of IOStreams.
Some reasons for me doing this are that this would allow C users
to write to new external representations using 'fprintf()' (when
implementing IOStreams in terms of stdio, this would require that the
stdio functions would use a documented abstraction which is not the
case in any implementation I have seen), the functions could use user
defined locales (currently this is only possible in a very limited
way by supplying suitable files in the directory where the locale data
is searched and it is not standardized at all), and I can imagine that
certain operations are more efficient (mainly due to the locale definition
to use streambuf iterators), at least if locales are used.

> (The
> connection between a FILE object and a file descriptor is a nonstandard
> extension common to many Standard C libraries.)

So what is the point in exposing a 'FILE'? You still have to rely on
system specific features and it is also common to expose a file descriptor
in 'filebuf', at least on systems supporting file descriptors: There is
no point in the indirection. ... and providing a corresponding method can
also be done in a standard conforming fashion, eg. by naming it '_FD()'.

The only thing the standard might be blamed for is for not providing
access to the underlying system resource, eg. a file descriptor on POSIX
systems: I would expect that all system provide some mechanism and there
could be typedef for, say, 'filehandle_type' in 'filebuf' (and family)
defining the return type of a function 'filehandle()' and the argument
for a constructor and/or the 'open()' function.

> VC++ does have one nonstandard (but conforming) extension you can
> use to advantage. First open the file using fopen, then construct your
> iostream object from that with an added constructor, as in:

One feature of libraries is that they should provide a compatibility mode
which guarantees at least source compatibility (that is, it should be
possible to compile code written for older version of the library). For
methods this is at first sight not that easy because you need to strip
them off the class to be standard conforming. However, using macros (yuk)
this can be done although the macros obvious pollute the global namespace
(which may be a bigger problem than using a new name for an old function).
When replacing one implementation of the standard library by another one
even the new implementation should support old functions. This also holds
if the new code is from another creator of the library. MS apparently
choose not to support their old interface... Note: I'm not blaming
Dinkumware for this but MS!
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35D9B0D4.A2879B8B@ilinknet.com>,
  Sharath K Shetty <sharath@ilinknet.com> wrote:
>
> I recently started porting all my old C++  code into
> ANSI/ISO C++ and I am facing some serious problems.
>
> For locking  files, I was using the following method:
>
> // lock 10 bytes of the file starting at offset 100
> fstream input("filename.txt",ios::in|ios::out|ios::binary,SH_DENYNO);
> file.seekp(100);
>  _locking(input.rdbuf()->fd(),_LK_LOCK,10);    // in VC++
>
> However, this doesn't work with standard C++ library.
> There is no way to get the file descriptor from the std::fstream.
> std::file_buf does not support fd() any more.
>
> I couldn't find any other way to lock a file in ANSI/ISO C++.
> So, I am stuck with the good old fstream for now. I somehow
> can't believe that such a important feature can be left out of
> the standards. So, how does one lock files using standard C++ ???

The same way you always did in standard C, and in earlier versions of
C++: use an implementation specific extension.  Neither C nor C++ have
ever had any support for either file locking or file descriptors;
traditionally, implementors under UNIX and Windows (and before that
MS-DOS) have provide the file descriptor support as an extension,
and under UNIX at least, you could use the file descriptor to implement
locking (although the way to do so tended to vary between UNIXes).

So, although the standard doesn't support filebuf::fd, if earlier
implementations did, and the new one doesn't, I'd complain very loudly
to the vendor.  The standard doesn't say anything about backwards
compatibility, but quality of implementation certainly does, and only
a very irresponsible vendor would remove filebuf::fd() if earlier
versions supported it.  However, be very aware that anything involving
file descriptors or locking is implementation dependant, and isolate
it as much as possible.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6rejal$b0b$1@nnrp1.dejanews.com>,
  dietmar.kuehl@claas-solutions.de wrote:
>
> MS apparently
> choose not to support their old interface... Note: I'm not blaming
> Dinkumware for this but MS!

Why blame anyone?  Somewhere, there was a communications failure, Microsoft
forgot to specify, or Dinkumware overlooked a requirement in the specification
(and Microsoft forgot to verify it).  These things happen, all too frequently.
(I don't say this to justify either of the parties, but rather to suggest
a preferred action path when you find yourself in a similar situation.)

Of course, now that the error has been pointed out, if they don't do
anything to correct it, or don't recognize it as an error, one can start
blaming.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]