Re: How to get filename from path in C++
Alf P. Steinbach wrote:
* Bo Persson:
Andreas Dehmel wrote:
On Wed, 22 Jul 2009 01:46:21 +0200, Bo Persson wrote:
Andreas Dehmel wrote:
On Tue, 21 Jul 2009 15:55:39 +0200, Bo Persson wrote:
[...]
But it is a rather bad standard, if it is not implementable on
some systems. The C and C++ standards go to great lengths not
to require specific pointer formats, 32 bit ints, or IEEE
floating point, because it is known that important systems out
there can't support it.
You seem to suggest that by leaving lots of fundamental concepts
implementation-defined the standard becomes more usable or
something.
Yes, by not specifying everything down to the last bit, the
language is actually usable on a wider range of machines.
There's a big difference between "defining everything down to the
last bit" and defining an absolute minimum to make the library
usable at
all. Not defining character encodings in any way nor providing
interfaces to access files/directories in a portable manner simply
makes anything string- or IO related in the standard library
unusable if you need it
to work on systems like Windows on non-8-bit locales (which, with
China and India alone are more than 2 billion potential users).
This isn't about Windows at all, but on 8-bit locales using
encodings like EBCDIC.
The z/OS uses 'dataset' names (not files) that can look like
USERID.PROJECT.LEVEL.TYPE(FILENAME)
for my files. How does that fit Windows or Linux names?
Nobody there
can use what the standard library provides in these areas, nor can
anyone developing with these regions in mind. The Standard
Committe finally realized that themselves and added Unicode to
C++0x -- but it's already way too late and by the time
production-quality C++0x-compilers will
be available I doubt there'll be many people left who need this
and haven't already adopted alternative solutions.
Another "totally portable" language needs special hardware
add-ons to run on some machines where C++ runs natively:
For the primitive concepts like char encodings and file system
access
or even directories we're talking about here? You've got to be
joking.
No. The hardware add-on is mainly for providing IEEE floating
point to an architecture that pre-dates Java and floating point
standards by 20-30 years.
Why would anyone standardize a language that isn't implementable on
machines that has been around since the 1960's? They are
competitors of course, but anyway?
Oh, and the z/OS doesn't have directories but a central Catalog for
global files. Local files are, eh - local - and not known to other
programs. Did I mention the EBCDIC problem?
Your points have been addressed previously in the thread.
Some machines don't have anything "standard" that the standard
streams can map to: it's not a valid argument against having
standardized access to the standard streams, which we do have
(although mostly in a very inadequate form).
There is support for streams, just not for '/' or '\' separated paths
or file names using ASCII or UTF-8. That makes it very hard for a
language standard to require that.
Similarly, the EBCDIC argument is null and void, like other "let's
ensure we support ENIAC, that's a must" arguments: it's simply not
relevant.
EBCDIC is very relevant for the companies using IBM mainframes. They
might not be that many, but that the are generally large
multi-national organizations. Should the C++ standard ignore them?
And more generally, the argument that "I'm personally unable to see
a way to do this" isn't an argument, it's just an observation of
one's own limitations.
Could be. But it is also a hint to the standards committee to look
into this, and assure that I am wrong so the language is really
implementable on the widest set of hardware. Ignoring IBM hardware
seems sub-optimal.
Especially in the face of several counter-examples such arguments
are really annoying, because there's almost no way to counter them
without sounding a bit personal. Like, oh, you're one of those who
haven't heard of Java? Well, it's a programming language, and it
does support those kinds of things, successfully...
Even though C++1x will have some "conditionally supported" features, I
don't see a great advantage of adding file and path support, which is
known NOT to work on most non-Windows/non-*nix systems.
Bo Persson