Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to get filename from path in C++

755 views
Skip to first unread message

Aaron Gray

unread,
Jul 20, 2009, 9:35:37 PM7/20/09
to
Whats the best way to get the filename from a path using std::string and
using char[] ?

Many thanks in advance,

Aaron


Daniel T.

unread,
Jul 20, 2009, 10:03:53 PM7/20/09
to
"Aaron Gray" <ang.u...@gmail.com> wrote:

Sound a lot like a homework problem... Start from the end of the string
and work your way forward looking for the path separator character.

std::string already has a member function to do it, and there is a
function in the <cstring> header to handle the char[].

Good luck.

Pavel

unread,
Jul 20, 2009, 10:24:01 PM7/20/09
to
Daniel T. wrote:
> "Aaron Gray" <ang.u...@gmail.com> wrote:
>
>> Whats the best way to get the filename from a path using std::string and
>> using char[] ?
>>
>> Many thanks in advance,
>
> Sound a lot like a homework problem... Start from the end of the string
> and work your way forward looking for the path separator character.
To me it sounded more like asking for a standard library facility that
would do the job. Something like File::Spec in Perl or java.io.File in
Java or basename/dirname in shell, you know..

I guess, everybody's hearing is different.. I am programming in C++ for
some two decades and it is still a puzzle to me how the people in charge
of the standard library select priorities. BTW, does anybody know if
such a basic facility (working with file names) is going to be
standardized in C++0x? Or does that new semantics for square brackets
trample everything? (obviously the past decade was the decade of angle
brackets, but now the squares rule, I guess. If I am still around I may
learn whole new story about parentheses in C++1y -- how exciting!).

-Pavel

Fred Zwarts

unread,
Jul 21, 2009, 3:34:20 AM7/21/09
to
"Aaron Gray" <ang.u...@gmail.com> wrote in message news:7ckkbaF...@mid.individual.net...

> Whats the best way to get the filename from a path using std::string and
> using char[] ?

This is not really a C++ question. It depends very much on the operating system.
Usually operating system dependent file-name parsing functions are used.

Fred Zwarts

unread,
Jul 21, 2009, 3:37:56 AM7/21/09
to

"Pavel" <dot_com_yahoo@paultolk_reverse.yourself> wrote in message news:5F99m.518$MA3...@nwrddc02.gnilink.net...

> Daniel T. wrote:
>> "Aaron Gray" <ang.u...@gmail.com> wrote:
>>
>>> Whats the best way to get the filename from a path using std::string and
>>> using char[] ?
>>>
>>> Many thanks in advance,
>>
>> Sound a lot like a homework problem... Start from the end of the string
>> and work your way forward looking for the path separator character.
> To me it sounded more like asking for a standard library facility that
> would do the job. Something like File::Spec in Perl or java.io.File in
> Java or basename/dirname in shell, you know..
>
> I guess, everybody's hearing is different.. I am programming in C++ for
> some two decades and it is still a puzzle to me how the people in charge
> of the standard library select priorities. BTW, does anybody know if
> such a basic facility (working with file names) is going to be
> standardized in C++0x? Or does that new semantics for square brackets
> trample everything? (obviously the past decade was the decade of angle
> brackets, but now the squares rule, I guess. If I am still around I may
> learn whole new story about parentheses in C++1y -- how exciting!).

Maybe it is nice to know that in the OpenVMS operating system
square brackets and angle brackets are both used as alternatives to
indicate the directories in a full file path. :)

Fred Zwarts

unread,
Jul 21, 2009, 3:52:22 AM7/21/09
to
"Daniel T." <dani...@earthlink.net> wrote in message news:daniel_t-933048...@earthlink.vsrv-sjc.supernews.net...

This assumes that there is only one path separator. There are operating systems that use more.
E.g., OpenVMS starts the directory part of the path with one character, separates the sub-directories
with a second separator and ends the directories with a third one. It further has other characters
to separate the device part and the file version number from the file name. Strange enough it uses
the same character for separating sub-directories and for separating the file name from the file extension.
E.g.: USERDISK:[HOME.USER.SANDBOX]FILENAME.EXT;17
Given the fact that instead of square brackets also angle brackets can be used
(not to mention the separator for the node name part in a full path for remote file names),
the parsing is very complex.
It can be done with member functions of std:string, but it is much better to use
specific OS functions.

Bo Persson

unread,
Jul 21, 2009, 4:29:26 AM7/21/09
to
Fred Zwarts wrote:
> "Daniel T." <dani...@earthlink.net> wrote in message
> news:daniel_t-933048...@earthlink.vsrv-sjc.supernews.net...
>> "Aaron Gray" <ang.u...@gmail.com> wrote:
>>
>>> Whats the best way to get the filename from a path using
>>> std::string and using char[] ?
>>>
>>> Many thanks in advance,
>>
>> Sound a lot like a homework problem... Start from the end of the
>> string and work your way forward looking for the path separator
>> character.
>>
>> std::string already has a member function to do it, and there is a
>> function in the <cstring> header to handle the char[].
>
> This assumes that there is only one path separator.

It also assumes that the OS uses paths. :-)

Some do not, like IBM z/OS.

> It can be done with member functions of std:string, but it is much
> better to use
> specific OS functions.

Exactly.


Bo Persson


tni

unread,
Jul 21, 2009, 6:09:25 AM7/21/09
to
Fred Zwarts wrote:
> "Aaron Gray" <ang.u...@gmail.com> wrote in message news:7ckkbaF...@mid.individual.net...
>> Whats the best way to get the filename from a path using std::string and
>> using char[] ?
>
> This is not really a C++ question.

It should be. The C++ standard library is incredibly lean in terms of
functionality provided.

There are tons of different libraries that each do there own thing (and
probably even have own string types) for this kind of stuff.


Boost filesystem (it may end up being part of standard C++ one day):
http://www.boost.org/doc/libs/1_39_0/libs/filesystem/doc/index.htm

WxWidgets:
http://docs.wxwidgets.org/stable/wx_wxfilename.html

Qt:
http://doc.trolltech.com/qdir.html
http://doc.trolltech.com/qfileinfo.html

James Kanze

unread,
Jul 21, 2009, 6:37:58 AM7/21/09
to
On Jul 21, 12:09 pm, tni <nob...@example.com> wrote:
> Fred Zwarts wrote:
> > "Aaron Gray" <ang.use...@gmail.com> wrote in
> > messagenews:7ckkbaF...@mid.individual.net...

> >> Whats the best way to get the filename from a path using
> >> std::string and using char[] ?

> > This is not really a C++ question.

> It should be.

Maybe, but how? To date, I don't think anyone has proposed
anything. (Remember, a standard solution would have to work
when the system didn't have sub-directories, or when it also had
version numbers and such.)

--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Michael Doubez

unread,
Jul 21, 2009, 7:07:55 AM7/21/09
to
On 21 juil, 12:37, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 21, 12:09 pm, tni <nob...@example.com> wrote:
>
> > Fred Zwarts wrote:
> > > "Aaron Gray" <ang.use...@gmail.com> wrote in
> > > messagenews:7ckkbaF...@mid.individual.net...
> > >> Whats the best way to get the filename from a path using
> > >> std::string and using char[] ?
> > > This is not really a C++ question.
> > It should be.
>
> Maybe, but how?  To date, I don't think anyone has proposed
> anything.  (Remember, a standard solution would have to work
> when the system didn't have sub-directories, or when it also had
> version numbers and such.)

There was a filesystem proposal for TR2 based on boost implementation.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html#Header-filesystem-synopsis

It wasn't included into C++0x.

--
Michael

Aaron Gray

unread,
Jul 21, 2009, 7:29:03 AM7/21/09
to
"Pavel" <dot_com_yahoo@paultolk_reverse.yourself> wrote in message
news:5F99m.518$MA3...@nwrddc02.gnilink.net...
> Daniel T. wrote:
>> "Aaron Gray" <ang.u...@gmail.com> wrote:
>>
>>> Whats the best way to get the filename from a path using std::string and
>>> using char[] ?
>>>
>>> Many thanks in advance,
>>
>> Sound a lot like a homework problem... Start from the end of the string
>> and work your way forward looking for the path separator character.

No I am working on a COFF backend and I need to create a module identifier
from the filename.

> To me it sounded more like asking for a standard library facility that
> would do the job. Something like File::Spec in Perl or java.io.File in
> Java or basename/dirname in shell, you know..
>
> I guess, everybody's hearing is different.. I am programming in C++ for
> some two decades and it is still a puzzle to me how the people in charge
> of the standard library select priorities. BTW, does anybody know if

Yes this is an evident fact. C++ standard libraries suck when it comes to
file handling and sockets.

> such a basic facility (working with file names) is going to be
> standardized in C++0x? Or does that new semantics for square brackets
> trample everything? (obviously the past decade was the decade of angle
> brackets, but now the squares rule, I guess. If I am still around I may
> learn whole new story about parentheses in C++1y -- how exciting!).

Maybe it should be suggested.

> -Pavel
>>
>> std::string already has a member function to do it,

std::string filename = ...
size_t index = filename.find_last_of('/\\');
char moduleId[18]
filename.copy( moduleId, std::max( 18, filename.size() - index), index);
// throws out_of_range

>> and there is a function in the <cstring> header to handle the char[].

strrchr, problem is I want it to work on Unix and Windows.

I suppose

char *filename = ....
char *moduleId = std::max( strrchr( filename, '/'), strrchr( filename,
'\\'));
moduleId = moduleId ? moduleId : filename;

I think this second C like version is probably best, but it does not take in
to account a max length of 18.

I was really hoping there were proper API's in place for this. Unix has them
I believe.

Thanks for the pointers Pavel,

Aaron


tni

unread,
Jul 21, 2009, 8:27:57 AM7/21/09
to
James Kanze wrote:
> On Jul 21, 12:09 pm, tni <nob...@example.com> wrote:
>> Fred Zwarts wrote:
>>> "Aaron Gray" <ang.use...@gmail.com> wrote in
>>> messagenews:7ckkbaF...@mid.individual.net...
>>>> Whats the best way to get the filename from a path using
>>>> std::string and using char[] ?
>
>>> This is not really a C++ question.
>
>> It should be.
>
> Maybe, but how? To date, I don't think anyone has proposed
> anything. (Remember, a standard solution would have to work
> when the system didn't have sub-directories, or when it also had
> version numbers and such.)

It doesn't have to work everywhere. It's not like current compilers
support all of the C++ standard. If you have some exotic system, you
just have to do something platform specific (like you have to do today).
Something like versioning could certainly be mapped to paths, e.g. look
at Clearcase.

Michael Doubez

unread,
Jul 21, 2009, 9:24:42 AM7/21/09
to
On 21 juil, 14:27, tni <nob...@example.com> wrote:
> James Kanze wrote:
> > On Jul 21, 12:09 pm, tni <nob...@example.com> wrote:
> >> Fred Zwarts wrote:
> >>> "Aaron Gray" <ang.use...@gmail.com> wrote in
> >>> messagenews:7ckkbaF...@mid.individual.net...
> >>>> Whats the best way to get the filename from a path using
> >>>> std::string and using char[] ?
>
> >>> This is not really a C++ question.
>
> >> It should be.
>
> > Maybe, but how?  To date, I don't think anyone has proposed
> > anything.  (Remember, a standard solution would have to work
> > when the system didn't have sub-directories, or when it also had
> > version numbers and such.)
>
> It doesn't have to work everywhere.

Then it is not C++ standard compliant.

> It's not like current compilers
> support all of the C++ standard. If you have some exotic system, you
> just have to do something platform specific (like you have to do today).

Some compiler may not be fully standard compliant but it is nor
something to aim at.

> Something like versioning could certainly be mapped to paths, e.g. look
> at Clearcase.

I expect the program could check for conformance/portability or verify
abstraction supported by the filesystem (on a path).

--
Michael

Bo Persson

unread,
Jul 21, 2009, 9:55:39 AM7/21/09
to
tni wrote:
> James Kanze wrote:
>> On Jul 21, 12:09 pm, tni <nob...@example.com> wrote:
>>> Fred Zwarts wrote:
>>>> "Aaron Gray" <ang.use...@gmail.com> wrote in
>>>> messagenews:7ckkbaF...@mid.individual.net...
>>>>> Whats the best way to get the filename from a path using
>>>>> std::string and using char[] ?
>>
>>>> This is not really a C++ question.
>>
>>> It should be.
>>
>> Maybe, but how? To date, I don't think anyone has proposed
>> anything. (Remember, a standard solution would have to work
>> when the system didn't have sub-directories, or when it also had
>> version numbers and such.)
>
> It doesn't have to work everywhere.

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.

It would be really surprising if the language would then try to
standardize file names and directories.


Bo Persson


Andreas Dehmel

unread,
Jul 21, 2009, 2:58:11 PM7/21/09
to
On Tue, 21 Jul 2009 15:55:39 +0200, Bo Persson wrote:

> tni wrote:
> > James Kanze wrote:
> >> On Jul 21, 12:09 pm, tni <nob...@example.com> wrote:
> >>> Fred Zwarts wrote:
> >>>> "Aaron Gray" <ang.use...@gmail.com> wrote in
> >>>> messagenews:7ckkbaF...@mid.individual.net...
> >>>>> Whats the best way to get the filename from a path using
> >>>>> std::string and using char[] ?
> >>
> >>>> This is not really a C++ question.
> >>
> >>> It should be.
> >>
> >> Maybe, but how? To date, I don't think anyone has proposed
> >> anything. (Remember, a standard solution would have to work
> >> when the system didn't have sub-directories, or when it also had
> >> version numbers and such.)
> >
> > It doesn't have to work everywhere.
>
> 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.
I'd say that, on the contrary, the only result of this is that rather
than parts of it being unusable on some exotic systems it becomes
unusable everywhere. What good is a standard which doesn't even allow me
to do the most elementary things like a simple portable command line
tool which takes a filename as parameter and does some IO-operation with
that file? If you think that works: think again (Windows on non 8-bit
locales). Yeah, I know, C++0x will address that... at least 10 years
too late, but what the hey...


> It would be really surprising if the language would then try to
> standardize file names and directories.

Me too, but only because so far the standard seems to have a history
of trying to weasel out of exactly the kind of ugly, low-level
abstractions a standard library should provide first and foremost
of all. Which pretty much forces developers to code outside of the
standard, e.g. using Qt, which (although primarily a GUI-abstraction
layer) does provide things like a _proper_ string class (efficient,
with fully-fledged interfaces to codecs, filesystem etc). In other words
exactly the kind of thing that's indispensable for a _usable_ standard
library.

We'll see about C++0x. Personally, based on past experience, I'm not
holding my breath...

Andreas
--
Dr. Andreas Dehmel Ceterum censeo
FLIPME(ed.enilno-t@nouqraz) Microsoft esse delendam
http://www.zarquon.homepage.t-online.de (Cato the Much Younger)

Andy Champ

unread,
Jul 21, 2009, 3:18:04 PM7/21/09
to
Aaron Gray wrote:
<snip>

> char *filename = ....
> char *moduleId = std::max( strrchr( filename, '/'), strrchr( filename,
> '\\'));
> moduleId = moduleId ? moduleId : filename;
>
My 2c worth:
I'd just like to remind you that in Japan on Windoze the currency
symbol(1) can be used as a path separator. And are those ascii or
unicode or what chars there?

(1) yen symbol, which I can't work out how to type so you'll all be able
to read it - a Y overstruck with an equals sign


Andy

Aaron Gray

unread,
Jul 21, 2009, 7:17:44 PM7/21/09
to
"Andy Champ" <no....@nospam.invalid> wrote in message
news:ha2dnYQB49f2ifvX...@eclipse.net.uk...

Does not really apply to the compiler I am writing the COFF backend for.

Yay,

Aaron


Bo Persson

unread,
Jul 21, 2009, 7:46:21 PM7/21/09
to

Yes, by not specifying everything down to the last bit, the language
is actually usable on a wider range of machines.

Another "totally portable" language needs special hardware add-ons to
run on some machines where C++ runs natively:

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


> I'd say that, on the contrary, the only result of this
> is that rather than parts of it being unusable on some exotic
> systems it becomes unusable everywhere. What good is a standard
> which doesn't even allow me to do the most elementary things like a
> simple portable command line tool which takes a filename as
> parameter and does some IO-operation with that file?

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

>
>> It would be really surprising if the language would then try to
>> standardize file names and directories.
>
> Me too, but only because so far the standard seems to have a history
> of trying to weasel out of exactly the kind of ugly, low-level
> abstractions a standard library should provide first and foremost
> of all. Which pretty much forces developers to code outside of the
> standard, e.g. using Qt, which (although primarily a GUI-abstraction
> layer) does provide things like a _proper_ string class (efficient,
> with fully-fledged interfaces to codecs, filesystem etc). In other
> words exactly the kind of thing that's indispensable for a _usable_
> standard library.

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

This system doesn't even have a GUI:

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

>
> We'll see about C++0x. Personally, based on past experience, I'm not
> holding my breath...
>

Please don't.


Bo Persson


Pavel

unread,
Jul 22, 2009, 12:01:31 AM7/22/09
to
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.. :-).

-Pavel

James Kanze

unread,
Jul 22, 2009, 5:18:27 AM7/22/09
to
On Jul 21, 1:29 pm, "Aaron Gray" <ang.use...@gmail.com> wrote:
> "Pavel" <dot_com_yahoo@paultolk_reverse.yourself> wrote in message

[...]


> >> std::string already has a member function to do it,

> std::string filename = ...
> size_t index = filename.find_last_of('/\\');
> char moduleId[18]
> filename.copy( moduleId, std::max( 18, filename.size() - index), index);
> // throws out_of_range

> >> and there is a function in the <cstring> header to handle
> >> the char[].

> strrchr, problem is I want it to work on Unix and Windows.

Then you'll need the std::string solution. Windows allows both
'/' and '\' as path separators (and it's not unusual to see
both, depending on the context), so strchr can't be used.

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

James Kanze

unread,
Jul 22, 2009, 5:20:27 AM7/22/09
to

> implementation.http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html#He...

> It wasn't included into C++0x.

Maybe because it can't be implemented on some platforms, and
doesn't address all of the issues on others. Doing something
that is portable between Windows and Unix is relatively trivial,
but C++ aims to be portable to other systems as well.

Michael Doubez

unread,
Jul 22, 2009, 6:37:08 AM7/22/09
to
On 22 juil, 11:20, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 21, 1:07 pm, Michael Doubez <michael.dou...@free.fr> wrote:
>
>
>
> > On 21 juil, 12:37, James Kanze <james.ka...@gmail.com> wrote:
> > > On Jul 21, 12:09 pm, tni <nob...@example.com> wrote:
> > > > Fred Zwarts wrote:
> > > > > "Aaron Gray" <ang.use...@gmail.com> wrote in
> > > > > messagenews:7ckkbaF...@mid.individual.net...
> > > > >> Whats the best way to get the filename from a path using
> > > > >> std::string and using char[] ?
> > > > > This is not really a C++ question.
> > > > It should be.
> > > Maybe, but how?  To date, I don't think anyone has proposed
> > > anything.  (Remember, a standard solution would have to work
> > > when the system didn't have sub-directories, or when it also had
> > > version numbers and such.)
> > There was a filesystem proposal for TR2 based on boost
> > implementation.http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html#He...
> > It wasn't included into C++0x.
>
> Maybe because it can't be implemented on some platforms, and
> doesn't address all of the issues on others.  Doing something
> that is portable between Windows and Unix is relatively trivial,
> but C++ aims to be portable to other systems as well.

I agree we cannot ensure portability of filename but perhaps something
could be done to ensure a minimum set of common concept for
manipulating filenames and the underlying ressource.

tr2::filesystem does not seem far from that to me.

It has been accepted into TR2 (at the 2006 Berlin meeting it seems) at
the same time as <error_code> which has been included into C++0x. I
could not find minutes concerning Filesystem.
It is not mentioned in Portland 2006 Meeting:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2122.htm

I guess it is more a resource shortage to address the issue - from BS
interview:
http://www.ddj.com/cpp/207000124?pgno=2
<quote>
B.S.: The progress on standard libraries has not been what I hoped
for. We will get regular expressions, hash tables, threads, many
improvements to the existing containers and algorithms, and a few more
minor facilities. We will not get the networking library, the date and
time library, or the file system library. These will wait until a
second library TR. I had hoped for much more, but the committee has so
few resources and absolutely no funding for library development.
</quote>

--
Michael

Bo Persson

unread,
Jul 22, 2009, 8:47:59 AM7/22/09
to

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

unread,
Jul 22, 2009, 2:44:53 PM7/22/09
to
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). 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
>
>
> > I'd say that, on the contrary, the only result of this
> > is that rather than parts of it being unusable on some exotic
> > systems it becomes unusable everywhere. What good is a standard
> > which doesn't even allow me to do the most elementary things like a
> > simple portable command line tool which takes a filename as
> > parameter and does some IO-operation with that file?
>
> 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...


> >> It would be really surprising if the language would then try to
> >> standardize file names and directories.
> >
> > Me too, but only because so far the standard seems to have a history
> > of trying to weasel out of exactly the kind of ugly, low-level
> > abstractions a standard library should provide first and foremost
> > of all. Which pretty much forces developers to code outside of the
> > standard, e.g. using Qt, which (although primarily a GUI-abstraction
> > layer) does provide things like a _proper_ string class (efficient,
> > with fully-fledged interfaces to codecs, filesystem etc). In other
> > words exactly the kind of thing that's indispensable for a _usable_
> > standard library.
>
> 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...

Bo Persson

unread,
Jul 22, 2009, 3:43:20 PM7/22/09
to
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?


Bo Persson


Alf P. Steinbach

unread,
Jul 22, 2009, 5:27:59 PM7/22/09
to
* Bo Persson:

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

unread,
Jul 22, 2009, 5:37:12 PM7/22/09
to
"James Kanze" <james...@gmail.com> wrote in message
news:6e26653f-6906-4c19-bbe5->c70942...@k6g2000yqn.googlegroups.com...

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

unread,
Jul 23, 2009, 4:55:45 AM7/23/09
to
On Jul 22, 11:27 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * 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

unread,
Jul 23, 2009, 6:45:36 AM7/23/09
to
* James Kanze:

> On Jul 22, 11:27 pm, "Alf P. Steinbach" <al...@start.no> wrote:
>> * 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.

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


- Alf

Andreas Dehmel

unread,
Jul 23, 2009, 3:57:34 PM7/23/09
to


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.


[...]


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

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

Bo Persson

unread,
Jul 23, 2009, 4:52:50 PM7/23/09
to

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

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

Bo Persson


Bo Persson

unread,
Jul 23, 2009, 5:07:53 PM7/23/09
to

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

unread,
Jul 23, 2009, 5:15:52 PM7/23/09
to

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

unread,
Jul 23, 2009, 6:13:19 PM7/23/09
to
* Bo Persson:

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.

Alf P. Steinbach

unread,
Jul 23, 2009, 6:42:27 PM7/23/09
to
* Bo Persson:

> Alf P. Steinbach wrote:
>> * Bo Persson:
>>>
>>> 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.

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


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

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


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

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.


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

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

Pavel

unread,
Jul 23, 2009, 10:18:03 PM7/23/09
to
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

robert...@yahoo.com

unread,
Jul 23, 2009, 10:52:52 PM7/23/09
to
On Jul 23, 2:57 pm, Andreas Dehmel <blackhole.

8.zarquo...@spamgourmet.com> wrote:
> On Wed, 22 Jul 2009 21:43:20 +0200, Bo Persson wrote:
> > Andreas Dehmel wrote:
> > 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.


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

unread,
Jul 23, 2009, 11:04:55 PM7/23/09
to
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

unread,
Jul 23, 2009, 11:18:36 PM7/23/09
to
robert...@yahoo.com wrote:
> On Jul 23, 2:57 pm, Andreas Dehmel <blackhole.
> 8.zarquo...@spamgourmet.com> wrote:
>> On Wed, 22 Jul 2009 21:43:20 +0200, Bo Persson wrote:
>>> Andreas Dehmel wrote:
>>> 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.
>
>
> 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

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

James Kanze

unread,
Jul 24, 2009, 4:36:55 AM7/24/09
to

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

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

unread,
Jul 24, 2009, 4:56:15 AM7/24/09
to
On Jul 23, 11:07 pm, "Bo Persson" <b...@gmb.dk> wrote:

[...]


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

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

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.

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

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

unread,
Jul 24, 2009, 5:06:24 AM7/24/09
to
On Jul 24, 12:42 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * Bo Persson:
> > Alf P. Steinbach wrote:
> >> * Bo Persson:

[...]


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

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?

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

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

Andreas Dehmel

unread,
Jul 25, 2009, 10:34:23 AM7/25/09
to

Sure I would. _Any_ standard should not reflect the state of the art of
the oldest and dumbest systems around and thus drag everything down
to their level but rather use what the majority of systems offer and
what the majority of developers need, at least on a basic level.

And I find it highly amusing that on the one hand you think it'd be a problem
that systems too dumb to implement a standard like I suggest would have to
use non-standard extensions, but at the same time it's apparently no
problem to you that everybody who needs "exotic" things like real-world
filesystem access (with non-8-bit charsets and directories) already has
to use non-standard extensions because you simply can not get the job
done within the lame-excuse-for-a-standard we have.

Wherever the standard goes, someone will have to use proprietary entensions
as a consequence. I merely think the ones forced to do so should be the
ancient/exotic systems and not everybody else. Legacy systems can be
K&R-C compliant for all I care, but even taking them into account for new
standards is a huge mistake. It only serves the vanity of legacy systems
and their representatives (``look, 60ies technology and still standard-
compliant'') while screwing everybody else.


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

It is not to accomodate the needs of the dumbest possible system, neither
should a college degree cater for the non-intelligence of the common
retard, and for the same reason: to do so would render it meaningless.
Those who can't cut it can't cut it. Tough, get over it, better luck
next time.

A global standard _is_ there to provide people basing their work on that
standard (in this case all C/C++-developers worldwide) with a solid
foundation to work on. If that standard is so vague you can't base
your work on it in the first place (like the areas of the C++-standard
we've covered in this thread for e.g. desktop/workstation applications),
that standard has failed.

0 new messages