How to get filename from path in C++

[Bo Persson]

But it has Java (see same page) which incidentally has the standard
API for dividing a file name onto directory and file name proper
and more. I guess this system is simply not exotic enough.. .

Yes, but it runs Java in a virtual Linux partition to solve that part.

It can run C++ there as well if you want to, but C++ programs can also
be compiled for the native z/OS partition with EBCDIC filenames
(without paths) and non-IEEE floating point. Java isn't portable
enough to do that.


Bo Persson

 

[Andreas Dehmel]

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). 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.

http://www-03.ibm.com/systems/z/advantages/zaap/index.html



What makes you think that you run command lines on all systems? Not
everything is a desktop.

What makes you think there's a floating point unit on all systems (like
most ARM-based systems for one)? By your logic, the C/C++-standard should
not define floating point numbers in any way. There are no doubt also
systems out there which have no file system, so why support IO at all?
Go ahead, make to _totally_ useless while you're at it...

Yes, Qt claims "Portability across desktop and embedded systems". What
about everyting else?

What about it? Provided the standard defines a few fundamental things
rather than weasling out with "implementation-defined" left right and
center, implementers on exotic platforms will have more work on their
hands to provide a standard-compliant implementation or live with a
non-standard-compliant implementation. Is that a problem? I don't
think so. Having the standard library modelled after the dumbest
possible system and thereby severely compromising its usability on
the majority of systems, on the other hand, is a huge problem.

This system doesn't even have a GUI:

http://www-03.ibm.com/systems/z/hardware/

And? For instance Qt4's core library (including strings/file system etc.)
doesn't require a GUI. Nor did I claim the standard should define a GUI,
by the way...



Andreas

 

[Bo Persson]

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.



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?


Bo Persson

 

[Alf P. Steinbach]

* Bo Persson:

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.


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).

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.

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.

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...


Cheers & hth.,

- Alf

 

[Aaron Gray]

As has been pointed out, other systems have different
conventions. This is the sort of thing that needs to be in a
system dependent library (like the standard library).

Hve been waiting for that and socket library for over 10 years !

Aaron

 

[James Kanze]

* Bo Persson:
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).

The standard supports hosted and free-standing implementations.
If there's nothing standard streams can map to, the
implementation is free-standing.

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.

Maybe to you. I've had to deal with EBCDIC in the not too
distant past, and I know of people who have to deal with it
today. It's very relevant, today.

IMHO, it would be a serious error for C++ to impose one
particular encoding---I use at least two different ones (ISO
8859-1 and UTF-8) on a daily basis. And I know people who also
use EBCDIC on a daily basis.

 

[Alf P. Steinbach]

* James Kanze:

The standard supports hosted and free-standing implementations.
If there's nothing standard streams can map to, the
implementation is free-standing.


Maybe to you. I've had to deal with EBCDIC in the not too
distant past, and I know of people who have to deal with it
today. It's very relevant, today.

Which post-standard C++ compiler has EBCDIC as base character set?


- Alf

 

[Andreas Dehmel]

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.

Which has exactly nothing to do with any encoding(s) defined by the
standard. The standard could define a fixed all-encompassing encoding
like UTF-8 and thus require systems using a different native encoding
to transcode in the standard library. Alternatively, the standard could
define a set of standard encodings (e.g US-ASCII, ISO-8859-x, UTF-8 and
maybe even EBCDIC for the dinosaurs) which have to be supported and are
selectable with e.g. locale settings. I really have no idea where you see
any problems even worth mentioning.

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?

Why would it have to fit them? It's still just a simple tree structure,
like all filesystems I've come across are. With an object-oriented approach
(be it in C or C++) you could easily abstract all these filesystems and
work with them without ever needing to know what the directory separator
is, what the file/MIME-type of an entry is etc. You could even use the same
abstraction to work with a PKZIP archive without ever having to know it's
an image file rather than a real directory. Systems without subdirectories?
The standard library will simply never return "type=directory" for anything
but the root object. Systems without filesystem? Any attempt to open a
file or directory will return invalid. Again: I have no idea where you see
any problems with standardizing/abstracting any of this.


[...]

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.

You can usually also do that in software, although it'll be a lot
slower of course; I know systems where this is the way to get floating
point support. What does that have to do with standardization? All
you're saying is that anything exotic/stone-age hardware can't do natively
can't be put in the C/C++-standard, which is really beyond ridiculous.

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?

That's pretty much like saying ``why would anyone write a game that
doesn't work on a C64''. You want nothing but the minimum common
denominator in the standard, which only means that any old crap can
claim standard-compliance with a mostly useless standard. I want the
standard to abstract features found on the majority of systems because I
think it's a travesty I have to use external libraries just to get the
most fundamental things like portable filesystem-access. And this
discussion really seems to go nowhere...



Andreas

 

[Bo Persson]

* James Kanze:

Which post-standard C++ compiler has EBCDIC as base character set?

The IBM C++ compiler for z/OS - surprise?

http://www-01.ibm.com/software/awdtools/czos/



Bo Persson

 

[Bo Persson]

* Bo Persson:

On Wed, 22 Jul 2009 01:46:21 +0200, Bo Persson wrote:

Andreas Dehmel 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

 

[Bo Persson]

That's pretty much like saying ``why would anyone write a game that
doesn't work on a C64''. You want nothing but the minimum common
denominator in the standard, which only means that any old crap can
claim standard-compliance with a mostly useless standard. I want the
standard to abstract features found on the majority of systems
because I think it's a travesty I have to use external libraries
just to get the most fundamental things like portable
filesystem-access. And this discussion really seems to go nowhere...

So you are saying that it seems like a good idea to have a language
standard that IBM cannot implement on their systems? Forcing them to
use non-standard extensions?


Please remind me, what is the idea behind having a global standard?


Bo Persson

 

[Alf P. Steinbach]

* Bo Persson:

The IBM C++ compiler for z/OS - surprise?

No, it was a rhetorical question.

I gather that the person I addressed that question to understood that.

http://www-01.ibm.com/software/awdtools/czos/

Note that this (only) compiler has quite extensive support for ASCII-based
character encodings -- it does not require using EBCDIC even for creating
EBCDIC environment programs.


Cheers & hth.,

- Alf

 

[Alf P. Steinbach]

* Bo Persson:

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.

That's a strawman argument. Nobody has suggested doing anything so inane.

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?

Yes.

There are all sorts of other factors that means they're already using an
extensive set of tool and environment adaptions.

There's no point in the C++ standard castrating itself to support ENIAC while
the ENIAC guys are moving away from ENIAC as fast as they can...

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.

Actually, with repect to hardware ignoring IBM's (I think) and some others' is
just what the standard, very reasonably, does, e.g. by requiring at least 8 bits
for 'char'.

The problem with IBM is that it has caused customers to have a lot of business
data stored with obsolete encodings and obsolete formats: not just 1 such but a
phletora of largely incompatible ones (e.g., there's no single EBCDIC). This was
a business decision, starting all the way back in 196x when Lyndon B. Johnson
required ASCII for all new US government computers, and IBM, who participated in
the ANSI committee, decided to go their own way. It was a decision with some
known risk, and the cost of that decision has been paid over the years, and is
still being paid (with the final huge down-payment perhaps not yet in sight),
but it's a cost to be paid by those who took the risk, not by the C++ standard.

The only rational thing to do, IMHO, is to do the same with dinosaur data as
with dinosaur hardware architectures: let them evolve, as most of them struggle
to do. It was their decision to remain in the pre-historic habitat. The best way
to support them is to make sure that they understand that they're largely on
their own as long as they obstinately remain there.

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.

No, that is the "I can't see how to do it" argument.


Cheers & hth.,

- Alf

 

[Pavel]

Yes, but it runs Java in a virtual Linux partition to solve that part.

It can run C++ there as well if you want to, but C++ programs can also
be compiled for the native z/OS partition with EBCDIC filenames
(without paths) and non-IEEE floating point. Java isn't portable
enough to do that.


Bo Persson

I am not sure why you are saying that. Java runs on z/OS forever (ok,
not forever but I first met it around 2002 and I do not work with z/OS
every day). See
http://www-03.ibm.com/servers/eserver/zseries/software/java/
At least Java have run on z/OS longer than Linux on System z

For i/o, yes, they have ZFile to deal with their high-level abstraction
of files (those defined by DD statements in JCL) and datasets and
record-based files, because standard Java i/o just do not have
abstractions for these but you can also use java.io.File to access PC or
Unix file systems (on z/OS, not Linux). See
http://dovetail.com/docs/misc/s8368jza.pdf for more info. Long story
short, you do not have to run Linux to use java.io.File on z/OS.

-Pavel

 

[robertwessel2]

Why would it have to fit them? It's still just a simple tree structure,
like all filesystems I've come across are.

Actually it's not. The first part (the "userid.project.level.type"
part) is actually a single flat filename. There are conventions
(which don't have to be followed) to use certain patterns (for example
making the first segment the user ID), but there's nothing
hierarchical about it. The "(filename)" part only applies to certain
types of files (PDSs) which internally contain smaller
"files" (members). Commonly those are used for source code, object
code, and other small files (thus you might have "a0370.myproj.source.c
(myprog)"). Most of the datasets (files) containing real data are not
PDSs, and lack the trailing member designator.

To make things more confusing, zOS also supports a *nix style
hierarchical file system to aid in porting applications. And then
there are datasets which live in a somewhat disjoint namespace as well
(stuff in the spool queues, for example).

Other mainframe systems, like zVSE, are even less consistent, but
that's neither here nor there.

With an object-oriented approach
(be it in C or C++) you could easily abstract all these filesystems and
work with them without ever needing to know what the directory separator
is, what the file/MIME-type of an entry is etc. You could even use the same
abstraction to work with a PKZIP archive without ever having to know it's
an image file rather than a real directory. Systems without subdirectories?
The standard library will simply never return "type=directory" for anything
but the root object. Systems without filesystem? Any attempt to open a
file or directory will return invalid. Again: I have no idea where you see
any problems with standardizing/abstracting any of this.

I personally don't have a problem with the C or C++ standard including
support for various optional parts (directory handling, threading and
TCP/IP communications come to mind as obvious examples). A system not
supporting, one of those modules would just include a "#error" in the
header for it. And we can come up with some way of specifying and
application’s requirement for both base and optional features. I
acknowledge that some disagree, and want the standard to be as
consistent in implementation as possible, but there I have no problems
with some stuff being optional.

That being said, I'm not sure those optional libraries need to
actually be part of the C or C++ standard directly (although that, of
course, gives them vastly more weight). Doing it elsewhere is
reasonable, and we can look at Boost for an example of that.
boost::filesystem applies here.

But on the topic, I think you'd have to agree than any rational API
for inclusion in the standard would have to handle at least *nix and
DOS/Windows style directories (incidentally two classes of platform
for which boost::filesystem exists, VMS being the other), but there
are considerable semantic differences between those two classes, even
though they look quite similar. For example, the drive letter concept
in Windows means there is not just one current directory, but as many
as 26 (one of which is more current than the others, of course). This
impacts how you interpret directory specifications considerably. But
as boost:filesystem shows, it's far from trivial.

 

[Pavel]

So you are saying that it seems like a good idea to have a language
standard that IBM cannot implement on their systems? Forcing them to
use non-standard extensions?


Please remind me, what is the idea behind having a global standard?


Bo Persson

I got enough of it at last so here goes your reminder: see
http://blog.lib.umn.edu/tiet0024/wittgenstein/. I was looking for this
quote for few years..

"107. The more narrowly we examine actual language, the sharper becomes
the conflict between it and our requirement. (For the crystalline purity
of logic was, of course, not a result of investigation: it was a
requirement.) The conflict now becomes intolerable; the requirement is
now in danger of becoming empty.--We have got on to slippery ice where
there is no friction and so in a certain sense the conditions are ideal,
but also, just because of that, we are unable to walk. We want to walk:
so we need friction. Back to rough ground!"

-from Philosophical Investigations"

Global standard encompassing every platform will take infinite time to
create. As a result, we have NOTHING. Java, Perl, Python, C#, you name
it.. went other way and they have something that satisfies 99% of their
users in term of file system. Even that supposedly "obscure" IBM
implemented Java on their supposedly intractable platform. Including
java.io.File, by the way -- within reason and demand. Believe me, IBM
would implement whatever requirement ISO standard would contain for C++
file systems. They really can write programs. Platform *extensions* will
always be around as long as the competition is around but it does not
prevent us from standardizing *basics*. IBM did not make it an issue to
implement supposedly "Unixish" IETF FTP protocol, yes on z/OS FTP
servers that somehow have directories. Hey, they will actually give you
Unixish file system if this is what you prefer and the Standard does not
have special dataset / catalog / DD / records support. They did it to
Java guys..

C++ committee decided to.. wait for perfect solution.

But wait, we will have brand new meaning for square brackets, functional
programming (but only those features that could be implemented via OOP
without any issue) and we almost got concepts (no one yet showed to me
any useful application of a concept that could not be solved with a
separately instantiated templates facility that is not prohibited by the
standard -- maybe it should be made a requirement) -- fortunately that
one was dropped. My feeling is that nobody just wants to work on
libraries as opposed to "cool" things.

Aren't we bragging that C++ is already the best language for library
writers every time a humble application developer complains about its
being too complex for his/her little application? So why not to show to
us all how to add a couple of useful features to the libraries. As
simple as file names. So far the only "perfect" library facility is
locales and facets -- perfectly takes all speed out of those streams
that were supposed to be faster than printf.. Yeah, sure, they are
faster.. defined and often implemented via printf.. Show me a single
(buf fully compliant) implementation that is faster than optimized gcc
printf.. (fully compliant to C ISO Standard).


-Pavel

 

[Pavel]

Actually it's not. The first part (the "userid.project.level.type"
part) is actually a single flat filename. There are conventions
(which don't have to be followed) to use certain patterns (for example
making the first segment the user ID), but there's nothing
hierarchical about it. The "(filename)" part only applies to certain
types of files (PDSs) which internally contain smaller
"files" (members). Commonly those are used for source code, object
code, and other small files (thus you might have "a0370.myproj.source.c
(myprog)"). Most of the datasets (files) containing real data are not
PDSs, and lack the trailing member designator.

So how is it difficult to support plain filenames? Just return an empty
string from getParentDirectory() or whatever API call does it and return
the whole name from getFileNameProper() or whatever is standardized for
this? I mean - on z/OS, this will not prevent an implementation from
working properly on systems that have directories. Minimal standard
facility is better than no standard facility (and often better than too
sophisticated standard facility that no one can implement. Start small,
you can always add more calls in the next versions if you need them. As
opposed to new keywords and new meaning for existing tokens, new API
calls do not have to make older program that don't use them
non-compliant. Isn't this that simple?).

-Pavel

 

[James Kanze]

* Bo Persson:

No, it was a rhetorical question.

I gather that the person I addressed that question to
understood that.

Note that this (only) compiler has quite extensive support for
ASCII-based character encodings -- it does not require using
EBCDIC even for creating EBCDIC environment programs.

Never the less, using ASCII-based character encodings on a z/OS
is fighting the system. No one in their right mind would do it.
And it is the dominant machine in its market.

 

[James Kanze]

[...]

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.

"Many" is relative. All of the banks I've worked at use IBM
mainframes for some of their work.

Should the C++ standard ignore them?

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.

FWIW: as a follow-up to another discussion here, I raised the
question concerning support for Unisys MPC processors (much less
common than IBM z/OS) in the committee---the current wording in
the standard does create problems for them. Although there was
some discussion about how best to treat the problem, there did
seem to be a consensus (at least among the few people who
responded to my question) that C++ should be implementable on
such a machine.

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.

Java intentionally limits the platforms it supports, and I
wouldn't take it as a model for C++. (File is particularly
poorly designed, for example.) Common Lisp, however, seems to
address the problem in a far more "portable" way: a pathname has
six components: host, device, directory, name, type and version.
I've not read it in detail (presumably, for example, some of
these components could be empty, or ignored on certain systems),
but it obviously does try to address many of the problems which
have been raised (and which apply to Java's File as well).

(For those interested:
http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node202.html#SECTION002700000000000000000
is the starting point for the formal specification.)

 

[James Kanze]

* Bo Persson:

[...]
Why is it that every time someone opposes customizing the
standard to your personal use, you speak of ENIAC? Only because
you don't have any real argument?

There are all sorts of other factors that means they're
already using an extensive set of tool and environment
adaptions.

There's no point in the C++ standard castrating itself to
support ENIAC while the ENIAC guys are moving away from ENIAC
as fast as they can...

There are no ENIAC machines in existance, and ENIAC didn't use
EBCDIC.

IBM is still actively selling z/OS machines, and the park of
machines using EBCDIC is still growing. Not as fast, perhaps,
as those using Unicode, but people using such machines are still
investing in new equipment, and (young) people are still being
trained to use them. A PC is not the solution for everyone, and
somethings are best handled by a large, central processor.

[...]

Actually, with repect to hardware ignoring IBM's (I think) and
some others' is just what the standard, very reasonably, does,
e.g. by requiring at least 8 bits for 'char'.

It was a compromize, and it did affect the usual conventions on
a PDP-10 (which put five seven bit char's in a 36 bit word, with
one bit which wasn't accessible through a byte pointer). But
unlike forcing ASCII, it didn't cause any problems on processors
which were still being sold at the time the standard was
adopted. (And there were also places where people used 9 bit
characters on the PDP-10---the size of a byte was programmable
on it.)