HDTenEightyP/NetNews huggingface dataset:
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.std.c++
Subject: Re: Use of nested functions
Date: 12 Jan 1993 23:02:09 GMT
Organization: Sun
NNTP-Posting-Host: rbbb

In article <1993Jan11.215111.11291@qualcomm.com> greg@harvey.qualcomm.com (Greg Noel) writes:
>Recursion implies that the context of a pointer must be kept as part of
>the pointer, which leads to either expanding the size of a function pointer
>or generating trampoline code dynamically.  Expanding function pointers
>would be a cost even when nested functions are not used and there are
>some architectures where code cannot be generated on the fly.

I know that code can be generated on the fly on Sparc, 680x0, and
80286, 80386, 80486, PDP-11, VAX, 6502, and IBM 370.  What
architecture were you thinking of?

Given such an architecture, are you sure that its problems cannot be
treated by keeping a cache of generated code fragments (you keep a
per-thread cache of code+data pairs to avoid the cost of page
remapping and cache flushing).  Remember, most machines ARE able to
load programs and run them, so they must have some rudimentary ability
to "generate" code at run-time.

In truth, I don't high hopes for nested functions appearing in C++,
but arguments against them based on their "cost" or "difficulty of
implementation" are not very strong.

David Chase
Sun
From: heiniw@eebsun1.eeb.ele.tue.nl (Heini Withagen)
Newsgroups: comp.std.c++
Subject: Problems with gcc/g++ and profiling
Date: 12 Jan 93 15:41:24 GMT
Organization: Electronic Circuit Design Group, Eindhoven University of Technology, The Netherlands



I am having trouble with gcc/g++ 2.2.2 compiling programs with -pg
options for profiling. I have been looking what g++ actually does
during compilation/linking (-v option) and compared this to 'cc' (on 
a SUN Sparc).

It seem that g++ is linking the wrong libraries which do not contain
the right function for profiling. When I try to make a seperate call
to the linker with the same libraries substituded as with 'cc', I get
a long list of 'Undefined' names which look like 'LBE??' and 'LBB??'.


Does anyone know the answer to my problems ?? Please help me, because
I am getting quite desperate.


Thanks very much in advance,

Heini Withagen
Department of Electrical Engineering EH 9.29
Eindhoven Technical University
P.O. Box 513
5600 MB Eindhoven
The Netherlands
Phone: 31-40472366
Fax:   31-40455674
E-mail: heiniw@eeb.ele.tue.nl
Newsgroups: comp.std.c++,comp.lang.c++
From: krc@wam.umd.edu (Kevin R. Coombes)
Subject: Re: RESULTS: C++ file extension survey
Organization: University of Maryland, College Park
Date: Thu, 7 Jan 1993 18:27:57 GMT

In article <1if5q2INN8pj@tsavo.hks.com> webb@tsavo.hks.com (Peter Webb) writes:
>
>On Dec. 11, 1992, I surveyed the Net to determine the most popular extension
>to use for C++ code.  Each respondent was permitted multiple votes.
>Here are the results:
>[table omitted]
>The distribution of the votes is very interesting.  The .C extension got the
>most votes, but more people voted against than for it, though not by an
>overwhelming majority.
>[more omissions...]
> The .cc extension is the least controversial, with only
>a single respondent objecting to it.
>
>Note that this distribution is counter to the advice given in the FAQ, which
>recommends .C for Unix machines and .cpp or .cxx for DOS and OS/2.
>
>Respondents agreed that there was no standard or consensus yet.

If you're really looking for a "standard", then you have no choice but
to rule out both .C and .c++, since there are operating systems that
will not support them. Of the remaining choices you listed, only  .cc
and   .cpp   got more favorable votes than unfavorable. I found that
interesting, since those are the extensions I use (the first on UNIX,
and the second on MS-DOS). It would be really nice if everybody
agreed on some common extension; I'm tired of wrting batch files to
rename things, and shell scripts to build symbolic links when I switch
from one platform to the other.

Kevin Coombes <krc@math.umd.edu>
Xref: sparky comp.std.c++:2031 comp.lang.c++:18988
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: RESULTS: C++ file extension survey
Date: 10 Jan 93 19:30:27 GMT
Reply-To: bright@nazgul.UUCP (Walter Bright)
Followup-To: comp.std.c++
Organization: Zortech, Seattle

In article <1993Jan7.182757.8297@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
/It would be really nice if everybody
/agreed on some common extension; I'm tired of wrting batch files to
/rename things, and shell scripts to build symbolic links when I switch
/from one platform to the other.

Zortech C++ will recognize .cpp, .cxx, .cc and .c++ all as valid C++
filename extensions, though our examples all use .cpp.
Newsgroups: comp.std.c++
From: harvey@opl.com (Harvey Reed)
Newsgroups: comp.std.c++
Subject: Re: C++ already *has* nested functions SO WHAT'S THE BEEF?
Keywords: nested functions, dumb ideas
Date: 4 Jan 93 19:31:06 GMT

rfg@netcom.com (Ronald F. Guilmette) writes:


> ...
>Well, it appears that some people have this mental model of "nested
>functions" left over from the days when they programmed in Pascal, where
>*anything* in a containing scope could be accessed directly.  Sadly, these
>folks don't seem to "get" the fundamental idea which made C into the big
> ...

I share your consternation over "block programming" and your concern
of over "featurism" (your words).

If programmers want nested functions, it sounds a lot like delegation which
C++ can handle quite well, as is. Just delegate to another object, or
your self. This leaves matters fairly explicit.

I think a formal extension to add nested functions to C++ is not useful.
The example you gave however was interesting!

(wringing my hands also),

-- 
++harvey
========================================================================
internet:  harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice:     617-965-0220
Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: pointer comparisons
Organization: Liant Software Corporation
Date: Thu, 7 Jan 1993 14:55:11 GMT

In article <1993Jan06.194710.6913@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> In article <1993Jan5.203237.28304@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
> |Yes.  An _other_ object is distinct, not identical to the object with which
> |it shares storage. 
> 
> I still don't understand your [undefined] concepts of "distinctness"
> and "identity"

I suspect the definition wouldn't matter to our issues of pointer comparison.

Also, I'm hesitant to try to define identity of objects.  The fundamental
semantics of a programming language are typically specified by their 
(1) operation, (2) denotation, or (3) axiomatically.  In (1) and (2) you
start with a rigorous framework, which we don't even have an inkling of
for C++.  In (3) you don't define the fundamentals, you specify how to 
reason about them.

Identity of objects is more of the essence than storage, so it would be
problematic to define the former in terms of the latter.
--
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: cok@acadia.Kodak.COM (David Cok)
Subject: Re: Proposal for default scope
Organization: Eastman Kodak Co., Rochester, NY
Date: Mon, 11 Jan 93 15:36:02 GMT

In article <1993Jan8.044714.2027@qualcomm.com> greg@qualcom.qualcomm.com (Greg Noel) writes:
>
>That is,
>	class Class {
>	public:  int func1();
>	};
>	Class:: {
>		int helper() { /* ... */ }
>		int func1() { /* code including calls to helper() */ }
>	}
>Since helper() is not declared in the class, it is not exported from the
>scope, while func1() is declared in the class, so it is exported in the
>normal fashion.
>

I agree fully with your desire to provide helper functions with access to
a class which do not appear in the class declaration and thus do not
cause recompilation when they are introduced or removed.  This is how I
do it, sticking to existing C++.  It's not as good as having language 
facilities to add helper functions into a class without affecting the 
header file, but for the moment it is adequate.  The drawbacks are 
introduction of another class name (which is publically visible), the 
need for qualification of the helper functions, and being careful about 
derived classes of Class when used in Class_helper.

Class.h:

class Class {
	friend class Class_helper;
	private: void func_private();
	public: int func1();
};


Class.C:

#include "Class.h"

class Class_helper {
	friend class Class;
private:
	static int helper() { ... }
	static int helper2(Class* c) { c->func_private(); ... }
};

typedef Class_helper Ch; // abbreviation 
static Class_helper CH; // just for convenience -- see usage examples below

void Class::func_private() { ... }

int Class::func1() {
	Class_helper::helper(); // take your pick of these three alternatives
	Ch::helper();
	CH.helper();

	Ch::helper2(this);
}


It would be nice to be able to make Class_helper a nested class within Class
while still declaring it in Class.C; but if that were made possible, I imagine 
that the problem which gave rise to this programming idiom could be fixed
directly.

One can also derive Class_helper from Class to get at Class's member functions
directly.  Then helper2 does not need to be static and does not need an
argument, but there would need to be a conversion from Class* to Class_helper, 
so there is not a lot of gain.

David R. Cok
Eastman Kodak Company
cok@Kodak.COM
Xref: sparky comp.std.c++:1981 comp.lang.c++:18760
From: rodb@racerx.bridge.COM (Rod Burman)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Extra COntant definitions
Summary: Suggestions for Extending C++ types
Date: 6 Jan 93 17:30:44 GMT
Followup-To: comp.std.c++
Organization: Bridge Information Systems

It has just occured to me that since C++ is a strongly typed language
it should provide intrinsic support for constants of all intrinsic types
that is currently we have:

		1	// int
		1U	// unsigned int
		1L	// long
		1UL	// unsigned long
		'\1'	// unsigned char -- it is unsigned since only
			// octal and hex bit patterns are allowed and
			// by default they are unsigned -- this may be
			// shakey logic, it may be implimentation dependent
			// on whether char is signed/unsigned, I admit
		'\1'L	// wide unsigned char -- see above comment
		"\1"	// unsigned char[]
		"\1"L	// unsigned wide char -- w_chart is scheduled to
			// be an intrinsic type in ANSI/ISO C++

This as I see it leaves room for:

		1S	// short
		1US	// unsigned short
		1I	// int -- this may not be really neccessary!
		1UI	// unsigned int
		'\1'S	// signed char -- see I'm following the spirit of C
			// and confusing programmers nicely by using S for both
			// short and signed!
		'\1'U	// unsigned char
		'\1'SL	// signed wide char
		'\1'UL	// unsigned wide char
		"\1"S	// signed char[]
		"\1"U	// unsigned char[]
		"\1"SL	// signed wide char[]
		"\1"UL	// unsigned wide cahr[]

Ofcourse you can always have:

	(short) 1;	// etc

and this may be more portable since you can then have:

	(int16) 1;	// etc

where you typedef int16, etc to the correct type in some header somewhere which takes
care of compiler/OS/machine dependecies, but shouldn't you be able to do the other way
if you want? (Can any one send me the appropriate #define macro to convert 1INT32; to
1L or 1 depending on wether long is 32 or 64 bits?)
	Well just a though for the standards committee after all it shouldn't break any
existing code should it?
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: Wed, 6 Jan 1993 17:51:24 GMT

In article <1993Jan5.203237.28304@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
>
>Which is where I wish to leave the issue, willing to trust for the present
>that objects which I wish distinct will be distinct.  This trust rests on
>
>      1. The status of distinct objects as objects.
>
>      2. The guarantee of 1.3 that an object occupies at least 1 byte
>         of storage.

	What does 1.3 say? (I do not have the WP, only the ARM.
The ARM appears to guarrantee ONLY that operator new() must
yield distinct addresses, it says nothing about subobjects
or included objects that I can find. Have I missed something?)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: matt@physics2.berkeley.edu (Matt Austern)
Newsgroups: comp.std.c++
Subject: Re: C++ already *has* nested functions SO WHAT'S THE BEEF?
Date: 8 Jan 93 10:04:28
Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
	<9300811.3521@mulga.cs.mu.OZ.AU>
Reply-To: matt@physics.berkeley.edu
NNTP-Posting-Host: physics2.berkeley.edu
In-reply-to: fjh@munta.cs.mu.OZ.AU's message of Fri, 8 Jan 1993 00:39:33 GMT

In article <9300811.3521@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

> The classic
> sort of example where nested functions are useful is

  [Example of passing a function pointer to qsort deleted]

> Because the interface to qsort() is fixed, the alternative is to use a rather
> ugly hack using global variables (well, ok, you can make them file-scope
> static variables rather than real global variables).

Correct; that's just where nested function would be nice.

And note that encapsulating compare() in some class is not a solution:
qsort expects its argument to be a function pointer, not a member
function pointer.
--
Matthew Austern                   Just keep yelling until you attract a
(510) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
matt@physics.berkeley.edu         solutions, become a part of the problem!
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: pointer comparisons
Date: 05 Jan 93 00:38:19 GMT
Organization: Microsoft Corporation

In article <1992Dec31.170223.21637@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
|In article <1992Dec30.184614.5551@microsoft.com> (Jim Adcock) writes:
|> Can you define your terms for us?
|
|> "distinct objects" means what?
|It means the objects are not identical.  

Which only leaves the issue of object identity.

|I was going to say that the standard for C++ needs to spell out what it
|means for object to be identical in a better way than just by
|     1. An object is a region of storage.
|     2. A definition or a new expression reserves the storage
|        needed by the object.
|These two rules leave things much more loose than necessary when objects
|require no storage.  But note that section 1.3 of the working paper 

Lots of other things remain unclear.  If a definition or a new expressions
reserves the storage needed by an object, when and when not can other
objects use this storage? [this is a trick question ;-]

|	The constructs in a C++ program create, refer to, access, and
|	manipulate objects in memory.  Each object (except bit-fields)
|	occupies one or more contiguous bytes.

Can other objects occupy those bytes?

|I missed this a while back when enumerating the features of the ARM and
|working paper which supported
|> The desired feature is:
|>     Two pointers to the same type, which point to distinct objects
|>     of that type, compare not equal.
|This excerpt from 1.3 gives the general rule I was seeking, because
|objects can be distinguished by the storage reserved for them.

That depends on what exactly is meant by "two pointers to the same type,
which point to distinct objects of that type"

At the very least "same type" and "distinct objects" remain poorly defined
in this discussion.

|	Does it govern base class subobjects?  As I understand it,
|	base class subobjects are objects, and hence are covered.

As I understand it, base class subobjects are NOT objects, because
in the case of virtual bases this would violate the contiguous-bytes
rule.  Further it would violate the overlapping objects rule.  Also,
it would imply that deriving some class from some base class can cause
a change in behavior of an "object" of that base class, and such flies
in the face of reason [IMHO].  So I believe "base clas subobjects" are
simply distinct views on one object.  One object can have multiple
identities then, depending on how it is viewed -- as demonstrated in
my multiple-base example.
From: harvey@opl.com (Harvey Reed)
Newsgroups: comp.std.c++
Subject: Re: virtual destructors by default
Date: 4 Jan 93 19:38:59 GMT

ark@alice.att.com (Andrew Koenig) writes:

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

I agree. Tis better for compilers to make the programmer more aware,
than to do too much automatically.


-- 
++harvey
========================================================================
internet:  harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice:     617-965-0220
Newsgroups: comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Proposal for default scope
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 8 Jan 1993 06:44:03 GMT

greg@qualcom.qualcomm.com (Greg Noel) writes:

>In article <mkohtala.726108774@vipunen.hut.fi> Marko.Kohtala@hut.fi suggests
>the use of Class::{ /* ... */ } as syntactic sugar so that class members
>could be defined in the scope without the need to explicitly put the class
>prefix on each member.  He argues that this would make the code easier to
>write and maintain.
[...]
>It does have the disadvantage that it makes the language larger.  On the
>other hand, it would seem to eliminate the desire, expressed by several
>people, for nested functions.  Such nested functions would usually be
>helper functions in the implementation of a class, so by being able to
>expand the class context to include non-nested functions would provide
>an efficient solution.

Many people seem to think that the purpose of nested functions is purely
as encapsulation, a sort of code organization/modularization feature.
While it is true that they do support this form of encapsulation, the
real reason that they are useful is their access to parameters and local
variables, and the fact that their addresses can be passed to any function
that just expects a function parameter.

If a local function never has its address taken, then it does not use
the full power of nested functions.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.std.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Type System
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Sat, 9 Jan 93 00:19:48 GMT

In article <C0Iy9o.9x@frumious.uucp>, pat@frumious.uucp (Patrick Smith) writes:
|> jss@lucid.com (Jerry Schwarz) writes:
|> |The way I understand it, when an object is created (constructed)
|> |it can be "marked" as mutable or immutable. ("Marked" in quotes
|> |because no runtime marking is implied).  This mark cannot be
|> |changed.  The type system is designed so that (barring the
|> |use of unsafe casts) the following rule is assured.
|> |
|> |	If an lvalue has non-const type,
|> |	then it refers to a mutable object.
|> 
|> There is another loophole. :-(
|> But it's (I hope) an unusual type of situation. :-)
|> 
|>    struct A { A(); /*...*/ };
|>    A* pa;
|>    A::A { pa = this; }
|> 
|>    void f() {
|>       const A a;
|>       // Now pa has non-const type but points to an immutable object.
|>    }

You're right.  I knew about that loophole, but forgot about it when
I posted my original item.  If anyone has ideas for a clean way
to close this loophole, I'd be interested to hear them.  

The problem is that the object is only "marked" immutable when the
constructor returns.  The constructor itself is supposed to be free
to modify the object in any way it chooses.

  -- Jerry Schwarz

Newsgroups: comp.std.c++
From: greg@harvey.qualcomm.com (Greg Noel)
Subject: Re: Use of nested functions (Was: Proposal for default scope)
Organization: Qualcomm, Inc., San Diego, CA
Date: Sat, 9 Jan 1993 04:05:54 GMT

David Chase <chased@rbbb.Eng.Sun.COM> writes:
>This is not correct.  Nested functions are not expensive to implement.

OK, how do you do it so that:
     o	It's efficient enough on a wide class of architectures that I don't
	care about the overhead involved in using it.
     o	There is no penalty for _not_ using it.
     o	It invokes the subroutine in the context where its address was
	evaluated, even under recursion.
     o	It's thread-safe; that is, the compiler doesn't create any global
	variables or the like behind my back.
     o	The address of the function is compatible with a ``standard''
	function variable.

Note that if you can do this, it would be possible to bind a non-static class
member function and a class object together, assign that to a ``standard''
function variable, and arrange that when the function variable was invoked,
the class member function would be invoked on the object.  The mechanisms
involved are equivalent.

>I speak as someone who has done it.

Well, I haven't done it myself, but in a previous incarnation I got to grovel
through a lot of PL/I code that used the equivalent of function pointers.  The
code generated on an IBM/360 was astoundingly inefficient.

Of course, one can't make a general argument from one data point, but if
function pointers are that expensive on a not-unreasonable architecture,
you'll have to convince me that they can be considered ``inexpensive''
in the general case.  I'm willing to be proven wrong, but it will take
more than just an assertion that it can be done.

>Compared to the costs of programming, and the potential wins ... nested
>functions are a clear win.

Don't get me wrong---I would like to have nested functions.  But the same
logic that prevented the adoption of an exponention operator is in effect
here: it can be ``unexpectedly'' costly.

>>The ``Spirit of C'' ... ; C++ inherits much of this spirit.
>Is this good or bad?

It's neither good nor bad; it just is.  But it must be understood when
considering how the language is put together.
-- 
-- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com
Newsgroups: comp.std.c++