HDTenEightyP/NetNews huggingface dataset:
From: amf@amfent.Gwinnett.COM (Andy Feibus)
Newsgroups: comp.std.c++,comp.std.c
Subject: Re: Question about sizeof in C/C++.
Date: Mon, 21 Dec 92 08:54:59 EST

Resending this, since my upstream feed seems to be having problems....

diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:
> In article <wwJXVB3w164w@amfent.Gwinnett.COM> amf@amfent.Gwinnett.COM (Andy F
> >jamesc@swapsdev.state.state.COM.AU (James Cribb) writes:
> >> Given
> >>     struct Something*  ps;
> >>     unsigned  k;
> >> do the C or C++ standards guarantee that
> >>     &ps[k] == ((char*) ps) + k * sizeof(struct Something)
> >Assuming that you [cm]alloc enough memory for ps to support accessing the
> >k'th element of it, the answer is... no.
> He was asking about the standards, for which (under the condition you state)
> the answer is... yes.
Thanks for quoting me out of context, but he also asked:

	I'm asking because I have C++ code that relies on this.
	It works on Suns but is it portable?

And that was the question I answered.

> >Different compilers see &ps[k] differently; use parentheses to clarify:
> > &(ps[k]).
> Even K&R-1 and Stroustrop-1 prohibited seeing this expression differently.
That's nice in theory, but I've found at least one UNIX-based compiler 
that interprets it differently.  Since his question was about 
portability, I told him what to do to make sure it worked on 
whatever compiler he chose.  Of course it's not standard, but
complying with the standard and being portable can sometimes be
two very different animals.

-- Andy.
andyfe@utoday.com

Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 24 Dec 92 00:58:48 GMT
Organization: Microsoft Corporation

In article <9235622.25712@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
|A ptrcmp that always returned 0 would be useless, IMHO.

Such an implementation would allow people to write code that does the
ptrcmp.  If the ptrcmp is zero, then the pointers could be compared.
If the pointers didn't compare equal, then the invoking code would know
that this machine doesn't support ptrcmp, and then the invoking code would
fall back on a secondary, possibly slightly slower [but more globally 
implementable] approach -- such as comparing object surrogates.

Thus such a ptrcmp would allow "optimal" performance on those systems
that can reasonably implement a total ordering, and would allow near
optimal performance on those machines that can't reasonably implement
a total ordering.  Rather than insisting that those systems that can't
reasonably implement ptrcmp do so anyway, or alternately not implement it
at all, leading to "portable" code that isn't in practice portable anyway.

Newsgroups: comp.std.c++,comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: Question about sizeof in C/C++.
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 24 Dec 1992 02:06:45 GMT

In article <cuX5VB1w164w@amfent.Gwinnett.COM> amf@amfent.Gwinnett.COM (Andy Feibus) writes:
>diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:
>>In article <wwJXVB3w164w@amfent.Gwinnett.COM> amf@amfent.Gwinnett.COM (Andy F
>>>jamesc@swapsdev.state.state.COM.AU (James Cribb) writes:
>>>>do the C or C++ standards guarantee that &ps[k] ==  [...]
>>>the answer is... no.
>>He was asking about the standards [...] the answer is... yes.

>he also asked:
>>>>is it portable?
>And that was the question I answered.
>>>Different compilers see &ps[k] differently; use parentheses to clarify:
>>> &(ps[k]).
>>Even K&R-1 and Stroustrop-1 prohibited seeing this expression differently.

>That's nice in theory, but I've found at least one UNIX-based compiler 
>that interprets it differently.  Since his question was about portability,

OK, you found at least one UNIX-based compiler for a non-C language.
I've found various compilers with various bugs too.  If you assert that
portability means porting to broken compilers, then there is no such thing
as a portable program.  Zero.  Zilch.  I think the original poster was
asking about portability among standard conforming implementations.  In
fact, even among pre-standard implementations of the C and C++ languages,
portability was there.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Compiler should generate virtual destructors
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 31 Dec 1992 05:01:50 GMT

I would like to propose that if a class has virtual functions,
then any destructor generated by the compiler will be virtual
by default.

(The suggestion was first read by me in a paper of Markku Sakkinen,
who claims it was not his idea originally either.)

Advantages: much safer, ensures correct deletion of objects
by default.  Removes a source of bugs. Removes the reminder
that its wise to do this from the FAQ.

Disadvantage: might slow down destruction a little. Can be
fixed by the programmer explicitly declaring a non-virtual
destructor.

Any comments?

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.std.c++
From: bucjet@uxa.ecn.bgu.edu (Jeffrey Terrell)
Subject: Converting EXE files Back to source code
Organization: Educational Computing Network
Date: Sun, 27 Dec 1992 04:19:38 GMT

I was looking through some of my old C programs when I came across a EXE
file with no C source code.  I was wondering if it was possible to
convert a C EXE file back to its orginal source code?  It was a great
program I wrote but I would like to see how I wrote it.

Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Type System
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 1 Jan 1993 17:20:44 GMT

Further to a previous post describing modifications to the type
system, I want to try to explain the underlying concept with some
further examples.

The basic idea is that 'int' and 'T' are object types,
whereas 'int&' or 'const int&' are not object types.
I would say they are 'accessors' to an object of type 'int'.

All identifiers (and expressions) are accessors.
Consider:

	int x;
	int& y=x;
	const int& z=x;

In use, one cannot distinguish 'x' and 'y'. It is absurd IMHO
to pretend that 'x' is of type 'int' whereas 'y' is of type 'int&'.
Instead, one says that 'x' and 'y' and indeed 'z' refer to,
or access, an object of type int.

The 'access' method of both 'x' and 'y' is reference to int,
i.e. they are both 'int&'. 'z' is also a reference to an
int, but it has a restriction imposed preventing the call
of non-const functions.

Consequences: of this and the previous post:

consider a template function:

template<class T> f(T){ ... }

what function is generated  by the calls

	f(3);
	f(x);
	f(y);
	f(z);
??

My system is simple: in all cases

	f(int);

is used. If you wanted to create

	f(int&);

you should have defined 

template<class T> f(T&) { ...}

(in which case the calls f(3), f(z) are illegal)

The reason is trivial: <class T> stands for a class (or pointer)
type, ie an object type, and int& is not a type, but a reference
to an object of the type int.
 
-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: Argument matching
Organization: Liant Software Corporation
Date: Thu, 31 Dec 1992 17:08:54 GMT

In article <1992Dec31.053242.3376@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> Proposal: 
> 
> 1) for the purposes of computing the signature of a function,
> the symbols 'const', 'volatile' and any trailing '&' are ignored.

> 2) As usually, attempting to define two functions with the same
> signature results in a duplicate defintion.

The worst effect of this idea would be that

	void f(int&)
and	void f(const int&)

could not be overloaded.  This is useful and I don't think bad design.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com

Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: Pointer comparisons
Organization: Liant Software Corporation
Date: Tue, 22 Dec 1992 17:43:27 GMT

In article <1992Dec19.001851.22116@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> On the contrary, for the test to not prove true would
> mean that the empty base class part has to be implemented by the compiler
> using gratuitous padding, and gratuitous padding is an anathema to
> traditional C/C++ implementation.  

"Gratuitous" is your own judgment.  Some of us disagree.

Moreover, such padding is in the C++ tradition.  The ARM requires padding 
in two places, where the principal intent is to support

            p and q point to different objects implies p!=q

    1. 5.3.2 "The size of any class object is larger than zero."

    2. 5.3.3 "This implies that an operator new() can be called with an
       argument zero.  In this case, a pointer to an object is returned.
       Repeated such calls return pointers to different objects."
       [An example follows to demonstrate that the intent is that
       distinguishable pointers values be returned.]
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 24 Dec 92 00:52:01 GMT
Organization: Microsoft Corporation

In article <1992Dec20.201212.8974@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes:
|The goal was to write data structures that use the ordering of
|pointers to improve search time.  What I need is mechanism that
|compares the pointers -- what they actually point to is not relevant.

On the contrary, you DO NOT then need such a mechanism, because alternate
approaches not using pointers can give you similar improvements to search times.

|C and C++ has some notion of equality between pointers.  You can
|clobber the semantics of this equality with memory mapping and what
|not, but that is in my view an issue beyond the language.

Agreed, as long as *you* stick to the C and C++ notion of equality
between pointers -- which is an extremely limited notion of equality.

|I would finally like to return to a claim I made earlier, but nobody
|has commented on (as far as I know).  I belive that even if you
|imposed a total ordering on pointers in a segmented architecture
|(e.g., Inte 8086 family), compilers would be able to handle the
|follwing common case efficiently:
|
|	void zap(int* a, unsigned n)
|	{
|		for (int* p = a; p < a+n; p++)
|			*p = 0;
|	}
|
|and produce the same code as today (without the total ordering).
|After all, the assignment "p = a" says that "p" must point to the same
|segment as "a".  Any comments?

You statement is true, but does not imply your intended conclusion, 
namely that thus one can efficiently implement total ordering.
Newsgroups: comp.std.c++,comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Question about sizeof in C/C++.
Organization: TauMetric Corporation
Date: Mon, 21 Dec 1992 16:58:58 GMT

jamesc@swapsdev.state.state.COM.AU (James Cribb) writes:

>Suppose a single struct Something needed 7 bytes of memory.  For word
>alignment, these might need to start on, say, 4-byte boundaries.

>E.g. (assume 4-byte floats),

>    struct Something
>    {
>        float  x;
>        char  s[3];
>    };

>Do the standards guarantee that sizeof(struct Something) will always be
>8 rather than 7?

The C Standard (there isn't a C++ Standard yet) guarantees:
- sizeof will return the amount of space reserved by the struct when it
    is a member of an array;
- each sub-object will be properly aligned;
- there will be no unused space (padding) at the start of the struct.

There may be padding between members or at the end of the struct.  The
size of the struct might be larger or smaller than the sum of the
sizeof's of its members.  (The compiler might pack struct members more
or less tightly than objects in an array.)

So if floats must start on a 4-byte boundary and sizeof(float)==4,
then sizeof(struct Something) cannot be 7.  It must be some value
greater than 7 which is a multiple of 4.  The most likely candidate
is 8, but that is not guaranteed by the Standard.

For the case of C++ structs which are also legal C structs, the rules
should be the same in the eventual C++ Standard.  That is, the intent
(at the moment) is that a C struct should have the same size and memory
layout when compiled by a compatible C++ compiler.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: virtual destructors by default
Date: 4 Jan 93 03:40:43 GMT
Article-I.D.: alice.24544
Organization: AT&T Bell Laboratories, Murray Hill NJ

There are two problems with extending C++ so that
classes with virtual functions also automatically acquire virtual destructors:

1. It will be a long, long time before a careful programmer can take
   advantage of the feature, because if a program that does so is
   run under an implementation that doesn't support it, it will
   quietly do the wrong thing and the user will blame the author.

   In general, extensions that define previously undefined behavior
   (rather than defining previously illegal behavior) must be viewed
   with caution.

2. The proposal doesn't solve the whole problem: it is possible to write
   class definitions that have no virtual functions and nevertheless
   require a virtual destructor.  For instance:

   struct Thing { Thing(); ~Thing(); };
   struct B { };
   struct D: B { Thing t; };

   main()
   {
	B* bp = new D;
	delete bp;	// Oops!
   }

   The commented line is undefined unless D has a virtual destructor.

For these reasons, I am dubious about the proposal.  I do think, though,
that it is wise for compilers to issue warning messages for classes
with virtual functions that do not also have virtual destructors.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Compiler should generate virtual destructors
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 3 Jan 1993 03:10:32 GMT

In article <9300301.307@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>>I would like to propose that if a class has virtual functions,
>>then any destructor generated by the compiler will be virtual
>>by default.
>>
>>Advantages: much safer, ensures correct deletion of objects
>>by default.  Removes a source of bugs. Removes the reminder
>>that its wise to do this from the FAQ.
>>
>>Disadvantage: might slow down destruction a little. Can be
>>fixed by the programmer explicitly declaring a non-virtual
>>destructor.
>
>I think that this situation should cause a compiler warning, rather
>than adding another arbitrary rule in the language for programmers to
>remember. 

	What arbitrary rule? Do you mean the rule that says
automatically generated destructors are *non-virtual* :-) ??

	The point here is that the forgetful programmer is protected.

>[Off the topic, another situation that should have a required warning
>is the (void *) to (T *) conversion. 


	void *x;
	T* t;
	t=x; // error here, no mere warning
	t=(T*)x; // warning inserted by programmer in the form of (T*)
	t=reinterpret_cast<T*>x; // grepable warning 

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Pointer comparisons
Date: 28 Dec 92 17:52:18 GMT
Organization: Microsoft Corporation

In article <1992Dec24.200201.25709@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
||Does anything go for A's.  E.g.
||
||	void f() {
||	    A a1, a2 ;  // can &a1==&a2 
||	    ... ; 
||        }
|
|Of course not!  ARM clearly requires members within a labeled public/private/
|protected section to be ordered with later members having "higher" addresses.

Sorry -- to much eggnog -- I misread the question.

Let me restate the question as an answer.

Does the ARM anywhere say that two pointers of the same type to two different 
objects of the same type not in the same array must compare not equal?  

If not then what does the ARM say of any such comparison?
Newsgroups: comp.std.c++
From: khcheng@unix.amherst.edu (KIM HONG CHENG)
Subject: MS C/C++ 7.0 & SDK 3.0 sale
Organization: Amherst College
X-Newsreader: TIN [version 1.1 PL7]
Date: Sun, 3 Jan 1993 21:34:55 GMT

MS C/C++ 7.0 + SDK 3.0
* still in plastic wrap (never been used)
* registration card included
* 45 lb of manuals (all manuals never been used)
* $200 +shipping
(I think this is more than $600)

Hong Cheng
327 Lincoln Ave.
Amherst, MA 01002

413-542-8084 (day)
413-549-4690 (eve & weekend)
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.std.c++
Subject: Re: Must derived class reserve space for an empty base class?
Date: 27 Dec 92 14:39:07 GMT
Article-I.D.: alice.24490
Organization: AT&T Bell Laboratories, Murray Hill NJ



jimad@microsoft.com (Jim Adcock @ Microsoft Corporation) writes

 > Below find an example that frequently catches programmers off guard.
 > Again, C++ pointers DO NOT model any notion of object identity.  If you
 > want your objects to maintain a notion of object identity [A good
 > idea, IMHO] then you must explicitly GIVE your objects a notion of object
 > identity.  C++ comes with no such notion built-in.
 > 
 > #include <iostream.h>
 > 
 > class A { char bsPadding; };
 > class B : public A {};
 > class C : public A {};
 > class D : public B, public C {};
 > 
 > main()
 > {
 > 	D d;
 > 
 > 	B* pb = &d;
 > 	C* pc = &d;
 > 	A* pa1 = pb; 
 > 	A* pa2 = pc; 
 > 
 > 	if (pa1 == pa2)
 > 		cout << "pointers match\n";
 > 	else 
 > 		cout << "pointers don't match -- even though of the same"
 > 			" type and 'to the same object'!\n";
 > 
 > 	return 0;
 > };

Huh? pa1 and pa2 does not point to the same object of type A. They point to
different sub-objects the D each of type A. 

I conjecture that people who think that pa1 and pa2 should point to the
same object aren't confused about `object identity' but about the distinction
between virtual and ordinary base classes (and the reason for that is often
that they haven't read a good C++ textbook, but thought they could deduce
the meaning of the example from first principles or experience with some
other language).
Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Zero-length structures and pointer comparisons
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 22 Dec 1992 00:29:57 GMT

In article <1gtblgINN72@darkstar.UCSC.EDU> daniel@cse.ucsc.edu (Daniel R. Edelson) writes:
>
>>	For this reason I think the ARM requirement is unworkable,
>>and must be modified. The rule should state that pointers
>>derived from the same object directly in the program must
>>compare equal. Pointers obtained from the OS need not follow
>>this rule, in that case it is implementation defined.
>
>Neither the C standard nor the C++ standard discusses any OS.
>(As far as I recall.)

	Precisely, nor should they, instead, they ought discuss
the conditions under which the rule is true, otherwise
it is implementation defined.
>
>A call to the operating system should be viewed as
>a call to an extension supplied by the language provider. 
>A program that uses an extension can be conforming but
>not strictly conforming, as per the X3J16 definitions. 

	Sure. But my interpretation of the p==q rule
is that any implementation in which it isnt true
is *non*-conforming. That is, there is no scope in the rule
for non-strict conformance.

>
>Thus, I think a better rule is:
>	``In a strictly conforming program, two pointers
>	to the same object compare equal.''
>Thus, this property need not be true in any program that
>calls the operating system.

	That is in the spirit of what I wanted, but I'm
not sure if a standard can say it in those words. Besides,
I wanted to be more explicit: even if I do an operting
system call somewhere, I want the system
to guarrantee

	T* p=new T;
	T* q=p;
	if(!(p==q))cout<"Non conforming program";

But I want that

	q=alias(p); // OS call to alias pointer
	if(!(p==q))cout<"Not a strictly conforming program";

(Given that p and q point to the same object after aliasing).
In particular I dont want the above code to render the whole
program non-conforming.	
>
>I think actually that ramifications of multiple inheritance 
>and multiple object-addresses should be explicitly addressed
>in the rule, such as by saying that a pointer to a base-class
>subobject is not a pointer to the same object as a pointer
>to the most-derived class object.
>
	The rule only applies when p and q are the same type.
If a conversion from a derived to base type occurs a comparison
would quite correctly yield 1 if the base subobject was a
sub-object of the complete object.

	The other issue is whether empty subobjects are generated
or not, if they can be, pointers to different subobjects of the
same type might compare equal.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: pointer comparisons
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 1 Jan 1993 15:52:41 GMT

In article <1992Dec31.170223.21637@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
>	Does it govern base class subobjects?  As I understand it,
>	base class subobjects are objects, and hence are covered.

	One consequence: abstract objects can exist.

	Corollary: such objects have states not accessible via
	the contiguous storage allocated for them.
	(via virtual function calls)


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.std.c++