HDTenEightyP/NetNews huggingface dataset:
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: Compiler should generate virtual destructors
Date: 25 Jan 93 21:23:36 GMT
Article-I.D.: alice.24702
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <harvey.727978914@regina> harvey@opl.com (Harvey Reed) writes:

> Would this apply if the "compatibility mode" was phased out over time?
> In a similar manner to how C vendors gradually migrated to ANSI C?

Yes.  While the "compatibility mode" is being phased out, I still
have to write in the intersection of the two languages, until the
old one is well and truly gone.
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.std.c++
Subject: Re: Use of nested functions
Date: 22 Jan 1993 18:58:21 GMT
Organization: Sun
NNTP-Posting-Host: rbbb

In article <1993Jan22.081555.12027@us-es.sel.de> reindorf@us-es.sel.de (Charles Reindorf) writes:
>On the subject of "trampolenes" in the implementation of nested functions, this 
>presumably means the following appraoch:

> [code generation into stack frame, which works.]
> ... The main objection I can see is that on some operating systems
>you are not allowed to do any run-time code generation.

One workaround is to keep a cache of trampolines, which in this case
are pairs of code+data, where each piece of code is compiled to
reference a particular piece of data.  Some run-time code generation
must still occur.  In the limit case (the least flexible OSes) a
different calling convention must be used for all function calls.

>Other people talk about "bound" functions which presumably means that
>given an object a of class A with member function f, then "a.f" can be
>regarded as a new function (whose pointer can be taken) with a non
>member-function signature.  The only way I can see of using a
>trampolene appraoch for this situation is to place the trampolene for
>the function a.f into the object a itself.

Actually, you could "new" them.  Just allocate the functions on the
"heap", and free them when you are done.  Or, we could take a flying
leap at the slippery slope and add garbage collection.

>This surely makes member function closures an impracticable and
>unworkable addition to the language?

I think the answer is another question: "compared to what?"  I'm
really looking forward to run-time instantiation of templates.

David Chase
Sun
From: dak@cip-s03.informatik.rwth-aachen.de (David Kastrup)
Newsgroups: comp.std.c++
Subject: Re: Use of nested functions
Date: 28 Jan 93 12:53:25 GMT
Organization: Rechnerbetrieb Informatik - RWTH Aachen
Distribution: world
NNTP-Posting-Host: cip-s03.informatik.rwth-aachen.de

One problem with trampolines and self-modifying code is that there
is no longer a separate, read only code space. This can complicate
code sharing by demand paging (self-mod code), and be influenced by
the processor's caches and prefetch queues, if self-modifying code is
expected to work under all circumstances.
 I know for a fact that some CPU testers find out about perfectly
object-code compatible CPUs by finding out, under which circumstances
in self-modifying code is the old code executed instead of the
modified one.

The real problem is dealing with separate code space cache controllers,
which are likely not to be designed for that purpose.
From: peterj@PROBLEM_WITH_INEWS_GATEWAY_FILE (Peter Westley)
Date: Tue, 26 Jan 1993 01:47:14 GMT
Subject: BC++3.0/OWL DDEACK structure from WM_DDE_EXECUTE
Organization: HP Australasian Response Centre (Melbourne)
Newsgroups: comp.std.c++
X-Newsreader: TIN [version 1.1 PL8.5]

[ Article crossposted from comp.os.ms-windows.programmer.misc ]
[ Author was Peter Westley ]
[ Posted on Tue, 26 Jan 1993 01:33:13 GMT ]

Is the DDEACK structure which comes pointed to in LOWORD of lParam when
WM_DDE_ACK is in response to a WM_DDE_EXECUTE message, valid?

Let me explain:

I have a method called when I receive a WM_DDE_ACK message:
(Using OWL dynamic dispatching it's easy) It get's called after sending a
WM_DDE_XXX message to the DDE serveer, when the server replies with an 
WM_DDE_ACK message.

class DDEClass
{
    //...
    WMDDEAck(TMessage & Msg)
	=[WM_FIRST + WM_DDE_ACK];
    WORD PendingMessage;
}

void DDEClass::WMDDEAck(TMessage& Msg)
{
    switch (PendingMessage)//pending message is the message which was just sent
			   //to the DDE server - i.e. it's what this WM_DDE_ACK
			   //is in reply to.
    {
	case WM_DDE_INITIATE:
	    //stuff
	    break;
        case WM_DDE_REQUEST:                       
	//I put this and the next case in blocks so that the DdeAck is only
	//created if it's needed (i.e. a local copy only)
	    {   //Get the pointer to the DDEACK     
		DDEACK *DdeAck = (DDEACK *)Msg.LP.Lo;
		if(DdeAck->fAck)               //\
		    //stuff if ack is valid;   // \
                else                           //  |- these are different to the
		    //other stuff if it isn't; // /   DDE_EXECUTE commands
	    }                                  ///
	    break;
	case WM_DDE_EXECUTE:
	    {   //Get the pointer to the DDEACK
		DDEACK *DdeAck = (DDEACK *)Msg.LP.Lo; 
		if(DdeAck->fAck)
		    //stuff if ack is valid;
                else
		    //other stuff if it isn't;
	    }
	    break;
    }
}

The problem is that when I get the response from the WM_DDE_REQUEST message,
everything is fine (same for the WM_DDE_INITIATE but I don't use the DDEACK
structure there)  When it enters the case WM_DDE_EXECUTE case section,
I get a GP fault on access to the DdeAck->fAck location.  The code generated
by the compiler is the same for both parts of the case statements (though
I haven't been able to check the code which sets up the DDEACK struct).

SO, does anyone know if there is a problem in the windows code (3.1) which 
might be broken here such that it doesn't allocate the DDEACK structure 
properly?  Is the DDEACK struct supposed to be valid when it's in response
to a WM_DDE_EXECUTE message?

Please help!

Thank in anticipation,

Peter Westley			 .-_!\		Hewlett Packard
Phone: +61 3 (T)272 2440        /     \		Australian Support Centre
Fax: +61 3 890 0326      	\_.-.b/<--------31-41 Joseph St.
E-mail: peterj@hparc0.aus.hp.com     v          Blackburn, Victoria 3130
//
// The views, opinions, information or other data here is solely from the
// mind of myself.  It is not the official word from my employer.  While I
// endeavour to provide accurate information, no responsibility is taken
// for errors or omissions.
From: mharriso@digi.lonestar.org (Mark Harrison)
Newsgroups: comp.std.c++
Subject: sprintf return value
Date: 26 Jan 93 20:21:58 GMT
Organization: DSC Communications Corp, Plano, TX

Will the C++ standard specify the return type of sprintf()?
-- 
Mark Harrison, mharriso@dsccc.com
Newsgroups: comp.std.c++
From: reindorf@us-es.sel.de (Charles Reindorf)
Subject: Re: Use of nested functions
Organization: SEL-Alcatel Line Transmission Systems Dept. US/ES
Date: Fri, 22 Jan 93 08:15:55 GMT

On the subject of "trampolenes" in the implementation of nested functions, this 
presumably means the following appraoch:

Suppose a function g is nested inside a function f; Any pointer to the function
"g" is simply a pointer to a small "trampolene" compiled by function f into it's
own stack frame. The "trampolene" code adds an extra parameter to the parameters
for function "g" and then calls the real body of function "g" which is already
compiled into the code section. The extra parameter point's to f's stack frame
so that g can access "f"s instance variables.

Some people say that they "don't like" trampolenes, but don't seem to give any
reason for it. The main objection I can see is that on some operating systems
you are not allowed to do any run-time code generation. But there again, in 
these architectures there do exist other, addmittedly less efficient workarounds
to this problem, surely.

Other people talk about "bound" functions which presumably means that given an
object a of class A with member function f, then "a.f" can be regarded as a new
function (whose pointer can be taken) with a non member-function signature. The 
only way I can see of using a trampolene appraoch for this situation is to place
the trampolene for the function a.f into the object a itself. This increases
the memory overhead for function a. In fact, the compiler would have to do
this by default for every member function of a, because it won't know in
advance which will be bound (without ghastly extensions to the language). This
surely makes member function closures an impracticable and unworkable addition
to the language?

-- Charles Reindorf
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re:  can a pointer cast to a void* be compared to (void*)0 ?
Date: 25 Jan 93 01:52:14 GMT
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo

In article <28570@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
>In article <alien.02pi@acheron.amigans.gen.nz> alien@acheron.amigans.gen.nz
>(Ross Smith) writes:
>>standard does not require pointers to functions to be castable to/from any
>>other pointer type.

>Yes (or rather, the effect is undefined or unspecified or otherwise

If a converted pointer is used to call a function that has a type that is
not compatible with the type of the called function, the behavior is undefined.
By intuitive implication, I'd say that if the converted pointer is used to call
a function that has a type compatible with the converted pointer, it works.

>>(1) Are pointers to different types of function required to be castable to
>>each other?

>Yes; however, the result is up to the implementation.  Your only guaranteee
>is that if the result is then cast *back* to the `correct' type [...]
>the final result can be used to *call* that function; I am somewhat
>less certain that it must compare equal to the original pointer.

It must compare equal.

>>(2) If a compiler does allow casting between "ordinary" pointers and function
>>pointers, does the rule about null pointers remaining null still apply?

>Note, however, that the null pointer constant [blah blah blah...]

Doesn't look like he asked about that one though.

If an implementation says that an object-or-incomplete pointer is allowed to
be cast to a function pointer (or vice-versa), then see what the implementation
says if the original pointer happens to be null.  If the implementation doesn't
say, and you've just been lucky so far in playing with undefined behavior, then
it's up to you to decide if you want to continue depending on luck.

>Another question (which belongs in comp.std.c; note followup header):
>do null pointer constants, cast or assigned to pointers to functions
>of different types, then to a common type, compare equal?

If two pointers to function types are both null pointers or both point to the 
same function, they compare equal.  But you can't use this to compare two
incompatible function pointer types because of the constraints.  So this
reduces to the question, if a null function pointer is cast to a different
type of function pointer, is the result still a null pointer?  Oh good, yes.
[ANSI classic 3.3.9 and last paragraph of 3.2.2.3.]
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?
Newsgroups: comp.std.c
From: gsf@ulysses.att.com (Glenn S. Fowler)
Subject: Re: Libraries specified in source?
Date: Mon, 25 Jan 1993 05:13:19 GMT
Organization: AT&T Bell Labs

In article <1993Jan23.194202.20332@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes:
>ray@astro.ocis.temple.edu (Ray Lauff) writes:
>>but why not just have a line in the main program such as
>>
>>#library "/lib/libc.a"
>
>Two problems I can think of right off.  How do you know that the
>function you want is in that library on every system and how do
>you know that the libraries reside in that directory?
>> ...
>How is this easier than using the Make file?

something like #[pragma] library would be very useful for providers of
non standard libraries

[warning -- concrete example follows]

take unix sockets (or leave them)
on BSD derived systems
	#include <sys/socket.h>
in the source is sufficient because all the gunk is in libc
but on sys5r4 you need to link with -lsocket -lnsl (and maybe some others)
while on 10th edition you need -ltcp -lyou-get-the-picture

if the <sys/socket.h> provider uses #[pragma] library ... then
no makefile mods are needed and the provider can partition the
library objects any which way, even change them from release to release

however I would prefer a notation that more closely follows the unix cc
-l option that abstracts the library name out of the file system namespace
	#pragma library "socket"	/* -lsocket */
	#pragma library "nsl"		/* -lnsl */

Glenn Fowler    (908)-582-2195    AT&T Bell Laboratories, Murray Hill, NJ
uucp: {att,ucbvax}!ulysses!gsf              internet: gsf@ulysses.att.com
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.std.c
Subject: Re: Libraries specified in source?
Date: 25 Jan 93 04:36:28 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1993Jan21.182949.29796@cronkite.ocis.temple.edu>, ray@astro.ocis.temple.edu (Ray Lauff) writes:
> I have been programming in c for about a year or so now on various 
> platforms and I often find myself wondering why standard C has
> no mechanisms for embedding the libraries required for loading
> into the code.

David Tilbrook had a utility, I think it was called "com".
It just searched a file for special comments and made the compiler command
line from them.  All you need is a convention:

	/*! Needs: -lm */

and a preprocessor which can locate such comments and do The Right Thing (TM)
with them.  (dt's utility didn't go this far.)
From: dsb@duke.cs.duke.edu (D. Scott Bigham)
Newsgroups: comp.std.c
Subject: Re: Empty macro arguments
Date: 21 Jan 93 23:00:29 GMT
Organization: n. Arrangement in an orderly or logical fashion.  See "miracle".

From the Holy Book of <1993Jan18.065413.26508@nntpd.lkg.dec.com>
  as spake by diamond@jit.dec.com (Norman Diamond) :

>In article <16355@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

>>Am I likely to run into any trouble if I just go ahead and use what the
>>standard itself proposes as an extension?

>I don't see any wording in the standard that proposes an extension. [...]

Hmm.  Does this imply that a conforming compiler faced with the
following code fragment:

#define fred(a,b,c) a b c
fred(1,,3)

is _required_ to issue a diagnostic?

						-sbigham
-- 
Scott Bigham                   | The opinions expressed above are
dsb@romeo.cs.duke.edu          | (c) 1993 Hacker Ltd. and cannot be
bigham@hercules.acpub.duke.edu | copied or distributed without a
    (but not for long)         | Darn Good Reason(tm).
From: bill@twwells.com (T. William Wells)
Newsgroups: comp.std.c
Subject: Re: Is this allowed in C?
Date: 28 Jan 93 15:28:17 GMT
Distribution: comp
Organization: None, Mt. Laurel, NJ

In article <1993Jan26.4502.4824@dosgate> "peter curran" <peter.curran@canrem.com> writes:
:           void *p;
:    p = malloc(1);
:
: Are there any alignment restrictions on the allocated memory?

Yes. The reason is that even though you may not store a double
there, the rules on casting require that you be able to assign
the pointer to a pointer to double and back again without
changing the pointer. E.g., on a machine that has a double
pointer that can't also represent arbitrary char pointers, the
returned value would have to be such that it is representable as
a double pointer. However, the compiler may cheat. On most
machines, you can't really tell whether the pointer is properly
aligned or not except by storing into it and you could never
actually store a double there so if the compiler does cheat, no
strictly conforming program could tell the difference.

---
Bill                            { rutgers | decwrl | telesci }!twwells!bill
bill@twwells.com
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: Is this allowed in C?
Date: 25 Jan 93 02:01:22 GMT
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo

In article <C19Juw.7GL@undergrad.math.waterloo.edu> bbobak@undergrad.math.waterloo.edu (Brad Bobak) writes:
>In article <1993Jan22.012502.5241@nntpd.lkg.dec.com>, diamond@jit533.jit.dec.com (Norman Diamond) writes:
>> In article <C17p4n.Dx8@undergrad.math.waterloo.edu> bbobak@undergrad.math.waterloo.edu (Brad Bobak) writes:
>> >[...]
>> The C standard guarantees that whenever malloc() succeeds (which you forgot
>> to check), the value will point to storage suitably aligned for everything,
>> including structs.  So (struct astruct *)store can indeed be used as a pointer

> My example wasn't clear on what I really meant. Lets change the malloc()
>  line to:
> store = malloc(sizeof(blah)+3) + 3;
> /* so that store isn't guaranteed to be aligned for anything, except
>  * chars (is this true?) */

The C standard guarantees that whenever malloc() succeeds, the value will
point to storage suitably aligned for everything, ....
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?
From: ray@astro.ocis.temple.edu (Ray Lauff)
Newsgroups: comp.std.c
Subject: Libraries specified in source?
Date: 21 Jan 93 18:29:49 GMT
Organization: Temple University
X-Newsreader: TIN [version 1.1 PL8]

I have been programming in c for about a year or so now on various 
platforms and I often find myself wondering why standard C has
no mechanisms for embedding the libraries required for loading
into the code.  Right now I have to specify them on the command
line of the compiler call.  Of course, using make files can
simplify the process, but why not just have a line in the 
main program such as

#library "/lib/libc.a"

which would then alert the linker that that library will be 
required.  DIGITAL supplies macro assembly programmers with
this capibility (.library directive), but they recommend
against using it since it makes moving library files a problem
since all the source code would need to be updated.  Perhaps
C could avoid this problem by putting them in an include file.

It seems to me this would be a reasonable extension to C, since
just about every c program requires some type of library that's
not automagically provided.  Does this make sense to anyone 
else?  Would it not be a consideration for the language?

Ray
ray@astro.temple.edu
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: binary data with stdin/stdout
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Wed, 27 Jan 1993 01:56:33 GMT

In article <ig25.728085496@fg70> ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
>Does the standard have anything to say about wether stdin and stdout
>are opened to a file stream opened in binary mode?

Almost.  It says that they're text streams.  It doesn't require text streams
to be different from binary streams, but of course on some implementations
they are different.

>Would a program which wrote binary data to standard output, or read it
>from standard input, be complying?

Under the weak definition of "conforming" (for programs) it could very well
do so.  Under the strong definition of "strictly conforming" it is possible,
but you'd have to be very restrictive in the data that you write, and in
other operations that you do.  I'd have to guess your purpose and guess no.

>The reason for asking is that many programs which were developed for
>UNIX, which do this, fail on systems where binary and text mode for file
>streams are not identical.  I'd like to know wether they fail in a
>standard - conforming or a non - standard - conforming way :-)

If the failure means that the output is different from what the output
would be when they succeed, then obviously they're not strictly conforming.
(Part of the definition of strictly conforming is that they do not produce 
output dependent on any unspecified, undefined, or implementation-defined
behavior.)
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: Null pointer constant compatible with pointer to funtion ?
Keywords: pointer
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 21 Jan 1993 06:14:33 GMT

In article <1993Jan21.001622.13452@xilinx.com> lou@xilinx.com (Lou Sanchez-Chopitea) writes:
>    Is a null pointer constant (3.2.2.3) (and therefore NULL (4.1.5)) 
>assignment compatible with a pointer to function ?
>standard conforming ?
>    	#include <stddef.h>
>    	    void (*g)( void);
>    	    g = NULL;

Yes.  Null pointer constants specifically have this magic property.
3.2.2.3, 3.3.16.1, 3.3.9, and 3.3.15 all define capabilities for
null pointer constants in relation to all kinds of pointers.

In other contexts, a null pointer constant reverts to being a simple
integer constant which happens to be 0, or a constant (void *) pointer
to objects which happens to be a null pointer (depending on which kind of
expression you coded, or which way the implementation defines NULL).
Those would be different, not compatible with pointers to functions.
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Libraries specified in source?
Organization: TauMetric Corporation
Date: Fri, 22 Jan 1993 20:10:20 GMT

ray@astro.ocis.temple.edu (Ray Lauff) writes:

>... but why not just have a line in the main program such as

>#library "/lib/libc.a"

>which would then alert the linker that that library will be 
>required.  ...

>It seems to me this would be a reasonable extension to C, since
>just about every c program requires some type of library that's
>not automagically provided.  Does this make sense to anyone 
>else?  Would it not be a consideration for the language?

If you mean to propose adding this to the Standard, I doubt it would
happen.  This assumes that implementations use a linker and libraries,
neither of which is required.

The C Standard specifies what constitues a legal program and the
meaning of legal programs.

There has to be some way to get from source code to an execution
of the program, and the implementation has to tell you how to do that.
Whether there is a compiler or a linker or libraries involved is a
subject separate from the C language.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: binary data with stdin/stdout
Date: 28 Jan 93 14:36:17 GMT

In article <ig25.728085496@fg70>, ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
> Does the standard have anything to say about wether stdin and stdout
> are opened to a file stream opened in binary mode?

ANSI 4.9.3 Files (emphasis mine):
	At program startup, three *text* streams are predefined...
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
These findings suggest a logical course of action. -- Calvin
Newsgroups: comp.std.c