🚀 go-pugleaf

Proposed:

That when a parameter [including the hidden "this" parameter] is declared 
"const", or when the object referenced by a parameter is declared "const",
than it is not legal to modify that which is declared "const" within the 
function. This is to say, the trick of casting to a non-const does not 
work on a parameter declared as "const."  Compilers can flag as an error 
these situations.

The reason I propose this restriction on the casting trick is to allow 
compilers to correctly optimize code when presented with independently
compiled libraries.  To be able to correctly optimize, compilers need to
be able to assume that "const means const" in those libraries.

The counter-position is that "const" means that an object appears unchanged
from the outside, but individual members of the object may be changed
[such as cached values.]  However, an optimizing compiler can enregister
one or more of those "const" values, such a hybrid, inconsistent object
results when the "const"-ness of a function is not correctly stated.
Thus if the counter-position is adopted, members of a object
cannot reasonably be enregistered across "const" functions.  Also, the 
possibility of placing "const" objects in read-only or write-once memory
is eliminated.

Let's let "const mean const" and deprecate the cast to non-const trick.

[disclaimer: the above represents the opinion of an individual C++ user]

Proposed:

We need a way to "pack" objects over inheritence boundaries, and possibly
between labeled fields of a declaration.  I do not propose here exactly
what the "right" way to do this is.

I claim this is important because I see lots of examples of serious C++
programmers implementing "hacks" to "pack" objects across inheritence
boundaries.  Examples include:  Base class B needs two bits, and derived
class D needs three bits, so let's implement a bit sharing hack between 
base and derived, rather than being able to use bit fields, and automatically
have those fields "packed" into one word in the final structure.  Or base class
B needs a byte, and derived class B needs a byte, but each is going to 
be placed in their own word-aligned slot, so instead implement a hack so
that both bytes can reside in one word.  Features commonly use should be
part of the language, not implemented via "hack" word-arounds.

---

Possible full or partial "solutions" to this problem include:

* Throw out the current C++ restrictions on field ordering entirely.  What
does it buy us anyway?  Use 'extern "C"' where an object needs backwards
compatibility to "C" packing order.

* Require current field ordering restrictions be maintained on things declared
"struct", but removed restrictions on anything declared "class."

* Introduce an explicit keyword "packed" or similar.  Declaring a base class
"packed" turns off field ordering restrictions in that class and its 
derivatives, as well as representing a directive to the compiler that small
size is to be preferred to fast access.  Possibly vtable ptrs could also 
be replaced with smaller type tags in such classes....

....

[disclaimer: this posting respresents the opinions of an individual C++ user]

In article <56163@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>Proposed:
>
>That when a parameter [including the hidden "this" parameter] is declared 
>"const", or when the object referenced by a parameter is declared "const",
>than it is not legal to modify that which is declared "const" within the 
>function. This is to say, the trick of casting to a non-const does not 
>work on a parameter declared as "const."  Compilers can flag as an error 
>these situations.
>

	I don't agree with the illegalization of this construct. I think it
is against the spirit of the language to illegalize a cast.

	In C, and C++ a cast is supposed to always work, no matter what
object you're casting. I think that it should be legal for compilers to
preform optimizations based on the information given by declaring a const
parameter, but programmers should be allowed to cast if they feel it
neccesary.

Have fun,
UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper   (Eric Hopper)
     __                    /)                       /**********************/
    / ')                  //                         * I went insane to   *
   /  / ______  ____  o  //  __.  __  o ____. . _    * preserve my sanity *
  (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_  * for later.         *
Internet:              />                            * -- Ford Prefect    *
hopper@ux.acs.umn.edu </  #include <disclaimer.h>   /**********************/

In article <1913@ux.acs.umn.edu> hopper@ux.acs.umn.edu (Nils  McCarthy) writes:
>In article <56163@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>>Proposed:
>>
>>That when a parameter [including the hidden "this" parameter] is declared 
>>"const", or when the object referenced by a parameter is declared "const",
>>than it is not legal to modify that which is declared "const" within the 
>>function. This is to say, the trick of casting to a non-const does not 
>>work on a parameter declared as "const."  Compilers can flag as an error 
>>these situations.
>>
>
>	I don't agree with the illegalization of this construct. I think it
>is against the spirit of the language to illegalize a cast.
>
>	In C, and C++ a cast is supposed to always work, no matter what
>object you're casting. I think that it should be legal for compilers to
>preform optimizations based on the information given by declaring a const
>parameter, but programmers should be allowed to cast if they feel it
>neccesary.
>
>Have fun,
>UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper   (Eric Hopper)
>     __                    /)                       /**********************/
>    / ')                  //                         * I went insane to   *
>   /  / ______  ____  o  //  __.  __  o ____. . _    * preserve my sanity *
>  (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_  * for later.         *
>Internet:              />                            * -- Ford Prefect    *
>hopper@ux.acs.umn.edu </  #include <disclaimer.h>   /**********************/

I disagree with the statement "In C ... a cast is always supposed to work.."
In fact, it does not always work, although you are always allowed to try
without the compiler getting too upset.  For instance, casting a pointer
to a char as a pointer to double is not guaranteed to work, event if the
bit pattern at the address is a legal floating-point number.  Why? Because
some machines don't support arbitrary alignment of operands and many
compilers (rightfully IMHO) don't slow down the code with multiple fetches
to get around the alignment problem of the hardware.

I submit that const cast tricks are in a similar class to char/double
cast tricks -- they might work but are not guaranteed and shouldn't be
assumed to work.  You might even get a bus error trying to write to ROM
or a read-only peripheral register.  Let the optimizer do their thing without
having to worry about a buch of tricks.  If you don't want a const, don't
use a const!

--
------------------------------------------------------------------------
Scott Townsend               |   Phone: 216-433-8101
NASA Lewis Research Center   |   Mail Stop: 5-11
Cleveland, Ohio  44135       |   Email: fsset@bach.lerc.nasa.gov
------------------------------------------------------------------------

One use for dereferencing null pointers leaps to mind.  Consider this
definition, used in Intrinsics-based widgets in the X Window System:


Copyright 1987, 1988 by Digital Equipment Corporation, Maynard,
Massachusetts, and the Massachusetts Institute of Technology,
Cambridge, Massachusetts. All Rights Reserved.

#define XtOffset(type,field) \
        ((unsigned int) (((char *) (&(((type)NULL)->field))) - \
                         ((char *) NULL)))



It's used to calculate offsets into the elements of a struct, as
in this snippet from a fictional wristWatch widget:

static XtResource Resources[] = 
{
  { XtNwatchFaceColor,
      XtCFaceColor,
      XtRString,
      sizeof(char *), 
      XtOffset(GIWristWatchWidget, watch.face_color),
      XtRImmediate,
      "White"
  },
....


Can anyone else think of a situation where null dereferencing is
useful, besides compile-time calculation of offsets?


Rod
--
---------------------------------------------------------------------
 __  __
|__)(__'  Don't worry about not seeing the top....
|  \___)               _    o   
                        -_ -\>
                          -_<\
                            -_
                              -_
              ...so much as seeing the bottom.

Roderick Sprattling                      DialCom:  8*833-7054

sprattlingrl@crd.ge.com	                 rls@onondaga.crd.ge.com
uunet!crd.ge.com!sprattlingrl

---------------------------------------------------------------------

In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>Proposed:
>
>We need a way to "pack" objects over inheritence boundaries, and possibly
>between labeled fields of a declaration.  I do not propose here exactly
>what the "right" way to do this is.

[edited for brevity]

>Possible full or partial "solutions" to this problem include:
>
>* Throw out the current C++ restrictions on field ordering entirely.  What
>does it buy us anyway?  Use 'extern "C"' where an object needs backwards
>compatibility to "C" packing order.
>* Require current field ordering restrictions be maintained on things declared
>"struct", but removed restrictions on anything declared "class."

Let's see if I understand what you're proposing in the above two options.

I get the idea that what you want is to have the compiler be able to
assemble the fields in the classes in any order, rather than strictly
in the order in which they were defined.  Which *would* allow you to
pack bit fields together in the way you want, however....

I would argue against both of the above as a 'default' for the following
reasons:

	A) You would not be guaranteed that a data file written by a given
	program on one machine, would be readable by the same program compiled
	on a different machine under a different implementation of C++.
	(Assuming that hardware and byte ordering are the same, the order
	of structure/class elements wouldn't necessarily be the same.)

	B) Certain C++ languages (Lattice C++ for the Amiga for one) make
	extensive use of C++ structures/classes to hide the cruft of working
	with the system libraries.  Surely a desireable end.  However, the
	system libraries depend on a specific order of elements within a
	structure and would likely break under either of the above.

>* Introduce an explicit keyword "packed" or similar.  Declaring a base class
>"packed" turns off field ordering restrictions in that class and its 
>derivatives, as well as representing a directive to the compiler that small
>size is to be preferred to fast access.  Possibly vtable ptrs could also 
>be replaced with smaller type tags in such classes....

This would be more acceptable, as it leaves it as an option that the programmer
can use if appropriate, but doesn't force the issue.  However, it could still
have the problems shown above, and should therefore NOT be used where
portability is important.  If the structure/class is purely internal, never
appearing outside of the program in question, then it's acceptable.

At least not until the order and method of packing items is agreed upon
by the C++ industry, and preferably by the C compiler writers as well!

[disclaimer: this posting respresents the opinions of an individual C++ user]

In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>* Introduce an explicit keyword "packed" or similar.  Declaring a base class
>"packed" turns off field ordering restrictions in that class and its 
>derivatives, as well as representing a directive to the compiler that small
>size is to be preferred to fast access.  Possibly vtable ptrs could also 
>be replaced with smaller type tags in such classes....

Any derivative that uses a 'packed' class, but is not itself packed should
be flagged in the compiler with at least a warning message.  The user of the
base class might not realize that it was packed!  In fact, you might declare
such useage an error and REQUIRE the user to explicitly mark the new class
as packed.

[disclaimer: this posting respresents the opinions of an individual C++ user]

In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>Proposed:
>We need a way to "pack" objects over inheritence boundaries, and possibly
>between labeled fields of a declaration.
>...[excerpted]....

>* Require current field ordering restrictions be maintained on things declared
>  "struct", but removed restrictions on anything declared "class."

Personally, I like this option best.  On an entirely subjective level, it is
in keeping with the philosophy of C++ being "extended/better C", and it would
minimize confusion when switching often between writing C and C++.

[disclaimer: just another user's comments on the first user's suggestion.]
-- 
John T. Baldwin                      |  johnb@srchtec.uucp
Search Technology, Inc.              |  johnb%srchtec.uucp@mathcs.emory.edu
standard disclaimer:                 |  ...uunet!samsung!emory!stiatl!srchtec..
opinions and mistakes purely my own. |  ...mailrus!gatech!stiatl!srchtec...

In article <56159@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>Proposed:
>
>1) That null references explicitly be defined as legal in the language.  A 
>null reference is that which is created from a "dereferenced" null pointer
>such as follows:
>
>	FOO& fooref = *((FOO*)0);
>
>2) That "dereferencing" null pointers except in the initialization of references
>be explicitly defined as not legal in the language.  The exact effect
>of dereferencing a null pointer would be "implementation defined", but the
>intent is that no legal object can be referenced via a null pointer.
>
>[disclaimer: this posting represents the opinions of an individual C++ user]

Jim,

It appears that you are going to be making a lot of proposals.  That's fine,
but if you want them taken seriously, you should try to come up with
some very specific wording that could be incorporated directly into the
ANSI draft document.  Also, you should try to specify what section of E&S
we are talking about for this proposal and you should say where and how
your new proposed text should be fitted together with the existing wording
in that section.

For instance:

	8.4.3 References

		Strike the first sentence and replace it with:

		"A variable declared to be a T&, that is `reference
		to type T' (&8.2.2), must be initialized by a value of
		type T&.  For the initializer of a reference, a conversion
		of a type T value to a type T& value will be implicitly
		supplied by the compiler where needed."

		"If the initializer for a reference is an expression
		whose last operation is the dereferencing of a pointer
		valued subexpression via the unary `*' operator, then the
		evaluation of the initializer expression will not include
		the application of the final unary `*'.  Rather, in such
		cases, the reference will be initialized to refer to the
		same portion of memory as does the pointer-valued sub-
		expression.  (Note that the value of the pointer-valued
		subexpression may legally be NULL.)"

		"Similarly, if the initializer for a reference is an
		expression which (before implicit conversions are applied)
		itself has the same reference type, then the evaluation of the
		initializer expression will not include the application of
		normal implicit conversion of that reference type value to its
		corresponding (referent) object type value.  Rather, the
		reference value itself will initialize the reference
		object which is being initialized."

-- 
// Ron Guilmette
// C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.

In article <1990Jul31.161942.1938@eagle.lerc.nasa.gov> fsset@bach.UUCP (Scott E. Townsend) writes:
>In article <1913@ux.acs.umn.edu> hopper@ux.acs.umn.edu (Nils  McCarthy) writes:
>>In article <56163@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>>>Proposed:
>>>
>>>That when a parameter [including the hidden "this" parameter] is declared 
>>>"const", or when the object referenced by a parameter is declared "const",
>>>than it is not legal to modify that which is declared "const" within the 
>>>function. This is to say, the trick of casting to a non-const does not 
>>>work on a parameter declared as "const."  Compilers can flag as an error 
>>>these situations.
>>>
              .
              .
              .
>>	In C, and C++ a cast is supposed to always work, no matter what
>>object you're casting. I think that it should be legal for compilers to
>
>I disagree with the statement "In C ... a cast is always supposed to work.."
>In fact, it does not always work, although you are always allowed to try
>without the compiler getting too upset.  For instance, casting a pointer

	Small terminology mistake. I meant that it was always supposed to
compile, NOT always supposed to work.

Sorry 'bout that,
UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper   (Eric Hopper)
     __                    /)                       /**********************/
    / ')                  //                         * I went insane to   *
   /  / ______  ____  o  //  __.  __  o ____. . _    * preserve my sanity *
  (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_  * for later.         *
Internet:              />                            * -- Ford Prefect    *
hopper@ux.acs.umn.edu </  #include <disclaimer.h>   /**********************/

In article <56163@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>Proposed:
>
>That when a parameter [including the hidden "this" parameter] is declared 
>"const", or when the object referenced by a parameter is declared "const",
>then it is not legal to modify that which is declared "const" within the 
>function.

Your wording is fuzzy, but I get the idea.

Note that for:

	extern void foobar (const int i);

It can't make any difference to an optimizing compiler whether or not the
const is in there or not, or whether or not foobar() enforces it strictly.
However in the case of:

	extern void foobar (const int* i);

it certainly can make a difference.


>This is to say, the trick of casting to a non-const does not 
>work on a parameter declared as "const."  Compilers can flag as an error 
>these situations.

Why so fascist?  I prefer warnings in such cases.

I can even give you an example where "casting aside const'ness" was
indispensible to me on one occasion.

Imagine that you have a big program that every so often creates "nodes"
(actually structs or classes) of some type.  Each time one of these
puppies gets created, it gets linked into some larger data-structure
consisting of a large set of these things.  (Let's just call it a network
of "nodes".)  Now once these guys are created, they remain essentially
constant.  So right after they get created and initialized, we totally
wipe out any remnant of the original pointers to these guys and from
then on use `const*' pointers instead.  We pass these around, from routine
to routine, throughout this big program, all over the place.

Now although 99% of the program is perfectly happy to have the *entire*
structures be constant (because no fields are ever modified after
initialization) there is one tiny exception.  Eventually, we want to
print out a list of the contents of each of these "nodes", but we want
to make sure that we never print any node more than once.  Since the
overall data-structure is a network, we (unfortunately) have no easy
way to traverse the complete data structure such that we can be assured
of only visiting each node one (and only one) time.

Whatdaya do?  Simple.  Add a boolean field to each node called "printed".
This gets initialized to false, but whild we are in the printing stage,
these fields (in each record) will be set, one-by-one to true.  If,
during our printing traversal through the data structure, we see a node that
has already been "checked off" (i.e. printed == TRUE), we avoid printing
that node (redundantly) again.

My code (in C) looked kinda like:

	struct node {
		const struct node *related1;
		const struct node *related2;
		int printed;
	};

	void print_traversal (const struct node *arg)
	{
		if ( ! arg->printed)
		  {
		    print (arg);
		    /* Cast aside const'ness */
		  }
		print_traversal (arg->related1);
		print_traversal (arg->related2);
	}

>The reason I propose this restriction on the casting trick is to allow 
>compilers to correctly optimize code when presented with independently
>compiled libraries.  To be able to correctly optimize, compilers need to
>be able to assume that "const means const" in those libraries.

This is already allowed.  Read your ANSI C standard.  If one uses dirty
tricks (like casting away const'ness) the standard sez that your
compiler has the right to screw you unless you are very careful.

Of course, the standard doesn't use the term "screw you".  It prefers
"behavior undefined".


-- 
// Ron Guilmette
// C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.

In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>Proposed:
>
>We need a way to "pack" objects over inheritence boundaries, and possibly
>between labeled fields of a declaration.  I do not propose here exactly
>what the "right" way to do this is.
>
>I claim this is important because I see lots of examples of serious C++
>programmers implementing "hacks" to "pack" objects across inheritence
>boundaries.  Examples include:  Base class B needs two bits, and derived
>class D needs three bits, so let's implement a bit sharing hack between 
>base and derived...

It's an obvious and serious problem. Yes.

>... Features commonly used should be
>part of the language, not implemented via "hack" word-arounds.

Quite so.

>Possible full or partial "solutions" to this problem include:
>
>* Throw out the current C++ restrictions on field ordering entirely.  What
>does it buy us anyway?

If you mean the rule that says that all protected members get clumped together
(despite my best efforts and intentions, and no matter what I would prefer)
then yes.  This restrictive and irritating rule should be thrown out.

What ever happened to the philosophy that says that the programmer knows
what he want's, so (unless it obviously stupid *and* dangerous) let him
do what he wants?

>Use 'extern "C"' where an object needs backwards
>compatibility to "C" packing order.

Huh?

>* Require current field ordering restrictions be maintained on things declared
>"struct", but removed restrictions on anything declared "class."

Bad idea.

>* Introduce an explicit keyword "packed" or similar.  Declaring a base class
>"packed" turns off field ordering restrictions in that class and its 
>derivatives, as well as representing a directive to the compiler that small
>size is to be preferred to fast access.  Possibly vtable ptrs could also 
>be replaced with smaller type tags in such classes....

Since the issue involves the boundary between a derived class and exactly
one of its base classes, I suggest that perhaps "packed" should be a way
of doing inheritance, e.g.:

	class doe : public rea, packed public me { ... };

would specify that the earliest field of `doe' should get packed up against
the latest field of `me'.


-- 
// Ron Guilmette
// C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.

In article <6785@netxcom.DHL.COM> ewiles@netxcom.DHL.COM (Edwin Wiles) writes:

	   A) You would not be guaranteed that a data file written by a given
	   program on one machine, would be readable by the same program compiled
	   on a different machine under a different implementation of C++.
	   (Assuming that hardware and byte ordering are the same, the order
	   of structure/class elements wouldn't necessarily be the same.)

The ability for a compiler to re-order the elements of structures/unions is a
useful optimization.  I would argue that any code which writes structures to
a data file is non-portable.  If data is to be portable it should *always* be
written element by element, preferably in ASCII.  The programmer should never
assume specific structure ordering, except in the case of bit field
specifications, which can override the compiler's defaults.

This is the sort of hackery which causes many C programs to fail!
--
--
Jeremy Webber			   ACSnet: jeremy@chook.ua.oz
Digital Arts Film and Television,  Internet: jeremy@chook.ua.oz.au
60 Hutt St, Adelaide 5001,	   Voicenet: +61 8 223 2430
Australia			   Papernet: +61 8 272 2774 (FAX)

In article <6786@netxcom.DHL.COM> ewiles@netxcom.DHL.COM (Edwin Wiles) writes:
> In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
> >* Introduce an explicit keyword "packed" or similar.  Declaring a base class
> >"packed" turns off field ordering restrictions in that class and its 
> >derivatives, as well as representing a directive to the compiler that small
> >size is to be preferred to fast access.  Possibly vtable ptrs could also 
> >be replaced with smaller type tags in such classes....
> 
> Any derivative that uses a 'packed' class, but is not itself packed should
> be flagged in the compiler with at least a warning message.  The user of the
> base class might not realize that it was packed!  In fact, you might declare
> such useage an error and REQUIRE the user to explicitly mark the new class
> as packed.
> 
> [disclaimer: this posting respresents the opinions of an individual C++ user]

Nope.  The derivative class would tack all of its fields onto the end
rather than mixing them in.  You would end up with a structure that is
initially packed with unpacked stuff at the end.  This should be quite
allowable.

Where you will get into trouble is if you try to derive a packed class
from an unpacked class.  This should definitely be an error.  This is
cuz you don't want the subclass to try packing itself into the parent
class.

---

That was an argument from a purely theoretical standpoint.  I think
packed classes are dumb.  You should be able to guarantee the ordering
somewhat.  You would have some really nasty rules to define for things
like structures within the class, bit fields that are to be packed as
a unit rather than mixed in, etc.

The original poster said that these would be good for avoiding things
like defining funny bit fields that are shared by subclasses and such.
I would state that a correct implementation of a shared bit field
array can be accomplished quite nicely and straightforward through a
combination of inline methods for accessing the bit fields.  The only
problem you may hit is if you need to add a bit field to a superclass
when some subclasses have already used some (i.e. class a uses bits 0
to 2 and subclass b uses 3 and 4; it might not be trivial to reserve
an additional bit for a).  I think even this can be overcome through
the correct use of inline functions and a proper protocol for
declaring how many bits a particular class uses.

[ I can supply a rough sketch of the code necessary if somebody needs
  it -- I'm just too lazy to do it and I don't know C++ off the top of
  my head... ]

--
Greg Stein	-- This posting bears no relation to my employer
Arpa: gstein%oracle.uucp@apple.com
UUCP: ..!{uunet,apple}!oracle!gstein

>>>>> On 31 Jul 90 23:13:11 GMT, jeremy@cs.ua.oz.au (Jeremy Webber) said:
Jeremy> The ability for a compiler to re-order the elements of
Jeremy> structures/unions is a useful optimization.  I would argue that any
Jeremy> code which writes structures to a data file is non-portable.

True.  Even if the ordering is identical, the alignment may vary.  However,
alignment is not _likely_ to vary between systems using the same CPU,
although it still _can_ vary due to compiler differences.

Jeremy> If data is to be portable it should *always* be written element by
Jeremy> element, preferably in ASCII.

If your program isn't already I/O bound, this is an excellent strategy, and
I highly recommend it as the default strategy.

Jeremy> The programmer should never assume specific structure ordering,
Jeremy> except in the case of bit field specifications, which can override
Jeremy> the compiler's defaults.

Even this can fail, unless all the world is a 32 bit int.  Seriously, many
programs have to bang hardware which may not pack data in the "optimized"
form.  Perhaps this (and portability between compilers) is partly why order
of inheiritance became defined under C++ 2.0.

I also suspect reordering members between parents in a derived class such
that their elements are interleaved, would present a run time nightmare for
the C++ implementor.  Perhaps one of the implementors out there would care
to comment.

Jeremy> This is the sort of hackery which causes many C programs to fail!

...and many operating systems to work.

#pragma STD_DISCLAIMER
--
Chuck Phillips  MS440
NCR Microelectronics 			Chuck.Phillips%FtCollins.NCR.com
Ft. Collins, CO.  80525   		uunet!ncrlnk!ncr-mpd!bach!chuckp

In article <RLS.90Jul31125458@onondaga.steinmetz.ge.com> rls@onondaga.steinmetz.ge.com (Rod Sprattling) writes:
>
>One use for dereferencing null pointers leaps to mind.  Consider this
>definition, used in Intrinsics-based widgets in the X Window System:
>
>#define XtOffset(type,field) \	 ...

The correct way to deal with this is with ANSI C's `offsetof' macro,
which can do whatever magic is necessary in a particular implementation.

That is, there is no need to invent a solution -- e.g. allowing null
dereferencing -- for this problem, it has already been solved.
-- 
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry

In article <6785@netxcom.DHL.COM> ewiles@netxcom.DHL.COM (Edwin Wiles) writes:
>	A) You would not be guaranteed that a data file written by a given
>	program on one machine, would be readable by the same program compiled
>	on a different machine under a different implementation of C++.

This is already the case, and is not likely to change.  The internal format
of structs/classes typically contains machine-specific padding, which isn't
always the same even between machines using the same processor (680x0 systems
differ!), never mind seriously-different machines.  There are also the small
issues of byte ordering, floating-point representation, ones-complement
integers, etc.  The "guarantee" that you are claiming has never existed.

>	B) Certain C++ languages (Lattice C++ for the Amiga for one) make
>	extensive use of C++ structures/classes to hide the cruft of working
>	with the system libraries.  Surely a desireable end.  However, the
>	system libraries depend on a specific order of elements within a
>	structure and would likely break under either of the above.

This just means that there have to be enough guarantees on behavior that
the library code can assume a stable base.  This is much the same as what
would be needed to make inheritance work anyway, so I don't see a problem
there in general.
-- 
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry

In article <1913@ux.acs.umn.edu> hopper@ux.acs.umn.edu (Nils  McCarthy) writes:
>In article <56163@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>>Proposed:
>>
>>That when a parameter [including the hidden "this" parameter] is declared 
>>"const", or when the object referenced by a parameter is declared "const",
>>than it is not legal to modify that which is declared "const" within the 
>>function.  [...]

>	I don't agree with the illegalization of this construct. I think it
>is against the spirit of the language to illegalize a cast.
>
>	In C, and C++ a cast is supposed to always work, no matter what
>object you're casting. 

This is not true of C or C++.  Examining Section 5.4 of E&S reveals 
the following:
	
	"Any type conversion not mentioned below and not explicitly 
	defined by the user (Section 12.3) is an error.

	Any type that can be converted to another by a standard 
	conversion (Section 4) can also be converted by explicit
	conversion and the meaning is the same."

	Pointer to integer casts are valid, subject to restrictions.

	Integer to pointer casts are valid, subject to restrictions.

	Pointer to pointer casts are valid, subject to rectrictions.

	Object to reference casts are valid, subject to restrictions.


That's it.  In particular, for example, casts of floats to pointers or
of one object of user-defined type to one of another UDT in the absence
of appropriate user-defined conversions is an error.


	Bob Atkinson
	Microsoft

In article <1913@ux.acs.umn.edu> hopper@ux.acs.umn.edu (hopper) writes:
>In article <56163@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>>Proposed:
>>
>>That when a parameter [including the hidden "this" parameter] is declared 
>>"const", or when the object referenced by a parameter is declared "const",
>>than it is not legal to modify that which is declared "const" within the 
>>function. This is to say, the trick of casting to a non-const does not 
>>work on a parameter declared as "const."  Compilers can flag as an error 
>>these situations.
>>
>	I don't agree with the illegalization of this construct. I think it
>is against the spirit of the language to illegalize a cast.

Until recently (after C++ invented it), C did not have "const".  Therein
lies some confusion.  I submit that it is absurd to put const in the same
category with other type names.  Const is not a typename, it is a storage
qualifier, like "auto" and "static".  You can't typecast from auto to
static, and I agree with Jim that you shouldn't be able to cast from const
to non-const.
--
--------------------------------------------------------------------------
Glenn P. Parker        Bitstream, Inc.
uunet!huxley!glenn     215 First Street
glenn@bitstream.com    Cambridge, MA 02142-1270

The only arguments I have heard against arbitrary reordering of structures are
that it is incompatible with C, and that it makes writing structures to files
less portable.

Being incompatible with C is not something I consider a valid reason for not
doing something.  That's why we have `extern "C"'.  A structure declared within
`extern "C"' would, of course, obey C's conventions and not get reordered.

Writing structures to files as they appear in memory is not portable anyway.
Even given the same machine (and thus the same sizes for the basic types and
the same byte and word orders), different compilers (or even different compiler
options) may use different padding in structures.

Are there any other arguments against allowing arbitrary reordering of
structures?
--
	Roland McGrath
	Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland

In article <MCGRATH.90Aug1122802@helen.Berkeley.EDU> mcgrath@helen.Berkeley.EDU (Roland McGrath) writes:
>Are there any other arguments against allowing arbitrary reordering of
>structures?

Yes, I want to have a data structure with several different kinds of
nodes.  Each node contains common data that may be manipulated by
general purpose routines that do not need understand the rest of the
data in each node.  I want to be sure that the layout of each node
begins the same way.  I don't want to use a union since the nodes range 
in size from a few bytes to hundreds of bytes (the larger nodes being rare).

-- 
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232
unmvax.cs.unm.edu!bbx!bbxsda!scott

In article <GLENN.90Aug1145326@huxley.bitstream.com>,
glenn@bitstream.com (Glenn P. Parker) writes:
|> Until recently (after C++ invented it), C did not have "const".  Therein
|> lies some confusion.  I submit that it is absurd to put const in the same
|> category with other type names.  Const is not a typename, it is a storage
|> qualifier, like "auto" and "static".  You can't typecast from auto to
|> static, and I agree with Jim that you shouldn't be able to cast from const
|> to non-const.

The overloading system in C++ treats const as part of the type; there may be

int foo(char*);
int foo(const char*);

and these may be two different functions.  const is part of the type; it's
different from static and auto.

I've had to write casts from const to non-const because the following situation
sometimes arises:

a) The writer of some library function declares an argument to be type char*,
   although the string is not changed by the function;

b)  I want to pass a const char* to it.  I wouldn't want to see this forbidden.

I do think it's reasonable to give writers of optimizing compilers carte
blanche
to assume that a function that takes a pointer to const cannot under any
circumstances change the object.  If you cheat and do it anyway by casting
or other tricks, the compiler is free to break your code; you deserve to lose.

Historically (from C) a cast says "trust me, I know what I'm doing".  The same
should apply in C++.  The programmer should be allowed to write any type of
cast, and the resulting program may be non-portable if he does.


--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck	

In an article jeremy@cs.ua.oz.au (Jeremy Webber) writes:
>In an article ewiles@netxcom.DHL.COM (Edwin Wiles) writes:
>>
>> A) You would not be guaranteed that a data file written by a given
>> program on one machine, would be readable by the same program compiled
>> on a different machine under a different implementation of C++.
>> (Assuming that hardware and byte ordering are the same, the order
>> of structure/class elements wouldn't necessarily be the same.)
>
>The ability for a compiler to re-order the elements of structures/unions is a
>useful optimization.

Granted, it has it's uses.  So I'm in favor of having a "packed" keyword
which instructs the compiler to rearrainge the structures as appropriate,
but against making such rearraingment the default.

>I would argue that any code which writes structures to a data file is
>non-portable.  If data is to be portable it should *always* be written
>element by element, preferably in ASCII.

I work in the real world (presumably you do too), and in the real world you
don't always have enough file space to store data in 'ascii' format.  (And you
can't always "throw hardware at the problem" either!)  Nor do you have the time
that is required to write and debug thirty or more 'read/write' statements for
every one of your data structures.  THAT is wasted effort.  Far quicker and
simpler to write the data structure itself out.

Unfortunately, although I use C++ on my home computer, I haven't been able to
convince work to switch over, and even when I do, they will NOT allocate the
time required to rewrite all the old code.  This means that when/if we switch
to C++ for our new code, the data it writes MUST be compatible with the
existing code, who's data files ARE portable to a number of machines, and which
DOES use structures for reading and writting data.

>The programmer should never
>assume specific structure ordering, except in the case of bit field
>specifications, which can override the compiler's defaults.

Now that is just sooo much malarky.

No C compiler that I know of rearranges the order of elements in a structure.
Some of them adjust to 2 byte boundaries, and some to 4, due to hardware
considerations, but NONE of them change the order of the data as specified by
the source.

>This is the sort of hackery which causes many C programs to fail!

Never done it to me!  If it has to you, then I suggest that there are
compiler writers out there who are puting in "features" which are most
definitely non-standard.  Any non-standard feature should NOT be the
default but should instead be used only by the express wish of the user.

					Later!
						Edwin.

In article <GLENN.90Aug1145326@huxley.bitstream.com> <glenn@bitstream.com> (Glenn Parker) writes:
>Const is not a typename, it is a storage qualifier, like "auto" and "static".

"int" is an atomic type.  "auto" is a storage class.  "const" is a type
qualifier.  The three are distinct concepts.

>I agree with Jim that you shouldn't be able to cast from const to non-const.

Seems to me that the ANSI C rules have it right: you can cast from const to
non-const if you have to, but you can't use the non-const pointer to modify an
object that's ultimately const.  The compiler could legally put a const object
into nonwritable store.

Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint

In article <MCGRATH.90Aug1122802@helen.Berkeley.EDU>
mcgrath@helen.Berkeley.EDU (Roland McGrath) writes:

| The only arguments I have heard against arbitrary reordering of structures are
| that it is incompatible with C, and that it makes writing structures to files
| less portable.
| 
| Being incompatible with C is not something I consider a valid reason for not
| doing something.  That's why we have `extern "C"'.  A structure declared within
| `extern "C"' would, of course, obey C's conventions and not get reordered.
| 
| Writing structures to files as they appear in memory is not portable anyway.
| Even given the same machine (and thus the same sizes for the basic types and
| the same byte and word orders), different compilers (or even different compiler
| options) may use different padding in structures.
| 
| Are there any other arguments against allowing arbitrary reordering of
| structures?

Hmm, don't you care about compatibility with things like system calls?
I imagine the grief people would get if the stat structure got
rearranged because some OS jock added a byte field at the end of the
structure?  Yes, extern "C" can be used, but it just means that there
are even more things to worry about getting right.

Also, it would seem to me that reordering things across class
boundaries is a really bad idea -- then subclassing and virtual
functions would have no chance of working.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Do apple growers tell their kids money doesn't grow on bushes?

In article <6815@netxcom.DHL.COM> elw@netxcom.DHL.COM (Edwin Wiles) writes:

   >I would argue that any code which writes structures to a data file is
   >non-portable.  If data is to be portable it should *always* be written
   >element by element, preferably in ASCII.

   I work in the real world (presumably you do too), and in the real world you
   don't always have enough file space to store data in 'ascii' format.  (And
   you can't always "throw hardware at the problem" either!)  Nor do you have
   the time that is required to write and debug thirty or more 'read/write'
   statements for every one of your data structures.  THAT is wasted effort.
   Far quicker and simpler to write the data structure itself out.

Fine.  Do it.  Just don't expect the data files to be portable.  That's all.

   Unfortunately, although I use C++ on my home computer, I haven't been able
   to convince work to switch over, and even when I do, they will NOT allocate
   the time required to rewrite all the old code.  This means that when/if we
   switch to C++ for our new code, the data it writes MUST be compatible with
   the existing code, who's data files ARE portable to a number of machines,
   and which DOES use structures for reading and writting data.

As I said, this is why we have `extern "C"'.  If certain structures need to be
done compatibly, declare them inside `extern "C"', and they will be done just
as the C compiler does them (not that this gives you any measure of portability
across different machines, operating systems, compilers, or compilation-time
command-line flags).

   >The programmer should never
   >assume specific structure ordering, except in the case of bit field
   >specifications, which can override the compiler's defaults.

   Now that is just sooo much malarky.

   No C compiler that I know of rearranges the order of elements in a
   structure.  Some of them adjust to 2 byte boundaries, and some to 4, due to
   hardware considerations, but NONE of them change the order of the data as
   specified by the source.

Well, good!  Then when you make your strucutre declarations inside `extern "C"'
you won't have any problems.  Outside of `extern "C"', we're talking about a
different language, however.

   >This is the sort of hackery which causes many C programs to fail!

   Never done it to me!  If it has to you, then I suggest that there are
   compiler writers out there who are puting in "features" which are most
   definitely non-standard.  Any non-standard feature should NOT be the
   default but should instead be used only by the express wish of the user.

Agreed.  However, we are talking about the standard for C++.  As this standard
remains to be defined, and is independent from the existing standard for C,
I don't see the relavence of your statement.
--
	Roland McGrath
	Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland

In article <MEISSNER.90Aug1191316@osf.osf.org> meissner@osf.org (Michael Meissner) writes:

   Hmm, don't you care about compatibility with things like system calls?
   I imagine the grief people would get if the stat structure got
   rearranged because some OS jock added a byte field at the end of the
   structure?  Yes, extern "C" can be used, but it just means that there
   are even more things to worry about getting right.

If you don't declare the `stat' function inside `extern "C"', it won't
necessarily work right anyway.  Using:

extern "C"
{
#include <sys/stat.h>
}

seems entirely reasonable to me.

   Also, it would seem to me that reordering things across class
   boundaries is a really bad idea -- then subclassing and virtual
   functions would have no chance of working.

If it is not feasible to reorder members across class boundaries and still do
subclassing and virtual functions right then noone will try to do it in their
implementation.  That doesn't mean the standard should prevent people from
trying if they want to.
--
	Roland McGrath
	Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland

In article <MEISSNER.90Aug1191316@osf.osf.org> meissner@osf.org (Michael Meissner) writes:
>Also, it would seem to me that reordering things across class
>boundaries is a really bad idea -- then subclassing and virtual
>functions would have no chance of working.

In article <MCGRATH.90Aug1231443@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes:
>If it is not feasible to reorder members across class boundaries and still do
>subclassing and virtual functions right then no one will try to do it in their
>implementation.  That doesn't mean the standard should prevent people from
>trying if they want to.

Reordering does not have to go so far as to change the offsets of inherited
members.  The rule could be that new members can be placed in holes left by
padding in the superclass or in unused portions of storage units that
contain inherited bitfields.  I think this would do all the packing that
Jim Adcock originally wanted, without affecting current implementations of
inheritance.
   Since nothing in C corresponds to class inheritance, I don't see that
this introduces any incompatibility, either.  If you declare a struct, it
would be laid out just like a C struct.

    Glen Ditchfield  gjditchfield@violet.uwaterloo.ca  Office: DC 2517
Dept. of Computer Science, U of Waterloo, Waterloo, Ontario, Canada, N2L 3G1
	      These opinions have not been tested on animals.

In article <GLENN.90Aug1145326@huxley.bitstream.com> <glenn@bitstream.com> (Glenn Parker) writes:
>Until recently (after C++ invented it), C did not have "const".  Therein
>lies some confusion.  I submit that it is absurd to put const in the same
>category with other type names.  Const is not a typename, it is a storage
>qualifier, like "auto" and "static"...

The real, underlying problem here is precisely whether const *is* a
storage qualifier or not, by intent.  Unfortunately, const gets used for
two very different purposes:  "this is really, truly, a constant" and
"I may be allowed to modify this but you aren't".  It might have been
better to use different words for these two uses.  It's a bit late now.
-- 
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry

In article <MEISSNER.90Aug1191316@osf.osf.org> meissner@osf.org (Michael Meissner) writes:
>I imagine the grief people would get if the stat structure got
>rearranged because some OS jock added a byte field at the end of the
>structure?  Yes, extern "C" can be used, but it just means that there
>are even more things to worry about getting right.

In the case of system calls, system header files are charged with getting
this right for you; there is no reason for you to be defining your own
version of the stat structure.  OS jocks *always* have to worry about
compatibility when they change interfaces.
-- 
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry

In article <MCGRATH.90Aug1225852@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes:
>... However, we are talking about the standard for C++.  As this standard
>remains to be defined, and is independent from the existing standard for C,
>I don't see the relavence of your statement.

It is currently a defined property of C++ (see E&S) that any program which
is both legal C and legal C++ means the same in both (with a couple of tiny
and hard-to-avoid exceptions).  Many people think that this limited upward
compatibility is a good idea and should not be sacrificed.  The name of
the language is "C++", not "D".

On a related point, people should bear in mind that the best language
standards are the ones that codify *existing practice*, as opposed to
throwing in every wild and wonderful feature that somebody thought was
a good idea.  X3J11 did, by and large, a very good job on this for C.
(If you want to see what happens when standards committees start trying
to invent the language, look at ANSI BASIC or FORTRAN 9x.)  If the C++
standards effort does its job properly, ranting on the net about the
vital need for your favorite feature will be entirely futile.  What
you need is an implementation of it and some favorable experience using
that implementation, followed by a formal proposal to the committee (no,
posting it to the net does not qualify).
-- 
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry

In article <GSTEIN.90Jul31194438@goober.oracle.com>, gstein@oracle.com
(Greg Stein) writes:
> Where you will get into trouble is if you try to derive a packed class
> from an unpacked class.  This should definitely be an error.  This is
> cuz you don't want the subclass to try packing itself into the parent
> class.

If a packed is derived from a non-packed, the packing should not intrude
into the non-packed base class.  This introduces no compilation problems.

This whole idea is nuts. It's clear that C++ really needs one more
feature that severely restricts the ability to do derivation.

Jon

In article <1990Aug2.142410.10541@watmath.waterloo.edu>,
gjditchfield@watmsg.uwaterloo.ca (Glen Ditchfield) writes:
|> Reordering does not have to go so far as to change the offsets of inherited
|> members.  The rule could be that new members can be placed in holes left by
|> padding in the superclass or in unused portions of storage units that
|> contain inherited bitfields.  I think this would do all the packing that
|> Jim Adcock originally wanted, without affecting current implementations of
|> inheritance.

Consider this example:

class Base {
	char c;
	int i;
}

Let's say there's a hole between c and i.

class Derived : public Base {
	char c2;
}

I take it you want to insert the c2 in the hole.

But does this mean that all methods of class Base have to make sure to preserve
the contents of holes, under all conditions, because the Base object may really
be a Derived object?  In this case that wouldn't be too hard, but what if c and
c2 were bitfields instead?  Think about compiler-generated assignment
operators.
Seems to me they'd get more complex.


--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck	

In article <1913@ux.acs.umn.edu> hopper@ux.acs.umn.edu (Nils  McCarthy) writes:
>
>	I don't agree with the illegalization of this construct. I think it
>is against the spirit of the language to illegalize a cast.
>
>	In C, and C++ a cast is supposed to always work, no matter what
>object you're casting. I think that it should be legal for compilers to
>preform optimizations based on the information given by declaring a const
>parameter, but programmers should be allowed to cast if they feel it
>neccesary.

Okay, lets enumerate some choices about how compilers can choose to handle 
this problem.  I'm assuming that the language definition needs to be such
that the traditional separately compiled modules, standard linkers with
"type safety" via name mangling is used.

1) Never optimize when calling functions with const parameters.  [Pessimistic
approach]

2) A function with a const parameter which is cast to a non-const is flagged
with a error when it is compiled.

3) A function with a const parameter which is cast to a non-const is flagged
with a warning when it is compiled.

4) A function with a const parameter which is cast to a non-const is not
flagged when it is compiled, just silently accepted, leading potentially to
optimization errors when it is used.

---

I'd reject option #1 because I believe C++ code needs to be highly optimized
in order to get C-like performance.

I'd reject option #4 since compilers can then generate bad [erroneous] code
without giving the user any hint that anything is going on.

Option #3 has the "advantage" of letting people write functions that will 
work in some calling sequences, and fail in other calling sequences.  These
failures would be hard to track down, and impossible to fix -- other than
turning optimization off.

So I'd prefer to just see option #2.  Option #3 [warning] would be acceptible
in compilers that don't do much optimizations.  A compiler with a flag to
turn optimization on and off could switch the level from warning to error --
but this is a poor "solution" given that the "const" function can be compiled
with the optimization flag off, and the calling function can be compiled with
optimization on.

[standard disclaimer]

In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>Proposed:
>
>We need a way to "pack" objects over inheritence boundaries, and possibly
>between labeled fields of a declaration.  I do not propose here exactly
>what the "right" way to do this is.

I should clarify that I was not proposing that every compiler actually has
to do the packing, nor that there need to be a standard way to do that 
packing.  What I was proposing is that we need a way to turn off the standard
C++ field ordering restrictions, such that a compiler can choose to lay out
those fields in any order it feels is appropriate.  Perhaps the easiest way 
to accomplish this is just throw away the traditional restrictions on field
ordering.

> ... we are talking about the standard for C++.  ... this standard remains
> to be defined, and is independent from the existing standard for C,

Well, not quite independent.  The goals statement adopted by X3J16 last
March includes a statement that looked a lot like this:

    The standard will be based on the C++ Reference Manual
    (X3J16/90-0020) and the C Programming Language Standard
    (ANS X3.159-1989).
    
    The ISO C Standard will become an additional base document
    when available.

    The C++ Reference Manual will take precedence when the
    base documents disagree, except where the committee decides
    otherwise.

(The C++ Reference Manual that this refers to is not Ellis & Stroustrup's
book, but rather Stroustrup's "UNIX System V AT&T C++ Language System
Release 2.1 Product Reference Manual, Select Code 307-159".  It is
nearly identical to E&S minus the annotations.)

It seems clear to me that the intent is to make ANSI C++ "As Close As
Possible to ANSI C, but No Closer".  Remember, X3J16's job is not to
design a new language.
-- 
    Speaking neither for Sun nor for X3J16...
Doug Landauer - Sun Microsystems, Inc. - Languages - landauer@eng.sun.com
    Matt Groening on C++:  "Our language is one great salad."

In article <1990Aug1.171148.22119@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>>	B) Certain C++ languages (Lattice C++ for the Amiga for one) make
>>	extensive use of C++ structures/classes to hide the cruft of working
>>	with the system libraries.  Surely a desireable end.  However, the
>>	system libraries depend on a specific order of elements within a
>>	structure and would likely break under either of the above.
>
>This just means that there have to be enough guarantees on behavior that
>the library code can assume a stable base.  This is much the same as what
>would be needed to make inheritance work anyway, so I don't see a problem
>there in general.

	One of the nicer things in C, (and C++) is to be able to create
machine specific data sructures that correspond to some area in memory.
(i.e. bit-fields and such). I agree that writing machine specific code is
generally undesirable, sometimes it is necessary.

	Currently the methods of structure member ordering, and packing
specifications are easy enough to figure out that you can easily write a
structure that models some hardware/OS data structure rather well. If
packing of bit-fields, and structure members became a standard, unavoidable
thing, this would no longer be easy to do. In other words, you would no
longer be able to write an OS in C++.

Have fun,
UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper   (Eric Hopper)
     __                    /)                       /**********************/
    / ')                  //                         * I went insane to   *
   /  / ______  ____  o  //  __.  __  o ____. . _    * preserve my sanity *
  (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_  * for later.         *
Internet:              />                            * -- Ford Prefect    *
hopper@ux.acs.umn.edu </  #include <disclaimer.h>   /**********************/

In article <1944@ux.acs.umn.edu> hopper@ux.acs.umn.edu (hopper) writes:
	   One of the nicer things in C, (and C++) is to be able to create
   machine specific data sructures that correspond to some area in memory.
   (i.e. bit-fields and such). I agree that writing machine specific code is
   generally undesirable, sometimes it is necessary.

	   Currently the methods of structure member ordering, and packing
   specifications are easy enough to figure out that you can easily write a
   structure that models some hardware/OS data structure rather well. If
   packing of bit-fields, and structure members became a standard, unavoidable
   thing, this would no longer be easy to do. In other words, you would no
   longer be able to write an OS in C++.

We are talking here about Standard C++.  In Standard C, you can't necessarily
have a `struct' that corresponds to a hardware layout, because there may be
padding (and the standard leaves it completely up to the implementation, except
that there can be no padding before the first member).

If you want to have a `struct' that corresponds to some hardware thing or
whatever, and you know enough about the C compiler's padding conventions to do
this, then write it inside `extern "C"' in C++.  This still doesn't guarantee
you a damn thing as far as the standards are concerned.

"We can't allow A in the standard because it makes it more difficult to do
nonstandard, unportable hack B (which is not guaranteed by the standard to
work, but which probably will most days of the week)" does not sound to me like
a reasonable argument.

You must remember that we are talking about the standard for C++.  I propose
simply that the standard make no restrictions about structure member order
(outside of `extern "C"', since inside `extern "C"' the restrictions of
standard C apply).  That member reordering makes various implementation details
difficult (like that base classes must deal with derived classes' members
possibly being in between the base class's members) is none of the standard's
bloody business.  It's an implementation problem.  If all these problems are as
insurmountable as you seem to think, then no implementor will overcome them,
and no implementation will reorder structure members.  I don't know how to
implement reordering correctly either, but I'm more than willing to concede
that some C++ implementor out there is more clever than I, and see no reason to
prohibit someone else from doing something I can't figure out how to do.
--
	Roland McGrath
	Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland

I'm not suggesting codifying practice that does not yet exist.

I'm merely suggesting not prohibiting it.
--
	Roland McGrath
	Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland

In article <1990Aug2.165111.25529@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
   It is currently a defined property of C++ (see E&S) that any program which
   is both legal C and legal C++ means the same in both (with a couple of tiny
   and hard-to-avoid exceptions).  Many people think that this limited upward
   compatibility is a good idea and should not be sacrificed.  The name of
   the language is "C++", not "D".

I don't see how this would not remain true if member reordering were allowed.
The C compiler will generate accesses to the structure in the given order
throughout the program, so all the accesses will work.  The C++ compiler will
generate accesses to the structure in whatever order it deems appropriate,
using this single order throughout the program, so all the accesses will work.

You can't expect to interlink different pieces of a program that is both legal
C and legal C++, some of which are compiled in C, some in C++, anyway.  If you
could, `extern "C"' would not have been invented.
--
	Roland McGrath
	Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland

How about when  a function takes two parameters, one const and the other
non-const. If
the caller passes the same object (by reference or through a pointer)
for each parameter
should it be smart enough to know that the const object may have
actually changed through 
the other parameter ? Or is it the responsibility of the programmer
writing the calling code
(in which case I would never use const for functions taking two or more
parameters of the same type).

I'm learning C++ and have been staying away from const parameters
because I wasn't
sure how a compiler would handle the above case.

Are there any rules that cover this case ?

Ashok Nadkarni

In article <MCGRATH.90Aug3011745@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes:
>   It is currently a defined property of C++ (see E&S) that any program which
>   is both legal C and legal C++ means the same in both...
>
>I don't see how this would not remain true if member reordering were allowed.

The problem is that in C, the ordering is a documented property of the
language *and programs are therefore allowed to depend on it*.  For
example, it is explicitly guaranteed that a pointer to a later member
compares high against a pointer to an earlier one, and there are probably
programs out there somewhere that need this.  Such a program will break,
despite being legal C, if compiled with a reordering C++ compiler.
-- 
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry

In article <6785@netxcom.DHL.COM> ewiles@netxcom.DHL.COM (Edwin Wiles) writes:
>In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>>* Throw out the current C++ restrictions on field ordering entirely.  What
>>does it buy us anyway?  Use 'extern "C"' where an object needs backwards
>>compatibility to "C" packing order.
>>* Require current field ordering restrictions be maintained on things declared
>>"struct", but removed restrictions on anything declared "class."
>
>Let's see if I understand what you're proposing in the above two options.
>
>I get the idea that what you want is to have the compiler be able to
>assemble the fields in the classes in any order, rather than strictly
>in the order in which they were defined.  Which *would* allow you to
>pack bit fields together in the way you want, however....

Compilers already do not have to assemble the fields in the order they are 
defined.  The basic present restriction is that within a labeled region
[labeled by private: public: protected:] fields are to be placed at increasing
addresses.  The order in which various labeled regions are placed is compiler
dependent.  The spacing between those fields is compiler dependent -- one
compiler might pack shorts on 2-byte boundaries, another might pack shorts
on 4-byte boundaries -- representing two different compiler's choices of 
how they feel the tradeoff between speed and space should be handled.
Also, where hidden fields [vtable pointers, virtual base pointers] are
packed is also compiler dependent.

Other issues in getting C++ compilers to be compatible are name mangling
conventions, global ::new conventions, vtable agreements, calling conventions,
optimization conventions,....

...So I believe C++ compiler compatibility is outside the scope of the language.
If a group of compilers are going to be compatible, their people are going
to have to form some kind of consortium, and agree on hundreds of little
nagging details. 

>I would argue against both of the above as a 'default' for the following
>reasons:
>
>	A) You would not be guaranteed that a data file written by a given
>	program on one machine, would be readable by the same program compiled
>	on a different machine under a different implementation of C++.
>	(Assuming that hardware and byte ordering are the same, the order
>	of structure/class elements wouldn't necessarily be the same.)

This will not work today anyway -- for the reasons listed above.

>	B) Certain C++ languages (Lattice C++ for the Amiga for one) make
>	extensive use of C++ structures/classes to hide the cruft of working
>	with the system libraries.  Surely a desireable end.  However, the
>	system libraries depend on a specific order of elements within a
>	structure and would likely break under either of the above.

Yes, I agree there is a need to have a way to maintain backwards compatibility
with prior "C" libraries -- and their associated data structures.  This is 
easily accomplished if a C++ compiler honors the 'extern "C"' to mean
that C naming conventions are to be used, that C calling conventions are
to be used, and that C packing conventions are to be used.  Likewise
'extern "Pascal"' can be used where Pascal naming conventions are to be
used, Pascal calling conventions, and Pascal packing conventions.

>>* Introduce an explicit keyword "packed" or similar.  Declaring a base class
>>"packed" turns off field ordering restrictions in that class and its 
>>derivatives, as well as representing a directive to the compiler that small
>>size is to be preferred to fast access.  Possibly vtable ptrs could also 
>>be replaced with smaller type tags in such classes....
>
>This would be more acceptable, as it leaves it as an option that the programmer
>can use if appropriate, but doesn't force the issue.  However, it could still
>have the problems shown above, and should therefore NOT be used where
>portability is important.  If the structure/class is purely internal, never
>appearing outside of the program in question, then it's acceptable.

This is an argument relative to maintaining historical standards verses
introducing innovative new techniques.  Compilers can choose to be innovative,
or they can choose to be conservative and maintain old packing standards.
The marketplace can decide what compiler they like best.  Or these choices
can be handled via options.  Likewise, many C++ compilers do not follow
"C" calling conventions, but rather use Pascal calling conventions, or register
passing conventions.  The language does not dictate that C calling conventions
continue to be used. Why should the language dictate even the minimal amount
of packing order restrictions presently in place?  What legal things can a 
programmer do to make use of the present packing order restrictions?  Present
packing order restrictions do almost nothing towards helping to C++ compilers
be compatible.  Nor do they help programmers.  Lets get rid of the packing
order restrictions.

In article <MCGRATH.90Aug3011039@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes:
>In article <1944@ux.acs.umn.edu> hopper@ux.acs.umn.edu (hopper) writes:
>	   One of the nicer things in C, (and C++) is to be able to create
>   machine specific data sructures that correspond to some area in memory.
>   (i.e. bit-fields and such). I agree that writing machine specific code is
>   generally undesirable, sometimes it is necessary.
                     .
                     .
                     .
>   thing, this would no longer be easy to do. In other words, you would no
>   longer be able to write an OS in C++.
>
>We are talking here about Standard C++.  In Standard C, you can't necessarily
>have a `struct' that corresponds to a hardware layout, because there may be
>padding (and the standard leaves it completely up to the implementation, except
>that there can be no padding before the first member).
>
>If you want to have a `struct' that corresponds to some hardware thing or
>whatever, and you know enough about the C compiler's padding conventions to do
>this, then write it inside `extern "C"' in C++.  This still doesn't guarantee
>you a damn thing as far as the standards are concerned.
>
>"We can't allow A in the standard because it makes it more difficult to do
>nonstandard, unportable hack B (which is not guaranteed by the standard to
>work, but which probably will most days of the week)" does not sound to me like
>a reasonable argument.

	I think you've missed my point. One of the nicer things about C, and
C++ is the ability to write anything you darn well please, whether it
accesses memory mapped I/O directly, models a complicated hardware
structure, or what have you. If you suddenly make the ordering of you
structures & classes hard to figure out, such things will no longer be very
easy.

	I like the idea of a compiler being able to re-order my data
structures to make them more efficient, but having it do this all the time
could get to be VERY annoying if I'm trying to do something with the things
mentioned above. I want C++ to remain a language that one can write an OS
in.

Have fun,
UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper   (Eric Hopper)
     __                    /)                       /**********************/
    / ')                  //                         * I went insane to   *
   /  / ______  ____  o  //  __.  __  o ____. . _    * preserve my sanity *
  (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_  * for later.         *
Internet:              />                            * -- Ford Prefect    *
hopper@ux.acs.umn.edu </  #include <disclaimer.h>   /**********************/

In article <56268@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>>Proposed:
>>
>>We need a way to "pack" objects over inheritence boundaries, and possibly
>>between labeled fields of a declaration.  I do not propose here exactly
>>what the "right" way to do this is.
>
>I should clarify that I was not proposing that every compiler actually has
>to do the packing, nor that there need to be a standard way to do that 
>packing.  What I was proposing is that we need a way to turn off the standard
>C++ field ordering restrictions, such that a compiler can choose to lay out
>those fields in any order it feels is appropriate.  Perhaps the easiest way 
>to accomplish this is just throw away the traditional restrictions on field
>ordering.

There already exists a defined way within the language to "turn off the
standard C++ field ordering restrictions".

Section 9.2 (page 173, middle of the page) in E&S says:

	"The order of allocation of nonstatic data members {which are}
	separated by an access specifier is implementation dependent (11.1)".

Therefore, the members of the following type, may legally be laid out in
*any* arbitrary ordering by a "standard conforming" compiler.

	struct S {
		int f1:22;
	public:
		int f2:10;
	public:
		int f3:3;
	public:
		int f4:5;
	public:
		char f5;
	public:
		short f6;
	};

I personally find the rule cited above intensely offensive because it gives
the compiler licence to thwart the will of the programmer (who is supposed
to be in control after all).  I don't like that one little bit!

(I tried to point out this problem here once before, but either nobody was
listening or else nobody was cared).

I am *not* in the camp that believes that the compiler should be given even
more leway to mess around with my intentions, and to change my intended
meaning.  Quite the opposite.

I'm a big boy now.  I can establish a good and proper ordering for the data
members within my structs and classes all by myself, and without any help
from the compiler, thank you.  In fact I would *prefer* to do it myself,
because I believe that it is far more likely that I will understand where
things out to go (or must go) than the compiler will.

Consider the following:

	class C {
		unsigned private_member_1:22;
	public:
		unsigned public_member_2:10;
	private:
		unsigned private_member_3:7;
	public:
		unsigned public_member_4:25;

		C ();
		// ... other member functions
	};

Now I wrote the fields in the order shown so that they would fit perfectly
into two words *only* as long as they are actually allocated in the order
shown.  Unfortunately, the rule cited above allows "standard conforming"
compilers to thwart my intentions and to reorder the fields in any damn
order they please.

The implication is that I simply cannot make use of access specifiers (and
the benefits they can provide) for any class or struct where field ordering
is critical (either for reasons of space economy or because I am dealing
with some hardware-defined layout, such as commonly arises in cases of
memory-mapped I/O devices with multiple control/data registers).

So what I'm trying to say is that we DO NEED to have some way of telling
compilers "pack the last field of the parent class into the same word
(if possible) as the first field of the derived class" but what we DON'T
NEED is the current rule that allows the compiler to rearrange fields
any way it pleases.

These issue are mostly separate, until you see that the achievment of
"good" packing between a base class and a derived class may depend upon
the ability of the programmer to force a particular (packable) field
to be allocated *last* within a struct or class.

Right now, if you want to (or need to) use access-specifiers within the
base class, it is IMPOSSIBLE select (or to force) the proper allocation.



-- 
// Ron Guilmette
// C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.

In article <1944@ux.acs.umn.edu> hopper@ux.acs.umn.edu (Eric Hopper) writes:
>	Currently the methods of structure member ordering, and packing
>specifications are easy enough to figure out that you can easily write a
>structure that models some hardware/OS data structure rather well.

Why not give names to the packing (arrangment, really ) strategies ?
The default strategy would be good for packing bit fields, being
clever about inheritance, etc., while others would have definite,
documented implications for the bitwise arrangement of members.
-- 
Robert P. Krajewski
Internet: rpk@ai.mit.edu ; Lotus: robert_krajewski.lotus@crd.dnet.lotus.com

In article <1990Aug2.164129.25231@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
> The real, underlying problem here is precisely whether const *is* a
> storage qualifier or not, by intent.  Unfortunately, const gets used
> for two very different purposes:  "this is really, truly, a
> constant" and "I may be allowed to modify this but you aren't".

For example, consider the strchr function (from ANSI C):

char* strchr( const char* s, int c )

and how it might be called from two functions, f1 (which takes a char*
to search through), and f2 (which is passed a const char* to examine).
The declaration of strchr() is intended to state that strchr() will not
modify the data pointed to by its first argument.  This is implemented
by incrementing the pointer until it points to the appropriate
character, and then casting *that* pointer from a const char* to a
char*.

Now, how does that affect strchr()'s callers?  f1() has permission from
its caller to modify the string; f2() does not.  If strchr() returned a
const char*, f2() would be fine, but f1() would be handed a pointer it
can't use to modify the string.

We could declare two polymorphic functions:

const char* strchr( const char* s, int c );
char* strchr( char* s, int c)

which C++ could distinguish between because of the difference in the
first arguments' types; but where's the "promise" that the second
function won't modify the data it's passed a pointer to?  Left
unspoken, for convenience's sake?

> It might have been better to use different words for these two
> uses.  It's a bit late now.

I'm afraid so.

> Henry Spencer at U of Toronto Zoology, henry@zoo.toronto.edu
> utzoo!henry

Paul S. R. Chisholm, AT&T Bell Laboratories
att!mtunq!psrc, psrc@mtunq.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.

In article <MCGRATH.90Aug3011039@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes:
>In article <1944@ux.acs.umn.edu> hopper@ux.acs.umn.edu (hopper) writes:
>>	   Currently the methods of structure member ordering, and packing
>>   specifications are easy enough to figure out that you can easily write a
>>   structure that models some hardware/OS data structure rather well. 

Boy, talk about a bad case of deja vu. A long time ago, there was an 
interesting little systems programming language. It allowed you to define
data structures and lay them out exactly as they would have to be layed out 
in memory. If the machine you were on could not handle odd addresses it was 
your responsibility to pad the structures yourself. As it happened it was
just terrific for writing OS code on minicomputers and things like that.
I assume you all can guess the name of this language.

We used to make fun of Pascal because you could define a structure in Pascal
but never really be sure of how it got laid out, unless of course you used 
"packed" and kind of knew how the compiler laid things out and how
big the compiler assumed certain scalar types were and so on. Sound familiar?

>If you want to have a `struct' that corresponds to some hardware thing or
>whatever, and you know enough about the C compiler's padding conventions to do
>this, then write it inside `extern "C"' in C++.  This still doesn't guarantee
>you a damn thing as far as the standards are concerned.
>"We can't allow A in the standard because it makes it more difficult to do
>nonstandard, unportable hack B (which is not guaranteed by the standard to
>work, but which probably will most days of the week)" does not sound to me like
>a reasonable argument.

So, if i read this right, C (and hence its descendant, C++) 
has moved so far from its origins as a systems programming language that
it is now useless for some things it used to be very good for, e.g. writing
device drivers. 
Not only that, but that one particular use is being called a nonstandard,
unportable hack, whereas at one time (I know, maybe too long ago)
that was cited as a "case in point" for the power of the language. 
This is progress?

I think that if C++ and/or C could somehow resolve this problem of 
exact bit-by-bit specification of a structure, a problem which actually
has been solved many other times in other languages, that would enhance
its usefulness. And it would sure be nice if whatever comes out does not 
have magic numbers like 16 or 32 hidden in it.
-- 
1987: We set standards, not Them. Your standard windowing system is NeUWS.
1989: We set standards, not Them. You can have X, but the UI is OpenLock.
1990: Why are you buying all those workstations from Them running Motif?

In article <140068@sun.Eng.Sun.COM> landauer@morocco.Sun.COM (Doug Landauer) writes:
>(The C++ Reference Manual that this refers to is not Ellis & Stroustrup's
>book, but rather Stroustrup's "UNIX System V AT&T C++ Language System
>Release 2.1 Product Reference Manual, Select Code 307-159".  It is
>nearly identical to E&S minus the annotations.)

Yes but, read the E&S before debating aspects of C++ standardization in
this forum.  The annotations are very helpful in understanding the design
tradeoffs in C++.  Read E&S, and let's try to keep the debate on track:
minor changes and/or clarifications to the existing C++ languages that 
might reasonably make it into the C++ standard!

In article <1028@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>Jim,
>
>It appears that you are going to be making a lot of proposals.  That's fine,
>but if you want them taken seriously, you should try to come up with
>some very specific wording that could be incorporated directly into the
>ANSI draft document.  Also, you should try to specify what section of E&S
>we are talking about for this proposal and you should say where and how
>your new proposed text should be fitted together with the existing wording
>in that section.

I'm not sure I buy this.  I'd like to have comp.std.c++ be the forum
for "public input" on the c++ standard.  This is the spirit in which
I am writing to comp.std.c++

Hopefully, at least on some issues, public input will reach some kind
of general consensus on how some of the loose ends in C++ should be
resolved.

But, eventually what's going to happen is a representatives from various
compiler vendors, etc, are going to have to sit down in a room, hammer out
the exact details, and fix the wording in the C++ documentation.  That
is the place where things are going to have to get really formal, not 
in public discussion.  However, the wording can't get fixed until
the intent is nailed down.

In any case, I hope to be able to restrain myself from making lots of
proposals.  I'm mainly trying to point out little loose ends that need 
to be cleaned up -- not major overhauls.