[Maybe this is only a compiler implementation issue ... but I think
that comments on a proposed extension solely suggested to fix a
code generation problem might also occur in this group.]

In article <4a3h2q$sdf@news.aloha.com>, jching@aloha.com (Jimen Ching) writes:
|>Kevlin A P Henney (Kevlin@two-sdg.demon.co.uk) wrote:
[...]
|>>Sounds like enums to me -- you've got all the language you need to do the job.
|>
|>I did use enums.  I switched to a class because it allows me to control
|>the size.  The type I had in mind is used very often.  Thus size and
|>efficiency is very important.  On many systems (especially 32 bit machiens),
|>sizeof(enum) == 4.  But, for my internal_type  sizeof(internal_type) == 1.
|>Thus, I can store four times as many data, and yet still have the operators
|>for convience.  The only problem was, I no long can use switch statements
|>like I could with enums.  I guess if I want speed, I have to use array
|>indexing.  But with large number of constants, the array will be large,

There are at most 256 constants with sizeof(switch_type) == 1 (at least
if CHAR_BIT == 8). Even those 8051 derivates have at least 64K possible code
size, so the jump table with its max. 512 bytes (or 1K on larger systems)
should be no problem, should it?

|>so I still lose storage space.  I just can't win.  :)

But what will the compiler do with your switch statement? I assume it
will either produce an if-then-else-chain or a jump-table that is indexed
by constants. Maybe a compiler could even build code which does both -
but all these options are also open to you (if-then-else is part of
the language, jump-tables can be emulated by mapping all your switch labels
to a dense set of enum constants and then apply a usual switch statement).

HMMueller

== -------------------------------------------------------------------
== Dr. Harald M. Mueller                 PSE EZE TNA1
== email: mueller@garwein.hai.siemens.co.at     Siemens AG Austria
== tel: +43-1-71711-5336                 Erdberger Laende 26
== fax: +43-1-71711-5425                 A-1030 Vienna/Austria
== -------------------------------------------------------------------




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

In article <9512071449.AA03547@titania.hai.siemens.co.at>,
mueller@titania.hai.siemens.co.at (Harald M. Mueller) wrote:

>> |>for convience.  The only problem was, I no long can use switch statements
>> |>like I could with enums.  I guess if I want speed, I have to use array

What about :

class internal_type {
    short operator short(); // a "casting" operator
    };

Where short can be anything from char to long ?

--
-- Etay Bogner,
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.

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

Jimen Ching (jching@aloha.com) wrote:
|> Kevlin A P Henney (Kevlin@two-sdg.demon.co.uk) wrote:
|> >Why? Given that an important feature of a switch statement is that the
|> >target labels are unique, how do you intend to determine this at compile
|> >time for runtime expressions?

|> The labels are unique because they are intended to be used as constants,
|> just like 'a' or 'z'.  Just like you do not change 'a' at run time, you
|> can not (or should not) change my constants either.  I guess I should say
|> I want to create my own constant 'literals', and be able to control the size.

|> >Sounds like enums to me -- you've got all the language you need to do the job.

|> I did use enums.  I switched to a class because it allows me to control
|> the size.

Since when?  The only thing which allows you to control the size (more
or less) would be to use char or unsigned char.

|> The type I had in mind is used very often.  Thus size and
|> efficiency is very important.  On many systems (especially 32 bit machiens),
|> sizeof(enum) == 4.  But, for my internal_type  sizeof(internal_type) == 1.

Although this corresponds to the results on my machine, I admit that it
sort of surprises me.  I would expect that typically, the reverse would
hold; the compiler would simply enforce alignment restrictions for all
classes, regardless, but would put the enum into the smallest type
possible.

|> Thus, I can store four times as many data, and yet still have the operators
|> for convience.  The only problem was, I no long can use switch statements
|> like I could with enums.  I guess if I want speed, I have to use array
|> indexing.  But with large number of constants, the array will be large,
|> so I still lose storage space.  I just can't win.  :)  It would be great
|> if the switch could detect that my internal type was actually a 'char'
|> type and base the selection process on that.  I'm not sure how complicated
|> the compiler would be to do this.  But I think it is possible.  Maybe it
|> should be an optional feature in C++.

It would be impossible for the compiler, since it would cease to be
conforming (I believe).

In view of what you have just said, what would be wrong with just having
a function which returns the enum.  For example:

    template< class T >         //  T must be an enum which fits in a char
    class EnumByte
    {
    public :
                            EnumByte( T init = 0 )
                                :   theValue( init )                   {}
        T                   value() const
                                {   return theValue ;                   }
                            operator T() const
                                {   return theValue ;                   }
        //  Any other operators you want.
    private :
        unsigned char       theValue ;
    } ;

This is *not* guaranteed to result in an object with the smallest
possible size, but if it works one your machine, it may solve your
problem.

Note that the enum constants are still external, and exist separately as
constants.  So they can be used as cases in a switch.  And with the
conversion operator, you should be able to use EnumByte<T> types
directly as the control of the switch.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
              -- A la recherche d'une activit    dans une region francophone

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

In article <DJGD0L.AEA@kroete2.freinet.de> erik@kroete2.freinet.de
(Erik Corry) writes:

|> Steve Clamage (clamage@Eng.Sun.COM) wrote:
|> :
|> : In C and C++, the size of a char or a byte is always
|> : implementation-defined, and neither is required to be exactly 8
|> : bits. A char or a byte could have more (or fewer) than 8 bits.

|> James Kanze has already pointed out that large parts of the ANSI/ISO
|> C standard are included in the C++ draft. In the ANSI C section
|> 5.2.4.2.1:

At the end of section 18.2.2, there is a specific reference to ISO C
subclause 5.2.4.2.1.  So one must presume that this section is
included by reference.

|> > [..] Their implementation defined values shall be equal or greater
|> > in magnitude to those shown, with the same sign.
|> >
|> > - number of bits for smallest object that is not a bit-field (byte)
|> >   CHAR_BITS      8

|> Which I read to mean a char has at least 8 bits, not 7 as the above
|> seems to imply. I very much hope this is one of the sections that also
|> applies to C++.

I think that Steve just got carried away.  Historically, bytes could
be less that 8 bits, although I don't know if there was ever an
implementation of C where this was the case.  ISO C requires at least
8 bits (as you point out).

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



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

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: In C and C++, the size of a char or a byte is always implementation-defined,
: and neither is required to be exactly 8 bits. A char or a byte could have more
: (or fewer) than 8 bits.

Isn't CHAR_BITS (in limits.h) required to be at least 8 (with the
obvious implication that char is at least 8 bits)?
--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.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. ]

Jerry Coffin (jcoffin@rmii.com) wrote:
>
> signed char -127 .. 127
> unsigned char 0 .. 255
> short  -32767 .. 32767
> unsigned short 0 .. 65535
> int  -32767 .. 32767
> unsigned 0 .. 65535
> long  -214783647 .. 214783647
> unsigned long 0 .. 4294967295
>
> (With plain `char' having the same range as either `signed char' or
> `unsigned char', but being of a type distinct from either.)
> (ISO C: 5.2.4.2.1, referred to by r.2.3 and r.3.6.1 in C++PL2 )
>
> AFAIK, these ranges require the previously posted number of bits to
> represent.  If you can show a way of representing these ranges in fewer
> bits, you have the foundation of the worlds greatest data compression
> algorithm...

I see no reference to this in the DWP. 3.9.1 [basic.fundamental] specifies
the ordering and it says that any of them can be equal in size as long as
none are smaller than the previous. It suggests that int would be the
natural size for the machine.

18.2 [lib.support.limits] describes the <limits> header and the
numeric_limits class is in 18.2.1.1 which has to be specialised for builtin
types so you can use numeric_limits<int>.min() and .max().

--
[=======================================================================]
[ Kevin Lentin                   |      The Mighty Carlton Blues      | ]
[ K.Lentin@cs.monash.edu.au      |          1995 AFL Premiers         | ]
[ Macintrash: 'Just say NO!'     |CARLTON 21-15-141 d geelong 11-14-80| ]
[=======================================================================]


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

> ==========Steve Clamage, 12/4/95==========

> In portable code, assume only the minimum ranges required by the
> standard.

This is what causes the trouble as certain minimum number
of bits really matter in many cases and the highly conservative,
standard minimum ranges are unrealistic.  64 vs. 32 vs. 16 bits
make enormous differences in much code.  For a random
number mill, 16 bits is generally inadequate.  For the whole
random number abstraction, the difference between 32 and 64
bits doubles the length of the sequence that has full representation.
This is but one example.  There are just too many cases
where you need to do better than the hyper-conservative
stance of the C standard or the C++ DWP.

> That problem is particularly easy to resolve in C++. Create a
class that
> manages the bit-fiddling, and reimplement only that class for each
> different architecture. The remainder of the source code is unchanged.

The issue is performance by both the software and the programmer.
Having exception-free built-ins with better granularity guarantees
matters a lot.

Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.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. ]

In article ghm@bcarh8ab.bnr.ca, "brian (b.c.) white" <bcwhite@bnr.ca> writes:
>
>I thought I read somewhere that C++ guarantees a "char" to be 8 bits (or
>was that "one byte"?).

In C and C++, the size of a char or a byte is always implementation-defined,
and neither is required to be exactly 8 bits. A char or a byte could have more
(or fewer) than 8 bits.

Excerpts from the C++ draft standard:

[intro.memory]  1.5 The C++ memory model
The fundamental storage unit in the C++ memory model is the byte. A byte is
at least large enough to contain any member of the basic execution character
set and is composed of a contiguous sequence of bits, the number of which
is implementation   defined.  ...

[basic.fundamental]  3.9.1 Fundamental types
Objects declared as characters (char) shall be large enough to store any
member of the implementation's basic character set.  ...
---
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. ]

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

John Galt (jgalt@infosoft.com) wrote:
>
> 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.

It actually possible to do this in C++ with some cunning use of friend
classes and private and public constructors. An exercise for the reader.

> 7.  Add #pragmas to tell the compiler where optimizations are okay; for
> example, where it's okay to assume that an array pointer is not aliased.
> (To those who say the compiler should not trust the programmer to tell it this,
> I say, I have yet to see a compiler smart enough to know for itself -- and C++
> really isn't robust enough that it _can_ always tell, even in principle!)

Asking for a standard to add #pragmas makes no sense. #pragmas are, by
definition, not part of the language.
>
> 8.  Eliminate the stupid, bogus concept of a "member pointer."  The following
> code should be legal:

It is.

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

Get GNU autoconf. Makes writing portable code much easier. Writing portable
C++ code at this point in time is very difficult.
>
> 10.  Add a preprocessor directive that lets you test compiler options, like
> {$ifopt x} in Turbo Pascal.

Compilers are free to #define things if they want - in fact that do. GNU
C++ defines something (__GNUC__ I think) to tell you that you can use some
weird extensions they have put in.

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

How would the compiler know. Your comments seem to indicate you are a DOS/WIN
programmer only where it is difficult to separate the compiler and the
system. On most other operating systems the language and the system library
are very different and are covered by different standards.

>      - Which version of the for scope rule is supported?
Just
#define for if (0) ; else for
or use something like autoconf.

>      - Does real (enforced) record locking exist?

LAUGH! There's only one way to find that out and that is to test. NEVER
trust the documentation, compiler, library or anything else. At least that
is my experience.

>      - The exact behavior of date and time functions
>      - The size in bits of a character, short, int, long, etc.
>      - The size in bits of the unit used by the sizeof() operator
>      - Whether the system is little- or big-endian
>      etc.

If you are writing code that needs to know all this then chances are it's a
fairly technical piece of work and probably needs more than the normal
simple setup and configuration.

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

The with statement can lead to horribly ambiguous code (from the reader's point
of view). You can simplify your code using a reference.

Although while accusing the with statement of creating ambiguities, I can't
leave out namespaces which do the same thing. Now which i did I just
modify? :-)
>
> 15.  Allow multiple subscripts to be specified as [x,y] rather than [x][y].
> This will not break existing code, unless someone is silly enough to be using
> the comma operator inside a subscript on purpose!

Silly enough? Geez. Features exist. People use them. You can't call them
silly for doing something like that. You can call the language silly for
including them originally but they are here to stay now. Those semantics of
the comma operator are widely used, especially in for loop initialisation
and increment sections. Making it mean somethine completely different with
[] would be a bad thing.

--
[=======================================================================]
[ Kevin Lentin                   |      The Mighty Carlton Blues      | ]
[ K.Lentin@cs.monash.edu.au      |          1995 AFL Premiers         | ]
[ Macintrash: 'Just say NO!'     |CARLTON 21-15-141 d geelong 11-14-80| ]
[=======================================================================]

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

> ==========Matt Austern, 11/30/95==========

> The real standardization issue here is that the standard class library
> doesn't include any multidimensional array classes; I find that
> unfortunate, since multidimensional arrays are widely useful.
> Presumably most compiler vendors will provide them, even if the
> standard doesn't require them to; maybe we can hope for a de facto
> standard version.

I have a stronger hope that a committee will form
that includes compiler vendor representation for the
purpose of establishing a forum for making up front
de facto standard additions.  Having them agree
(rather than war over things that should ultimately
end up in the next revision of the real stanard upteen
years from now) would benefit all.

As far as STL is concerned, there are many things
that seem to have missed only because of time.
It is incomplete as a result.  Some of those would
start the effort.  Of course, additional stuff would
follow including changes (possibly in a distinct
namespace) to existing stuff that was found to
miss the newly perceived mark.  This is needed
at minimum.

Such a committee could even take on language
extensions and fixups so that those have more
commonality.  If fixing the exception mechanism
is seen as new rather than clenaup by the committee,
then this would need attention by the less formal
forum.  It would likely give rise to the defacto
language going beyond the standard time-wise,
but that seems to be the norm in most standards
efforts.  Look at SCSI standards for an example
of the real world moving faster than the standards
process.  It can be done.  There are probably
even better examples out there.  But for SCSI
standards, the defacto effort seems part of the
formal effort, at least during the more recent
stages (the earlier stages were more like the
war approach).

Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.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. ]

jcoffin@rmii.com (Jerry Coffin) wrote:

[ talking about allowing [x,y] for multiply dimensioned arrays  ]

>I'll openly state that this is NOT something I'd reccomend, but it
>certainly looks to me like it can be done without modifying the
>standard, if one chooses to do so.  Therefore, if anybody wants to
>discuss it further, it probably belongs in comp.lang.c++ rather than
>here.  (Most likely any further discussion _should_ simply be flaming me
>for even suggesting such a horrible abuse of overloading.  If anybody
>ever actually sees me DO such a thing, please feel free to flame
>away...)

>[ moderator's note: Discussions about whether a feature belongs in the standard
>  are appropriate for this news group. It's also OK to disagree with anyone's
>  opinion, but let's try to keep the disagreements civil, and avoid personal
>  attacks.  -sdc ]

Just to clarify: when I talked about further discussion, I meant of how
to overload the comma and subscript operators to do it under the current
standard, not discussion of modifying the standard to allow it without
the overloading...

Further contemplation makes me wonder if this really couldn't be added
to the language, perhaps with less impact than initially seems likely.

If, inside of brackets, the comma was defined to be a separator, much
like in a function call, and a comma operator required that the
expression using it be enclosed in parentheses, this could be managed
without ambiguity.  Further, the vast majority of usage of comma
operators (outside of for loops) is in macros, which typically enclose
their bodies in parentheses anyway.

If this were done, it would certainly break some code, but at least if
the same separator vs. operator rules were adopted as are presently used
in function calls, much old code would still work, and no basic
capability would be lost. (I.e. you could still use the comma operator
inside a subscript if you wanted to. )  Most of the old code that would
break would be macros that don't parenthesize their bodies, in which
case they may break in some existing situations anyway.  Finally, no
fundamentally new constructs or syntax rules would be needed -- this
would simply apply an existing rule in a different area.

Cons:

The comma already has a couple different uses, and requires special
syntax at times to separate between them.  This adds more of the same.
Further, it adds no capability not easily available under the current
standard -- it strictly adds a new syntax for an existing capability.
Though it's not clear exactly how much code would be affected, it would
break some existing code that's been legal for quite some time.
Finally, it would introduce a basically gratuitious difference between C
and C++.  Most other differences appear nearly unavoidable without
drastically impacting the languages, but this one seems quite easily
avoided.  OTOH, If it were deemed suitable and important, it likely
wouldn't be terribly difficult for this to be considered for C9X.
    Later,
    Jerry.

/* I can barely express my own opinions; I certainly can't
 * express anybody else's.
 *
 * The universe is a figment of its own imagination.
 */



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

> ==========Michael Cook, 11/30/95==========

> >>>>> "JG" == John Galt <jgalt@infosoft.com> writes:

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

> That sounds reasonable.  The most frequent use of bitfields
> seems to be to
> model external data (such as hardware registers or datacom packets).
> It's frustrating to be restricted to partial specifications.

With all of the discussion of the freedom to compilers
on sizeof the raw block, where the stuff is in the block,
and where the "this" points in all of that (assuming it
is in and not out of the block), I have not yet convinced
myself that it is possible to code stuff that is "up close
and personal" to hardware without intimate knowledge
of a particular incarnation of a particular compiler (I have
not yet had much time for this either).  This was not as much
of a potential problem in C.  So, is there a way to nail
this sort of thing to the floor without such intimate knowledge?
Or do I still have to compile some C code with strict C
rigidity of rules (or even assembly code) to insure the
proper alignment?  [Hopefully, I solve my hardware
problems at home, get Win95 installed, and my compilers
(both Borland 4.5x and VC++ 4.0) up so I can try things
out on reasonably current compilers.  sigh]

Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.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. ]

Jerry Coffin (jcoffin@rmii.com) wrote:
: On top of that, all but the 64 bit types already exist, just with
: different names:

: typedef signed char  int8;
: typedef unsigned char  unsigned8;
: typedef signed short  int16;
: typedef unsigned short  unsigned16;
: typedef signed long  int32;
: typedef unsigned long  unsigned32;

: These are equally applicable to C as C++.  Of course in all these cases,
: the standards allow the implementation to exceed the given size
The current drafts and all precvous C and C++ standards and K+R C
define something like this:
There  are  four  signed  integer  types:  "signed char", "short int",
  "int", and "long int." In this list, each type provides  at  least  as
  much storage as those preceding it in the list, but the implementation
  ...

They do not pecify or require any particular number of bits.

Grrrrrrrrr.


--
 dick@csci.csusb.edu=rbotting@wiley.csusb.edu.
Find out what's new at http://www.csci.csusb.edu/doc/www.sites.html
Disclaimer:`CSUSB may or may not agree with this message`.
Copyright(1995):Copy this freely but include the following link to the
<a href="http://www.csci.csusb.edu/dick/signature.html">author's signature</a>

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

In article <49r5vc$pk2@news.aloha.com> jching@aloha.com "Jimen Ching" writes:

 [standard switch statement]

 > This is valid for C and C++.  So for the above premise of C++, I should
 > also be able to do the following as well:
 >
 > class internal_type
 >         {
 >         friend bool operator==(const internal_type &lhs, const internal_type
 >  &rhs)
 >                 { return lhs.data == rhs.data; }
 > public:
 >         internal_type(char c = '0') : data(c) {}
 > private:
 >         char data;
 >         };
 >
 > internal_type const a('a');
 > internal_type const b('b');
 > internal_type const c('c');
 >
 > f(internal_type &it)
 >         {
 >         switch (it)
 >                 {
 >                 case a: /* do something... */ break;
 >                 case b: /* do something... */ break;
 >                 default: /* do something... */ break;
 >                 }
 >         }

Why? Given that an important feature of a switch statement is that the
target labels are unique, how do you intend to determine this at compile
time for runtime expressions? Don't forget that C/C++ builtins don't allow
you to runaway w/ the show as you've suggested: floats and pointers are not
switchable [Sun used to support switching on floats, but pointers could be
kind of amusing, so perhaps next 1st April...].

 > If C++ lived up to its promise, why can't I do the above?

It lives up to its promises because it _doesn't_ do the above ;->

[example omitted]

Sounds like enums to me -- you've got all the language you need to do the job.
_______________________________________________________________________

  Kevlin A P Henney        2sdg Ltd        kevlin@two-sdg.demon.co.uk
  "What happens to the hole when the cheese is gone?"  Bertolt Brecht
_______________________________________________________________________


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

dick@silicon.csci.csusb.edu (Dr. Richard Botting) wrote:

>The current drafts and all precvous C and C++ standards and K+R C
>define something like this:
>There  are  four  signed  integer  types:  "signed char", "short int",
>  "int", and "long int." In this list, each type provides  at  least  as
>  much storage as those preceding it in the list, but the implementation
...
>They do not pecify or require any particular number of bits.

They don't give the specificactions in terms of numbers of bits, but
they require that all integer types use a "pure binary" representation,
and they require at least the following ranges of each type:

signed char -127 .. 127
unsigned char 0 .. 255
short  -32767 .. 32767
unsigned short 0 .. 65535
int  -32767 .. 32767
unsigned 0 .. 65535
long  -214783647 .. 214783647
unsigned long 0 .. 4294967295

(With plain `char' having the same range as either `signed char' or
`unsigned char', but being of a type distinct from either.)
(ISO C: 5.2.4.2.1, referred to by r.2.3 and r.3.6.1 in C++PL2 )

AFAIK, these ranges require the previously posted number of bits to
represent.  If you can show a way of representing these ranges in fewer
bits, you have the foundation of the worlds greatest data compression
algorithm...
    Later,
    Jerry.

/* I can barely express my own opinions; I certainly can't
 * express anybody else's.
 *
 * The universe is a figment of its own imagination.
 */



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

Hi,
 Since we're on the subject, I have another feature I would like
some opinions.  This feature is based on the following premise:

 C++ allows the programmer to deal with user defined types like
 any other types, including internal types.

The above is what I understood the advantage of C++ over C.  Now, in C/C++
we can do the following:

typedef char internal_type;
f(internal_type it)
 {
 switch(it)
  {
  case '0' /* or any other constant of internal_type */:
   /* do something here */
   break;
  case /* ... */
  }
 }

This is valid for C and C++.  So for the above premise of C++, I should
also be able to do the following as well:

class internal_type
 {
 friend bool operator==(const internal_type &lhs, const internal_type &rhs)
  { return lhs.data == rhs.data; }
public:
 internal_type(char c = '0') : data(c) {}
private:
 char data;
 };

internal_type const a('a');
internal_type const b('b');
internal_type const c('c');

f(internal_type &it)
 {
 switch (it)
  {
  case a: /* do something... */ break;
  case b: /* do something... */ break;
  default: /* do something... */ break;
  }
 }

If C++ lived up to its promise, why can't I do the above?  You might
wonder where I got this idea.  Well, I was working on a project which
needs to model register states, such as logic low, logic high, high
impedance and don't care.  So I have a class called 'logic'.  But
instead of using a switch for each logic state, I have to use a bunch
of 'if', 'else if' statements.  This is not a problem for 4 states, but
many digital circuits can test for 'strengths' in logic levels, and
with 'char' type, I can support upto 256 states.  Also, what if I
wanted to do the same thing for a special sequence of states, such
as 1,5,9,15,77,99.  I would have to test for each one of these.  Not
a problem if the sequence is small, but what if it was over 50 values?
I understand why C couldn't do this, but why can't C++?

I haven't looked at the latest draft standard.  If the latest draft
standard supports this, please point me to where I can look it up.
Thanks in advance...
--jc
--
Jimen Ching (WH6BRR)      jching@aloha.com     wh6brr@uhm.ampr.org


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