"Nicholas Salerno" <ndsalerno@yahoo.com> wrote in message
news:b9da50a9.0209011155.2cbaf503@posting.google.com...
<SNIP/>
> After all, we are talking about the next C++ standard.  So I didn't
> need to be told that "= 0" makes a function pure virtual.  In fact,
> that is why I posted the "abstract" item.  It is because I think "=0"
> is stupid.
<SNIP/>
> The "= 0" feature doesn't make that list [not complaining about them]
> though, and so I will complain about it.  What is going on here?  An
> assignment statement??

In my opinion an assignment of sorts is going on. 0 has a special meaning
with regard to pointers. A virtual function in a class is just a function
pointer entry in a hidden static virtual function table for the class. This
has always been quite intuitive for me.

Setting it to 0 is like setting int *ptr = 0. To me this means that there is
no function to be pointed to. The underlying implementation doesn't have to
use 0 (in fact I don't believe Microsoft C++ compiler does, it uses a
pointer to a function that calls abort/terminate with an explanitory - I
assume incase an instance of that class somehow gets created through casting
or something).

>
> Second, many people posted the use of the preprocessor as a solution
> to my list of wanted keywords.  Yuck!!  I used to do that but now I
> avoid the preprocessor like the plague.  I used to do things like
> "#define abstract = 0" but you know what, it is not really standard in
> the sense that other programmers are going to see "void MyFunction
> abstract;" and be confused until they learn all my little preprocessor
> definitions.  To make this short I have learned the hard way to avoid
> using the preprocessor in that fashion.  There is a place for the
> preprocessor.  Using it like a language is NOT one of them.
> Microsoft's MFC library is proof of concept.

Totally agree. I do use the pre-processor in limited scenarios that I
believe are self describing. MFC does go too far though IMHO. We'll never
get agreement on how far to take the preprocessor because that's very much a
personal thing from purists who never believe the preprocessor should be
used (and may well have worked on the implementation of the Java
language/compiler) to those who use it extensivley (and probably worked on
MFC)!

Regards
John.
---
[ 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                       ]

ndsalerno@yahoo.com (Nicholas Salerno) writes:

> Attila Feher <Attila.Feher@lmf.ericsson.se> wrote in message
>  > I am sorry, but if I use module as a class name inside my own namespace
>  > of a framework what is wrong with that?  Why is it not a good name?  It
>  > is the base class for all modules.  I use my own namespace.  The only
>  > way to break my code is to introduce a new keyword - without thinking of
>  > the consequences.
>  >
>  > Attila
>  >
>
> Even if module was not keyword, I have to ask what is a module?

Maybe you are writing a Fortran 90 compiler, and the class module is
meant to represent the Fortran 90 concept named, well, module?

> Sounds too vague and doesn't give me any indication of the nature of
> the class.  I think "module" is not a good name for a class.  However,
> I do agree that if module is in a namespace then the namespace
> identifier can help narrow it down (unless the namespace identifier is
> also vague).  Without knowing the name of your name space I will have
> to make up one for example.  PlugIn::module is not so bad but I am
> still a bit uneasy of the name module for a class.  There for I would
> not use a "using PlugIn::module" statement and would instead actually
> write PlugIn::module where I needed the class.  That way I know what I
> am looking at and there is no name clash.

But that doesn't help against a keyword "module".

In the hypothetical f90 compiler, you might have the name

  f90::module

which is about the most descriptive name I can imagine for something
that shall represent f90 modules.

Now if some future C++ version made "module" a keyword, this would
immediatly break.

>
> You wrote that "module" is the base class of all modules.  In that
> case if the base class is defining policy or state (say a
> Strategy/State pattern) then call it abstract, as well as make the
> class abstract.  Thus TAbstractModule is a much better name than
> "module".

No, definitively not.

First, the fact that the class is abstract should IMHO not be
reflected in it's name. It's a property of the class, not part of the
meaning of the class. And the T for types is a convention which you
might like, but which isn't at all universal (and certainly you'll not
get any agreement here).

But not every class named "module" would necessarily be an abstract
class. See my f90 example: There's exactly one thing in f90 called
"module". There are not different types of modules. It would not make
any sense to have module be a base class (whether abstract or not).
---
[ 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                       ]

 >> I want:
 >> typedef int function(int aValue) TCallBack;

I missed the original message, but I'll be proposing a library class that
supports a very similar syntax:

   typedef function<int (int aValue)> TCallBack;

This syntax is available in the CVS version of Boost.Function and will be
available in Boost 1.29.0 whenever that gets out the door...

         Doug



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Garry Lancaster wrote:

> Garry Lancaster:
>
>> > > Are there any current C++ compilers for machines with
>>
>>> > non-8-bit bytes?
>>>


    UNISYS ClearPath servers still use the old UNIVAC 36-bit
architecture, which goes back through the UNISYS 2200 line
to the UNIVAC 1100 line to the vacuum-tube Univac Scientific Computer
of the 1950s.  You can still order these things.  See

http://www.unisys.com/products/clearpath__servers/clearpath__plus__os__2200/index.htm

Often, there's Windows NT running on one processor, and OS 2200 on
another. Not just ancient stuff, too; Unisys offers Internet Commerce
Enabler for OS 2200.

    "char" is 9 bits wide in that environment.

    This is the last major non-8-bit product line of which
I am aware.

    John Nagle

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

John Nagle <nagle@animats.com> wrote in message
news:3D7BB03E.5030104@animats.com...
> Garry Lancaster wrote:
>
> > Garry Lancaster:
> >> > > Are there any current C++ compilers for machines with
> >>> > non-8-bit bytes?

John Nagle:
>     UNISYS ClearPath servers still use the old UNIVAC 36-bit
> architecture, which goes back through the UNISYS 2200 line
> to the UNIVAC 1100 line to the vacuum-tube Univac Scientific Computer
> of the 1950s.  You can still order these things.  See
>
>
http://www.unisys.com/products/clearpath__servers/clearpath__plus__os__2200/
index.htm
>
> Often, there's Windows NT running on one processor, and OS 2200 on
> another. Not just ancient stuff, too; Unisys offers Internet Commerce
> Enabler for OS 2200.
>
>     "char" is 9 bits wide in that environment.
>
>     This is the last major non-8-bit product line of which
> I am aware.

I found one reference to a C++ compiler for OS 2200 (on the
home page of a Unisys employee!). The Windows NT support
doesn't seem relevant since it runs separately to OS 2200 on
normal Intel 32 bit processors.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net


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

Nicholas Salerno wrote:
....
> You wrote that "module" is the base class of all modules.  In that
> case if the base class is defining policy or state (say a
> Strategy/State pattern) then call it abstract, as well as make the
> class abstract.  Thus TAbstractModule is a much better name than
> "module".

Just because you don't approve of that name isn't sufficient reason to
break code that currently uses it. If you have to propose a new keyword,
it's better to grab it from the set of names reserved to the
implementation - fewer lines of code need to be altered, and the people
who have to alter them are more likely to be up-to-speed on the need to
change them. Thus, use "_module", rather than "module".



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nicholas Salerno wrote:
 >
 > Attila Feher <Attila.Feher@lmf.ericsson.se> wrote in message
 >  > I am sorry, but if I use module as a class name inside my own namespace
 >  > of a framework what is wrong with that?  Why is it not a good name?  It
 >  > is the base class for all modules.  I use my own namespace.  The only
 >  > way to break my code is to introduce a new keyword - without thinking of
 >  > the consequences.
 >
 > Even if module was not keyword, I have to ask what is a module?

Well, it is what module means inside that namespace.

 > Sounds too vague and doesn't give me any indication of the nature of
 > the class.

In general it isn't in my namespace it does.  It is a very basic term of
the framework it belongs to.

 > I think "module" is not a good name for a class.

You are free to think that.  I know situations when it is a valid class
name for my use.  NDA stops me from revealing them.

 > You wrote that "module" is the base class of all modules.  In that
 > case if the base class is defining policy or state (say a
 > Strategy/State pattern) then call it abstract, as well as make the
 > class abstract.  Thus TAbstractModule is a much better name than
 > "module".

Well, I do not waste my screen real esate to put T at the beginning of
every name - yes, in Turbo Xxx languages it was used.  Another thing is
that what if module is _not_ abstract?  I believe that the word module,
inside a namespace can be a good name.

BTW, why would I put to word Abstract into my type name, when it is
clearly visible from the declaration, that it is abstract?  So if I
happen to change it and it is not abstract anymore I will refactor to
name it NotAbstractAnymoreModule?  What I mean here that you are trying
to solve a problem (namely how to add a to vague word as keyword to a
10+ years old programming language) by doing some raindance and
rationalization - and by doing that you went into a trap.  You have
created a name, which tells more than it needs to tell.  IMHO.

Attila



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Garry Lancaster:
>  > > Are there any current C++ compilers for machines with
> >  > non-8-bit bytes?

James Kanze:
>  > Good question.

Jean-Marc Bourguet:
> There is someone working on porting gcc on the PDP-10:

For those who aren't familiar with this system it has 36 bit
words and was last produced around 1983.

> http://pdp10.nocrew.org/
>
> I don't know if this is with or without the C++ front end.

Apparently the aim is to get a working version of C.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

ndsalerno@yahoo.com (Nicholas Salerno) wrote
 > What Peter Becker and Francis Glassborow wrote makes sense.  I didn't
 > think of that and I could imagine that many coders have already used
 > some of those names.  However, I do have to say, if you use names like
 > "abstract", "module", "specialization", etc., then you are asking for
 > trouble.  Those are not good names.  They do not follow the noun and
 > strong verb convention of naming variables and functions,
 > repsectively.  Also, if they are the names of constants and
 > enumerations then the same criticism applies.  A good naming
 > convention should not yield "abstract" as the name of a constant or an
 > element of an enumeration.

You have a point, but you've said it much too broadly.

For effective customer communication, it's important to use names from
the problem domain whenever possible. The problem domain is usually
the industry domain. If you're writing a system for an automibile
plant, you could name an object "vehicle" on the general principle
of using generic names whenever possible; but if the auto plant is
not expected to build any other vehicles besides cars, then what
you've done is distanced yourself from your client. Calling the object
"car" is much more clear in this case.

Certainly there are at least one or two industries that use the term
"module!" (Hint: computer programmers, builders of space vehicles,
pre-fab housing, etc.). If your clients are in these industries, I
think it might be very possible for "module" to be both clear and
unambiguous within the problem domain.

Similar logic applies to the term "abstract," and in fact probably
every term on your list.

 > In posting to this newsgroup I was under the impression that people
 > would assume I know C++ while I assume that all of you know C++.
 > After all, we are talking about the next C++ standard.  So I didn't
 > need to be told that "= 0" makes a function pure virtual.

That's a very good point. And of course, once you know C++, when you
see "=0" in the right context you read "abstract."

There's an interesting story behind the keyword "mutable." That seems
an odd word, doesn't it? English, but not ordinary English -- think
about the last time you saw that word in (non-technical) print, or
used it in a conversation.

That's actually the very reason that this keyword was used, rather
than something more obvious. The new keyword CAN break existing code,
but it was less likely to do so than other possibilities were.

 > In fact,
 > that is why I posted the "abstract" item.  It is because I think "=0"
 > is stupid.  I do admit that C++ has some ugly features for
 > evolutionary reasons.  When a language has to satisfy a diverse number
 > of programmers, with different programming styles, and also take into
 > account different platform/system specifics, it is normal for
 > somethings not to turn out perfectly.  I understand this.  There are
 > list of things I wish could be better but I don't complain about
 > because of these reasons.  The "= 0" feature doesn't make that list
 > though, and so I will complain about it.  What is going on here?  An
 > assignment statement??  What next, can I assign 5 to a member
 > function?  Does that mean the member function is now asychronous ;-)

Your point seems to be that computer programs should read like English
wherever feasible. But there are very good reasons for using shorthands;
the fact that keywords could clash with identifiers is only one of them.
If you insist that all code should read like English, you probably can't
do much better than COBOL.

Please note that when the language makes something possible, that doesn't
always make it required. It is possible to write bad COBOL, just as it is
possible to write bad C++.

 > Second, many people posted the use of the preprocessor as a solution
 > to my list of wanted keywords.  Yuck!!  I used to do that but now I
 > avoid the preprocessor like the plague.  I used to do things like
 > "#define abstract = 0" but you know what, it is not really standard in
 > the sense that other programmers are going to see "void MyFunction
 > abstract;" and be confused until they learn all my little preprocessor
 > definitions.  To make this short I have learned the hard way to avoid
 > using the preprocessor in that fashion.  There is a place for the
 > preprocessor.  Using it like a language is NOT one of them.
 > Microsoft's MFC library is proof of concept.

Good call.

 > Lastly, some people ask what does having new keywords buy me.  That is
 > basically asking what benefit does code that read like English
 > provide?  This is obviously a debate all to itself, and I know that
 > many of you think I am wrong.  That is fine.  I don't claim to be
 > right.  I will say this though, if you can read Martian then more
 > power to you.  I prefer code that reads like English.  Also,
 > researchers at the SEI, like Watts Humphrey and Charles McCabe, write
 > many reports about software engineering and software quality that tie
 > productivity and bugs to the quality of the code base.  Martin Fowler,
 > of Rational Rose whom lead the design of the Unified Modeling
 > Language, states that any one can write code that the computer
 > undestands but great programmers write code that people understand.

If you want cryptic code, perhaps APL is best for you. Not that you
can't write readable APL -- it's just that APL is always interpreted,
so short statements always execute better than long ones, which is
at least one incentive to smash statements together whenever possible.

 > With C++ you can write some
 > quality, efficient, bug-free, unreadable code.  Sounds like a great
 > product, but also sounds like a maintenance nightmare.

AFAIK, this is true of any general-purpose computer language,
including "pure English" languages such as COBOL.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nicholas Salerno wrote:
...
> Here is my wish list for the next C++.  New keywords!!!!
>
> Seriously, I really want to know why the designers and implementors of
> C++ cannot add new keywords.  Is it that big of a deal.  I am no
> expert in compiler design but wouldn't it make the parsing and BNF
> grammars a bit nicer if there was a new keyword that meant one and
> only one thing?

The fundamental problem with new keywords, is backward compatibility.
The new keyword might conflict with user-defined identifiers (variable
names, function names, macros, typedefs, class names, namespace names,
etc.) in currently legal code. The shorter, simpler, and more
appropriate the keyword's name is for it's intended use, the more likely
it is it to already be in use somewhere.

If the new keyword is chosen from the set of names reserved to the user,
it might break a lot of user code. If the new keyword is chosen from the
set of names reserved to the implementation, then it might conflict with
an implementation that already uses that keyword for some other purpose.

Since there's a lot more user code than implementation code, it's better
to use names reserved to the implementation, but there's no perfect
solution.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 Russell Kuyper Jr." wrote:
>
> You're not likely to usefully deprecate 'unsigned char' and 'signed
> char'. They're much too widely used in existing code, to ever justify
> removing them from the standard (which is what deprecation promises -
> that they will someday be removed).

It's not quite that strong. It's a warning that it is not guaranteed to
be in future revisions.

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



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nikolai Pretzell wrote:
 >
 > You request 21 bit at least (how that? AFAIK  aren't there
 > unicode implementations of the Windows OS and of Java, that use 16 bit?)

Yes, some shortsighted designers locked themselves into Unicode 2.0.
Unicode is now at version 3.2.0, and those systems can't handle it
efficiently.

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



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

"Nicholas Salerno" <ndsalerno@yahoo.com> wrote in message
news:b9da50a9.0208281516.ae0566e@posting.google.com...
> Here is my wish list for the next C++.  New keywords!!!!
>
> Seriously, I really want to know why the designers and implementors of
> C++ cannot add new keywords.  Is it that big of a deal.  I am no
> expert in compiler design but wouldn't it make the parsing and BNF
> grammars a bit nicer if there was a new keyword that meant one and
> only one thing?
Every time you introduce a new keyword, somewhere some code breaks that used
that keyword as an identifier in some sort.

sm




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

What Peter Becker and Francis Glassborow wrote makes sense.  I didn't
think of that and I could imagine that many coders have already used
some of those names.  However, I do have to say, if you use names like
"abstract", "module", "specialization", etc., then you are asking for
trouble.  Those are not good names.  They do not follow the noun and
strong verb convention of naming variables and functions,
repsectively.  Also, if they are the names of constants and
enumerations then the same criticism applies.  A good naming
convention should not yield "abstract" as the name of a constant or an
element of an enumeration.

In posting to this newsgroup I was under the impression that people
would assume I know C++ while I assume that all of you know C++.
After all, we are talking about the next C++ standard.  So I didn't
need to be told that "= 0" makes a function pure virtual.  In fact,
that is why I posted the "abstract" item.  It is because I think "=0"
is stupid.  I do admit that C++ has some ugly features for
evolutionary reasons.  When a language has to satisfy a diverse number
of programmers, with different programming styles, and also take into
account different platform/system specifics, it is normal for
somethings not to turn out perfectly.  I understand this.  There are
list of things I wish could be better but I don't complain about
because of these reasons.  The "= 0" feature doesn't make that list
though, and so I will complain about it.  What is going on here?  An
assignment statement??  What next, can I assign 5 to a member
function?  Does that mean the member function is now asychronous ;-)

Second, many people posted the use of the preprocessor as a solution
to my list of wanted keywords.  Yuck!!  I used to do that but now I
avoid the preprocessor like the plague.  I used to do things like
"#define abstract = 0" but you know what, it is not really standard in
the sense that other programmers are going to see "void MyFunction
abstract;" and be confused until they learn all my little preprocessor
definitions.  To make this short I have learned the hard way to avoid
using the preprocessor in that fashion.  There is a place for the
preprocessor.  Using it like a language is NOT one of them.
Microsoft's MFC library is proof of concept.

Lastly, some people ask what does having new keywords buy me.  That is
basically asking what benefit does code that read like English
provide?  This is obviously a debate all to itself, and I know that
many of you think I am wrong.  That is fine.  I don't claim to be
right.  I will say this though, if you can read Martian then more
power to you.  I prefer code that reads like English.  Also,
researchers at the SEI, like Watts Humphrey and Charles McCabe, write
many reports about software engineering and software quality that tie
productivity and bugs to the quality of the code base.  Martin Fowler,
of Rational Rose whom lead the design of the Unified Modeling
Language, states that any one can write code that the computer
undestands but great programmers write code that people understand.

Okay, here is a test, go look at Borland's VCL library.  Then go look
at Microsoft's MFC library, and/or Dinkumware's STL library.  Then
come back to me and tell that English keywords that mean one and only
one thing do not provide any benefit.  With C++ you can write some
quality, efficient, bug-free, unreadable code.  Sounds like a great
product, but also sounds like a maintenance nightmare.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Francis Glassborow wrote:
> In article <b9da50a9.0208281516.ae0566e@posting.google.com>, Nicholas
> Salerno <ndsalerno@yahoo.com> writes
>
>>Here is my wish list for the next C++.  New keywords!!!!
>>
>>Seriously, I really want to know why the designers and implementors of
>>C++ cannot add new keywords.  Is it that big of a deal.  I am no
>>expert in compiler design but wouldn't it make the parsing and BNF
>>grammars a bit nicer if there was a new keyword that meant one and
>>only one thing
>
> New keywords are a very big deal, not to compiler writers but to all
> those with many millions of lines of legacy code. If, in a safety
> critical context, I change a single letter of my code I have to have it
> revalidated.  That does not come cheap.

Trully a minor problem.
In a context like this we are going to do full revalidation when we
switch to a new version of a compiler anyway - with or without extra
keywords. Besides, in those environments there must be a ready set of
regression tests all set up and testing ought to be automated.

Also, all those arguments are not specific to whether to add new
keywords. They apply equally well to absolutely any change in the
language: we will always have to change some code, some libraries and
revalidate everything.


> If you introduce a new keyword
> that happens to coincide with a variable name that my code generator
> generates I must now spend time and valuable resources changing the code
> generator.

Time is the only resource we are about to spend here. I do not think
anyone is going to burn a CPU or max out one's hard drive mileage
fixing variable names in the code. What's important is a trade-off: if
the language is going to get better (read: "more clear", "easier to
learn", "easier to work with"), it may be worth spending some time.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message
news:<TeGb9.1741$ex3.22082@newsfep2-win.server.ntli.net>...
> Nikolai Pretzell:
> > > - adding 'byte' and 'unsigned byte' as integer data types,
> > >   which are guaranteed to be 8-bit on all platforms.

> James Kanze:
> > Even platforms which have no native 8 bit type?

> Are there any current C++ compilers for machines with non-8-bit bytes?

Good question.

There are some embedded systems, I think, with 32 bit bytes.  But they
aren't hosted implementations, so it may not matter.  As for the odd
sizes (9 bit bytes, etc.) they have existed, and I've seen them.  But
that was a long, long time ago.

> (I know that there are or have been machines like this and that some
> of them have had C compilers, but that's not what I'm asking. My
> impression is that these esoteric architectures have more or less died
> out nowadays, but maybe someone knows different.)

The last one I know of for sure was the Unisys serie A.  8 bit bytes,
but 48 bit ints, with 8 bits required to be 0, and signed magnitude
representation.  Went out of production at least two years ago.

Generally speaking, all of the big manufacturers have 8 bit bytes and
either 32 or 64 bit words, are byte addressable, and use two's
complement for negatives.  With very few exceptions, they all use IEEE
for floating point as well -- it's even an option on IBM mainframes
now.  And given the current cost structure, it would seem a good bet
that all of the smaller manufacturers just buy in standard
microprocessors (which are all 8 bit based as well).

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nicholas Salerno wrote:
>
> What Peter Becker and Francis Glassborow wrote makes sense.  I didn't
> think of that and I could imagine that many coders have already used
> some of those names.  However, I do have to say, if you use names like
> "abstract", "module", "specialization", etc., then you are asking for
> trouble.  Those are not good names.  They do not follow the noun and
[SNIP]

I am sorry, but if I use module as a class name inside my own namespace
of a framework what is wrong with that?  Why is it not a good name?  It
is the base class for all modules.  I use my own namespace.  The only
way to break my code is to introduce a new keyword - without thinking of
the consequences.

Attila



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nicholas Salerno wrote:
>
> What Peter Becker and Francis Glassborow wrote makes sense.  I didn't
> think of that and I could imagine that many coders have already used
> some of those names.  However, I do have to say, if you use names like
> "abstract", "module", "specialization", etc., then you are asking for
> trouble.  Those are not good names.  They do not follow the noun and
> strong verb convention of naming variables and functions,
> repsectively.  Also, if they are the names of constants and
> enumerations then the same criticism applies.  A good naming
> convention should not yield "abstract" as the name of a constant or an
> element of an enumeration.

That's not sufficient justification for a change that would break code
that didn't follow that naming convention. Keep in mind that in general
a new keyword can, in principle, conflict with all other possible uses
of an identifier, not just variables and functions - it could also
interfere with struct tags, typdefs, macros, enumeration constants,
template parameters, or even namespace names and aliases (for any
particular keyword, some of those possibilities might not be relevant).

...
> somethings not to turn out perfectly.  I understand this.  There are
> list of things I wish could be better but I don't complain about
> because of these reasons.  The "= 0" feature doesn't make that list
> though, and so I will complain about it.  What is going on here?  An
> assignment statement??  What next, can I assign 5 to a member
> function?  Does that mean the member function is now asychronous ;-)

The point is, that the feature you requested already exists; changing
the syntax used to implement that feature is a very low priority, even
a  negative one, considering the possibility that the new keyword may
break some existing code.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nikolai Pretzell <nikolai@Sun.COM> wrote in message
news:<20020830.7445176@mis.configured.host>...

> Am 30.08.2002, 00:55:31, schrieb kanze@gabi-soft.de (James Kanze) zum
> Thema Re: Feature-Wish for next C++:

> > Nikolai Pretzell <nikolai@sun.com> wrote in message
> > news:<20020822.16204248@mis.configured.host>...
    [...]
> > > Semantically, a char is a fundamentally different thing than an
> > > integer, and many problems could be avoided by handling them as
> > > that: completely different.

> > True.  And there could be an argument for adding a character type to
> > C++, which doesn't have one at present.  On the other hand, while we
> > know enough to know that a character is not really an integer, I'm
> > not sure that we know enough yet to say exactly what it is, and what
> > the semantics of a character type should be.

> That's true. Within this thread, some people thought wchar_t (or 16
> bit) would do it.

Wchar_t isn't required to be 16 bits.  It can be as little as 8 bits.

> You request 21 bit at least (how that? AFAIK - aren't there unicode
> implementations of the Windows OS and of Java, that use 16 bit?)

Unicode 3.2 requires 21 bits.

Unicode 3.0 only required 16 bits.  Some people standardized too soon.
Too bad for them.  Or rather, too bad for their users, because they are
now more or less locked in.  Java practically can't change the size of
char, with all of their write once, debug^^^^^run everywhere baley hoo.
For Windows, it would create a number of problems to change without
breaking everything everywhere.

What surprises me in the whole business is that the real experts (in ISO
10646) have been saying that 16 bits wouldn't suffice for a long time
now.

> and there are considerations to use 32 bit in future. Also character
> sequencing, white spaces, null-terminations may be problematic in non
> western languages.

The size of wchar_t is implementation defined.  On most implementations,
it is already 32 bits.  I think Windows is one of the few exceptions
(but maybe AIX as well).

> But, I think your alternative suggestion, to add a (or some)
> completely new character types to C++ is rather the way to go, than my
> proposal.

Well, a new type has the advantage of not breaking existing code (except
for the new keywork needed to define it).

I also have a suspicion that a true character type shouldn't define
operators like + and -, and certainly not * and /.

> > > - declaring 'unsigned char' and 'signed char' deprecated,
> > Now THAT would break code.

> Well, deprecated seems to have been the wrong term, I meant something
> like the no-use of "goto". Not removing them from the standard.

Goto isn't deprecated either:-).

A lot of good programs use char, unsigned char and signed char.  Like,
about 100% of them, or at least, of those which interface to the OS
somewhere.  The current "best practice", I believe, is to use char for
(narrow) characters, and signed or unsigned char for small integral
values.

> > > - adding 'byte' and 'unsigned byte' as integer data types,
> > >   which are guaranteed to be 8-bit on all platforms.

> > Even platforms which have no native 8 bit type?

> Right. I should have added "minimal".

> > > - adding 'unicode' (16bit) and 'long unicode' (32 bit)
> > >   as char data types
> > I don't see the 16 bit type; Unicode requires at least 21 bits.

> That contradicts existing unicode implementations (Windows OS,
> Java). I don't know, which standards those fulfill or break. However,
> they work until today.

How do they represent the Unicode values in the range 0x10000-0x10FFFF?

The reason Unicode when beyond 16 bits is because 16 bits simply don't
suffice.  I suspect that Windows uses the surrogates in the range
0xD800-0xDB7F and 0xDC00-0xDFFF, with multi-wchar_t characters.  Java
just ignores them; who cares about all those Chinese or the Byzantine or
mathematics scholars anyway?

The only real solution would be to define a Unicode type, which is
required to use ISO 10646, and is required to be at least 21 bits (or
more -- I wouldn't exclude the possibility that Unicode develop to even
more bits).  The problem is perhaps that we don't want to impose this
overhead on machines where it isn't relevant; today, they simply define
wchar_t as the equivalent of char, and get on with it.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

glancaster@ntlworld.com (Garry Lancaster) wrote (abridged):
 > Are there any current C++ compilers for machines with
 > non-8-bit bytes?
 >
 > (I know that there are or have been machines like this and
 > that some of them have had C compilers, but that's not what
 > I'm asking. My impression is that these esoteric architectures
 > have more or less died out nowadays, but maybe someone
 > knows different.)

I doubt the hardware has died out. I think there are still
signal-processing chips with direct support for only a single word-size,
typically 32-bits. If that's all you need, doing only that makes for a
simpler, cheaper, cooler, faster chip. The business demand will never go
away.

Whether such chips need a C++ compiler is another matter. It was a design
objective of C++ that it be usable where-ever C is usable. Or more
precisely (from D&E $4.5)

     Leave no room for a lower-level language below C++ (except
     assembler).

So the design of C++ keeps them in mind, even if no vendor currently
supports them.

   Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
       brangdon@cix.co.uk      |   And close your eyes with holy dread,
                               |  For he on honey dew hath fed
  http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

"Nicholas Salerno" <ndsalerno@yahoo.com> wrote:

 > What Peter Becker and Francis Glassborow wrote makes sense.  I didn't
 > think of that and I could imagine that many coders have already used
 > some of those names.  However, I do have to say, if you use names like
 > "abstract", "module", "specialization", etc., then you are asking for
 > trouble.  Those are not good names.  They do not follow the noun and
 > strong verb convention of naming variables and functions,
 > repsectively.  Also, if they are the names of constants and
 > enumerations then the same criticism applies.  A good naming
 > convention should not yield "abstract" as the name of a constant or an
 > element of an enumeration.
 >

I understand your good intentions, but it is *way* too late to change this
now.

The compatibility between C and C++ is a sort of catch 22, in that a lot of
old warts come from C, but *also* a huge user base. If we could design a
language from scratch, there would be plenty of room for improvements, like
not allowing things like

for(;;)
for(;;);
auto
5;
i = (int*)j;
long double
signed char
if(i=5) vs if(i==5)
f;  vs  f();
int*  i, j;
int (*p(int))(int);
#include
#define

but we cannot do this any longer. There are 100s of millions of lines code
that would break (or silently change meaning).

There are also languanges like Pascal, that was intentionally designed to be
readable, easy to learn, and still powerful. So why are we coding in C++??


Because, warts and all, C++ is a reasonable compromise with a big enough
pool of followers to pay for compilers with good optimizers. That's what
makes a language useful. If you "improve" the language enough, you take the
risk that the guys with the biggest code base split of with their own
dialect.


Another problem with your suggestions is that the improvements do not
address the major shortcomings of the language, but some minor points
(IMHO). I don't like =0 either, but it is not present in the majority of my
code, so it is not a big deal. If we could have a general wish list for
readability (like for C++ christmas), I would like a keyword 'loop' to
replace an empty 'for(;;)', keywords 'begin' and 'end' to replace '{' and
'}'  (oops, already taken, need a new standard library too), change
std::find into std::search because sometimes it cannot find what you are
looking for, change ...

Oh well, let's be happy for what we've already got.  :-)


Bo Persson
bop2@telia.com






      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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:
....
> How do they represent the Unicode values in the range 0x10000-0x10FFFF?
>
> The reason Unicode when beyond 16 bits is because 16 bits simply don't
> suffice.  I suspect that Windows uses the surrogates in the range

That depends entirely upon the situation. 8 bits is more than
sufficient, for many purposes. Code that currently uses 16 bits can do
everything with those 16 bits that they used to be able to do; the fact
that there are other things that they can't do because they didn't
choose 32 bits, doesn't matter if for applications that don't need to do
them



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

kanze@gabi-soft.de (James Kanze) writes:

 > "Garry Lancaster" <glancaster@ntlworld.com> wrote in message
 > news:<TeGb9.1741$ex3.22082@newsfep2-win.server.ntli.net>...
 > > Nikolai Pretzell:
 > > > > - adding 'byte' and 'unsigned byte' as integer data types,
 > > > >   which are guaranteed to be 8-bit on all platforms.
 >
 > > James Kanze:
 > > > Even platforms which have no native 8 bit type?
 >
 > > Are there any current C++ compilers for machines with non-8-bit bytes?
 >
 > Good question.

There is someone working on porting gcc on the PDP-10:

http://pdp10.nocrew.org/

I don't know if this is with or without the C++ front end.

Yours,

--
Jean-Marc

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nicholas Salerno wrote:

> However, I do have to say, if you use names like "abstract",
> "module", "specialization", etc., then you are asking for
> trouble.  Those are not good names.  They do not follow the noun and
> strong verb convention of naming variables and functions,
> repsectively.

Really?

   class article
   {
      person      author;
      std::string abstract;
      std::string full_text;
   };

seem like reasonable names to me. Your suggestion could give people
writing publishing software a hard time. Similarly, the names "module"
and "specialization" can make perfect sense in the code for a CASE tool.

Whether a name is good or not depends very much on the domain context.

Gerhard Menzl
--
#dogma int main()

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 <b9da50a9.0209011155.2cbaf503@posting.google.com>, Nicholas
Salerno <ndsalerno@yahoo.com> writes
 >
 >What Peter Becker and Francis Glassborow wrote makes sense.  I didn't
 >think of that and I could imagine that many coders have already used
 >some of those names.  However, I do have to say, if you use names like
 >"abstract", "module", "specialization", etc., then you are asking for
 >trouble.  Those are not good names.  They do not follow the noun and
 >strong verb convention of naming variables and functions,
 >repsectively.  Also, if they are the names of constants and
 >enumerations then the same criticism applies.  A good naming
 >convention should not yield "abstract" as the name of a constant or an
 >element of an enumeration.
    <snip>

But "abstract" *is* a noun. Each paper in a science journal has an
abstract. There are huge commercial databases of abstracts. There is
software that moves abstracts around, writes them to CDs, emails, web
pages, etc, etc.

In other words, there is an application domain where "abstract" is a
word that people will not want to lose.

    John
--
John Harris
    mailto:john@jgharris.demon.co.uk

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Attila Feher <Attila.Feher@lmf.ericsson.se> wrote in message
 > I am sorry, but if I use module as a class name inside my own namespace
 > of a framework what is wrong with that?  Why is it not a good name?  It
 > is the base class for all modules.  I use my own namespace.  The only
 > way to break my code is to introduce a new keyword - without thinking of
 > the consequences.
 >
 > Attila
 >

Even if module was not keyword, I have to ask what is a module?
Sounds too vague and doesn't give me any indication of the nature of
the class.  I think "module" is not a good name for a class.  However,
I do agree that if module is in a namespace then the namespace
identifier can help narrow it down (unless the namespace identifier is
also vague).  Without knowing the name of your name space I will have
to make up one for example.  PlugIn::module is not so bad but I am
still a bit uneasy of the name module for a class.  There for I would
not use a "using PlugIn::module" statement and would instead actually
write PlugIn::module where I needed the class.  That way I know what I
am looking at and there is no name clash.

You wrote that "module" is the base class of all modules.  In that
case if the base class is defining policy or state (say a
Strategy/State pattern) then call it abstract, as well as make the
class abstract.  Thus TAbstractModule is a much better name than
"module".

     Nicholas



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

"Nicholas Salerno" <ndsalerno@yahoo.com> wrote in message
news:b9da50a9.0208281516.ae0566e@posting.google.com...

> Here is my wish-list:
> 1) Add abstract to the language.  Then I could write code like this:
> class TMyAbstractReader
> {
> public:
>     // Blah
>     bool Read(void* apBuffer, int aBytesToRead) abstract;
>
> private:
>     // Blah
> };

    We already have that. It's called pure virtual functions. Granted that
the "=0" terminology is neither clear, nor elegant, and the "pure" keyword
would be nice.

>
> 2) Add specialization.  Instead of
> template<> void sort<char*>(Array<char*>&);
>
> I want:
> specialization void sort<char*>(Array<char*>&);

    And what advantage does your new syntax have?

> 3) Better ways to declare (member)function pointers.
> int (*fp)(int aValue); // Yuck!

    It falls inline with other pointer declarations.

> I want:
> typedef int function(int aValue) TCallBack;

    typedef int (*TCallBack)(int);

    TCallback mycallback=NULL;

    /* code ommited... */

    if(mycallback)
        mycallback(1);

>
> int SomeFunction(int aParam);
> TCallBack CallBack; // Now I have a function pointer.
> CallBack = SomeFunction;

    See above.

> 4) I want a module or unit keyword to replace the unnamed namespace.
> Unnamed namespace?  What was that all about?  Doesn't exactly let you
> know that it means stuff that is visible only in the translation unit.

    It does if you read the standard. Consider this version of the argument:
Module? What was that all about? Doesn't exactly let you know that it means
stuff that is visible only in one translation unit.

    -n



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nicholas Salerno wrote:
>
> Here is my wish list for the next C++.  New keywords!!!!
>
> Seriously, I really want to know why the designers and implementors of
> C++ cannot add new keywords.  Is it that big of a deal.  I am no
> expert in compiler design but wouldn't it make the parsing and BNF
> grammars a bit nicer if there was a new keyword that meant one and
> only one thing?

It's not a matter of technical feasibility, but of practicality. Adding
a keyword means making any current code that uses that identifier
illegal.

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



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 <b9da50a9.0208281516.ae0566e@posting.google.com>, Nicholas
Salerno <ndsalerno@yahoo.com> writes
>Here is my wish list for the next C++.  New keywords!!!!
>
>Seriously, I really want to know why the designers and implementors of
>C++ cannot add new keywords.  Is it that big of a deal.  I am no
>expert in compiler design but wouldn't it make the parsing and BNF
>grammars a bit nicer if there was a new keyword that meant one and
>only one thing?


New keywords are a very big deal, not to compiler writers but to all
those with many millions of lines of legacy code. If, in a safety
critical context, I change a single letter of my code I have to have it
revalidated. That does not come cheap. If you introduce a new keyword
that happens to coincide with a variable name that my code generator
generates I must now spend time and valuable resources changing the code
generator. Any library that has that new keyword as a variable name must
now be upgraded (that may be a delight for the library vendor, but it
certainly isn't for the user)

Note that I am not against new keywords, but they must meet very
stringent cost-benefit analysis.

My wish is that we had had the foresight to build in a feature of
keyword substitution coupled with a keyword namespace. So that we could
have:
  keywords {
   pure;

// etc.
}

int foo()keyword::pure;

but also have

using keyword::pure;
int bar()pure;

ON second thoughts that might have just have made it too easy to add
keywords:-)

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



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nikolai Pretzell:
> > - adding 'byte' and 'unsigned byte' as integer data types,
> >   which are guaranteed to be 8-bit on all platforms.

James Kanze:
> Even platforms which have no native 8 bit type?

Are there any current C++ compilers for machines with
non-8-bit bytes?

(I know that there are or have been machines like this and
that some of them have had C compilers, but that's not what
I'm asking. My impression is that these esoteric architectures
have more or less died out nowadays, but maybe someone
knows different.)

> > - adding 'unicode' (16bit) and 'long unicode' (32 bit)
> >   as char data types
>
> I don't see the 16 bit type; Unicode requires at least 21 bits.

I think the 16 bit Unicode he's referring to is that used previous
version of Unicode before any surrogate pairs were defined i.e.
the one used internally by the Windows NT OS line and, I think,
Java (?). Or possibly he means the UTF-16 encoding of the
current Unicode character set. It isn't clear.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nicholas Salerno wrote:
[SNIP]
> Here is my wish list for the next C++.  New keywords!!!!

I want a BMW!  7 series.  Honestly. :-)))

> Seriously, I really want to know why the designers and implementors of
> C++ cannot add new keywords.  Is it that big of a deal.  I am no
> expert in compiler design but wouldn't it make the parsing and BNF
> grammars a bit nicer if there was a new keyword that meant one and
> only one thing?

It would be nicer.  Except for those folks, who have used in theit code
those words.  It would perfectly be possible to do many wonderful things
in C++ syntax change, but most of them would break existing code.  So
comparing the costs to the benefits it isn't done.

> Here is my wish-list:
> 1) Add abstract to the language.  Then I could write code like this:
> class TMyAbstractReader
> {
> public:
>     // Blah
>     bool Read(void* apBuffer, int aBytesToRead) abstract;

#define abstract = 0;

> private:
>     // Blah
> };
>
> 2) Add specialization.  Instead of
> template<> void sort<char*>(Array<char*>&);
>
> I want:
> specialization void sort<char*>(Array<char*>&);

#define specialization template<>

How about:

template <class T, int I> class Arr;

template <class T> class Arr<T,0>;

???

do you want:

partial_specialization<class T>...?

> 3) Better ways to declare (member)function pointers.
> int (*fp)(int aValue); // Yuck!
>
> I want:
> typedef int function(int aValue) TCallBack;

This is what works:
typedef int (*function)(int aValue) TCallBack;

compare the two.  What is the big deal?

> int SomeFunction(int aParam);
> TCallBack CallBack; // Now I have a function pointer.
> CallBack = SomeFunction;

[SNIP]
> 4) I want a module or unit keyword to replace the unnamed namespace.
> Unnamed namespace?  What was that all about?  Doesn't exactly let you
> know that it means stuff that is visible only in the translation unit.
>
> Instead of
> namespace
> {
>     int gMaxCharacterWidth;
>     int gMaxCharacterHeight;
> }
>
> I want
>
> module
> {
>     int gMaxCharacterWidth;
>     int gMaxCharacterHeight;
> }


#define module namespace

BTW just for this idea I can present you about 50 designers ready to
spank you!  module is a class name of an abstract class in quite a few
systems!

> Well that is it for now.  I have more, but this should be enough for
> everyone to tell me that it's not going to happen for one reason or
> another.

:-)  Be reasonable.  In your code you get most of those effects if you
want to.  However beware!  Noone else but you will know what do they
mean.  Observe (this is C code!):

PROC dosth( in number x, out string y) begin
  if (...) then
    ...
  fi

  switch()

  esac

end

I do not mention what will this do to code trying to use STL containers
(since it is C), but you can imagine calling myVector.{ :-))

Not to mention the look on the face of anyone who has to touch this
code.  Readable?  Yes - to whom? ;-)

Attila



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Hi,


Am 30.08.2002, 00:55:31, schrieb kanze@gabi-soft.de (James Kanze) zum
Thema Re: Feature-Wish for next C++:

> Nikolai Pretzell <nikolai@sun.com> wrote in message
> news:<20020822.16204248@mis.configured.host>...

> > As there are many problems with ambiguities (in overloading functions
> > and elsewhere) with numbers and characters, I wonder if it would be
> > possible to change the behaviour of the basic language so that there
> > ar no longer any more implicit conversions between char/wchar_t on one
> > and all other integer types on the other side.

thanks for all the comments!
I didn't expect my suggestion to be welcomed openheartedly ;-)
However, I wished to raise the issue, because it bothered me
already many times.

> > Semantically, a char is a fundamentally different thing than an
> > integer, and many problems could be avoided by handling them as that:
> > completely different.

> True.  And there could be an argument for adding a character type to
> C++, which doesn't have one at present.  On the other hand, while we
> know enough to know that a character is not really an integer, I'm not
> sure that we know enough yet to say exactly what it is, and what the
> semantics of a character type should be.

That's true. Within this thread, some people thought wchar_t (or 16 bit)
would do it. You request 21 bit at least (how that? AFAIK     aren't there
unicode implementations of the Windows OS and of Java, that use 16 bit?)
and there
are considerations to use 32 bit in future. Also character sequencing,
white spaces, null-terminations may be problematic in non western
languages.

But, I think your alternative suggestion, to add a (or some) completely
new character types to C++ is rather the way to go, than my proposal.


> > - declaring 'unsigned char' and 'signed char' deprecated,
> Now THAT would break code.
Well, deprecated seems to have been the wrong term, I meant something
like the no-use of "goto". Not removing them from the standard.

> > - adding 'byte' and 'unsigned byte' as integer data types,
> >   which are guaranteed to be 8-bit on all platforms.

> Even platforms which have no native 8 bit type?

Right. I should have added "minimal".


> > - adding 'unicode' (16bit) and 'long unicode' (32 bit)
> >   as char data types
> I don't see the 16 bit type; Unicode requires at least 21 bits.

That contradicts existing unicode implementations (Windows OS, Java). I
don't
know, which standards those fulfill or break. However, they work until
today.

> And forcing a fixed length would be a novelty as well.  What about
> machines with 36 bit words?
Well, apart from that you are right of course, this argument comes often



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

ndsalerno@yahoo.com (Nicholas Salerno) wrote in message news:<b9da50a9.0208281516.ae0566e@posting.google.com>...
> 1) Add abstract to the language.  Then I could write code like this:
> class TMyAbstractReader
> {
> public:
>     // Blah
>     bool Read(void* apBuffer, int aBytesToRead) abstract;
>
> private:
>     // Blah
> };

#define abstract = 0

> 2) Add specialization.  Instead of
> template<> void sort<char*>(Array<char*>&);
>
> I want:
> specialization void sort<char*>(Array<char*>&);

#define specialization template<>

> 3) Better ways to declare (member)function pointers.
> int (*fp)(int aValue); // Yuck!
>
> I want:
> typedef int function(int aValue) TCallBack;
>
> int SomeFunction(int aParam);
> TCallBack CallBack; // Now I have a function pointer.
> CallBack = SomeFunction;
>
> -- and for functions that belong to objects --
>
> typedef int class_function(int aValue) TCallBack;
>
> class TMyClass {public: int SomeFunction(int aInt);};
> class TMyOtherClass {private: TCallBack fCallBack;};
>
> void TMyOtherClass::Initialize(TMyClass& aObj)
> {
>     fCallBack = aObj.SomeFunction;
> }

This one would take some work.

> 4) I want a module or unit keyword to replace the unnamed namespace.
> Unnamed namespace?  What was that all about?  Doesn't exactly let you
> know that it means stuff that is visible only in the translation unit.
>
> Instead of
> namespace
> {
>     int gMaxCharacterWidth;
>     int gMaxCharacterHeight;
> }
>
> I want
>
> module
> {
>     int gMaxCharacterWidth;
>     int gMaxCharacterHeight;
> }

#define module namespace

Macros already give you 3/4 of what you want.

Each of the things you are asking for are not new things, in the sense
that they are things that can be done with existing language
constructs. Maybe not the constructs you'd like to use, but they can
be done. What would we gain from making these changes?

Bob



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nikolai Pretzell <nikolai@sun.com> wrote
 > I wonder if it
 > would be possible to change the behaviour of the
 > basic language so that there ar no longer any more implicit
 > conversions between char/wchar_t on one and all other
 > integer types on the other side.

Why?

[Because[
 > there are many problems with ambiguities (in overloading
 > functions and elsewhere) with numbers and characters,

Such as?



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Hi,

As there are many problems with ambiguities (in overloading
functions and elsewhere) with numbers and characters, I wonder if it
would be possible to change the behaviour of the
basic language so that there ar no longer any more implicit
conversions between char/wchar_t on one and all other
integer types on the other side.

This breaks some existing code. However, the change of scope of
declarations within for-loop-headers also broke existing code
probably even more. One could provide compiler-switches for old code.

Semantically, a char is a fundamentally different thing than an
integer, and many problems could be avoided by handling them as that:
completely different.

Some possible changes to achieve that:

- declaring 'unsigned char' and 'signed char' deprecated,
- adding 'byte' and 'unsigned byte' as integer data types,
  which are guaranteed to be 8-bit on all platforms.
- adding 'unicode' (16bit) and 'long unicode' (32 bit)
  as char data types
- changing implicit conversion rules such, that integer
  conversions apply as they are only among integer-types (and
  among char-types? not?), but not from one family to the other.
  However a cast by reinterpret_cast<> still would be possible.
  Enums also would not cast implicitely to char-types.
- tidying up std::basic_string

How think other people about the usefulness of such a
distinction?

Do people think this change would be possible (if it would be
considered useful)?


Regards,

Nikolai



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

> Some possible changes to achieve that:
>
> - declaring 'unsigned char' and 'signed char' deprecated,

Absolutely not. I use signed char and unsigned char for their integer
properties and for the fact they are the smallest integral type.
So do others.

> - adding 'byte' and 'unsigned byte' as integer data types,
>   which are guaranteed to be 8-bit on all platforms.

What about platforms where char is 9 bits? Must byte and unsigned byte be
simulated?

Stephen Howe



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nikolai Pretzell wrote:
>
> Hi,
>
> As there are many problems with ambiguities (in overloading
> functions and elsewhere) with numbers and characters, I wonder if it
> would be possible to change the behaviour of the
> basic language so that there ar no longer any more implicit
> conversions between char/wchar_t on one and all other
> integer types on the other side.
>
> This breaks some existing code. However, the change of scope of
> declarations within for-loop-headers also broke existing code -
> probably even more. One could provide compiler-switches for old code.

There's a key difference - there was no prior standard that specified
the scope of those declarations. It was just a matter of deciding what
the first version of the standard should say about the matter.

> Semantically, a char is a fundamentally different thing than an
> integer, and many problems could be avoided by handling them as that:
> completely different.
>
> Some possible changes to achieve that:
>
> - declaring 'unsigned char' and 'signed char' deprecated,
> - adding 'byte' and 'unsigned byte' as integer data types,
>   which are guaranteed to be 8-bit on all platforms.
> - adding 'unicode' (16bit) and 'long unicode' (32 bit)
>   as char data types
> - changing implicit conversion rules such, that integer
>   conversions apply as they are only among integer-types (and
>   among char-types? not?), but not from one family to the other.
>   However a cast by reinterpret_cast<> still would be possible.
>   Enums also would not cast implicitely to char-types.
> - tidying up std::basic_string
>
> How think other people about the usefulness of such a
> distinction?
>
> Do people think this change would be possible (if it would be
> considered useful)?

You're not likely to usefully deprecate 'unsigned char' and 'signed
char'. They're much too widely used in existing code, to ever justify
removing them from the standard (which is what deprecation promises -
that they will someday be removed).
And don't even think of changing the implicit conversion rules - that
will break huge quantities of existing code.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nikolai Pretzell <nikolai@sun.com> wrote in message news:<20020822.16204248@mis.configured.host>...
> Hi,
>
> As there are many problems with ambiguities (in overloading
> functions and elsewhere) with numbers and characters, I wonder if it
> would be possible to change the behaviour of the
> basic language so that there ar no longer any more implicit
> conversions between char/wchar_t on one and all other
> integer types on the other side.
>
> This breaks some existing code. However, the change of scope of
> declarations within for-loop-headers also broke existing code
> probably even more. One could provide compiler-switches for old code.
>
> Semantically, a char is a fundamentally different thing than an
> integer, and many problems could be avoided by handling them as that:
> completely different.
>
> Some possible changes to achieve that:
>
> - declaring 'unsigned char' and 'signed char' deprecated,
> - adding 'byte' and 'unsigned byte' as integer data types,
>   which are guaranteed to be 8-bit on all platforms.
> - adding 'unicode' (16bit) and 'long unicode' (32 bit)
>   as char data types
> - changing implicit conversion rules such, that integer
>   conversions apply as they are only among integer-types (and
>   among char-types? not?), but not from one family to the other.
>   However a cast by reinterpret_cast<> still would be possible.
>   Enums also would not cast implicitely to char-types.
> - tidying up std::basic_string
>
> How think other people about the usefulness of such a
> distinction?
>
> Do people think this change would be possible (if it would be
> considered useful)?

Here is my wish list for the next C++.  New keywords!!!!

Seriously, I really want to know why the designers and implementors of
C++ cannot add new keywords.  Is it that big of a deal.  I am no
expert in compiler design but wouldn't it make the parsing and BNF
grammars a bit nicer if there was a new keyword that meant one and
only one thing?

Here is my wish-list:
1) Add abstract to the language.  Then I could write code like this:
class TMyAbstractReader
{
public:
    // Blah
    bool Read(void* apBuffer, int aBytesToRead) abstract;

private:
    // Blah
};

2) Add specialization.  Instead of
template<> void sort<char*>(Array<char*>&);

I want:
specialization void sort<char*>(Array<char*>&);

3) Better ways to declare (member)function pointers.
int (*fp)(int aValue); // Yuck!

I want:
typedef int function(int aValue) TCallBack;

int SomeFunction(int aParam);
TCallBack CallBack; // Now I have a function pointer.
CallBack = SomeFunction;

-- and for functions that belong to objects --

typedef int class_function(int aValue) TCallBack;

class TMyClass {public: int SomeFunction(int aInt);};
class TMyOtherClass {private: TCallBack fCallBack;};

void TMyOtherClass::Initialize(TMyClass& aObj)
{
    fCallBack = aObj.SomeFunction;
}

4) I want a module or unit keyword to replace the unnamed namespace.
Unnamed namespace?  What was that all about?  Doesn't exactly let you
know that it means stuff that is visible only in the translation unit.

Instead of
namespace
{
    int gMaxCharacterWidth;
    int gMaxCharacterHeight;
}

I want

module
{
    int gMaxCharacterWidth;
    int gMaxCharacterHeight;
}

Well that is it for now.  I have more, but this should be enough for
everyone to tell me that it's not going to happen for one reason or
another.

    Nicholas



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nikolai Pretzell <nikolai@sun.com> wrote in message
news:<20020822.16204248@mis.configured.host>...

> As there are many problems with ambiguities (in overloading functions
> and elsewhere) with numbers and characters, I wonder if it would be
> possible to change the behaviour of the basic language so that there
> ar no longer any more implicit conversions between char/wchar_t on one
> and all other integer types on the other side.

Only if you accept that you are creating a new language, and that most
existing programs will not compile with it.

> This breaks some existing code.

It probably breaks well over 90% of all existing code.

> However, the change of scope of declarations within for-loop-headers
> also broke existing code - probably even more. One could provide
> compiler-switches for old code.

> Semantically, a char is a fundamentally different thing than an
> integer, and many problems could be avoided by handling them as that:
> completely different.

True.  And there could be an argument for adding a character type to
C++, which doesn't have one at present.  On the other hand, while we
know enough to know that a character is not really an integer, I'm not
sure that we know enough yet to say exactly what it is, and what the
semantics of a character type should be.

> Some possible changes to achieve that:

> - declaring 'unsigned char' and 'signed char' deprecated,

Now THAT would break code.

> - adding 'byte' and 'unsigned byte' as integer data types,
>   which are guaranteed to be 8-bit on all platforms.

Even platforms which have no native 8 bit type?

> - adding 'unicode' (16bit) and 'long unicode' (32 bit)
>   as char data types

I don't see the 16 bit type; Unicode requires at least 21 bits.

And forcing a fixed length would be a novelty as well.  What about
machines with 36 bit words?

> - changing implicit conversion rules such, that integer
>   conversions apply as they are only among integer-types (and
>   among char-types? not?), but not from one family to the other.
>   However a cast by reinterpret_cast<> still would be possible.
>   Enums also would not cast implicitely to char-types.

Why not deprecate ALL lossy conversions.  That would be more useful.

> - tidying up std::basic_string

I think that there is a general consensus that std::basic_string could
stand some tidying up.  I think that there is a lot less consensus as to
what the tidying up should entail.

> How think other people about the usefulness of such a distinction?

If we were designing a new language, I think that the distinction would
be useful, if we could really decide what the semantics of a character
type should be.  (You obviously can't multiply two characters, for
example.  But addition?)  But we're not designing a new language.  The
name for the smallest integral type in C++ is spelled char, and we
cannot change that any more than we could change the spelling of int to
integer.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Nikolai Pretzell wrote:
>
> Hi,
>
> As there are many problems with ambiguities (in overloading
> functions and elsewhere) with numbers and characters, I wonder if it
> would be possible to change the behaviour of the
> basic language so that there ar no longer any more implicit
> conversions between char/wchar_t on one and all other
> integer types on the other side.

Wow, do you wear your flame proof vest? ;-)

> This breaks some existing code.

For example 100% of C code - 50% of the lines in it.

> However, the change of scope of
> declarations within for-loop-headers also broke existing code -
> probably even more. One could provide compiler-switches for old code.

For a beginning language - but you want to change a rule, which comes
from C, which was a well established language for decades and the amount
of existing code is _huge_.

> Semantically, a char is a fundamentally different thing than an
> integer, and many problems could be avoided by handling them as that:
> completely different.

It is, for overloading, so if you provide a char (or template)
implementation that will be chosen and not the int.

> Some possible changes to achieve that:
>
> - declaring 'unsigned char' and 'signed char' deprecated,

???

> - adding 'byte' and 'unsigned byte' as integer data types,

I have a more simple solution!  Learn, that in C++ char means byte.  :-)

>   which are guaranteed to be 8-bit on all platforms.

Ajjajjjaj.  This breaks the zero-overhead rule!  There are platforms
where char is 16 or even 128 bits!

> - adding 'unicode' (16bit) and 'long unicode' (32 bit)

OK.  How about the existing wchar_t, which is for that purpose?  And
again: you will be told by many experts that the _only_ thing a Standard
language can define is the _minimum_ number of bits.  A Standard lives
for about 10 years before the next update.  So it would be a showstopper
for applications trying to use new platforms.

>   as char data types

What would long unicode be?  I assume unicode is exactly the wchar_t.

> - changing implicit conversion rules such, that integer
>   conversions apply as they are only among integer-types (and
>   among char-types? not?), but not from one family to the other.

What is the problem of promoting a char to integer?  I can believe that
there can be with the conversions the other way around.

I think that you have a misunderstanding about what char means.  The
type char _is_ a byte (sized, min. 8 bits) type (signed or unsigned),
which is capable of representing the native character set of the
platform.  But nothing says it is _only_ for characters - and as I see
your thinking path is based on this.  One could say that char should be
separated from unsigned char (the unsigned byte type) and signed char
(signed byte type), because they are real "tiny integers", while char is
more like a woman: misterious and noone knows for sure if it will be
signed or unsiged on the platforms one meets.

>   However a cast by reinterpret_cast<> still would be possible.

reinterpret_cast is implementation defined and the casting from chart
types to integer types was defined so far - so this kinda change will
certainly not be tolerated.

>   Enums also would not cast implicitely to char-types.

You have got me here, I thought that it only casts to int types...

> - tidying up std::basic_string
>
> How think other people about the usefulness of such a
> distinction?

I think there is much more to it than meets the eye!

> Do people think this change would be possible (if it would be
> considered useful)?

I doubt it.  Just think about that it would either make a bigger
distance between C and C++ _or_ break all existing C code.

Attila



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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