HDTenEightyP/NetNews huggingface dataset:
From: porum@county.oz.au (Peter Orum)
Subject: Indirect container classes
Organization: County NatWest, Sydney
Date: Sun, 20 Dec 92 23:20:25 GMT

Could someone advise on what is the best method of
having a collection of pointers to large objects. The
large objects may appear on more than one list, but I
only want one instance of each object  to be created.

	a)	a list of pointers, eg List<String *>
	
	b)	a list class that assumes its  data are pointers
		eg Indirect_List<String *>
		
	c)  use List<String>, but class String is implemented using
		a pointer to a reference-counted String_rep.
		
To  me,  method  a)  is  the easiest to implement but you lose
the  ability  to  test  for  list  membership  by  content, as
comparison is on absolute memory addresses.

Method  b)  has  the  disadvantage  of (slightly) complicating
the   List   class, requiring  overloading  of  the  comparison
operators, search & copy functions.

Method  c)  complicates the class definition, but means in the
client  code  I  don't have to decide on which type of List to
use, nor whether to use pointers or objects.

What do other people do? 

Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: & of inline functions
Organization: TauMetric Corporation
Date: Wed, 16 Dec 1992 18:18:07 GMT

dgrammel@dgrammel.mentorg.com (Dave Grammel) writes:

>In article <1992Dec13.185310.20140@math.ufl.edu>, x9999bvj@maple.circa.ufl.edu writes:
>|> 
>|> What is the official method for handling taking the address of an inline
>|> function?

>Don't make it inline.

Nonsense.  An inline function is just a function.  You take its address
in exactly the same way as you would any function of its type.
Examples:

	inline int ordinary(int i) { return i; }

	int (*fp)(int) = ordinary;

	class X {
	public:
	    int member(int i) { return i; } // inline
	};

	int (X::*mfp)(int) = &X::member;

In such cases, the compiler will create a callable version of the
inline function for you, and use that address.  You could then have
both inline and non-inline uses of the function in the same program.
Continuing the previous examples:

	foo()
	{
	    int j = ordinary(3);	// expanded inline
	    int k = fp(4);		// called via the pointer
	    ...
	}
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: TRY ... FINALLY
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 19 Dec 1992 18:09:21 GMT

In article <MCGRANT.92Dec18050954@rascals.stanford.edu> mcgrant@rascals.stanford.edu (Michael C. Grant) writes:
>In article <1992Dec18.094624.28329@us-es.sel.de>
>reindorf@us-es.sel.de (Charles Reindorf) writes:
>
>   I have actually seen a post, I think on this newsgroup, concerning the equivalent
>   to Modula 3's TRY ... FINALLY clause. (This is exception handling related)
>
>   If you have :
>      TRY
>         statements1
>      FINALLY
>         statements2
>      END
>
>   "statements1" gets executed follwed by "statements2" but, if an exception
>   gets raised executing "statements1" then "statements2" gets executed before
>   re-throwing.  

>Yep, it's also called unwind-protect in lisp dialects... and it makes sense
>to call it that, because after FINALLY are PROTECTED statements in that
>they are executed when the stack is UNWOUND, even for non-local exits.
>
>I suppose it could be simulated by creating a local automatic version of
>a class containing as its destructor any 'statement2' you wish. But, the
>downside is that any variable it accesses must be enclosed inside that
>class. Too bad.
>
	You can fix this by making the function a member of the object.
In fact, it can be made the constructor of the object.
The destructor body has access to
all the local variables of the function then, because those
local variables are just data member of the object.

	Interestingly, the Cecil language doesn't have many
control structures, instead it is designed in such a way that
you can implement your own control structures easily using objects.
(Cecil is prototype based, which makes inventing your own
control structures 'on the fly' easy).

-- 
;----------------------------------------------------------------------
        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.lang.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Standard library functions and macros
Date: Fri, 18 Dec 1992 01:40:48 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

jimad@microsoft.com (Jim Adcock) writes:
|Verses it would be nice to be able to port C code to C++ without having
|to rewrite the whole da*ned thing.  My concern is that I am seeing people
|*trying* to port C to C++ and having a hellish time of it.

Hmmm.  My one experience at porting C code (about 80,000 lines of it,
if I remember correctly) to C++ went quite smoothly.  Different cases,
different experiences.


Suppose the C++ standard said that standard library functions must
have external linkage, and prohibited implementing them as macros.
Would this change the meaning of any C programs if compiled as C++?

Under this rule, it would still be possible (even easy) for compilers
to substitute inline code for most calls to certain library
functions.  For example, <strings.h> might contain

   size_t strlen(const char* p);

   inline size_t __strlen(const char* p) {
      size_t n = 0;
      while (*p++) n++;
      return n;
   }

The only extra knowledge this would require in the compiler is some
way to know that calls to strlen could be replaced by calls to
__strlen.

(This is just meant as an easy way for compilers to inline calls.
In practice, I suspect many compiler writes might embed the
knowledge of how to generate inline code for some functions
directly in the compiler, without using tricks such as the above.)


|I'm seeing though.  Further, the proposed
|changes take away the ability to selectively decide whether a std library
|should be implemented in one's code via a function call, or an inline
|[albeit macro] expansion, without giving programmers an equivalent functionality

Do they?

As Steve Clamage pointed out, you can call the function through a
function pointer; this will probably cause the compiler to
generate a true function call.

Going the other way, if the _implementation_ is prohibited from
making putchar a macro, the _programmer_ should be permitted to
make putchar a macro.  So the programmer who wants to force
inline code for putchar can simply write the macro.  A particular
implementation might choose to make this easier by providing
a __putchar macro so the programmer could write

   #define putchar(c) __putchar(c)

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
From: andy@federation.gatech.edu (Andy Register)
Newsgroups: comp.lang.c++
Subject: Re: Survey: File Extension
Date: 11 Dec 92 22:58:55 GMT
Organization: CERL-EE, Georgia Institue of Technology

In article <1gb1h0INNle2@tsavo.hks.com> webb@hks.com writes:
 >I have a survey question for you all:
 >
 >	What extension do you believe is correct for C++ source code?
 >	Is a clear majority winner emerging?  The contenders are: .C, .c
 >	and .cxx. 

don't forget .cpp for all us borland users.

Toodles
Andy
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Give me safe C++
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 19 Dec 1992 17:51:11 GMT

In article <HF.92Dec18115942@whyaduck.tk.telematik.informatik.uni-karlsruhe.de> hf@tk.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) writes:
>In article <1992Dec17.192301.23525@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>> Anyone else for nested functions? Against?
>
>I agree that they are sometimes quite handy, but I've never missed
>them. In the old days when I was a Modula-2 addict, I used them most
>of the time in a situation where I needed a function call in a
>specific context (which in turn can be expressed as a kind of
>"state"), and this is exactly what objects are for.
>
	You are perfectly correct that nested functions can be replaced
by members if one rewrites huge hunks of code.  

	It is also possible to just use an ordinary function in many cases, 
and pass it lots of parameters.

	Your argument is also one that would disallow all nested blocks. 

	In the spirit of your argument, I suggest that functions
not be allowed to have more than one parameter,
or more than one local variable.
If somehow this seems to leave you with an object that is just
a subtly hidden subspace of 'global' data, you would be
correct.

	While I'm definitely not a structured programming fan,
there are times when functional decomposition is appropriate,
and data decomposition is not.

	Especially considering the C++ is not just an OO language,
there are times when nested functions are far and away superior
to using objects, and others when objects are more correct
but its just too much work to bother.

	In any case, I'd like the choice. While developing
a parser recently the function got too big to read,
I wanted to decompose it. Because of the amount of context,
I was *forced* to rewrite it in terms of objects.

	The rewrite took LONGER to do than the original code
took to develop, and it still doesnt work properly.
Yes, it is now much easier to manage, but nested functions would
have provided a better transition from procedural code
to object oriented code. In particular I have been forced
to bind my data structures and interfaces prematurely
into classes when I actually wanted rapid prototyping.

	CLOS as I understand it IMPLEMENTS OO by nested
functions, the object IS the local activation record,
the nested functions ARE the members of that record,
and the object persists because of Garbage Collection.

	Perhaps the moral of this story is that there is more
than one way to do OO, and more than one way to write a program,
C++ is supposedly a hybrid language, and often C is said
to be block structured. I just wish this were true, so
I'm repeating my call for the artifical restriction against
nested functions to be removed.
-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: arthur@turing.ac.uk (Arthur van Hoff)
Newsgroups: comp.lang.c++
Subject: Re: Survey: File Extension
Date: 18 Dec 92 11:19:20 GMT
	<stanleyr.724172017@kramden> <Bz80Bu.HI4@knot.ccs.queensu.ca>
Organization: The Turing Institute Ltd., Glasgow, Scotland


Hi,

In article <Bz80Bu.HI4@knot.ccs.queensu.ca> kirkwood@qucis.queensu.ca
(Scott Kirkwood) writes:
>  BTW: these are the extensions I've come across: .C, .c, .cxx,
>  .cp (Macintosh), .cpp, .cc, .c++, .C++, .h, .H, and .hxx (off the top
>  of my head).

The "Rules and Recommendations" document for programming in C++ by
Mats Henricson and Erik Nyquist of Ellemtel states that .hh should
be used for headerfiles, .icc for files that contain inline methods
and .cc for other source files.

The .icc extentions seems to be missing from your list. A special extention
for files that contain inline code is useful so that you can write the
following to handle inline methods (from the above mentioned document):

// AnyClass.hh
#ifndef OUTLINE
#include "AnyClass.icc"
#endif

// AnyClass.cc
#ifdef OUTLINE
#define inline
#include "AnyClass.icc"
#undef inline
#endif

	Arthur van Hoff (arhtur@turing.com)
--

	Arthur van Hoff 
	The Turing Institute Limited
	36 North Hanover Street, 
	G1 2AD Glasgow, Scotland

	Tel: +44 41 552 8858 or +44 41 552 6400
	Fax: +44 41 552 2985
	Email: arthur@turing.com

	The opinions expressed in this message are not 
	necessarily those of The Turing Institute Limited.
From: cbarber@bbn.com (Chris Barber)
Newsgroups: comp.lang.c++
Subject: C++ Compilers for Sparc?
Date: 14 Dec 92 21:51:49 GMT
Organization: BBN Systems and Technology, Inc.

What C++ compilers are available for Sun's Sparcstation
platform?

Template support is important and exceptions would be nice.

Phone numbers and/or e-mail addresses of vendors would
also be appreciated.

Please e-mail me and I will summarize to the net.

Thanks in advance....
-- 
Christopher Barber
(cbarber@bbn.com)
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Complex Addition.
Organization: University of Illinois at Urbana-Champaign
Date: Fri, 11 Dec 1992 18:42:59 GMT

In <1992Dec11.170849.18525@rs6000.bham.ac.uk> pickerig@eee.bham.ac.uk (Guy Pickering) writes:

>In ARM, the code for the `+` operator for the complex class is given as:

>inline complex operator+(complex a, complex b)
>{
>  return complex(a.re+b.re,a.im+b.im)
>}

>In general, can I create an instance of a class in a member function and
>return the object?

*****>	Yes.

>Doesn't the complex object go out of scope?

*****>	It's not in the scope of the function; it's in a temporary for
	the return-value of the function that gets destroyed sometime
	thereafter.

>Could I do this:

>SomeClass operator<<(SomeClass data, int places)
>{
>  SomeClass temp(data);		// Copy data to temporary object.

>  // manipulate temp internally to perform
>  // the << operation.

>  return temp;
>}

>Would this allow me to write:

>  value1 = value2 << 5;

>If both variables were of type SomeClass?

*****>	Yes, but you don't need 'temp' since 'data' is a copy anyway
	since you aren't passing it by reference.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: schmidt@rz.uni-passau.de (SCHMIDT GUIDO)
Subject: Re: help using BCC with template
Organization: University of Passau - Germany
Distribution: ne
Date: Fri, 18 Dec 1992 11:59:29 GMT

In article <1992Dec16.173251.18550@engage.pko.dec.com> chou@riscee.pko.dec.com (Jesse Chou WSG/SECG) writes:


>This may be a very basic and silly question to ask but I am new to Borland
>c++.  It is greatly appreciated that someone could enlighten me or give me
>pointer to a FAQ.


>I am writing a list class using template and got link error:

>Error: Undefined symbol slist_base::append(slink near*) in module tpc.cpp


>I had a similar error using other c++ compiler and found that I have to use
>a command line switch with the compiler.  I suppose that someone could
>easily point to me what I should do in my makefile.  Or maybe there is
>other problems that I am not aware of.  In any rate, thanks in advance.



>Jesse



>-- 
>Jesse Chou     -- chou@riscee.enet.dec.com

>These words are entered into net by the keyboard.
>I am not responsible for them; neither is my employer.

When putting implementation code of a template class into a .cpp file you
must specify "global" template creation. You can do this by switching a
button in the dialog box Options/Compiler/CodeGeneration/Templates or with
bcc by using the correct /JE option (see help for the right one).

Guido.
--------------------------------------------------------------------
- Guido Schmidt                                                    -
- schmidt%rz@tcpgw1.uni-passau.de       <---- Please note          -
--------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: IS C++ a language for the "average programmer"
Organization: Rational
Date: Thu, 17 Dec 1992 22:08:33 GMT

sam4628@zeus.tamu.edu writes:

|In article <rmartin.724431509@thor>, rmartin@thor.Rational.COM (Bob Martin) writes...
|..
|> 
|>This is not a new idea.  Calculus is more complex than algebra.  Yet,
|>once learned, it alows a whole new ream of concepts to be conveniently
|>expressed.  


|Yes, but does OO _really_ allow you to tackle a more complex problem?
|Or does it just allow you a new "notation" which is conveniently adapted
|to the more complex type of problems?  

No, it really allows you to tackle a more complex problem.  This is
because of the paradigm has more expressive power than procedural
programming does.  

|I've never heard of a programming
|goal which absolutely required OO to achieve it -- however, there are
|a large number of math problems which algebra just cannot solve, no
|matter how you manipulate it (assuming, of course, that you don't start
|making simplifying assumptions/approximations).

I don't want to push the analogy too far.  Granted there are no
applications that _require_ OO.  but OO makes most applications easier
to express.   One could also say that every application could be
programmed in binary.  But we don't do it because a compiler makes the
problem easier to express.  You get the same kind of leverage from OO.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: mcgrant@rascals.stanford.edu (Michael C. Grant)
Subject: Re: TRY ... FINALLY
Organization: Information Systems Laboratory, Stanford University
Date: 18 Dec 92 05:09:54

In article <1992Dec18.094624.28329@us-es.sel.de>
reindorf@us-es.sel.de (Charles Reindorf) writes:

   I have actually seen a post, I think on this newsgroup, concerning the equivalent
   to Modula 3's TRY ... FINALLY clause. (This is exception handling related)

   If you have :
      TRY
         statements1
      FINALLY
         statements2
      END

   "statements1" gets executed follwed by "statements2" but, if an exception
   gets raised executing "statements1" then "statements2" gets executed before
   re-throwing.  
   The important point here is that ANY exit from the TRY
   block results in "statements2" being executed, this includes the equivalent
   of returns, branches, break, continue, and normal exit from the loop. It is
   therefore *not* equivalent to the C++ example ...

Yep, it's also called unwind-protect in lisp dialects... and it makes sense
to call it that, because after FINALLY are PROTECTED statements in that
they are executed when the stack is UNWOUND, even for non-local exits.

I suppose it could be simulated by creating a local automatic version of
a class containing as its destructor any 'statement2' you wish. But, the
downside is that any variable it accesses must be enclosed inside that
class. Too bad.

Michael C. Grant
--
"Long hair, short hair--what's the difference once the head's blowed off?" (?)
From: robison1@husc10.harvard.edu (Keith Robison)
Newsgroups: comp.lang.c++
Subject: Re: Overriding the order of constructors?
Keywords: constructor ordering
Date: 14 Dec 92 04:29:03 GMT

dembo@csri.toronto.edu (Prof. Ron Dembo) writes:



>What is the rational for not allowing a programmer to override the
>default calling order of constructors and initializers?  I see
>the importance of having a well defined default.  However, why
>shouldn't the ordering of the initilizers be significant?  


	I believe you can effectively accomplish this dangerous
goal by calling virtual functions in your constructors:


class A {
  A() { reroute(); do_A_ctor_stuff(); }
  virtual void reroute(); { }
}

class B : public A {
  B() {}
  void reroute ()  { do_B_ctor_stuff(); }
}


This will cause B's reroute() to be executed before any 
A constructing has occurred.


Keith Robison
Harvard University
Department of Cellular & Developmental Biology
Department of Genetics / HHMI

robison@biosun.harvard.edu 
Newsgroups: comp.lang.c++
From: krc@wam.umd.edu (Kevin R. Coombes)
Subject: Re: static members in derived classes
Organization: University of Maryland, College Park
Date: Tue, 15 Dec 1992 15:06:12 GMT

In article <1992Dec14.215407.21631@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <1992Dec12.175244.17775@taumet.com> steve@taumet.com (Steve Clamage) writes:
>|"Virtual static" has been proposed from time to time.  I don't know of
>|any technical objections to it.  There are lots of good ideas for
>|extensions to C++.  The question is always one of evaluating the costs
>|and benefits of any proposed extension.
>
>The technical argument against it is that the same capability can be
>implementing using virtual functions.  If the complaint is that virtual
>functions are too slow to implement "virtual statics" then the counter-
>reply is that compilers can use a fat table implementation [or other
>implementation] instead of the common vtable implementation in order 
>to reduce the cost of the virtual function call in these cases.
>
The article to which Steve Clamage replied (and I wrote) pointed out that
the same capability could be achieved using virtual functions. I did not
object to the speed; I objected to the fact that this approach was
tedious and error-prone. In each derived class where I wanted to add
a different "virtual static" member, I had to add a new static member
and add the virtual functions to manipulate it. And besides, it looks
ugly.

Is it really the case that the only objection is that it can already be 
achieved using existing techniques?

>Going the opposite direction people who propose "virtual static" do so
>on the basis of an assumed vtable implementation of virtual functions.
>In which case including "virtual static" begins to dictate one implementation
>over other potentially faster implementations, which is not a good thing
>to do.  Language should specify language, not dictate implementation.
>

I don't see how it follows that allowing "virtual static" data dictates
a particular implementation. Certainly, language definitions should not
restrict implementations unnecessarily. However, I think of "virtual
static" data as completing the following picture: Member functions belong
to the class; data members belong to individual objects. Things that
belong to the class can be delegated to derived classes by calling them
"virtual". Things that belong to individual objects don't need to be
made virtual, because they can have their own values anywhere you need
them. Static data members, on the other hand, are neither here nor there.
They belong to the class, but you cannot vary them in derived classes.

Kevin Coombes <krc@math.umd.edu>
From: rogerl@Minsk.docs.uu.se (Roger Lundberg)
Newsgroups: comp.lang.c++
Subject: Bug in BC/C++ 2.0 ?
Date: 18 Dec 92 17:21:49 GMT
Organization: Uppsala University
NNTP-Posting-Host: minsk.docs.uu.se
Summary: Is this a bug in BC 2.0 ?
Keywords: bugs


I recently bought a copy of Borland C/C++ v. 2.0 (I know it's a bit old, but I
got for a decent price :-). So I thought I would try it out with a small prog
that I copied from Stroustrups "The C++ Programming Language" 2nd ed. The prog
was the "class string" example. But BC wouldn't compile ? It barfed at all 
constructs of the following type.


String::~String() {
  if ( --p->n == 0) {
    delete[] p->s;
/*          ^^^^^ Here does the compiler barf */
    delete p;
  }
}


It gave an error message indicating that it interpreted the "->" construct as
a minus sign "-" followed by garbage. Is this a bug in BC 2.0 or is the example
in the book at fault ???

I have used the same example with gcc with no problems at all.

	/Roger



--
Roger Lundberg
E-Mail: rogerl@Minsk.DoCS.UU.SE
Tel.: +46 (0)18-460346
Mail: Sernanders v. 8-512 , S-75261 Uppsala , Sweden