From 7042256995577935261 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,40bc29384a77c552 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-04-13 08:25:01 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: James Dennett Newsgroups: comp.std.c++ Subject: Re: Messages facet and wide character filename Date: Sat, 13 Apr 2002 15:24:29 GMT Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <3CB834B8.6010606@acm.org> References: <3cb19462$0$11204$4c41069e@reader1.ash.ops.us.uu.net> <3CB239B4.E41D0B98@acm.org> <_yts8.1524$CA6.117218@newsread1.prod.itd.earthlink.net> <3CB2EF4B.DA3C3BBA@acm.org> <3CB36E29.8040709@yahoo.com> <5b15f8fd.0204100745.3580bfe0@posting.google.com> <86u1qisapd.fsf@alex.gabi-soft.de> <86wuvdvypv.fsf@alex.gabi-soft.de> <7JJt8.3357$L1.309058@newsread2.prod.itd.earthlink.net> X-Trace: mail2news.demon.co.uk 1018711474 mail2news:20834 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020313 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 120 Xref: archiver1.google.com comp.std.c++:10543 Edward Diener wrote: > "James Kanze" wrote in message > news:86wuvdvypv.fsf@alex.gabi-soft.de... > "Edward Diener" 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 --- [ 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 ]