"Edward Diener" <eldiener@earthlink.net> writes:

|>  "James Kanze" <kanze@gabi-soft.de> wrote in message
|>  news:86it6ugzlc.fsf@alex.gabi-soft.de...
|>  "James Kuyper Jr." <kuyper@wizard.net> writes:

|>  >>  Well, the existence of an actual implementation would serve to
|>  >>  resolve the very same uncertainty you mention. There's not much
|>  >>  point in allowing wide character file names, unless someone
|>  >>  actually needs them.

|>  > In this particular case, I think that there are implementors
|>  > willing to implement it, if there were any agreement as to what
|>  > the semantics should be.  (The issue has been discussed on the
|>  > committee mailing lists, and it is apparent that there is no
|>  > concensus whatever with regards to the semantics for machines not
|>  > supporting wide character file names natively -- which is the
|>  > usual situation today.)

|>  If there were an implementation for an OS not supporting wide
|>  character filenames, the do_open implementation of the
|>  std::messages<wchar_t> facet could fail by returning -1.

You mean that opening a file with the name L"xyz.h" could have different
results than opening it with "xyz.h"?  That doesn't sound very
acceptable to me.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kanze" <kanze@gabi-soft.de> wrote in message
news:86pu0yn0zp.fsf@alex.gabi-soft.de...
"Edward Diener" <eldiener@earthlink.net> writes:

>>>  "James Kanze" <kanze@gabi-soft.de> wrote in message
>>>  news:86it6ugzlc.fsf@alex.gabi-soft.de...
>>>  "James Kuyper Jr." <kuyper@wizard.net> writes:

>>>  >>  Well, the existence of an actual implementation would serve to
>>>  >>  resolve the very same uncertainty you mention. There's not much
>>>  >>  point in allowing wide character file names, unless someone
>>>  >>  actually needs them.

>>>  > In this particular case, I think that there are implementors
>>>  > willing to implement it, if there were any agreement as to what
>>>  > the semantics should be.  (The issue has been discussed on the
>>>  > committee mailing lists, and it is apparent that there is no
>>>  > concensus whatever with regards to the semantics for machines not
>>>  > supporting wide character file names natively -- which is the
>>>  > usual situation today.)

>>>  If there were an implementation for an OS not supporting wide
>>>  character filenames, the do_open implementation of the
>>>  std::messages<wchar_t> facet could fail by returning -1.

>> You mean that opening a file with the name L"xyz.h" could have different
>> results than opening it with "xyz.h"?  That doesn't sound very
>> acceptable to me.

If the OS does not support accessing files with wide character filenames,
and one attempts to open a file with a wide character filename, why should
this not fail ? L"xyz.h" and "xyz.h" are two different filenames as far as I
can see, unless the OS considers them as one in which case it will allow me
to open them using either name if the file exists.

The whole business of accessing a file is OS dependent but at least on the
OS I use, Windows ( NT, 2000, XP ), there is a completely different low
level function for opening a file using an ANSI filename and opening a file
using a wide character filename.

I admit that I am taking a simple view, which however seems logical and
practical to me, that files which consist of wide characters will be
normally denoted by wide character filenames, and that this will almost
always be occuring on operating systems in which the codepage is a wide
character one, most likely a Unicode character set. I don't think it is
worth worrying about the slim chance that an OS does not support wide
character filenames and the an end user still wants to create a messages
catalog for wide characters using an ANSI filename string. I am aware that
the filename string can actually be anything and does not have to be an
actual file, as long as the implementor of the messages<wchar_t> facet can
translate the name into something which allows access to a particular set of
messages as defined by the messages<> facet interface, but still the string
passed will most likely refer to a file, however the OS chooses to view that
concept.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." <kuyper@wizard.net> writes:

|>  Well, the existence of an actual implementation would serve to
|>  resolve the very same uncertainty you mention. There's not much
|>  point in allowing wide character file names, unless someone actually
|>  needs them.

In this particular case, I think that there are implementors willing to
implement it, if there were any agreement as to what the semantics
should be.  (The issue has been discussed on the committee mailing
lists, and it is apparent that there is no concensus whatever with
regards to the semantics for machines not supporting wide character file
names natively -- which is the usual situation today.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kanze" <kanze@gabi-soft.de> wrote in message
news:86it6ugzlc.fsf@alex.gabi-soft.de...
"James Kuyper Jr." <kuyper@wizard.net> writes:

>>  Well, the existence of an actual implementation would serve to
>>  resolve the very same uncertainty you mention. There's not much
>>  point in allowing wide character file names, unless someone actually
>>  needs them.

> In this particular case, I think that there are implementors willing to
> implement it, if there were any agreement as to what the semantics
> should be.  (The issue has been discussed on the committee mailing
> lists, and it is apparent that there is no concensus whatever with
> regards to the semantics for machines not supporting wide character file
> names natively -- which is the usual situation today.)

If there were an implementation for an OS not supporting wide character
filenames, the do_open implementation of the std::messages<wchar_t> facet
could fail by returning -1.

I would be interested in learning about other issues involved in this case,
even though I am not a standard committee member. Is there a way to do that
through the Internet ?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:
>
> "James Kanze" <kanze@gabi-soft.de> wrote in message
> news:86u1qisapd.fsf@alex.gabi-soft.de...
.....
> >  The role of
> > standardization is NOT a "creative process of changing or enhancing a
> > computer language", it is first and foremost the standardization of
> > existing practice.  The creative part has no role, or at least, should
> > have no role in standardization.
>
> Then at what point does the language get changed and/or improved ? If the
> role of standardization is just the "standardization of existing practice",
> then when does the other part occur ? Or is C++ so wonderful in every

Creativity is the responsibility of implementors, not the standardizers.
It's better that way; committees are not a good environment for
creativity, but they are a key tool in the process of reaching
consensus. Innovation works best in small groups. Look what Bjarne
Stroustrup did - he had lots of support from other people, but during
the early days of C++, everything about it was ultimately his
responsibility; C++ would have been far less innovative if he'd had to
work with a large committee to develop it.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3CB62981.87ED43A6@wizard.net...
> Edward Diener wrote:
> >
> > "James Kanze" <kanze@gabi-soft.de> wrote in message
> > news:86u1qisapd.fsf@alex.gabi-soft.de...
> .....
> > >  The role of
> > > standardization is NOT a "creative process of changing or enhancing a
> > > computer language", it is first and foremost the standardization of
> > > existing practice.  The creative part has no role, or at least, should
> > > have no role in standardization.
> >
> > Then at what point does the language get changed and/or improved ? If
the
> > role of standardization is just the "standardization of existing
practice",
> > then when does the other part occur ? Or is C++ so wonderful in every
>
> Creativity is the responsibility of implementors, not the standardizers.
> It's better that way; committees are not a good environment for
> creativity, but they are a key tool in the process of reaching
> consensus. Innovation works best in small groups. Look what Bjarne
> Stroustrup did - he had lots of support from other people, but during
> the early days of C++, everything about it was ultimately his
> responsibility; C++ would have been far less innovative if he'd had to
> work with a large committee to develop it.

So are you saying that unless I am an implementor, meaning a compiler writer
or a C++ standard library creator working for a company which puts out a C++
implementation, my proposals for change will meet with no success ? if that
is the case, then I am wasting my time even discussing ideas about C++ with
anybody on this NG who might effect changes since I am not in the category
above.

As to what happened in the past. changes nowadays go through a standards
commitee and are not being done by a single person anymore as in the time
when Mr. Stroustrup was shaping the language and assumed responsibilities
for its changes, although I believe he is still much involved as a committee
member.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <BFKs8.3658$3P4.298984@newsread2.prod.itd.earthlink.net>,
Edward Diener <eldiener@earthlink.net> writes
>> Experience shows that no change is so simple that it has no unexpected
>> impact: Experience with any change is crucially necessary. For an even
>> more practical point of view: The committee decided (at the Sophia-
>> Antipolis meeting) to accept proposals only if they are implemented.
>
>Are you telling me that if a proposal is made to change anything in the Ansi
>C++ standard, if that proposal has not already been implemented by either a
>compiler change or a library change in an existing implementation, the
>proposal will not be considered by the Ansi C++ committee ?

Fortunately, assuming there was such a decision, (I do not recall it and
that meeting was small because we were waiting for bureaucracy to grind
out the standard) such WG21 & J16 decisions do not bind future meetings
and only provide guidance.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:
>
> "James Kuyper Jr." <kuyper@wizard.net> wrote in message
> news:3CB62981.87ED43A6@wizard.net...
....
> > Creativity is the responsibility of implementors, not the standardizers.
> > It's better that way; committees are not a good environment for
> > creativity, but they are a key tool in the process of reaching
> > consensus. Innovation works best in small groups. Look what Bjarne
> > Stroustrup did - he had lots of support from other people, but during
> > the early days of C++, everything about it was ultimately his
> > responsibility; C++ would have been far less innovative if he'd had to
> > work with a large committee to develop it.
>
> So are you saying that unless I am an implementor, meaning a compiler writer
> or a C++ standard library creator working for a company which puts out a C++
> implementation, my proposals for change will meet with no success ? if that

No, I'm saying that the first place to take your proposals to is an
implementor. Try multiple implementors, if necessary, until you can find
one willing to give your idea a try. If you can't even convince a single
implementor that the idea is worth trying, you almost certainly will
never be able to convince a majority of the committee that the idea is
worth standardizing.

And that's as it should be - it should be much harder to get an idea
standardized than it is to get it implemented. The effects of trying an
idea as a extension on a single implementation, are limited to the users
of that implementation who bother trying out that extension. The effects
of a change to the standard apply to all users of any implementation,
and extend indefinitely into the future - once something has been added
to the standard, it can be very difficult to remove, even if it turns
out to be a very bad idea (like gets()).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Edward Diener" <eldiener@earthlink.net> writes:

|>  "James Kanze" <kanze@gabi-soft.de> wrote in message
|>  news:86u1qisapd.fsf@alex.gabi-soft.de...
|>  "Edward Diener" <eldiener@earthlink.net> writes:

|>  >>  I think the sort of disdain for such people's contributions, no
|>  >>  matter how much the committee feels that they themselves can
|>  >>  come up with all possible improvements and set the future
|>  >>  direction of C++, is a bad sign in the creative process of
|>  >>  changing or enhancing a computer language for future users.

|>  > I think that you are misinterpreting the situation.  The current
|>  > problem is that the committee has in the past been too open to
|>  > simple suggestions, without actual implementations behind them.
|>  > With the results that even five years after the stabilisation of
|>  > the standard, there is no released compiler which implements all
|>  > of it.

|>  This is largely the fault of the fact that C++ does not have a major
|>  monetary force behind it, such as MS with C# and VB, Borland with
|>  OP, and Sun with Java, and therefore many of the leading companies
|>  are in no hurry to implement a standard which directly competes with
|>  their own moneymakers.

I don't think that this is the reason (although it may play a part).
Most languages lack a major monetary force (or -- in the case of Fortran
-- the monetary force is against the changes in the standard).  The fact
is that even today, we don't know how any number of C++ features really
work.

|>  Except for the "export" keyword, whose possible implementation has
|>  been a subject of much debate, I don't know of any language or
|>  library feature which has been shown to be too difficult to
|>  implement.

Have you actually tried to implement any of them?

|>  There are a few compilers that are very close to the standard,
|>  Comeau I know of is one, and I don't think it is the impossibility
|>  of the standard which has kept many large companies from actually
|>  reaching 98%+ conformance, even though some of the rules,
|>  particularly regarding templates and overload resolution can be
|>  daunting.

Don't forget that it isn't enough to just implement something.  You have
to do it in a way that is reasonably efficient.  I remember when I first
started working on compilers; I was amazed at how easy it was to write a
parser (using yacc).  Until I tried to implement good error messages and
comfortable error recovery:-).  Just meeting the letter of the standard
is not enough.

|>  >  The role of standardization is NOT a "creative process of
|>  > changing or enhancing a computer language", it is first and
|>  > foremost the standardization of existing practice.  The creative
|>  > part has no role, or at least, should have no role in
|>  > standardization.

|>  Then at what point does the language get changed and/or improved ?

When the implementors offer extensions.  If the extension proves to be
useful, competitors adopt it (in order to maintain market share), and it
ends up being standardized in the next round.  When people have
experience with it, and know what is good and what is bad about it.

Once something is in the standard, it is there forever.  There's no
going back.

|>  If the role of standardization is just the "standardization of
|>  existing practice", then when does the other part occur ? Or is C++
|>  so wonderful in every respect, and so little in need of change
|>  and/or improvement, that there is no need to even have a process
|>  which would facilitate any changes ?

Actually, my impression over the last 10 years is that C++ needs a
process which would stabilize it some, and slow down changes.  Normally,
the standardization effort should have been that process, but it didn't
turn out that way.

|>  My interpretation of putting out a new C++ standard is that if
|>  creative ideas and implementations are presented and are shown to
|>  work and improve the language, then it can be part of the
|>  committee's process to add these to the language. Whether they do or
|>  not is their own decision.

How do you show that an idea works and improves the language, if not by
implementing it and trying it out?  Even today, I cannot say whether
export will help me or not -- I need something to ensure that a small
modification in a template implementation doesn't trigger the
recompilation of the entire project, but I have no idea whether export
will acheve this or not.  And having played around with different types
of iostreams lately (on an experimental basis -- not in production
code), I can definitly say that making the iostream classes templates
has not helped anything.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." <kuyper@wizard.net> writes:

> And that's as it should be - it should be much harder to get an idea
> standardized than it is to get it implemented. The effects of trying an
> idea as a extension on a single implementation, are limited to the users
> of that implementation who bother trying out that extension.

Furthermore, if nobody is interested in implementing the feature to
give your product an advantage over the competition, it is likely that
the feature won't be implemented once it is standardized, either.

Users sometimes try to "force" vendors into implementing some feature
by first smuggling it into the standard, then requesting standards
compliance from the vendor. The committee needs to protect both users
and vendors from such games.

Regards,
Martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Edward Diener" <eldiener@earthlink.net> writes:

> So are you saying that unless I am an implementor, meaning a
> compiler writer or a C++ standard library creator working for a
> company which puts out a C++ implementation, my proposals for change
> will meet with no success ?

No, you don't necessarily have to implement your proposal. You have to
*find* somebody to implement it. If all else fails, find some large
sum of money, and see if anybody can implement it for that money.

> if that is the case, then I am wasting my time even discussing ideas
> about C++ with anybody on this NG who might effect changes since I
> am not in the category above.

That could well be the case.

Regards,
Martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
>
> Actually, my impression over the last 10 years is that C++ needs a
> process which would stabilize it some, and slow down changes.  Normally,
> the standardization effort should have been that process, but it didn't
> turn out that way.
>

Actually, it did, although perhaps not as much as it should have.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:
> "James Kuyper Jr." <kuyper@wizard.net> wrote in message
> news:3CB62981.87ED43A6@wizard.net...
>
>>Edward Diener wrote:
>>
>>>"James Kanze" <kanze@gabi-soft.de> wrote in message
>>>news:86u1qisapd.fsf@alex.gabi-soft.de...
>>
>>.....
>>
>>>> The role of
>>>>standardization is NOT a "creative process of changing or enhancing a
>>>>computer language", it is first and foremost the standardization of
>>>>existing practice.  The creative part has no role, or at least, should
>>>>have no role in standardization.
>>>
>>>Then at what point does the language get changed and/or improved ? If
>>
> the
>
>>>role of standardization is just the "standardization of existing
>>
> practice",
>
>>>then when does the other part occur ? Or is C++ so wonderful in every
>>
>>Creativity is the responsibility of implementors, not the standardizers.
>>It's better that way; committees are not a good environment for
>>creativity, but they are a key tool in the process of reaching
>>consensus. Innovation works best in small groups. Look what Bjarne
>>Stroustrup did - he had lots of support from other people, but during
>>the early days of C++, everything about it was ultimately his
>>responsibility; C++ would have been far less innovative if he'd had to
>>work with a large committee to develop it.
>
>
> So are you saying that unless I am an implementor, meaning a compiler writer
> or a C++ standard library creator working for a company which puts out a C++
> implementation, my proposals for change will meet with no success ?

I think that no such thing was said.  It's just that you need to
speak with those who can implement and prove an idea, rather than
trying directly to sway the committee with unproven suggestions.

> if that
> is the case, then I am wasting my time even discussing ideas about C++ with
> anybody on this NG who might effect changes since I am not in the category
> above.

You do realize that a fair number of implementors read
this newsgroup, and will notice if any proposals they see
as being valuable to their customers appear, and may choose
to explore and implement those?  This group, and other forums,
can do a lot of work of helping to shape a proposal, discussing
it and finding its strengths and weaknesses.

> As to what happened in the past. changes nowadays go through a standards
> commitee and are not being done by a single person anymore as in the time
> when Mr. Stroustrup was shaping the language and assumed responsibilities
> for its changes, although I believe he is still much involved as a committee
> member.

We're saying that changes happen mostly outside of the world
of standards, to be incorporated into standards when they're
ready for prime-time.

Plenty of new material will make it into the next C++ Standard.
It will have been tested in real situations.  We have no shortage
of good ideas for things to do; the problem is in making them as
good as they need to be, not in generating ideas.  Certainly it's
possible, even likely, that parties not directly involved in
standardisation will have some of the best ideas, in which case
implementors will get interested and those ideas will meet the
real world before they formally meet the committee.
--
James Dennett <jdennett@acm.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kanze" <kanze@gabi-soft.de> wrote in message
news:86wuvdvypv.fsf@alex.gabi-soft.de...
"Edward Diener" <eldiener@earthlink.net> writes:

>>  My interpretation of putting out a new C++ standard is that if
>>  creative ideas and implementations are presented and are shown to
>>  work and improve the language, then it can be part of the
>>  committee's process to add these to the language. Whether they do or
>>  not is their own decision.

> How do you show that an idea works and improves the language, if not by
> implementing it and trying it out?  Even today, I cannot say whether
> export will help me or not -- I need something to ensure that a small
> modification in a template implementation doesn't trigger the
> recompilation of the entire project, but I have no idea whether export
> will acheve this or not.  And having played around with different types
> of iostreams lately (on an experimental basis -- not in production
> code), I can definitly say that making the iostream classes templates
> has not helped anything.

I don't believe that every proposed change should have to be implemented.
There are some changes which are, for the most part, self-evident and which
shouldn't need to be implemented to be considered. Implementing the change
might mean that the proposer of the change is not highly skilled enough to
be a C++ compiler writer or technically good enough to change some version
of his/her own C++ standard library files, but that should not necessarily
negate the proposal if it is a good idea and well considered. Of course I
recognize that even the most self-evident proposal may have side effects,
problems, and/or inconsistencies which the proposee hasn't considered, but
isn't that the reason why we have a C++ standard commitee, so that a well
proposed issue may be considered and discussed.

As an example of the above, I started this thread not with a formal proposal
but with a suggestion that the wide character messages facet use a wide
character file name for its message catalog rather than the current narrow
character file name. I originally mentioned this because it seemed normal to
me that a message catalog for wide character strings would most probably
exist on a system where wide character file names are the norm and not
narrow character file names, ie. A japanese version of Windows XXX. Now I
might be wrong and what I was considering might be untrue in most actual
situations ( A Japanese programmer of Windows XXX might consider it normal
to create a wide character message facet using a file with a narrow
character file name and Japanese Windows XXX and/or Japanese Windows XXX
might support both wide character and narrow character file name creation
using the same Japanese code page ), or I might be told that I have a point
but the committee did not think the reasoning was important enough to induce
a library change, but I fail to see how an implementation of this by me,
changing one of my compiler's C++ standard library message facet files,
would necessarily prove or disprove the point.

At the same time, attempting to implement a more complex proposal might very
well be important in proving that a proposed change is viable, and that is
something which I am not trying to deny. I just don't see how a blanket
determination of this can be made in every case before the proposal has even
been considered.

By insisting on implementation in every case, and not being willing to
listen to good and needed ideas for improvement without it, I think the C++
standards committee is doing themselves and the C++ community a disservice.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:
> "James Kanze" <kanze@gabi-soft.de> wrote in message
> news:86wuvdvypv.fsf@alex.gabi-soft.de...
> "Edward Diener" <eldiener@earthlink.net> writes:
>
>
>>> My interpretation of putting out a new C++ standard is that if
>>> creative ideas and implementations are presented and are shown to
>>> work and improve the language, then it can be part of the
>>> committee's process to add these to the language. Whether they do or
>>> not is their own decision.
>>
>
>>How do you show that an idea works and improves the language, if not by
>>implementing it and trying it out?  Even today, I cannot say whether
>>export will help me or not -- I need something to ensure that a small
>>modification in a template implementation doesn't trigger the
>>recompilation of the entire project, but I have no idea whether export
>>will acheve this or not.  And having played around with different types
>>of iostreams lately (on an experimental basis -- not in production
>>code), I can definitly say that making the iostream classes templates
>>has not helped anything.
>
>
> I don't believe that every proposed change should have to be implemented.

Before it becomes part of an ISO Standard, it should.  Standardisation
of programming languages is there to standardise existing practice.

> There are some changes which are, for the most part, self-evident and which
> shouldn't need to be implemented to be considered.

If they are so trivial, implementing them will not present a problem,
to someone who is interested enough to do them.  That does not have
to be the original proposer.

> Implementing the change
> might mean that the proposer of the change is not highly skilled enough to
> be a C++ compiler writer or technically good enough to change some version
> of his/her own C++ standard library files, but that should not necessarily
> negate the proposal if it is a good idea and well considered.

And as numerous people have said, it does not have to be the
original proposer who implements their idea.  If it is a good
idea, it should not be [too] hard for them to persuade at least
one implementor to try it.

> Of course I
> recognize that even the most self-evident proposal may have side effects,
> problems, and/or inconsistencies which the proposee hasn't considered, but
> isn't that the reason why we have a C++ standard commitee, so that a well
> proposed issue may be considered and discussed.

Well-proposed is a vague term!  One definition might require
that the idea has been proven by example to be implementable.

> As an example of the above, I started this thread not with a formal proposal
> but with a suggestion that the wide character messages facet use a wide
> character file name for its message catalog rather than the current narrow
> character file name. I originally mentioned this because it seemed normal to
> me that a message catalog for wide character strings would most probably
> exist on a system where wide character file names are the norm and not
> narrow character file names, ie. A japanese version of Windows XXX. Now I
> might be wrong and what I was considering might be untrue in most actual
> situations ( A Japanese programmer of Windows XXX might consider it normal
> to create a wide character message facet using a file with a narrow
> character file name and Japanese Windows XXX and/or Japanese Windows XXX
> might support both wide character and narrow character file name creation
> using the same Japanese code page ), or I might be told that I have a point
> but the committee did not think the reasoning was important enough to induce
> a library change, but I fail to see how an implementation of this by me,
> changing one of my compiler's C++ standard library message facet files,
> would necessarily prove or disprove the point.

Experience shows that more factors are found when an idea is
implemented than when it's discussed on a piece of paper.  This
is true of most things in programming, not just standardisation.
A specification isn't complete until we know that it provides
for an implementation.  An implementation eliminates, or at
least greatly reduces, the risk of finding various kinds of
flaws in a proposal.  It also makes it more concrete, so that
discussions can be more productive.

>
> At the same time, attempting to implement a more complex proposal might very
> well be important in proving that a proposed change is viable, and that is
> something which I am not trying to deny. I just don't see how a blanket
> determination of this can be made in every case before the proposal has even
> been considered.

We know that standardisation committees are not the best way
to determine what will work in practice, and have limited
resources.  It is know that better ideas will come from experience
than from theory.

>
> By insisting on implementation in every case, and not being willing to
> listen to good and needed ideas for improvement without it, I think the C++
> standards committee is doing themselves and the C++ community a disservice.

If the committee was unwilling to listen, that would be sad.
It is emphatically not the case.  They're just not willing to
add something to a standard unless it's proven, and don't have
time to spend discussing every idea that comes along.  If an
idea is a good one, someone will implement it, and then the
committee will likely get around to discussing it more formally.

I know that there are many informal routes by which ideas are
embraced by the C++ standards process.  The formal routes set
the barrier for entry a little higher, as they should.  Ideas
should rightly be proven before they are standardised.

-- James Dennett <jdennett@acm.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Edward Diener" <eldiener@earthlink.net> writes:

|>  "James Kanze" <kanze@gabi-soft.de> wrote in message
|>  news:86wuvdvypv.fsf@alex.gabi-soft.de...
|>  "Edward Diener" <eldiener@earthlink.net> writes:

|>  >>  My interpretation of putting out a new C++ standard is that if
|>  >>  creative ideas and implementations are presented and are shown
|>  >>  to work and improve the language, then it can be part of the
|>  >>  committee's process to add these to the language. Whether they
|>  >>  do or not is their own decision.

|>  > How do you show that an idea works and improves the language, if
|>  > not by implementing it and trying it out?  Even today, I cannot
|>  > say whether export will help me or not -- I need something to
|>  > ensure that a small modification in a template implementation
|>  > doesn't trigger the recompilation of the entire project, but I
|>  > have no idea whether export will acheve this or not.  And having
|>  > played around with different types of iostreams lately (on an
|>  > experimental basis -- not in production code), I can definitly say
|>  > that making the iostream classes templates has not helped
|>  > anything.

|>  I don't believe that every proposed change should have to be
|>  implemented.  There are some changes which are, for the most part,
|>  self-evident and which shouldn't need to be implemented to be
|>  considered.=20

If they are so self-evident, then there should be no problem
implementing them, right?  So where is the problem?

|>  Implementing the change might mean that the proposer of the change
|>  is not highly skilled enough to be a C++ compiler writer or
|>  technically good enough to change some version of his/her own C++
|>  standard library files, but that should not necessarily negate the
|>  proposal if it is a good idea and well considered. Of course I
|>  recognize that even the most self-evident proposal may have side
|>  effects, problems, and/or inconsistencies which the proposee hasn't
|>  considered, but isn't that the reason why we have a C++ standard
|>  commitee, so that a well proposed issue may be considered and
|>  discussed.

|>  As an example of the above, I started this thread not with a formal
|>  proposal but with a suggestion that the wide character messages
|>  facet use a wide character file name for its message catalog rather
|>  than the current narrow character file name.

An example of something for which the implementation is far from
evident.  Or rather, for which there are several, incompatible "evident"
implementations.  How do we know which one is more reasonable?

    [Very Windows specific example deleted...]

|>  At the same time, attempting to implement a more complex proposal
|>  might very well be important in proving that a proposed change is
|>  viable, and that is something which I am not trying to deny. I just
|>  don't see how a blanket determination of this can be made in every
|>  case before the proposal has even been considered.

|>  By insisting on implementation in every case, and not being willing
|>  to listen to good and needed ideas for improvement without it, I
|>  think the C++ standards committee is doing themselves and the C++
|>  community a disservice.

Nobody has insisted on implementation in every case.  On the other hand,
far too much was adopted in the last standard without any real
experience with it.  We don't want to repeat this mistake.  Anything
non-trivial should require existing practice.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:
>
> "James Kanze" <kanze@gabi-soft.de> wrote in message
> news:86wuvdvypv.fsf@alex.gabi-soft.de...
....
> > How do you show that an idea works and improves the language, if not by
> > implementing it and trying it out?  Even today, I cannot say whether
> > export will help me or not -- I need something to ensure that a small
> > modification in a template implementation doesn't trigger the
> > recompilation of the entire project, but I have no idea whether export
> > will acheve this or not.  And having played around with different types
> > of iostreams lately (on an experimental basis -- not in production
> > code), I can definitly say that making the iostream classes templates
> > has not helped anything.
>
> I don't believe that every proposed change should have to be implemented.
> There are some changes which are, for the most part, self-evident and which
> shouldn't need to be implemented to be considered. Implementing the change

But if they're so self-evidently worthwhile, you should have no trouble
convincing someone to implement them.

> might mean that the proposer of the change is not highly skilled enough to
> be a C++ compiler writer or technically good enough to change some version
> of his/her own C++ standard library files, but that should not necessarily
> negate the proposal if it is a good idea and well considered. Of course I

You keep harping on the issue of your own lack of the skills needed to
implement this. You keep ignoring the fact that you don't have to
implement it; you merely need to convince someone else to implement it.
If you can't find even a single implementor who's willing to try out
your idea, it's probably a lousy idea, and you'd probably be unable to
convince the committee to adopt it anyway, so why waste the committee's
time?

> recognize that even the most self-evident proposal may have side effects,
> problems, and/or inconsistencies which the proposee hasn't considered, but
> isn't that the reason why we have a C++ standard commitee, so that a well
> proposed issue may be considered and discussed.

No, that's the reason why we have implementors, who can try out an idea,
so that the side-effects, problems, and/or inconsistencies can be
discovered through actual use of a new idea, rather than counting on a
small number of committee members to notice them. It can be extremely
difficult to spot such problems merely by examining the specification
for a new feature, while it is usually quite easy to spot them when you
try to implement or use the feature. The committee's purpose is to
standardize the feature, once enough experience with it has been gained
to know a) that it can be implement it and b) how best to implement it.

> As an example of the above, I started this thread not with a formal proposal
> but with a suggestion that the wide character messages facet use a wide
> character file name for its message catalog rather than the current narrow
> character file name. I originally mentioned this because it seemed normal to
> me that a message catalog for wide character strings would most probably
> exist on a system where wide character file names are the norm and not
> narrow character file names, ie. A japanese version of Windows XXX. Now I
> might be wrong and what I was considering might be untrue in most actual
> situations ( A Japanese programmer of Windows XXX might consider it normal
> to create a wide character message facet using a file with a narrow
> character file name and Japanese Windows XXX and/or Japanese Windows XXX
> might support both wide character and narrow character file name creation
> using the same Japanese code page ), or I might be told that I have a point
> but the committee did not think the reasoning was important enough to induce
> a library change, but I fail to see how an implementation of this by me,
> changing one of my compiler's C++ standard library message facet files,
> would necessarily prove or disprove the point.

Well, the existence of an actual implementation would serve to resolve
the very same uncertainty you mention. There's not much point in
allowing wide character file names, unless someone actually needs them.
Having actually convinced an implementor to implement this feature would
go a long way toward proving that there is actually a need for such
filenames. This would be particularly true if, after the feature was
added, you found some people actually making use of it in their code.
I'm not suggesting this is a bad idea; I'm saying that if it is a good
idea, you should not have much trouble convincing someone to implement
it.

> By insisting on implementation in every case, and not being willing to
> listen to good and needed ideas for improvement without it, I think the C++
> standards committee is doing themselves and the C++ community a disservice.

They'd be doing a greater disservice by wasting their limited time
investigating ideas so poor that the proposer was unable to convince
anyone to try to implement them.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3CB239B4.E41D0B98@acm.org...
> > Edward Diener wrote:
> > >
> > > I tossed out an idea. I can not attend meetings. Please specify the path
> by
> > > which I can make a formal proposal.
> > >
> >
> > The first step is to implement what you propose, and get some experience
> > using it. That will often make a formal proposal moot.
> >
>
> I am not a compiler writer. Nor can I implement a change to the standard
> library in most non-trivial cases. Could you please be more specific in what
> you mean ?

The Free Software Foundation <http://www.fsf.org> provides an existing
implementation of C++, with full source code, which you're free to
modify in accordance with the very liberal conditions of their
"copyleft" agreement. I won't claim it's easy to figure out how it
works, or easy to modify, but the simple existence of such a thing
drastically lowers the barriers to innovation.

Another alternative is to find someone who is a language implementor,
and to convince them to try your idea as an experimental extension.
Again, the FSF people are good candidates - they are, if anything, too
eager to consider new extensions. However, like the C++ committee
itself, they're made up of volunteers, which means that they're likely
to ask you to do most of the work.

Nothing is more effective for getting an idea standardized, than to
already have a working implementation of that idea, and a large body of
users already experienced with the idea, clamoring for it be
standardized.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3CB2EF4B.DA3C3BBA@acm.org...
> Edward Diener wrote:
> >
> > "Pete Becker" <petebecker@acm.org> wrote in message
> > news:3CB239B4.E41D0B98@acm.org...
> > > Edward Diener wrote:
> > > >
> > > > I tossed out an idea. I can not attend meetings. Please specify the
path
> > by
> > > > which I can make a formal proposal.
> > > >
> > >
> > > The first step is to implement what you propose, and get some
experience
> > > using it. That will often make a formal proposal moot.
> > >
> >
> > I am not a compiler writer. Nor can I implement a change to the standard
> > library in most non-trivial cases. Could you please be more specific in
what
> > you mean ?
> >
>
> I mean what I said: implement it, understand it, and if you still think
> it's worthwhile, propose it. There are some things that are out of the
> reach of most users. But writing exception classes that provide both a
> char and a wchar_t reason is easy enough to do, until you face the issue
> of the relationship between the two strings.

OK, I see what you mean. I have actual done this last item you mentioned
directly above for a particular situation and am testing it out now in an
implementation I am working with. Testing proposals using non-C++ standard
classes is certainly doable.

> That's the real internal
> design issue, and it has nothing to do with compilers or with the
> standard library. And once that's done there's the question of
> usability, which is where experience is critical: it may be that these
> exceptions turn out to be too hard to use.

Certainly experience with using an idea is valuable, but ideas may have
merit of their own as an exploration point for further possibilities rather
than as a final point of actual changes and experience. Proposing an idea
which may not work smoothly in actual current experience can still serve as
a starting point for a change which will. I feel that some proposed changes
can be so simple that actual experience with the change is mostly
irrelevant.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3CB2D90B.1CC25054@wizard.net...
> Edward Diener wrote:
> >
> > "Pete Becker" <petebecker@acm.org> wrote in message
> > news:3CB239B4.E41D0B98@acm.org...
> > > Edward Diener wrote:
> > > >
> > > > I tossed out an idea. I can not attend meetings. Please specify the
path
> > by
> > > > which I can make a formal proposal.
> > > >
> > >
> > > The first step is to implement what you propose, and get some
experience
> > > using it. That will often make a formal proposal moot.
> > >
> >
> > I am not a compiler writer. Nor can I implement a change to the standard
> > library in most non-trivial cases. Could you please be more specific in
what
> > you mean ?
>
> The Free Software Foundation <http://www.fsf.org> provides an existing
> implementation of C++, with full source code, which you're free to
> modify in accordance with the very liberal conditions of their
> "copyleft" agreement. I won't claim it's easy to figure out how it
> works, or easy to modify, but the simple existence of such a thing
> drastically lowers the barriers to innovation.
>

I don't underestimate the value of having a free C++ compiler with open
source code but it is a daunting task for even a good C++ programmer such as
myself to attempt to change the compiler in order to test out a new language
feature. Nonetheless, thanks for pointing out this potential avenue.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:

> Certainly experience with using an idea is valuable, but ideas may have
> merit of their own as an exploration point for further possibilities rather
> than as a final point of actual changes and experience.


If a proponent of a change is not interested enough to experiment with
the proposed change, who do you assume would be interested enough?

> Proposing an idea
> which may not work smoothly in actual current experience can still serve as
> a starting point for a change which will.


If someone wants a change, he/she should determine what is the best way
to change something. Proposing a change to the public like to this forum
will spread the idea to a generally interested forum but even if there
is heavy interest and ideas are given from a forum the proponent(s) has
to do the actual work: Others have their own ideas and are also
generally too busy.

> I feel that some proposed changes
> can be so simple that actual experience with the change is mostly
> irrelevant.


Experience shows that no change is so simple that it has no unexpected
impact: Experience with any change is crucially necessary. For an even
more practical point of view: The committee decided (at the Sophia-
Antipolis meeting) to accept proposals only if they are implemented.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Dietmar Kuehl" <dietmar_kuehl@yahoo.com> wrote in message
news:3CB36E29.8040709@yahoo.com...
> Edward Diener wrote:
> > I feel that some proposed changes
> > can be so simple that actual experience with the change is mostly
> > irrelevant.
>
> Experience shows that no change is so simple that it has no unexpected
> impact: Experience with any change is crucially necessary. For an even
> more practical point of view: The committee decided (at the Sophia-
> Antipolis meeting) to accept proposals only if they are implemented.

Are you telling me that if a proposal is made to change anything in the Ansi
C++ standard, if that proposal has not already been implemented by either a
compiler change or a library change in an existing implementation, the
proposal will not be considered by the Ansi C++ committee ?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Edward Diener" <eldiener@earthlink.net> wrote:
> Are you telling me that if a proposal is made to change anything in the Ansi
> C++ standard, if that proposal has not already been implemented by either a
> compiler change or a library change in an existing implementation, the
> proposal will not be considered by the Ansi C++ committee ?

Basically: Yes. It somewhat depends on what the change does: To fix existing
problems, an implementation is not necessarily needed (although it would be
nice to verify that the solution indeed solves the problem). The standard
will, however, do no new inventions: If something new is to be added to the
language, an implementation has to exist showing the new feature. For example,
Boost libraries show the operation of new libraries: This was a major
motivation behind the thing.

To me, library extensions are pretty easy to demonstrate: you just have to
implement the library. Since I have implemented most of the standard library
for my private use (you can download my implementation, however), this is a
natural thing. With respect to language extensions (in the sense of the core
language; in some sense library extensions are also language extensions) it is
considerable harder from my point of view. Those having implemented a compiler
might, however, disagree :-)

However, you don't need a full standard C++ implementation to demonstrate a
certain feature: It is sufficient to implement the portion with which the
change interacts and it can be extracted from the standard library. For
example, with respect to a wide character name of message facets you just need
to implement you own message facets dealing with this particular issue.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Edward Diener" <eldiener@earthlink.net> writes:

> Are you telling me that if a proposal is made to change anything in
> the Ansi C++ standard, if that proposal has not already been
> implemented by either a compiler change or a library change in an
> existing implementation, the proposal will not be considered by the
> Ansi C++ committee ?

Not speaking for the ISO(!) committee: I would certainly hope this is
the case. A number of features are part currently of the C++ standard
that are hard to implement, and where the specification authors erred
when writing them down initially. There is no reason to repeat the
same mistake, IMO.

Notice that, as an end user, you don't have to convince the
committee. Just convince your compiler vendor instead, e.g. by funding
the development of an extension.

Regards,
Martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Dietmar Kuehl" <dietmar_kuehl@yahoo.com> wrote in message
news:5b15f8fd.0204100745.3580bfe0@posting.google.com...
> "Edward Diener" <eldiener@earthlink.net> wrote:
> > Are you telling me that if a proposal is made to change anything in the
Ansi
> > C++ standard, if that proposal has not already been implemented by
either a
> > compiler change or a library change in an existing implementation, the
> > proposal will not be considered by the Ansi C++ committee ?
>
> Basically: Yes. It somewhat depends on what the change does: To fix
existing
> problems, an implementation is not necessarily needed (although it would
be
> nice to verify that the solution indeed solves the problem). The standard
> will, however, do no new inventions: If something new is to be added to
the
> language, an implementation has to exist showing the new feature. For
example,
> Boost libraries show the operation of new libraries: This was a major
> motivation behind the thing.

This is more easily done than compiler changes as most good C++ programmers
can create libraries.

>
> To me, library extensions are pretty easy to demonstrate: you just have to
> implement the library. Since I have implemented most of the standard
library
> for my private use (you can download my implementation, however), this is
a
> natural thing. With respect to language extensions (in the sense of the
core
> language; in some sense library extensions are also language extensions)
it is
> considerable harder from my point of view. Those having implemented a
compiler
> might, however, disagree :-)

Very difficult for non-compiler writers to write a change in a language
feature into a compiler.

> However, you don't need a full standard C++ implementation to demonstrate
a
> certain feature: It is sufficient to implement the portion with which the
> change interacts and it can be extracted from the standard library. For
> example, with respect to a wide character name of message facets you just
need
> to implement you own message facets dealing with this particular issue.

That is much more sensible than requiring a proposal to have to be
implemented as a current compiler change for a language feature or an
existing standard library change for a library feature. While I am certainly
not against someone doing coding to attempt to prove that a proposal can
work with C++ as it currently is, I don't see the need for Draconian
measures just to make an intelligent proposal which might be considered by
the C++ committee. I am aware that the C++ committee wants to weed out
proposals which may sound good but which don't work in practical usage, but
certainly the intelligence of members of the committee can consider a
proposal which might offer an improvement to C++ and be worthwhile without
knowing immediately all of the ramifications involved in the change. And
yes, I would expect the proposee to do the necessary work in attempting to
consider any ramifications and responding to the committee's doubts about
the viability of a proposal in whatever practical situations would be deemed
to occur.

If the committee gets to the point where only working implementations will
be considered for proposed changes to C++, I think it is greatly losing out
on those who may have important suggestions and ideas to make, in the form
of proposals, but who are not compiler writers or library implementors. I
think the sort of disdain for such people's contributions, no matter how
much the committee feels that they themselves can come up with all possible
improvements and set the future direction of C++, is a bad sign in the
creative process of changing or enhancing a computer language for future
users.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:
....
> If the committee gets to the point where only working implementations will
> be considered for proposed changes to C++, I think it is greatly losing out
> on those who may have important suggestions and ideas to make, in the form
> of proposals, but who are not compiler writers or library implementors. I

If an idea is so unconvincing that you can't find a single implementor
who would be willing to try it out as an extension, I doubt that it's a
good enough idea to justify adding it to the standard. It's a lot easier
to convince a single writer/implementor than the entire committee, so
even if it was brought before the committee, such an unconvincing idea
would probably be rejected anyway.

Keep in mind the severe resource constraints that the committee works
under; it barely has enough time to consider the ideas that have been
proven out; it has no time to waste on ideas that haven't been proven
out yet. Just think of the individual implementors as pre-screeners for
the committee.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Edward Diener" <eldiener@earthlink.net> writes:

|>  If the committee gets to the point where only working
|>  implementations will be considered for proposed changes to C++, I
|>  think it is greatly losing out on those who may have important
|>  suggestions and ideas to make, in the form of proposals, but who are
|>  not compiler writers or library implementors.

Historically, the role of standardization is not to invent, but to
standardize existing practice (at least in the case of language
standards).  The C++ committee deviated quite a bit from this role in
C98.  Some deviation is almost always necessary, as existing practice
may vary; C90 added function prototypes for example (basing itself on
the existing practice in C++, but innovating with regards to mixing of
prototyped and non-prototyped functions) and in the preprocessor (where
there were several conflicting existing practices).  In the case of C++,
however, there was some total invention: export is an obvious example,
but so is e.g. making the streams templates (which would in retrospect
seem to be a mistake, since the semantics of basic_streambuf<char> and
basic_streambuf<wchar_t> are different, and instantiations for any other
type tend to wander so far into the realm of user defined behavior that
one wonders what the advantages are).

Globally, I think that I am not alone in feeling that too much
innovation is a disservice to the C++ community.  In this regard, I am
exceedingly pleased with what boost is trying to do -- obviously, not
everything in boost will make it into the standard, but for those parts
that do, we can be sure that the standard will be based on existing
practice.

|>  I think the sort of disdain for such people's contributions, no
|>  matter how much the committee feels that they themselves can come up
|>  with all possible improvements and set the future direction of C++,
|>  is a bad sign in the creative process of changing or enhancing a
|>  computer language for future users.

I think that you are misinterpreting the situation.  The current problem
is that the committee has in the past been too open to simple
suggestions, without actual implementations behind them.  With the
results that even five years after the stabilisation of the standard,
there is no released compiler which implements all of it.  The role of
standardization is NOT a "creative process of changing or enhancing a
computer language", it is first and foremost the standardization of
existing practice.  The creative part has no role, or at least, should
have no role in standardization.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kanze" <kanze@gabi-soft.de> wrote in message
news:86u1qisapd.fsf@alex.gabi-soft.de...
"Edward Diener" <eldiener@earthlink.net> writes:

>>  I think the sort of disdain for such people's contributions, no
>>  matter how much the committee feels that they themselves can come up
>>  with all possible improvements and set the future direction of C++,
>>  is a bad sign in the creative process of changing or enhancing a
>>  computer language for future users.

> I think that you are misinterpreting the situation.  The current problem
> is that the committee has in the past been too open to simple
> suggestions, without actual implementations behind them.  With the
> results that even five years after the stabilisation of the standard,
> there is no released compiler which implements all of it.

This is largely the fault of the fact that C++ does not have a major
monetary force behind it, such as MS with C# and VB, Borland with OP, and
Sun with Java, and therefore many of the leading companies are in no hurry
to implement a standard which directly competes with their own moneymakers.
Except for the "export" keyword, whose possible implementation has been a
subject of much debate, I don't know of any language or library feature
which has been shown to be too difficult to implement. There are a few
compilers that are very close to the standard, Comeau I know of is one, and
I don't think it is the impossibility of the standard which has kept many
large companies from actually reaching 98%+ conformance, even though some of
the rules, particularly regarding templates and overload resolution can be
daunting.

>  The role of
> standardization is NOT a "creative process of changing or enhancing a
> computer language", it is first and foremost the standardization of
> existing practice.  The creative part has no role, or at least, should
> have no role in standardization.

Then at what point does the language get changed and/or improved ? If the
role of standardization is just the "standardization of existing practice",
then when does the other part occur ? Or is C++ so wonderful in every
respect, and so little in need of change and/or improvement, that there is
no need to even have a process which would facilitate any changes ? My
interpretation of putting out a new C++ standard is that if creative ideas
and implementations are presented and are shown to work and improve the
language, then it can be part of the committee's process to add these to the
language. Whether they do or not is their own decision.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"nmtop40" <nmtop40@nmtop40.homechoice.co.uk> wrote in message
news:3cb07ec7$1@news1.homechoice.co.uk...
> > In a previous post I brought up the situation, which may be seen as
> another
> > problem but which I see as related, that the standard exception
hierarchy
> > always returns a string of chars for its What() message and suggested
that
> > the hierarchy be templatized ( like basic_string itself ) on a character
> > type so that wide character exceptions would return a string of wchar_t
> for
> > its What() message.
>
> There is no law that exceptions you throw have to be std::exception, and
> even
> if you do you can derive another class from it that has a const wchar_t *
> wwhat()
> method.

I have already done that but I still belive that the std::exception
hierarchy should support wide character What() strings.

> I agree about filenames though.

Thanks, but I believe P.J.Plauger who answered my original post decided to
bail out when I suggested that a change should be made to the C++ standard
library in that regard. From both my posts, I gather that to ask for a
change in the C++ standard, one has to make a Proposal on this NG somehow.
Of course in another previous post I suggested
that a means to make a formal proposal be specified and I was told to do so
on this NG. Unfortunately I do not know the magic words to accomplish this
and was evidently relying on just reason and discussion to do so.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Edward Diener" <eldiener@earthlink.net> wrote in message
news:em7s8.24258$nt1.1974256@newsread2.prod.itd.earthlink.net...

> I have already done that but I still belive that the std::exception
> hierarchy should support wide character What() strings.
>
> > I agree about filenames though.
>
> Thanks, but I believe P.J.Plauger who answered my original post decided to
> bail out when I suggested that a change should be made to the C++ standard
> library in that regard.

I beg your pardon? I said all that I felt needed saying. Don't recall bailing
out.

>                        From both my posts, I gather that to ask for a
> change in the C++ standard, one has to make a Proposal on this NG somehow.

That's one way. You can also attend meetings.

> Of course in another previous post I suggested
> that a means to make a formal proposal be specified and I was told to do so
> on this NG. Unfortunately I do not know the magic words to accomplish this
> and was evidently relying on just reason and discussion to do so.

Well, you can toss out ideas and hope that someone else will do the hard
work necessary to a) make a proposal, b) present it to the committee, c) deal
with the inevitable feedback, d) see it through to a successful vote, and
e) ensure that the normative change to the C++ Standard does what you want.
My major point in replying to your earlier postings was that getting to e)
from a) with a minimum of effort is not a Right Guaranteed to All Posters
in Any System That is Truly Democratic. Democracy takes work, and often
you get out of it only what you put into it.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"P.J. Plauger" <pjp@dinkumware.com> wrote in message
news:3cb19462$0$11204$4c41069e@reader1.ash.ops.us.uu.net...
> "Edward Diener" <eldiener@earthlink.net> wrote in message
> news:em7s8.24258$nt1.1974256@newsread2.prod.itd.earthlink.net...
>
> > I have already done that but I still belive that the std::exception
> > hierarchy should support wide character What() strings.
> >
> > > I agree about filenames though.
> >
> > Thanks, but I believe P.J.Plauger who answered my original post decided
to
> > bail out when I suggested that a change should be made to the C++
standard
> > library in that regard.
>
> I beg your pardon? I said all that I felt needed saying. Don't recall
bailing
> out.

You didn't respond to my message any further in this thread although your
response, albeit a bit cryptic, suggested that you viewed the present
solution as possibly inadequate. I viewed that as bailing out of any effort
to consider a change to the C++ standard library in the way I originally
mentioned. Of course you aren't under any necessity to consider what I
suggested any further, and of course you can personally reject the idea
entirely, but that is the way I saw it.

>
> >                        From both my posts, I gather that to ask for a
> > change in the C++ standard, one has to make a Proposal on this NG
somehow.
>
> That's one way. You can also attend meetings.
>
> > Of course in another previous post I suggested
> > that a means to make a formal proposal be specified and I was told to do
so
> > on this NG. Unfortunately I do not know the magic words to accomplish
this
> > and was evidently relying on just reason and discussion to do so.
>
> Well, you can toss out ideas and hope that someone else will do the hard
> work necessary to a) make a proposal, b) present it to the committee, c)
deal
> with the inevitable feedback, d) see it through to a successful vote, and
> e) ensure that the normative change to the C++ Standard does what you
want.

I tossed out an idea. I can not attend meetings. Please specify the path by
which I can make a formal proposal.

> My major point in replying to your earlier postings was that getting to e)
> from a) with a minimum of effort is not a Right Guaranteed to All Posters
> in Any System That is Truly Democratic. Democracy takes work, and often
> you get out of it only what you put into it.

I am willing to make more than a minimum of effort, short of attending
meetings which is both financially and time-wise impossible for me. If this
fact keeps me, or anybody, from making a serious proposal, then I think that
should be said outright by the commitee. If it does not, then I think the
method by which a serious proposal is to be made to the C++ committee should
be defined.

I am not at odds with the committee. I appreciate very much the work that
the comittee has and is doing to specify and promote an excellent language
through their work. I do feel that the committee seems to be at odds with
the C++ community members who want to contribute possible ideas and
proposals but who simply can not attend committee meetings to promote and/or
defend their proposals. Surely there must be a way for this situation to be
resolved but if it can not be resolved, short of a proposee attending
committee meetings, then the C++ committee should just say so and be done
with it.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:
>
> I tossed out an idea. I can not attend meetings. Please specify the path by
> which I can make a formal proposal.
>

Write up a detailed proposal.  It should refer (at least by
numerical reference) to any relevant sections of the standard,
ideally taking into account corrections arising from the first
Technical Corrigendum (though that would not be an absolute
requirement).  It should describe the problem you plan to
solve, your solution in detail, with examples, an assessment
of the impact, and assessments of any performance/portability
concerns.  It need not immediately be written in "standardese"
but should aim to be as formal as practical.

Your goal in writing such a proposal should be to show that
(a) a solution to a problem is needed, and (b) that such a
solution is possible and worthwhile.  Worthwhile takes into
account all of the related costs -- the cost to implementors,
cost to users learning to use C++, etc. -- as well as the
benefits you expect to accrue.  Only if the proposal, clearly
expressed, makes a plausible case, and if you explicitly ask,
are you likely to find a committee member willing to champion
it.

Your claim that we do not accept proposals from people who
cannot attend meetings is wrong, so there is no need to admit
to any such thing.  We just don't have time to follow every
vague idea -- only those with a reasonable chance of success.
If you're willing to listen to feedback and act on it then
the fact that you cannot physically be present at committee
meetings will not disallow your proposal.

I think Bjarne recently said informally that a first pass at
a proposal, in order to be worth serious discussion, ought to
expect to be around 10 pages long.  Obviously that would vary
depending on the complexity of the proposed change, but should
serve to give you some idea of the level of commitment involved
in making a serious proposal.  Even such a lengthy document is
likely to initially receive a barrage of questions, the answers
to which should be incorporated into a single revised document.
Ideally the changes would give rise to a rationale as well, to
avoid revisiting the same questions over and over.  During the
work to produce the 1998 standard, rationales were often lost,
but since then, for example with DRs, the committee have been
better at tracking their reasons for making decisions.  That
tracking takes a lot of work, but is very valuable.

It's also worth saying that if a proposal is obviously a
great one then a much shorter presentation is likely to get
it discussed by the committee.

--
James Dennett <jdennett@acm.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:
>
> I tossed out an idea. I can not attend meetings. Please specify the path by
> which I can make a formal proposal.
>

The first step is to implement what you propose, and get some experience
using it. That will often make a formal proposal moot.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Dennett" <jdennett@acm.org> wrote in message
news:3CB1FEA2.6060408@acm.org...
> Edward Diener wrote:
> >
> > I tossed out an idea. I can not attend meetings. Please specify the path
by
> > which I can make a formal proposal.
> >
>
> Write up a detailed proposal.  It should refer (at least by
> numerical reference) to any relevant sections of the standard,
> ideally taking into account corrections arising from the first
> Technical Corrigendum (though that would not be an absolute
> requirement).

Where is the Technical Corrigendum to be found ?

>  It should describe the problem you plan to
> solve, your solution in detail, with examples, an assessment
> of the impact, and assessments of any performance/portability
> concerns.  It need not immediately be written in "standardese"
> but should aim to be as formal as practical.
>
> Your goal in writing such a proposal should be to show that
> (a) a solution to a problem is needed, and (b) that such a
> solution is possible and worthwhile.  Worthwhile takes into
> account all of the related costs -- the cost to implementors,
> cost to users learning to use C++, etc. -- as well as the
> benefits you expect to accrue.  Only if the proposal, clearly
> expressed, makes a plausible case, and if you explicitly ask,

What does this mean "if you explicitly ask" ? If I explicitly ask what ?
That a committee member is willing to champion the proposal ?

> are you likely to find a committee member willing to champion
> it.

Thanks for the detailed response on how to create a proposal.

>
> Your claim that we do not accept proposals from people who
> cannot attend meetings is wrong,

I never claimed that. Please do not post such an erroneous statement.

> so there is no need to admit
> to any such thing.  We just don't have time to follow every
> vague idea -- only those with a reasonable chance of success.
> If you're willing to listen to feedback and act on it then
> the fact that you cannot physically be present at committee
> meetings will not disallow your proposal.
>
> I think Bjarne recently said informally that a first pass at
> a proposal, in order to be worth serious discussion, ought to
> expect to be around 10 pages long.  Obviously that would vary
> depending on the complexity of the proposed change, but should
> serve to give you some idea of the level of commitment involved
> in making a serious proposal.  Even such a lengthy document is
> likely to initially receive a barrage of questions, the answers
> to which should be incorporated into a single revised document.
> Ideally the changes would give rise to a rationale as well, to
> avoid revisiting the same questions over and over.  During the
> work to produce the 1998 standard, rationales were often lost,
> but since then, for example with DRs, the committee have been
> better at tracking their reasons for making decisions.  That
> tracking takes a lot of work, but is very valuable.
>
> It's also worth saying that if a proposal is obviously a
> great one then a much shorter presentation is likely to get
> it discussed by the committee.
>

I think I will just make the proposal as best I can accordingly to the
guidelines which you have set out and not worry about the length or
shortness of it.

Let me just add that the kind of more detailed explanation for making a
proposal which you have presented to me is something which I think the C++
standards comitteee should make available for everybody to peruse and
understand.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3CB239B4.E41D0B98@acm.org...
> Edward Diener wrote:
> >
> > I tossed out an idea. I can not attend meetings. Please specify the path
by
> > which I can make a formal proposal.
> >
>
> The first step is to implement what you propose, and get some experience
> using it. That will often make a formal proposal moot.
>

I am not a compiler writer. Nor can I implement a change to the standard
library in most non-trivial cases. Could you please be more specific in what
you mean ?


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3CB239B4.E41D0B98@acm.org...
> > Edward Diener wrote:
> > >
> > > I tossed out an idea. I can not attend meetings. Please specify the path
> by
> > > which I can make a formal proposal.
> > >
> >
> > The first step is to implement what you propose, and get some experience
> > using it. That will often make a formal proposal moot.
> >
>
> I am not a compiler writer. Nor can I implement a change to the standard
> library in most non-trivial cases. Could you please be more specific in what
> you mean ?
>

I mean what I said: implement it, understand it, and if you still think
it's worthwhile, propose it. There are some things that are out of the
reach of most users. But writing exception classes that provide both a
char and a wchar_t reason is easy enough to do, until you face the issue
of the relationship between the two strings. That's the real internal
design issue, and it has nothing to do with compilers or with the
standard library. And once that's done there's the question of
usability, which is where experience is critical: it may be that these
exceptions turn out to be too hard to use.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> In a previous post I brought up the situation, which may be seen as
another
> problem but which I see as related, that the standard exception hierarchy
> always returns a string of chars for its What() message and suggested that
> the hierarchy be templatized ( like basic_string itself ) on a character
> type so that wide character exceptions would return a string of wchar_t
for
> its What() message.

There is no law that exceptions you throw have to be std::exception, and
even
if you do you can derive another class from it that has a const wchar_t *
wwhat()
method.

I agree about filenames though.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

The message catalog opened in the std::messages<> facet is specified as
std::basic_string<char> type. I would have guessed the string type would
have been parameterized on the std::messages<> facet character type so that
for wide character messages a wide character filename would be opened. This
makes sense for locales for areas of the world where wide characters are the
language norm. I would expect, let's say, a Japanese user to have their
filenames be wide character strings on their OS of choice and not
single-byte Ascii strings. But perhaps my expectation is wrong and if it is
so I would love to be so informed.

Could anybody give me the rationale why the std::messages<> facet was
designed to take an Ascii string as the message catalog filename rather than
a string parameterized on the std::messages<> character type ?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Edward Diener" <eldiener@earthlink.net> wrote in message
news:Pcnq8.11088$ml2.843478@newsread1.prod.itd.earthlink.net...

> The message catalog opened in the std::messages<> facet is specified as
> std::basic_string<char> type. I would have guessed the string type would
> have been parameterized on the std::messages<> facet character type so that
> for wide character messages a wide character filename would be opened. This
> makes sense for locales for areas of the world where wide characters are the
> language norm. I would expect, let's say, a Japanese user to have their
> filenames be wide character strings on their OS of choice and not
> single-byte Ascii strings. But perhaps my expectation is wrong and if it is
> so I would love to be so informed.
>
> Could anybody give me the rationale why the std::messages<> facet was
> designed to take an Ascii string as the message catalog filename rather than
> a string parameterized on the std::messages<> character type ?

To paraphrase Woody Allen, it was a concept that got as far as a treatment
and never quite became a screenplay.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"P.J. Plauger" <pjp@dinkumware.com> wrote in message
news:3caa1ba0$0$9888$4c41069e@reader1.ash.ops.us.uu.net...
> "Edward Diener" <eldiener@earthlink.net> wrote in message
> news:Pcnq8.11088$ml2.843478@newsread1.prod.itd.earthlink.net...
>
> > The message catalog opened in the std::messages<> facet is specified as
> > std::basic_string<char> type. I would have guessed the string type would
> > have been parameterized on the std::messages<> facet character type so
that
> > for wide character messages a wide character filename would be opened.
This
> > makes sense for locales for areas of the world where wide characters are
the
> > language norm. I would expect, let's say, a Japanese user to have their
> > filenames be wide character strings on their OS of choice and not
> > single-byte Ascii strings. But perhaps my expectation is wrong and if it
is
> > so I would love to be so informed.
> >
> > Could anybody give me the rationale why the std::messages<> facet was
> > designed to take an Ascii string as the message catalog filename rather
than
> > a string parameterized on the std::messages<> character type ?
>
> To paraphrase Woody Allen, it was a concept that got as far as a treatment
> and never quite became a screenplay.

Is there any movement in the C++ standard committee to revisit this problem
or is it seen as being good enough not to need change ? Would a proposal to
match the filename string with the character type be considered by the
committee or is it seen as part of a larger localization problem in the C++
standard library which needs to be addressed ?.

In a previous post I brought up the situation, which may be seen as another
problem but which I see as related, that the standard exception hierarchy
always returns a string of chars for its What() message and suggested that
the hierarchy be templatized ( like basic_string itself ) on a character
type so that wide character exceptions would return a string of wchar_t for
its What() message.

Since I have been working recently with C++ and localization, certain
situations which seem like weaknesses in the language and libraries has
popped up and the current post illustrates one of them.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]