🚀 go-pugleaf

In article AA11227@getafix.infosoft.com, jgalt@infosoft.com (John Galt) writes:
>
>1.  Allow "units" like those in Pascal.  

Maybe someday. Not in this round of standardization. It's not a technology
issue. C++ did not have the feature initially so that it could be easily
ported to any machine having a C compiler. No other support was required.
(Now other support is required.)


>2.  Change the language's general behavior, in the case of error conditions,
>to throwing a (standard, portable) exception rather than either bombing out or
>just returning a value such as NULL or EOF. 

Where it doesn't conflict with C, that is already the case.


>3.  When "new" is used to allocate a class object, there should be a standard
>way for the constructor to tell "new" that it failed, causing "new" to free
>the storage it allocated....

Something like this is already in the standard.


>4.  Allow the subscripts of auto arrays to be non-constant expressions.  

This topic has been discussed here over the last few days. Don't you read
a newsgroup before posting to it?


>5.  Allow classes or functions to be declared as "friends" of an individual
>class member, rather than of the entire class!  This would essentially make
>the "protected" category unnecessary, allowing you to have its benefits in
>your derived classes without opening up your data to anyone who feels like
>writing a new class derived from yours.

Sounds like a terrible idea to me, making maintenance a nightmare.
Your taste may vary.


>6.  Allow static member functions and non-member functions to be inline.

It has always been allowed for any function to be declared inline.
It has always been allowed for any member function to be written
inline in the class definition. 


>7.  Add #pragmas to tell the compiler where optimizations are okay; 

Any compiler may have any pragmas it wants. IMHO, pragmas should not
be specified in the standard, since they are by definition outside
the language, affecting only implemenation details, or changing
language semantics from what the standard says.  


>8.  Eliminate the stupid, bogus concept of a "member pointer."  The following
>code should be legal:
>
>     int* ip;
>  
>     class X {
>       int m;
>  
>       void f() { ip = &m; }
>     };

Such code has always been legal. Evidently you don't understand what member
pointers are for. They serve a different purpose.


>9.  Add standard integer types that tell you their size (int16, unsigned8).
>All platforms would be required to support these, up to 64 bits, even if it
>means that a multiply takes 10-15 instructions instead of one or two.  (On CPUs
>with odd-sized words, an "int16" might be MORE than 16 bits, but never less.)

Why? (This topic is regularly beaten to death in comp.lang.c++, and
surfaces here from time to time.)


>10.  Add a preprocessor directive that lets you test compiler options, like
>{$ifopt x} in Turbo Pascal.

Any compiler can add any sort of feature test it wants, as a pragma, as
a special-format comment, or perhaps via some other syntax.
Nothing along those lines could possibly be portable.


>11.  Add predefined names that let you test the answers to questions like:
>
>     - Does the system support fork()?
>     - Does it support threads?
>     - Does real (enforced) record locking exist?

These are completely outside C++. They are OS issues. It would make more
sense to demand that the OS provide such query functions.

>     - Which version of the for scope rule is supported?

There is only one version: the version in the standard when it is finally
published. There are many, many rules related to scope and name injection.
Some aspects were undefined in the ARM, and different compiler did different
things, sometimes by accident. How would you characterize such rules with
predefined names? 

>     - The exact behavior of date and time functions

The behavior is specified in the C standard, and inherited by C++. Where
variations are allowed in implementations, the implementation has to
document the details. What sort of predefined names could capture all
the allowed variations? (Don't forget implementations that haven't been
written yet.)

>     - The size in bits of a character, short, int, long, etc.
>     - The size in bits of the unit used by the sizeof() operator

Those are already available, by using combinations of sizeof, the
standard headers <limits.h>, <float.h> and <stddef.h>.

>     - Whether the system is little- or big-endian

What about systems that are neither? For example, one widely-used
system puts the msb of floating-point numbers in the middle of the
object, considering the byte addresses in memory. 


>12.  Allow bit-field structures to be of any size, and allow the declaration
>to specify the position of the fields.

IMHO that is too low-level for C++. You can't do everything in a high-
level language. That's why you shouldn't throw away the assembler.
(Your taste may vary.)


>13.  Allow anonymous structs (that is, with neither a name for the struct type
>nor an object declared), 

That is suggested from time to time.


>similar to the anonymous unions in Borland C++.  (Make
>those standard too, if they aren't.)  

Anonymous unions have been part of C++ for a very long time.


>14.  Add a "with" statement, just like the one in Pascal.

That point is debated frequently in comp.lang.c++, and sometimes here.
You can already get the effect of a "with" while avoiding the scope
confusion by creating a reference to a portion of a nested structure.
That turns out to have the same semantics and generates the same code
as a Pascal "with". It is less convenient to write the code than using
a Pascal "with", but the code is a lot easier to understand.


>15.  Allow multiple subscripts to be specified as [x,y] rather than [x][y].
>This will not break existing code, ...

Of course it will. The expression [x,y] already has a defined meaning
which is completely different. How would you write portable code in
the face of two completely unrelated meanings of a comma, and compilers
written to completely different semantic rules? (Don't forget machine-
generated code often has constructs you would not deliberately
write yourself.)

---
Steve Clamage, stephen.clamage@eng.sun.com




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]