C++0x and file I/O

[Guest]

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.

Have these issues been considered for the next standard?

- Tronic -

Please CC me on replies.

 

[Ian Collins]

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.

You might be better off posting this to comp.std.c++.

 

[Earl Purple]

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.

I have managed to solve that problem though by using my own traits
class which uses 64-bit streampos and streamoff. It wasn't good enough
to make it unsigned. What would be good however would be standard types
that are guaranteed to be at least 64 bits.

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.

No reason why every system eg a device driver should even have a
concept of a file. However the language does support file I/O, but
adamantly refuses to support GUI or threads. And of course C++ has no
concept of a network, or any network protocols (including the
internet).

Hey, there is no standard way to open a file for read and write at any
place, creating the file if it doesn't exist without wiping the current
contents. Well yes the workaround is first to open with app then close
again then open without app. And there's no standard way to create the
directory path if it doesn't already exist, in fact there's no such
thing as a directory.

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.

This can be implemented with what we already have.

Have these issues been considered for the next standard?

Well there is boost::filesystem but will it become standard? I don't
know.

 

[JustBoo]

You might be better off posting this to comp.std.c++.

OMG. (8-O) Telling the guy to go to a DEAD newsgroup. This is getting
just ridiculous.

I don't know the answer to your question (I wish I did) and obviously
Ian doesn't either. All the "heavy weights" that could answer that
question have left this sad snake-pit of a newsgroup. Hmm... I wonder
why? All we're left with is Traffic Cops and Russian Mafia wannabes.

"comp.lang.c++.moderated" would be you're best bet. A few of the
"biggies" that attend the Standards meetings still post there.

Good Luck

MyopicPettyBureaucrat = LanguageLawyer += NetCop;

 

[Pete Becker]

OMG. (8-O) Telling the guy to go to a DEAD newsgroup. This is getting
just ridiculous.

I don't know the answer to your question (I wish I did) and obviously
Ian doesn't either. All the "heavy weights" that could answer that
question have left this sad snake-pit of a newsgroup. Hmm... I wonder
why? All we're left with is Traffic Cops and Russian Mafia wannabes.

"comp.lang.c++.moderated" would be you're best bet. A few of the
"biggies" that attend the Standards meetings still post there.

Some of the "biggies" who attend the standards meetings post here, too.
But comp.std.c++ is still the best place to pose questions related to
what's coming up in the future.

 

[JustBoo]

Some of the "biggies" who attend the standards meetings post here, too.

Well, not like it used to be, by any measure. But, time marches on,
people move on. That's li... well, one can't really use the analogy of
life to usenet can one.

But comp.std.c++ is still the best place to pose questions related to
what's coming up in the future.

Okay, I guess I became confused by having two messages a week show up
in comp.std.c++.

Does that say anything about new features in c++?

However beautiful the strategy, you should occasionally
look at the results. - Winston Churchill

 

[Ian Collins]

OMG. (8-O) Telling the guy to go to a DEAD newsgroup. This is getting
just ridiculous.

comp.std.c++ isn't dead and is the group for questions relating to the
thinking behind the standard and its future.

 

[Ian Collins]

Okay, I guess I became confused by having two messages a week show up
in comp.std.c++.

Does that say anything about new features in c++?

Odd, I see at least 20 a day.

 

[Clark S. Cox III]

Well, not like it used to be, by any measure. But, time marches on,
people move on. That's li... well, one can't really use the analogy of
life to usenet can one.


Okay, I guess I became confused by having two messages a week show up
in comp.std.c++.
Does that say anything about new features in c++?

I've seen 13 messages there so far today

 

[Bo Persson]

JustBoo wrote:
comp.std.c++ isn't dead and is the group for questions relating to
the thinking behind the standard and its future.

It's not at all dead, but it actually was in sort a coma over the New
Year, when all the moderators were absent at the same time.

The patient has slowly recovered since.


Bo Persson

 

[Ian Collins]

It's not at all dead, but it actually was in sort a coma over the New
Year, when all the moderators were absent at the same time.

The patient has slowly recovered since.

Ah yes, the famous "oops we were all on holiday at the same time and all
posts got lost" post....