>Key words: "typically" and "most" - that tells you precisely nothing
>about what the C++ standard actually requires. The standard doesn't
>specify the number of bits in any type that isn't a bit-field. (Future

Precisely! You got his point!

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

jukka@liimatta.org wrote:
> >Key words: "typically" and "most" - that tells you precisely nothing
> >about what the C++ standard actually requires. The standard doesn't
> >specify the number of bits in any type that isn't a bit-field. (Future
>
> Precisely! You got his point!

In his first message, his point seemed to be that the C++ standard
needed to be changed just because the ideal size for a file position
indicator is larger on some modern implementations than it used to be
for many older ones. In particular, he seemed to be under the
impression that this difference "drives people into using
platform-dependant I/O". It seems as if he thinks there's some reason
why C++ standard library I/O couldn't be defined on those platforms in
such a way as to use a larger size for the file position indicators. Or
perhaps he believes that it's not possible to write code that could be
compiled on two different platforms to work with C++ standard library
I/O that uses different sizes on each platform. It's not really clear
why he thinks there'd be a portability problem for properly written
code. It's certainly feasible to write code which makes inappropriate
assumptions about such issues, but I don't think it's appropriate to
take badly written C++ code into consideration - there's no limit to
how badly you can write C++ code.

In his second message, his point seemed to be that he felt he had some
legitimate reasons for expecting that C++ standard library file I/O
would be done using 32-bit types.

I "get" his points, in the sense that I understand precisely what's
wrong with them. Did you mean that in any other sense? If so, please
explain.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

I digged up the precise typedef's, here they are:

std::char_traits<char>::pos_type was..
std::streampos was..
std::fpos<_Mbstatet> was..
int

std::char_traits<char>::off_type was..
std::streamoff was..
long

Therein lies in the root of the problem. Sourcecode can be written
around this limitation, in true ad-hoc fashion, and the solution can be
called portable and correct. But what about 64 bit seeks on a platforms
that are capable of this? OK, this one is Microsoft's or Dinkumware's
fault, but I still don't see how this isn't a problem for those who
have to go and write the applications.

I choose to steer clear of the std::fstream, et cetera and I don't
count this as a strength of the std in any way or form. These is a
professionally cool solution, is it a trade secret or can you share it
with us? :)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

I will explain, thank you for asking. What he raises as issue might not
be worded in a way that satisfies you, but I have ran into the same
"problem" quite a many times when working with C++ and large files.
Those are increasingly common these days.

If I use a very common tool, Visual C++ 2005, the offsets through std
are signed 32 bit integers, which is a problem for me. For this purpose
I use WIN32 native I/O functions, which happen to be 64-bit in this
environment. Again, the handling of file I/O is different on other
platforms, therefore, I use filesystem abstraction layer that handles
these issues transparently.

I'm sorry, did you mean, that there is already typedef, which is
incorrectly "configured" in some tools on some platforms? Could that be
fixed, please?

>Or perhaps he believes that it's not possible to write code that could be
>compiled on two different platforms to work with C++ standard library
>I/O that uses different sizes on each platform.

I see. So let's say I have a 6 GB file here, I know my platform (let's
say, Windows XP) can seek with 64 bit offsets, which are more than
adequate for seeking any offset in the file. But the std::fstream
implementation that comes with the compiler (in this case, Visual C++
2005) does only seek up to 2 GB. The platform and hardware can do this
operation, while the software that is supposed to expose this
functionality does not, there seems to be a problem.

So my question to you is, how you propose this operation is done on the
mentioned platform with the mentioned compiler, in a *portable* fashion
that is still *correct* C++ using the Standard libraries only. It might
be trivial, that's why I'm asking if missing something obvious. You
seem to be the man to ask.

I see a problem and solutions that involve re-inventing the wheel. Not
good, but if that is good in your opinion who am I to argue what's good
in your opinion? The answer is pending, if I get a satisfactory answer
I am pleased. If I don't, I am atleast not displeased as things are as
they were yesterday, which wasn't too far from pleasant.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

jukka@liimatta.org wrote:
> I will explain, thank you for asking. What he raises as issue might not
> be worded in a way that satisfies you, but I have ran into the same
> "problem" quite a many times when working with C++ and large files.
> Those are increasingly common these days.
>
> If I use a very common tool, Visual C++ 2005, the offsets through std
> are signed 32 bit integers, which is a problem for me. For this purpose
> I use WIN32 native I/O functions, which happen to be 64-bit in this
> environment.

I only said that it was possible to implement C++ standard file I/O
using the appropriate size for the platform being used. I didn't mean
to imply that MS had actually done so. If they haven't, then what needs
to be changes is Visual C++ 2005, not the C++ standard. Incidentally,
I'm not accusing MS of being the only implementor to make such a
mistake; they're just the one you happened to mention.

.
> I'm sorry, did you mean, that there is already typedef, which is
> incorrectly "configured" in some tools on some platforms? Could that be
> fixed, please?

If you're having problems of that type, it seems likely that the
standard typedefs have been badly implemented on those platforms.
You'll have to ask the implementors for those platforms to fix it, it's
outside the scope of the C++ standard.

> >Or perhaps he believes that it's not possible to write code that could be
> >compiled on two different platforms to work with C++ standard library
> >I/O that uses different sizes on each platform.
>
> I see. So let's say I have a 6 GB file here, I know my platform (let's
> say, Windows XP) can seek with 64 bit offsets, which are more than
> adequate for seeking any offset in the file. But the std::fstream
> implementation that comes with the compiler (in this case, Visual C++
> 2005) does only seek up to 2 GB. The platform and hardware can do this
> operation, while the software that is supposed to expose this
> functionality does not, there seems to be a problem.

Then get Visual C++ 2005 to fix it's implementation of the library.
That will be far more effective than changing the C++ standard to make
a specific size mandatory. If MS doesn't like a given feature of the
C++ standard, they're quite capable of either ignoring it, or in
implementing it so badly that you'll still want to make the mistake of
tieing your code to MS-specific extensions.

> So my question to you is, how you propose this operation is done on the
> mentioned platform with the mentioned compiler, in a *portable* fashion
> that is still *correct* C++ using the Standard libraries only. It might
> be trivial, that's why I'm asking if missing something obvious. You
> seem to be the man to ask.

If an implementor is willing to encourage the creation of portable
code, using the ordinary C++ standard library will open up any type of
file you want to open that can exist on the platform you're using. If
the implementor want to force you to use implementation-specific
extensions that render your code unportable to any implementation other
than they're own, there's nothing the C++ standard can say to prevent a
conforming implementation of C++ from being practically unusable
without resort to those extensions.

There are two fundamental problems with mandating a particular size for
the file offsets. The first problems is that, for any choice you make
today, there are platforms existing right now for which that is not the
right choice; it will be either too big or too small. A platform with a
32KB file space (some platforms in current use have even less) could
create an interface using 64 bits, but it would be unnecessarily
wasteful. This well never go away - there will always be a niche market
for very small systems, and it's useful to be able to use the same
language to program them as for more ordinary systems. The second
problem is that the first problem can only be expected to get worse in
the future. You can be certain that some day, on some platform, sooner
or later, 64 bits will be too small; if somebody told me that this had
already happened, I would only be pleasantly surprised, not
incredulous.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Indeed, I would love to see MS fix this as it is a really nag. One
ad-hoc around this is to implement a seek wrapper which seeks as many
times as necessary to reach the desired offset. Yuck. Or ofcourse, use
the native I/O.

I want to make one clarification: I don't demand 64 bit seeks, but it
would be useful if there was stronger wording to encourage better
implementations. Think of std::vector, std::list, et cetera: they
actually *require* specific "cost" for methods expressed in big-O
notation.

I'm not interested in grass-root movement, though, just expressing my
"Oh Yeah!" as sentiments to agree that there is something rotten in the
state of Denmark (!) regarding the existing practice with large files
and C++, even if the Standard is not at fault, the practise still puts
developers through the hoops: it ain't right.

This is, ofcourse, NOT the Truth - just my opinion. :)

(Generally I'm in pretty positive moods with the compilers I use most:
g++ 4.x series and MSVC, they are light-years ahead of the crap we had
to deal with just a few years ago! So in that respect there is very
little to whine about in general.. opportunities don't knock too
often.. hey while I'm on the soap box, strong typedefs would be cool
but I know.. would break so much legacy code.. but that would be fun
all the same.. thanks!)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

jukka@liimatta.org wrote:
> I want to make one clarification: I don't demand 64 bit seeks, but it
> would be useful if there was stronger wording to encourage better
> implementations.

We could, I think, require 64 bits on platforms where 64 bits are
available.
Simply require the use of an integral type +large enough to hold any
possible offset in a file+. On systems where the file APIs are 32 bits,
all possible offsets will fit in 32 bits. If not, the implementor will
have to
use an appropriate type (e.g. long or long long)

HTH,
Michiel Salters

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michiel.Salters@tomtom.com wrote:
> jukka@liimatta.org wrote:
>
>>I want to make one clarification: I don't demand 64 bit seeks, but it
>>would be useful if there was stronger wording to encourage better
>>implementations.
>
>
> We could, I think, require 64 bits on platforms where 64 bits are
> available.
> Simply require the use of an integral type +large enough to hold any
> possible offset in a file+. On systems where the file APIs are 32 bits,
> all possible offsets will fit in 32 bits. If not, the implementor will
> have to
> use an appropriate type (e.g. long or long long)

    That's appropriate.  A type should be defined for file
positions, and it should be required that it 1) be able to
contain any file position on the platform, and 2) offer the
usual arithmetic operations.  On some platforms, the type
might have to be a class type, but this is C++; not C; we
can do that.

   John Nagle
   Animats

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

<Michiel.Salters@tomtom.com> skrev i meddelandet
news:1138894270.615843.64050@g14g2000cwa.googlegroups.com...
> jukka@liimatta.org wrote:
>> I want to make one clarification: I don't demand 64 bit seeks, but
>> it
>> would be useful if there was stronger wording to encourage better
>> implementations.
>
> We could, I think, require 64 bits on platforms where 64 bits are
> available.
> Simply require the use of an integral type +large enough to hold any
> possible offset in a file+. On systems where the file APIs are 32
> bits,
> all possible offsets will fit in 32 bits. If not, the implementor
> will
> have to
> use an appropriate type (e.g. long or long long)
>

But there isn't any long long type in C++, is there? And on a very
popular compiler, the long type is 32 bits, even in 64 bit mode. Then
what?


Bo Persson


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:L_tEf.49698$PL5.19737@newssvr11.news.prodigy.com...

> Michiel.Salters@tomtom.com wrote:
>> jukka@liimatta.org wrote:
>>
>>>I want to make one clarification: I don't demand 64 bit seeks, but it
>>>would be useful if there was stronger wording to encourage better
>>>implementations.
>>
>>
>> We could, I think, require 64 bits on platforms where 64 bits are
>> available.
>> Simply require the use of an integral type +large enough to hold any
>> possible offset in a file+. On systems where the file APIs are 32 bits,
>> all possible offsets will fit in 32 bits. If not, the implementor will
>> have to
>> use an appropriate type (e.g. long or long long)
>
>    That's appropriate.  A type should be defined for file
> positions, and it should be required that it 1) be able to
> contain any file position on the platform, and 2) offer the
> usual arithmetic operations.  On some platforms, the type
> might have to be a class type, but this is C++; not C; we
> can do that.

You could even call it std::fpos<char>.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

jukka@liimatta.org wrote:
.
> I want to make one clarification: I don't demand 64 bit seeks, but it
> would be useful if there was stronger wording to encourage better
> implementations.

Encouragement of bettter implementations is outside the scope of the
standard, and properly so. Standards are for mandating or prohibiting
things. Encouragement of higher implementation quality is something
that should appear in editorials and customer complaints, not
standards.

The C++ standard allows a wide range in qualify of implementation, and
I think that's a good thing, and therefore probably deliberate. By not
over-specifying the quality, the standard allows a quick-and-dirty, low
quality but completely conforming implementation for a new platform to
be completed fairly quickly, while allowing for improvement at a later
time.

> ... Think of std::vector, std::list, et cetera: they
> actually *require* specific "cost" for methods expressed in big-O
> notation.

It needs to do so, because it is the difference in those "costs" that
is the prime motivator for having several different standard
containers. Developers need that information, in order to decide which
standard container (if any) is appropriate to the task at hand.

Notice that the standard uses ony the big-O notation; it does not get
any more specific about the costs. This is an example of the standard
avoiding specifying anything more than the absolute minimum that it has
to.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Bo Persson" wrote:
> <Michiel.Salters@tomtom.com> skrev i meddelandet
> news:1138894270.615843.64050@g14g2000cwa.googlegroups.com...
.
> > We could, I think, require 64 bits on platforms where 64 bits are
> > available.
> > Simply require the use of an integral type +large enough to hold any
> > possible offset in a file+. On systems where the file APIs are 32
> > bits,
> > all possible offsets will fit in 32 bits. If not, the implementor
> > will
> > have to
> > use an appropriate type (e.g. long or long long)
> >
>
> But there isn't any long long type in C++, is there? And on a very
> popular compiler, the long type is 32 bits, even in 64 bit mode. Then
> what?

Then imposing that restriction would render that compiler
non-conforming. There wouldn't be much need to add a requirement, if
every existing implementation already satisfied it. If that restriction
were added to the standard, the makers of that compiler would have to
choose between giving up on conformance, or adding a 64-bit integer
type.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

<kuyper@wizard.net> skrev i meddelandet
news:1138978693.618115.240060@g49g2000cwa.googlegroups.com...
> "Bo Persson" wrote:
>> <Michiel.Salters@tomtom.com> skrev i meddelandet
>> news:1138894270.615843.64050@g14g2000cwa.googlegroups.com...
> .
>> > We could, I think, require 64 bits on platforms where 64 bits are
>> > available.
>> > Simply require the use of an integral type +large enough to hold
>> > any
>> > possible offset in a file+. On systems where the file APIs are 32
>> > bits,
>> > all possible offsets will fit in 32 bits. If not, the implementor
>> > will
>> > have to
>> > use an appropriate type (e.g. long or long long)
>> >
>>
>> But there isn't any long long type in C++, is there? And on a very
>> popular compiler, the long type is 32 bits, even in 64 bit mode.
>> Then
>> what?
>
> Then imposing that restriction would render that compiler
> non-conforming.

But it isn't right now. The standard requires a compiler to provide 32
bit integers, but nothing much else.

Also, the "popular compiler" runs on an equally popular OS, which has
64 bit file offsets even in its 32 bit API.

> There wouldn't be much need to add a requirement, if
> every existing implementation already satisfied it. If that
> restriction
> were added to the standard, the makers of that compiler would have
> to
> choose between giving up on conformance, or adding a 64-bit integer
> type.

They have chosen to not give up neither conformance, nor backward
compatibility. At the same time they have added a 64 bit non-standard
integer type (or two, actually :-).

That doesn't help the standard library though, as it is defined in
terms of the standard types. It is hard for the standard to require a
non-standard type in the library interface.  :-)


Bo Persson


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1138914784.248532.69660@g47g2000cwa.googlegroups.com>,
kuyper@wizard.net writes
>Encouragement of bettter implementations is outside the scope of the
>standard, and properly so. Standards are for mandating or prohibiting
>things. Encouragement of higher implementation quality is something
>that should appear in editorials and customer complaints, not
>standards.

Actually 'Standardese' allows the usage of 'should' to encourage but not
require something.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Bo Persson" wrote:
> <kuyper@wizard.net> skrev i meddelandet
> news:1138978693.618115.240060@g49g2000cwa.googlegroups.com...
> > "Bo Persson" wrote:
> >> <Michiel.Salters@tomtom.com> skrev i meddelandet
> >> news:1138894270.615843.64050@g14g2000cwa.googlegroups.com...
> > .
> >> > We could, I think, require 64 bits on platforms where 64 bits are
> >> > available.
> >> > Simply require the use of an integral type +large enough to hold
> >> > any
> >> > possible offset in a file+. On systems where the file APIs are 32
> >> > bits,
> >> > all possible offsets will fit in 32 bits. If not, the implementor
> >> > will
> >> > have to
> >> > use an appropriate type (e.g. long or long long)
> >> >
> >>
> >> But there isn't any long long type in C++, is there? And on a very
> >> popular compiler, the long type is 32 bits, even in 64 bit mode.
> >> Then
> >> what?
> >
> > Then imposing that restriction would render that compiler
> > non-conforming.
>
> But it isn't right now. The standard requires a compiler to provide 32
> bit integers, but nothing much else.

You asked what would happen if the standard were changed to require
that the file offset type be a type big enough to represent distinctly
every possible file offsets. Well, that renders any implementation that
doesn't provide a type that's big enough to meet that requirement
non-conforming. What's you're point? If there's any point at all to
adding a requirement to the standard, it's to render existing
implementations that don't meet that requirement non-conforming,
thereby pressuring the implementors to change it to meet that
requirement. If it isn't the desire of the committee to pressure that
implementation (and others like it) to provide a type big enough to
store all possible file offsets, then it shouldn't approve this
suggested change.

> Also, the "popular compiler" runs on an equally popular OS, which has
> 64 bit file offsets even in its 32 bit API.

That sounds to me like a good reason to pressure the implementation
into providing a 64 bit API.

> > There wouldn't be much need to add a requirement, if
> > every existing implementation already satisfied it. If that
> > restriction
> > were added to the standard, the makers of that compiler would have
> > to
> > choose between giving up on conformance, or adding a 64-bit integer
> > type.
>
> They have chosen to not give up neither conformance, nor backward
> compatibility.

I wrote that sentence using the FUTURE subjunctive: I was describing a
possible future situation. Of course they haven't made any decision yet
as to how to deal with this change to the standard; the change has only
been proposed, and only on a newsgroup. As far as I can tell, it hasn't
even been put before the committee for consideration. So the
implementation you're talking about does not YET have to decide between
conformance and backward compatibility. In the unlikely event that such
a change is approved, then they would have to decide; the fact that
they haven't decided yet is irrelevant; they probably haven't even
heard about this proposal.

> At the same time they have added a 64 bit non-standard
> integer type (or two, actually :-).

Why did they do that? There's enough different standard types to
support every popular integer size from 8 bits to 64 bits. I hope that
they at least named their non-standard types to conform to the C99
standard; those types are likely to make it into the next version of
the C++ standard.

> That doesn't help the standard library though, as it is defined in
> terms of the standard types. It is hard for the standard to require a
> non-standard type in the library interface.  :-)

It is, on the other hand, perfectly feasible for the standard to allow
for non-standard types. Any time there's a standard library typedef
(such as time_t or size_t or fpos_t), it's perfectly feasible for an
implementation to define it as a non-standard type, so long as it meets
all the applicable requirements, except where the standard specifically
says otherwise.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Lasse K   rkk   inen / Tronic wrote:
> Hi,
>
> While people are getting all excited of new features that will extend the
> language, I'm more worried about basic stuff that is important in a very
> large number of applications: file I/O.
>
> 1) 64 bit (or large enough) addressing on 32 bit systems. Files obviously
> are getting bigger and 32 bit addressing simply isn't enough anymore and
> the situation is only getting worse. This drives people into using
> platform-dependant I/O and thus makes even simple CLI applications unportable.

Nothing in the C++ standard specifies how many bits there are in an
int, long, size_t etc.

Best option is to define your own traits class (which you can use only
for big files) with these definitions:

#if defined _WIN32
    typedef __int64 off_type;
#elif defined _WIN64
    typedef __int64 off_type;
#else
    typedef long long off_type;
#endif

or whatever fits the platforms you are writing for.

(I do think that there should be an integral type in the standard that
is at least 8 bytes).


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Where did you read that C++ file size was specified to 32 bits ?

cplusplus.com reference suggests that streamoff is typically long, and
long is 32 bits on most (if not all) 32 bit platforms. However, it would
seem that glibc (or libstdc++), at least, actually uses long long for that
and thus the addressing works exactly the way it should.

However, I wonder if I should still be expecting portability problems when
porting my software to other operating systems.

- Tronic -

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Lasse K   rkk   inen / Tronic wrote:
> > Where did you read that C++ file size was specified to 32 bits ?
>
> cplusplus.com reference suggests that streamoff is typically long, and
> long is 32 bits on most (if not all) 32 bit platforms.

Key words: "typically" and "most" - that tells you precisely nothing
about what the C++ standard actually requires. The standard doesn't
specify the number of bits in any type that isn't a bit-field. (Future
versions will probably support the C99 size-named types, or something
very similar in effect, but AFAIK that hasn't been made official yet).
Since it doesn't specify the size of streamoff, the standard doesn't
need to be changed when the best size for streamoff changes. What might
need to change is the typedef statement that defines streamoff. Your
code shouldn't make unwarranted assumptions about the characteristics
of the type that streamoff refers to.

> However, I wonder if I should still be expecting portability problems when
> porting my software to other operating systems.

Yes, you should expect problems. If you're not fully aware of precisely
what the standard actually requires, and what it doesn't, your code
almost certainly makes some assumptions that may be be false on the
system you're trying to port to. Even if you do know what's required by
the standard, you may still stumble over portability issues that have
nothing to do with the standard.


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Earl Purple wrote:
> Lasse K   rkk   inen / Tronic wrote:
> > Hi,
> >
> > While people are getting all excited of new features that will extend the
> > language, I'm more worried about basic stuff that is important in a very
> > large number of applications: file I/O.
>
> Best option is to define your own traits class (which you can use only
> for big files) with these definitions:
>
> #if defined _WIN32
>     typedef __int64 off_type;
> #elif defined _WIN64
>     typedef __int64 off_type;
> #else
>     typedef long long off_type;
> #endif
>
> or whatever fits the platforms you are writing for.

That won't help if the OS or the C++ library vendor keep the file API's
at 32 bits.
And if both provide proper 64-bits APIs, the TS doesn't need your
classes.

HTH,
Michiel Salters


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michiel.Salters@tomtom.com wrote:
> Earl Purple wrote:
> > Lasse K   rkk   inen / Tronic wrote:
> > > Hi,
> > >
> > > While people are getting all excited of new features that will extend the
> > > language, I'm more worried about basic stuff that is important in a very
> > > large number of applications: file I/O.
> >
> > Best option is to define your own traits class (which you can use only
> > for big files) with these definitions:
> >
> > #if defined _WIN32
> >     typedef __int64 off_type;
> > #elif defined _WIN64
> >     typedef __int64 off_type;
> > #else
> >     typedef long long off_type;
> > #endif
> >
> > or whatever fits the platforms you are writing for.
>
> That won't help if the OS or the C++ library vendor keep the file API's
> at 32 bits.
> And if both provide proper 64-bits APIs, the TS doesn't need your
> classes.

It has helped me with files that are between 2 GB and 4GB. You'd need
an O/S change to allow files of more than 4GB.


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Earl Purple a    crit :

> (I do think that there should be an integral type in the standard that
> is at least 8 bytes).

long long must be at least 64 bits, but that's C99.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

While people are getting all excited of new features that will extend the
language, I'm more worried about basic stuff that is important in a very
large number of applications: file I/O.

1) 64 bit (or large enough) addressing on 32 bit systems. Files obviously
are getting bigger and 32 bit addressing simply isn't enough anymore and
the situation is only getting worse. This drives people into using
platform-dependant I/O and thus makes even simple CLI applications unportable.

2) File locking is pretty much essential for applications running in
multitasking environments. Sure, not every system supports it at all, and
not every system allows per-byte access control, but even having some very
basic functionality (lock entire files against writing or both writing and
reading) would help a lot.

3) Non-blocking or async I/O. Quite difficult to implement due to immature
OS support. Also not strictly required, as multi-threading (separate I/O
threads) can work around most of the problems. Unbuffered text console
reading is a related problem (should be possible to read single
keystrokes, instead of complete lines only).

Have these issues been considered for the next standard?

- Tronic -

Please CC me on replies.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Lasse K=C3=A4rkk=C3=A4inen / Tronic a =C3=A9crit :

> 1) 64 bit (or large enough) addressing on 32 bit systems. Files obvious=
ly
> are getting bigger and 32 bit addressing simply isn't enough anymore an=
d
> the situation is only getting worse. This drives people into using
> platform-dependant I/O and thus makes even simple CLI applications unpo=
rtable.


Where did you read that C++ file size was specified to 32 bits ?

--=20
Lo=C3=AFc

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]