HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: static "inheritance" question
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 11 Jan 1993 05:19:53 GMT

In article <86431@ut-emx.uucp> jamshid@emx.utexas.edu writes:
>I quote a few different articles below -- watch the attrib lines.
>
>In article <1993Jan4.144320.5586@dayfac.cdc.com> pault@dayfac.cdc.com (Paul Thompson;DAYFAC-ITS;) writes:
>>Consider class A which counts its 'live' instantiations.
>
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) answers in article <1993Jan5.051940.28930@ucc.su.OZ.AU>
>|	IF: you want to count all objects allocated (of any type):
>|
>|	Sure: two type of class: base classes and working 
>|classes. The base classes NEVER inherit A.
>|The working classes inherit from A when you want a counter.
>|It is not allowed to derive from a working class though.
>|[code deleted]
>
>Not allowing one to derive from the "working" class is too serious a
>restriction, IMHO.

	Not if you follow the paradigm consistently.
The "working" classes will always be derived 'at the last minute'
and preferably anonymously.

	For each class A, you have a class workA. If you want
to derive from 'workA' dont-just derive from 'A'. I cant
see any restriction here, just boring typing maintaining
two sets of classes. 
>|
>|	class Counter {
>|		virtual int* counter()=0;
>|	public:
>|		Counter() { (*counter())++; }
>|		~Counter() { (*counter())--; }
>|		int TellCount()const {return *counter();}
>|	};
>
>Famous last words :-).  I do agree it would be a yucky solution, but
>fortunately it just doesn't work.  The Counter ctor/dtor are calling
>a virtual function (and a pure one at that) -- make sure your
>compiler sternly warns about this.

	You're right!
>
>      class A : public KeyCount<A> {/*...*/};
>
>That's it.  Comments?  

	It doesnt work :-)

	class A : public KeyCount<A> { ... }
	class Z : public A, public Keycount<Z>
	{
		A a;
	};
	Z z;
	A a;

There is one 'A' object and one 'Z' object agree?

But the counts show:

	Z==1; // correct
	A==3; // woops!

To get this right one can follow a strict paradigm:

	class workA : public A, public KeyCount<A> {};
	workA a;
	class Z : public A { A a; };
	class workZ : public Z, public KeyCount<Z> {};
	workZ z;

	// always allocate a 'work' class to construct a whole
	// object
	// never contain or derive from this class

Counts are now: A==1, Z==1. Correct.

	
-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: peju@alice.att.com (Peter Juhl)
Newsgroups: comp.lang.c++
Subject: Re: feedback wanted on appropriate OOPL
Date: 12 Jan 93 15:57:11 GMT
Article-I.D.: alice.24596
Organization: AT&T Bell Laboratories, Murray Hill NJ




In a previous article, ac690@cleveland.Freenet.Edu (Edward Klimas) says:

>	The message at OOPSLA-92 from two separate experience reports
>	was that Smalltalk was possibly as much as an order of
>	magnitude better than C/C++ in terms of quality of the resulting
>	code.

``was possibly''?

This is a fine example of the level of debate in this group.  The
experience reports in question described systems implemented in
Smalltalk. No parallel system had been implemented in C++, so how
could anybody draw such a conclussion? Further, no such conclusion
were mentioned at the time by the people giving the experience reports.

What WAS said in one of the reports was that Smalltalk was chosen 
because it had a better programming environment at the time. 

Futhermore, you completely fail to mention the experience paper
pp 178-183 in the proceedings giving error statistics for a large
C++ project, Rational Rose. 

--- peter (peju@research.att.com)

Newsgroups: comp.lang.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Standard library functions and macros
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Thu, 7 Jan 93 04:21:21 GMT

I am going to respond to a few of the technical points.  


jss:
|> |For example, in C++ modes our headers contain (after expansion of
|> |some macros that allow us to control variation between compilation modes)
|> |
|> |    typedef void (*__sigtype)(int);
|> |    typedef void (*__alt_sigtype)(int,int,struct sigcontext*,char*);
|> |
|> |    /* The C standard declaration */
|> |    extern "C" __sigtype signal(int,__sigtype) ;
|> |
|> |    /* A variant expected by Sun programmers */
|> |    extern "C++" inline __alt_sigtype signal(int __sig,  __alt_sigtype __h) {
|> |        return (__alt_sigtype)signal( __sig, (__sigtype)__h) ;
|> |    }
|> 

jimad:
|> Seems to me that an inline call such as this requires a stub, either in
|> the library, or compile-time generated, if the programmer does anything
|> that prevents inline expansion of the inline function.

If I call the "alt" version

	void handler(int,int,sigcontext*, char*) ;
	...
	signal(0,handler) ;

The compiler generates a direct call to the C function. No stub
is layed down.  If I do something that requires a function pointer
[Sorry I'm using the types, but it's too confusing otherwise]

	__alt_sigtype (*paltsig)(int, __alt_sigtype)) = signal ;

A (static) stub is created.  

jimad:	
|>   And such control
|> over inline expansion is precisely the control permitted deliberately
|> and explicitly in the base doc -- the ANSI-C base doc.

You keep saying this, but you don't explain how you arrive at that
conclusion.  What the C standard allows is being sure that a
macro isn't in scope.  It does not let you control whether the standard
functions are inlined. 

jss:
|> |The extern "C" variant gets linked directly to Sun's C library
|> |without any problems. We don't need stubs.
|> 
jimad:
|> What happens when you take a type-correct pointer to the above function,
|> for example, and invoke via that pointer?  I'd think you'd get a stub
|> generated -- ie the compiler lays down an out-of-line function to implement
|> the alt signal function.
|> 

I explicitly refered to the extern "C" variant.  

	__sigtype (*psig)(int,__sigtype) = signal ;
	(*psig)(0,(__sigtype)0) ;

The value stored in psig is a pointer into the C library,
and a call is made directly to that function in the second line.
Most of the standard library functions would not have variants.

  -- Jerry Schwarz
From: hlf@nic.cerf.net (Howard Ferguson)
Newsgroups: comp.lang.c++
Subject: Re: Restatement and clarification of "static inheritance" question
Keywords: inheritance
Date: 10 Jan 93 18:16:24 GMT
Article-I.D.: news.1ipp5oINNg0e
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net

In article <1993Jan9.154850.5939@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>In article <1ikg2tINN2d3@news.cerf.net> hlf@nic.cerf.net (Howard Ferguson) writes:
>>>>WHAT I AM INTERESTED IN IS THE FUNCTIONALITY OF "COUNTING ONE'S
>>>>OWN INSTATIATIONS", NOT COUNTING THE TOTALITY OF ALL INSTATIATIONS OF
>>>>CLASS A. 
 -- stuff deleted --
>>
>>I still do not see a reason for inheritance when containment will do.
>>Can anybody clarify this???
>>
>
>	Sure. If you use containment you end up counting
>subobjects of the base classes too:
>
>	class X { A<X> ax; };
>	class Y { A<Y> ay; };
>	class Z { A<Z> az; };
>
>	Z z;
>
>// WOOPS: now we count 1 Z (correct) and 1 X and 1 Y (wrong)

Have you missunderstood, and thought that there is only one static
created for all of the A's. (I think) you are wrong here. The template
semantics create one static for each class and A<X> is a different class
from A<Y> so thge result would be 1 Z , zero X's, and zero Y's.

( Again I do not have a templating compiler yet so somebody please
correct me if I am wrong on this one.)

	hlf
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: varargs
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Mon, 11 Jan 1993 19:52:12 +0000

In article <1993Jan10.193617.5871@news.acns.nwu.edu> ecm@casbah.acns.nwu.edu (Edward Malthouse) writes:
> I am trying to write a function error which will will be declared as follows:
> error(va_list)
> 
> The usage will be
> error(char *format, arg_list)

Do you have some kind of problem with stdarg.h ? This is the standard 
method of doing variable argument lists, not the old varargs stuff.

#include <stdarg.h>

error(char *format, ...)
{
	va_list args;

	va_start(args, format);
	vfprintf(stderr, format, args);
	va_end(args);
	cleanup();
	exit(1);
}

I expect that, even with the old varargs stuff, you need to call vfprintf,
not fprintf. I am rather suspicious of your function declaration, also.

-- 
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
From: hlf@nic.cerf.net (Howard Ferguson)
Newsgroups: comp.lang.c++
Subject: Callbacks in C++
Date: 8 Jan 1993 01:11:58 GMT
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net
Summary: How should a class library accept and use callbacks

The FAQ for this group describes how to put wrapper functions around 
member functions so they can be called as callbacks from X libraries
and the like. But if I am writting a c++ class library, surley I should
be able to provide a cleaner mechanism to my customers. Is there
a standard way of doing this???

	ta,
		hlf
Newsgroups: comp.lang.c++
From: glw@io.it.uswc.uswest.com (Glenn Williams)
Subject: Re: C++ coding style guide??
Organization: U S WEST Communications
Distribution: usa
Date: Fri, 8 Jan 1993 16:56:53 GMT

We are looking at C++ Programming Guidelines by Plum and Saks. Its published by Plum Hall.

glenn williams
US WEST
Newsgroups: comp.lang.c++
From: suresh@argon.iss.nus.sg (Suresh Thennarangam - Research Scholar)
Subject: Re: Passing 2-d arrys to functions
Reply-To: suresh@iss.nus.sg (Suresh Thennarangam - Research Scholar)
Organization: Institute Of Systems Science, NUS
Date: Mon, 11 Jan 1993 03:02:38 GMT

In article <RUNE.93Jan10125255@pandora.nta.no> rune@nta.no (Rune Henning Johansen FBA) writes:
>In article <726521188snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
>
>  >  For a two (or more) dimensional array, to access element [m][n], the 
>  >  compiler needs to know the address of the first element, the size of each 
>  >  element, and the number of elements in the least significant dimension. 
>  >  The calculation for an array declared [DIM1][DIM2] is 
>  >  ((m * DIM2 + n) * sizeof(element)).
>
>I'm including a little program that seems to work fine. Here I'm pas-
>sing only the pointer to  a two dimensional array.  Can I expect such
>programs to work, and if so, why?
>
> - Rune
>
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
>
>#include <stream.h>
>
>#define begin {
>#define end   }
>
>void Input ( double **b )
>begin
>    b[0][0] = 1.0;
>    b[1][0] = 2.0;
>    b[0][1] = 3.0;
>    b[1][1] = 4.0;
>end
>
>void Output ( double **b )
>begin
>    cout << b[0][0] << "\n";
>    cout << b[1][0] << "\n";
>    cout << b[0][1] << "\n";
>    cout << b[1][1] << "\n";
>end
>
>int main ()
>begin
>    double **a = new double*[2];
>    a[0] = new double[2];
>    a[1] = new double[2];
>
>    Input  ( a );
>    Output ( a );
>
>    delete a[0];
>    delete a[1];
>    delete a;
>
>    return 0;
>end

Yes, I think this program will work always .. since you have passed in 
a double ** pointer which is a vector of double*, the least dimension
of the array is not required to correctly index the values.
Although the same syntax can be used to access 2-d arrays (no flames
please .. I mean statically allocated as in double arr[2][2] ) and
variables of type pointer to pointer ( double **), the underlying memory 
layout need not be the same. However, the algorithm used to index either
one is the same.. pointer arithmetic. 

I believe( correct me if I am wrong) most or all C/C++ compilers always
use the same pointer arithmetic no matter whether the array passed 
is declared as  double arr[][least_dim]  or  double **. This explains
how we can successfully mix pointer arithmetic and array-indexing. 
The last dimension is required merely for setting up storage.
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: Newbie Wants Advice on C-Programming
Date: 5 Jan 93 22:43:11 GMT
Organization: negligable

In article <1993Jan4.091953.29873@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
>Perhaps what is needed is being a skilled programmer and a skilled
>program architect/designer.

And which books would you recommend to start us on the way to
being a skilled software designer?		<g,d,r>


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Did you think it's a joke?		|
Well that's all right, do what 		|	-Richard Hartman
you want to do.				|	hartman@uLogic.COM
I've said my piece, now I 		|
leave it all up to you.			|
From: gcook@horus.cem.msu.EDU (Greg Cook|xxxxxx)
Newsgroups: comp.lang.c++
Subject: HELP with General Protection Fault
Date: 5 Jan 93 17:57:48 GMT
Organization: Michigan State University
NNTP-Posting-Host: horus.cem.msu.edu


I've installed Turbo C++ v 3.0 and am having some problems running 
TC.exe.  First, the mouse does not work well.  I usually have to
click the mouse button 5 or 6 times for it to respond to the mouse.
 
More importantly, most of the time when I quit TC, I get the following
message:
 
EXCEPTION 13:general protection fault at 00B7:2156 error code 035C
             ax=0001,bx=0000,cx=0140,dx=0060,di=00AA,si=002F
             ds=00BF limit=219F segment#
             es=00BF limit=219F segment#
             cs=00B7 limit=22BF segment#
             ss=005B limit=INVL segment#
             error code=035C limit=0483 segment#
 
             strike any key to continue  <I strike a key>
Unhandled exception 000D at 00B7 2156 ErrCode 035C
 
I have no idea what this means.  Can someone shed some light for me?
 
Below is my configuration.
 
Thanks for your help.
 
---Greg
 
486-33 4M RAM
 
----AUTOEXEC.BAT
 
c:\windows\smartdrv.exe 1024 1024
@ECHO OFF
PATH C:\EXCEL;C:\WINWORD;C:\DOS;C:\BIN;C:\BATCH;C:\WINDOWS;C:\WORD\VI;C:\pict\VPIC51;C:\MOUSE;C:\corel;C:\tc\bin;c:\bin\arj
MOUSE 
SET DIRCMD=/p
set TZ=EST6
dosedit alias
teclock t1*C  (an onscreen clock TSR)
prompt $e[s$e[1;1f$e[41m$e[37m                                                       3$d3         $e[1;2f$p$e[m$e[ucook$g$e[37m
 
SET TEMP=C:\DOS
SET FASTBACK=C:\DISkUTIL\FBPLUS
 
----CONFIG.SYS
 
DEVICE=C:\DOS\SETVER.EXE
DEVICE=C:\WINDOWS\HIMEM.SYS
DOS=HIGH
FILES=32
BUFFERS=30
DEVICE=C:\DOS\ANSI.SYS /X
STACKS=9,256
shell=c:\command.com /e:360 /p

     Gregory R. Cook         |  INTERNET:    gcook@horus.cem.msu.edu
 Department of Chemistry     |               cookgreg@student.msu.edu
Michigan State University    |  BITNET:      cook@msucem.BITNET
 East Lansing, MI  48824     |  COMPUSERVE:  74170,3010
From: thomson_n@kosmos.wcc.govt.nz
Newsgroups: comp.lang.c++
Subject: Copying 4D array's
Date: 8 Jan 1993 11:02:23 GMT
Organization: Wellington City Council (Public Access), Wgtn, Nz
Reply-To: thomson_n@kosmos.wcc.govt.nz
NNTP-Posting-Host: kosmos.wcc.govt.nz

 
I've got a problem, which I hope someone on the net can solve for me.
 
I'm new to the C language, but are programming in highc over the summer.
My main problem is the run time of certain parts of my program. 

I am  trying to copy a 4D array to another 4D array and to a 1D array.
 
 
Currently I am simply using a nested for loop.
 
"
 
for(i=0;i<=MAX_BUS;i++)
   for(j=year_req.start;j<=year_req.end;j++)
      for(k=month_req.start;k<=month_req.end;k++)
           for(l=min_isle;l<=max_isle;l++)
 
            graph_data[i][j][k][l] = column_A[i][j][k][l];
 
 
 
"
 
It is not possible, given the rest of the program, to get around copying the
array over, but I really need a faster method of doing this. Currently It's 
running on a digital 433dx workstation.
 
 
The second problem I have, which is much the same as the first, is that I
also need to copy this 4D array to a 1D array. This is done by calling a
function with the arguments of year, month, day, and halfhour. This function
date_to_hh_num returns an integer value, of the number of half hours since
1/1/1960
 
The question here, is again, is there any way to speed up this process?
 
 
for(yr1=year_req.start;yr1<=year_req.end;yr1++)
   yr = yr1-year_req.start;
   for(mo=month_req.start;mo<=month_req.end;mo++)
      for(da=day_req.start;da<=day_req.end;da++)
         for (hh=time_req.start;hh<=time_req.end;hh++) {
              current_hh_num = date_to_hh_num(yr,mo,da,hh);
              graph_data[current_hh_num] = column_A[yr][mo][da][hh];
             }
"
 
 
Thanks in advance :)
 
Replies by email please.
 
 
--
 
+----------------------------------------------------------------------------+
| cheesecake = Nigel Thomson            Email:  THOMSON_N@kosmos.wcc.govt.nz |
|  :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::   |
|          They don't call me cheesecake for nothing                    ::   |
|    :::::)        Chocolate cheesecake with Baileys :)                 ::   |
|    ::                                      *NOT* a Happy Smily Monster::   |
|    :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::   |
+----------------------------------------------------------------------------+
From: ajp@dsl.eng.cam.ac.uk (A. J. Piper)
Newsgroups: comp.lang.c++
Subject: References and Virtual Base Classes
Date: 7 Jan 93 19:54:26 GMT
Organization: Engineering Department, Cambridge University, England.


This is probably an FAQ, but how can I initialise a reference in a virtual base
class ? (excluding the obvious case where MI of it is not used more than once)

email would be helpful

andy
--
Andy Piper					email: ajp@uk.ac.cam.eng
Cambridge University Engineering Department 	tel: +44 223 33 2754
Trumpington St
Cambridge, UK
--
Andy Piper					email: ajp@uk.ac.cam.eng
Cambridge University Engineering Department 	tel: +44 223 33 2754
Trumpington St
Cambridge, UK
Newsgroups: comp.lang.c++
From: ravi@athena.cs.uga.edu (Ravi Vemuri)
Subject: modifying TInputLine to handle integers/ reals etc..need help
Organization: University of Georgia, Athens
Date: Sun, 10 Jan 1993 22:44:27 GMT

This is a novice TVision question.
I am having prbs creating a TInputLine object to handle integers. I overrode
the setdata and getdata functions by incorporating function calls for
string to integer conversion and viceversa. However, there are a few prbs
I could'nt overcome(and hence, works only partly!):
1. my object does not respond to <Enter> key like the parent object does.
2. I didnot override datasize(), but i think i should. however, the manual
does state that the simple str to int and int to str conversions should
suffice.
	I hope I have made myself clear. If any of you out there have some
experience (and am sure there are many), I'll be glad to elaborate on this
inquiry further.
thanx,
ravi
Newsgroups: comp.lang.c++
From: kanze@us-es.sel.de (James Kanze)
Subject: Re: Is it possible to use 'delete this' ?
Organization: SEL
	<C000qE.D3J@comp.vuw.ac.nz> <rmartin.726675168@thor>
Date: 12 Jan 93 15:30:48

In article <rmartin.726675168@thor> rmartin@thor.Rational.COM (Bob
Martin) writes:

|> robertd@kauri.vuw.ac.nz (Robert Davies) writes:

|> |The problem I had with Bob's first reply was that he didn't answer the
|> |question: is "delete this" legal.

|> To my knowledge, the syntax is legal.  (Steve Clamage:  Can you
|> comment on legality?)

|> |Then it would be appropriate to give a warning. Incidentally, is the warning
|> |about is causing difficulty to some compilers just a "gut feeling" or are
|> |there specific examples?

|> No specific examples.  I give the warning because I have seen no words
|> in the ARM to the effect that the code generated by the compiler must
|> assume that the object may not exist during a member function call.

|> |Bob's warning about "delete this" seems to apply to any use of "delete" by
|> |an entity that didn't do the corresponding "new". Otherwise there is always
|> |the risk that the "delete" will be applied to something not created by
|> |"new". Is this another safe programming rule?

|> No.  And my warning is only about the dangers of "delete this".
|> "delete this" can only be appropriate for objects that are "always"
|> allocated from the heap.  Unfortunately, there is no way for an object
|> to insure this. 

Granted, there is *no* way for an object alone to ensure that it was
allocated on the heap.  But not all classes exist in isolation.  If a
class is declared in the private part of another class, then it can
only be used by the containing class.  In this situation, the author
of the *two* classes *can* control where all of the instances of the
contained class come from, and using "delete this" would seem in this
case to be a reasonable solution.

As a practical example, a tree class contains the definition of its
nodes.  The node class(es) themselves contain a cleanup function,
which calls cleanup on the children, and then delete this.  The
destructor for the tree simply calls cleanup on the root node.  (I
have actually used code like this, and find it quite practical.)

On the other hand, I am very sceptical of using delete this in a class
which is directly accessible to everyone, for the very reason that Bob
states.  If a user can do something, you must program under the
assumption that he will, and if the class is accessable to the user,
he can (and sooner or later will) declare an object of that class on
the stack.  So I would consider it very bad programming style to use
"delete this" in any such class.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Standard library functions and macros
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 5 Jan 1993 05:28:54 GMT

In article <1993Jan04.224604.7304@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>Whether I'm overreacting or not also depends on whether people consider
>it important to get programmers to switch from C to C++.  

	IMHO much less of a problem than getting FORTRAN programmers
to switch to C++. C programmers will switch to C whether they
want to or not:  C-only compilers are likely to just fade away :-)

-- 
;----------------------------------------------------------------------
        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++