HDTenEightyP/NetNews huggingface dataset:
From: hhc@athena.mit.edu (Hong-Hsiang Chen)
Subject: Re: Recursive templates
Organization: Massachusetts Institute of Technology
Date: Tue, 17 Nov 1992 15:11:11 GMT

In article <1992Nov16.220526.21566@borland.com> pete@borland.com (Pete Becker) writes:
>In article <83733@ut-emx.uucp> jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
>>Has ANSI decided anything about the expansion of a recursive template
>>definition?
>
Interesting...I tried running the following example with gcc 2.3.1...
>	template <unsigned n> class Factorial
>	{
>	public:
>		unsigned eval() { return n*Factorial<n-1>.eval(); }
                                           ^^^^^^^^^^^^^^^^^^^^^
                                           what?? there's no instance here!
I used:
                static unsigned eval() { return n*(Factorial<n-1>::eval()); }
>	};
>
>	class Factorial<0>
>	{
>	public:
>		unsigned eval() { return 1; }
again, I used
                static unsigned eval() { return 1; } 
>	};
>
>	#include <iostream.h>
>
>	int main()
>	{
>	Factorial<6> f6;
>	cout << f6.eval() << endl;
I used
        cout << (Factorial<6>::eval()) << endl;
>	return 0;
>	}
>
>	That's from memory, so I may have some of the details wrong, but it
>worked in BC 3.0, and from discussions I've had the same sort of thing works
>with cfront.
Well, it seems that it would make more sense to have no instantations of the
class at all...
>	-- Pete
Interesting that it actually works with gcc 2.3.1...impressive...

Come to think of it, there shouldn't be any reason why recursive templates 
shouldn't work...anybody have an argument against it?  (besides it being a
vehicle for more obsfucated code :-))

Curiously, gcc 2.3.1 gives me a warning about shadowing member 'eval' with
member function... I guess I should use virtuals, eh?

Well, more thoughts on this later...




--
-----
Sean Chen.  hhc@athena.mit.edu
"Nunc in scutella iaceo,/et volitare nequeo,/dentes fredentes video./Miser!"
  Olim lacus colueram, _Carmina Burana_
From: garbinat@disun41.epfl.ch (Benoit Garbinato)
Newsgroups: comp.std.c++
Subject: c++ mode for gnu-emac
Date: 23 Nov 92 17:51:49 GMT
Organization: Ecole Polytechnique Federale de Lausanne

Is there an enhanced emacs mode for C++ and if so, where can I get it ? Thanks.
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.std.c++
Subject: Re: return values and destructors
Date: 18 Nov 1992 21:47:06 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu


In article <1992Nov17.204640.9222@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>>I still believe you're being confused by a compiler bug.  Can you quote
>>ARM to support your position?  Seems clear to me that a throw expression
>>has to be evaluated in scope, which means it must be evaluated before
>>the destructors, since destructors occurs on exiting scope.  Once the
>>throw expression has been evaluated, the throw object *has* its value, 
>>and the destructors can do what they want without affecting its value.

In article <Bxx2uD.42x@scd.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
>I don't think that "confusion" is the correct term since I also
>believe this to be a compiler bug.  My comment about thrown objects
>was an attempt to show how ridiculous it is for return expressions to
>be affected by destructors of local objects.  Remember, not everyone
>posting to this thread agrees that this is a problem.

Well, I was one of those who said that it wasn't a problem, because I
found the original example posted a bit contrived.  But Jim Adcock's
argument has convinced me that I was wrong; the argument to "return"
has to be evaluated before the destructors are evaluated, and the
sloppiness on this issue that I was advocating (e.g. assume nothing
about destructors that affect the return value in this way) was wrong
and would make the exceptions facility very difficult to use.

The ARM and draft standard could make this clearer.



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Recursive templates
Date: 20 Nov 92 00:41:50 GMT
Organization: Microsoft Corporation

In article <5225@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
|N-dimension matrixes should be possible to base on N-1-dimension matrixes,
|with 1-dimensional matrixes (arrays) as the recursion-stopper.
|
|The details are left as an exercise for the reader (:-).

Similarly there's the old example of recursively implementing a 2^n times-
the-range LongInt class based on a 2^(n-1) times-the-range implementation.

Newsgroups: comp.std.c++
From: mtichy@fraser.sfu.ca (Martin Tichy)
Subject: Shell Sort
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Mon, 16 Nov 1992 07:19:37 GMT

Can anyone please post or mail me a C++ shell sort?  I can't
seem to get this one to work.

void shell_sort (int list[], int size)
{
int i, j, gap;
 
for ( gap = size / 2; gap > 0; gap /= 2)
  for (i = gap; i < size; i++)
    for (j = i - gap; j >= 0; j -= gap)
      if (list [i] <= list [i+1]
        break;
swap ( &list [j], &list [j+1] );
}
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.std.c++
Subject: Re: Recursive templates
Date: 17 Nov 92 03:21:45 GMT
Article-I.D.: alice.24210
Organization: AT&T Bell Laboratories, Murray Hill NJ



Jamshid Afshar jamshid@emx.utexas.edu writes:

 > This would require
 > that compilers not expand a template function or member function
 > unless it is actually called.

This was discussed briefly in the ANSI/ISO committee and there seemed to
be consensus that a template member function should not be generated unless
it was used. This is therefore the most likely outcome as a more precise
specification is worked out, but it is not the only opinion that has ever
been voiced on this matter.
Newsgroups: comp.std.c++
From: vinoski@ch.apollo.hp.com (Stephen Vinoski)
Subject: Re: return values and destructors
Organization: Hewlett-Packard Corporation, Chelmsford, MA
Date: Wed, 18 Nov 1992 14:56:36 GMT

In article <1992Nov17.204640.9222@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <BxMxxB.CMp@scd.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
>|There is also a similar potential problem with exceptions and throw
>|statements; what happens if the value of the thrown object is affected
>|by the destructors executed due to stack unwinding before the throw
>|actually occurs?
>
>I still believe you're being confused by a compiler bug.  Can you quote
>ARM to support your position?  Seems clear to me that a throw expression
>has to be evaluated in scope, which means it must be evaluated before
>the destructors, since destructors occurs on exiting scope.  Once the
>throw expression has been evaluated, the throw object *has* its value, 
>and the destructors can do what they want without affecting its value.

I don't think that "confusion" is the correct term since I also
believe this to be a compiler bug.  My comment about thrown objects
was an attempt to show how ridiculous it is for return expressions to
be affected by destructors of local objects.  Remember, not everyone
posting to this thread agrees that this is a problem.

I want to ensure that the interpretation of this problem as a compiler
bug is correct given what the ARM says on page 90 about how return
works.

>Likewise on return values.  The return expression must be evaluated in
>scope which means it must be evaluated before the dtors so it must already
>*have* its value by the time scope is exited and dtors are executed.
>If the return object tries to get its value after dtoring its a compiler bug,
>since the dtoring implies scope has already been exited so then how could
>the return expression be being evaluated in scope?

You're preaching to the choir. :-)  I agree with you 100%.  I just
want somebody on the ANSI C++ committee to sit up and take notice of
this problem (yes, I have already notified the rep from my company).
This behavior should be more clearly specified by the language
standard.

I will consider this to be a cfront bug and report it as such.

-steve

Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.std.c++
Date: Tue, 17 Nov 1992 16:04:18 -0500 
From: Danny R Dalal <dd3e+@andrew.cmu.edu>
Subject: Re: NAMELESS FUNCTIONS

Are you trying to curry fucntions?
If you can generalize it without a high efficiency penalty, that would
be very usefull.


___Dan
Newsgroups: comp.std.c++,comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Operator -> cannot return non-class types?
Organization: TauMetric Corporation
Date: Sat, 14 Nov 1992 22:03:18 GMT

kanze@us-es.sel.de (James Kanze) writes:

>Basically, I don't offhand see anything in the language definition
>that would restrict an operator->() (the function) from returning
>whatever it wishes.  On the other hand, there is no way to use this
>operator *unless* it returns a pointer to a class.

ARM 13.4.6:

"... operator->() must return either a pointer to a class or an object
of or a reference to a class for which operator->() is defined."

That seems pretty clear.  The compiler was correct to reject a
declaration with any other sort of return type.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.std.c++
Subject: Re: Recursive templates
From: alanb@sdl.mdcbbs.com (Alan Braggins)
Date: 18 Nov 92 16:52:13 GMT
Organization: Shape Data (Division of EDS), Cambridge UK
In-reply-to: pjl@cs.uiuc.edu's message of Tue, 17 Nov 1992 22:46:23 GMT

>>>>> On Tue, 17 Nov 1992 22:46:23 GMT, pjl@cs.uiuc.edu (Paul Lucas) said:

>>N-dimension matrixes should be possible to base on N-1-dimension matrixes,
>>with 1-dimensional matrixes (arrays) as the recursion-stopper.

> *****>	What's a 5x3 matrix based on?  4x2, 3x1, 2x(oops!).

Dimension. Not size.  NxNxN is based on NxN is based on N was
specified as the recursion-stopper.

--
     Alan Braggins, alanb@sdl.mdcbbs.com, abraggins@cix.compulink.co.uk
Shape Data - A division of EDS-Scicon Limited.   Cambridge, UK +44-223-316673
   "Any technology distinguishable from magic is insufficiently advanced."
 "My employer does not necessarily share my views - but I'm working on it."
Newsgroups: comp.std.c++
From: pl2440@meibm31.cen.uiuc.edu (Paul Jay Lucas)
Subject: Re: Recursive templates
Organization: University of Illinois at Urbana
Date: Tue, 17 Nov 1992 00:18:39 GMT

In <1992Nov16.220526.21566@borland.com> pete@borland.com (Pete Becker) writes:

>In article <83733@ut-emx.uucp> jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
>>Has ANSI decided anything about the expansion of a recursive template
>>definition?

>	template <unsigned n> class Factorial
>	{
>	public:
>		unsigned eval() { return n*Factorial<n-1>.eval(); }
>	};

>	class Factorial<0>
>	{
>	public:
>		unsigned eval() { return 1; }
>	};

>	#include <iostream.h>

>	int main()
>	{
>	Factorial<6> f6;
>	cout << f6.eval() << endl;
>	return 0;
>	}

*****>	Has anyone got a *real* justification for this?  This is a very
	obfuscated way of writing factorial.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: jamshid@emx.cc.utexas.edu (Jamshid Afshar)
Newsgroups: comp.std.c++
Subject: Recursive templates
Date: 16 Nov 92 07:16:12 GMT
Organization: The University of Texas at Austin; Austin, Texas

Has ANSI decided anything about the expansion of a recursive template
definition?  Consider the following class template:

	template<unsigned N>
	class A {
	   int d[N];
	public:
	   A<N-1> operator--() const
	      { return A<N-1>(); }
	   A<N+1> operator++() const
	      { return A<N+1>(); }
	   int& operator[](unsigned i)
	      { return d[i]; }
	};

I agree
	A<0> a0;
should be an error since it results in a 0 length array, but what about
	A<1> a1;
if operator--() is never called on it?  Actually, will the effects of
even compiling code like this be defined, or could a compiler give an
"out of memory" error or crash (btw, BC++ 3.1 gives an error)?  Would
recursion-stopping specializations for A<1> and, say, A<8> make a
difference.  If so would they have to be in any particular order?

	class A<1> {
	public:
	   int d[1];
	public:
	   A<2> operator++() const
	      { return A<2>(); }
	   int& operator[](unsigned i)
	      { return d[i]; }
	};

	class A<8> {
	   int d[8];
	public:
	   A<7> operator--() const
	      { return A<7>(); }
	   int& operator[](unsigned i)
	      { return d[i]; }
	};

I'm hoping ANSI will allow recursive templates.  This would require
that compilers not expand a template function or member function
unless it is actually called.  I'm worried, though, that there are
situations where this is difficult or even impossible.  Has anyone
thought this through?

Thanks, Jamshid Afshar
jamshid@emx.utexas.edu
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Recursive templates
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Tue, 17 Nov 1992 22:53:52 GMT

In <1992Nov17.172152.14255@borland.com> pete@borland.com (Pete Becker) writes:

>In article <Bxu3J4.F93@news.cso.uiuc.edu> pl2440@meibm31.cen.uiuc.edu (Paul Jay Lucas) writes:
>>
>>*****>	Has anyone got a *real* justification for this?  This is a very
>>	obfuscated way of writing factorial.

>	Has anyone got a *real* justification for recursive functions?  They
>just provide a very obfuscated way of writing factorial().

*****>	Some algorithms are naturally recursive; most (other) people
	would agree that factorial is naturally expressed recursively.

>	The point of my original posting was simply that there is no work to
>be done to specify how such things work, because they already work in exactly
>the way you'd expect.

*****>	Huh?  I don't understand that paragraph.

>Whether there are useful things that can be done with
>such constructs is left as an exercise for the reader...

*****>	No, the point is whether it should be mandated that recursive
	templates be part of the standard or not.  If they're trivial to
	implement in compilers, then go ahead; if not, then I think
	justification is in order.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.std.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Recursive templates
Organization: University of Illinois at Urbana-Champaign
Date: Thu, 19 Nov 1992 21:56:27 GMT

In <ALANB.92Nov18175213@catalina.sdl.mdcbbs.com> alanb@sdl.mdcbbs.com (Alan Braggins) writes:

>>>>>> On Tue, 17 Nov 1992 22:46:23 GMT, pjl@cs.uiuc.edu (Paul Lucas) said:

>>>N-dimension matrixes should be possible to base on N-1-dimension matrixes,
>>>with 1-dimensional matrixes (arrays) as the recursion-stopper.

>> *****>	What's a 5x3 matrix based on?  4x2, 3x1, 2x(oops!).

>Dimension. Not size.  NxNxN is based on NxN is based on N was
>specified as the recursion-stopper.

	A misread on my part.  I'm still not convinced that recursive
	templates are anything but a curiosity.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.std.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Recursive templates
Organization: University of Illinois at Urbana-Champaign
Date: Tue, 17 Nov 1992 22:46:23 GMT

In <5225@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:

>pl2440@meibm31.cen.uiuc.edu (Paul Jay Lucas) writes:
>: In <1992Nov16.220526.21566@borland.com> pete@borland.com (Pete Becker) writes:
>: 
>: >In article <83733@ut-emx.uucp> jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
>: >>Has ANSI decided anything about the expansion of a recursive template
>: >>definition?
>: 
>: >	template <unsigned n> class Factorial
>: >	{
>: >	public:
>: >		unsigned eval() { return n*Factorial<n-1>.eval(); }
>: >	};
>: 
>: >	class Factorial<0>
>: >	{
>: >	public:
>: >		unsigned eval() { return 1; }
>: >	};
>: 
>: >	#include <iostream.h>
>: 
>: >	int main()
>: >	{
>: >	Factorial<6> f6;
>: >	cout << f6.eval() << endl;
>: >	return 0;
>: >	}
>: 
>: *****>	Has anyone got a *real* justification for this?  This is a very
>: 	obfuscated way of writing factorial.

>You should be able to base binary trees on unary trees (which are degenerate
>trees more commonly known as linked lists), trinary trees could be
>based on binary trees, and n-ary trees could be based on (n-1)-ary trees.

*****>	I'm not convinced.  List, or unary trees as you call them, serve
	different purposes than do binary trees.  A List class would
	have "list-type" operations on it; a BinaryTree class could have
	LeftChild() and RightChild() functions and wouldn't have
	list-type operations.
	
	Anyway, a Tree<class T,int noOfChildren> class can be
	implemented nicely without recursive templates; I don't see that
	the recursive definition buys you anything.

>N-dimension matrixes should be possible to base on N-1-dimension matrixes,
>with 1-dimensional matrixes (arrays) as the recursion-stopper.

*****>	What's a 5x3 matrix based on?  4x2, 3x1, 2x(oops!).
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: alx@network.msk.su (Frygin Alexander)
Newsgroups: comp.std.c++
Subject: Compatibility of TS JPI with libraries of other firms
Date: Tue, 17 Nov 92 13:19:27 +0200
Distribution: world
Organization: Computer NetWork Design, Ltd
Reply-To: alx@network.msk.su
Keywords: TS JPI, Microsoft, Zortec, Borland, library

      In  the  documentation on  TS  JPI   C++  3.01  is written, that it's
possible to use libraries  of firms Microsoft, Borland  or  Zortec, because
they are compatible on object code.  But in  my practice  I can't  realised
this possibility (different public name). How can I do it?

Thank you,
--- 
 ####      Alexander V. Frygin      #  ####################################
#      Computer Network Design Ltd. ## #     113186 Moscow Russia      #   #
#           alx@network.msk.su      # ##    Nagornaya St. 34 bld.2     #   #
 ####################################  # fone/fax +7-095-127-1945/7990 ####


Newsgroups: comp.std.c++
From: pete@borland.com (Pete Becker)
Subject: Re: Recursive templates
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Mon, 16 Nov 1992 22:05:26 GMT

In article <83733@ut-emx.uucp> jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
>Has ANSI decided anything about the expansion of a recursive template
>definition?

	template <unsigned n> class Factorial
	{
	public:
		unsigned eval() { return n*Factorial<n-1>.eval(); }
	};

	class Factorial<0>
	{
	public:
		unsigned eval() { return 1; }
	};

	#include <iostream.h>

	int main()
	{
	Factorial<6> f6;
	cout << f6.eval() << endl;
	return 0;
	}

	That's from memory, so I may have some of the details wrong, but it
worked in BC 3.0, and from discussions I've had the same sort of thing works
with cfront.
	-- Pete



Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: return values and destructors
Date: 17 Nov 92 20:46:40 GMT
Organization: Microsoft Corporation

In article <BxMxxB.CMp@scd.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
|There is also a similar potential problem with exceptions and throw
|statements; what happens if the value of the thrown object is affected
|by the destructors executed due to stack unwinding before the throw
|actually occurs?

I still believe you're being confused by a compiler bug.  Can you quote
ARM to support your position?  Seems clear to me that a throw expression
has to be evaluated in scope, which means it must be evaluated before
the destructors, since destructors occurs on exiting scope.  Once the
throw expression has been evaluated, the throw object *has* its value, 
and the destructors can do what they want without affecting its value.

Likewise on return values.  The return expression must be evaluated in
scope which means it must be evaluated before the dtors so it must already
*have* its value by the time scope is exited and dtors are executed.
If the return object tries to get its value after dtoring its a compiler bug,
since the dtoring implies scope has already been exited so then how could
the return expression be being evaluated in scope?

Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Must an object remain in place? (was: fwrite+fread of pointer)
Organization: SoftQuad Inc., Toronto, Canada
Date: Sat, 21 Nov 92 11:02:26 GMT

> Well, examine the *as if* rule.  I think a run-time system is able to
> move data under the proviso that it is able to identify all pointers
> and update them accordingly; even if they are stored in non-pointer type
> variables.  (I know of one Algol 68 garbage collector that did just that,
> but it cheated.  On a tagged architecture it would certainly be possible.)

In theory maybe, but not in practice.   Consider that you can transform
a pointer to a character string with "%p" in sprintf(), do arbitrarily
complex operations on the characters which end up reproducing the same
string, then use "%p" in sscanf() to reconstruct the pointer, and the
result must compare equal to the original pointer.

If the "as if" rule is used to make objects movable, then I think it has
to be done by a scheme with an extra level of indirection, such as the one
I outlined in my previous posting in this subthread.  In that scheme,
the thing accessed by %p would not be the real pointer but a pointer
to it, and the real pointer would be free to change.


> The questions answered are different from the question what happens if you
> write a pointer to file and read it back in.

Since it's agreed that the writing and reading does not change the bits,
I think it is all equivalent.
-- 
Mark Brader			"People with whole brains, however, dispute
SoftQuad Inc., Toronto		 this claim, and are generally more articulate
utzoo!sq!msb, msb@sq.com	 in expressing their views."	-- Gary Larson

This article is in the public domain.