HDTenEightyP/NetNews huggingface dataset:
From: jonl%kuwait@lucid.com (Jon L White)
Subject: Re: class variables
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 2 Oct 1992 16:26:52 GMT

Another approach to what are increasingly being called "per-class slots":


   --  set up a metaclass for such classes with this altered inheritance;
	for sake of discussion, call it PER-CLASS-SHARED-SLOTS-CLASS

   --  place a method on ENSURE-CLASS-USING-CLASS specialized to this
	metaclass (i.e. PER-CLASS-SHARED-SLOTS-CLASS) which snoops at
	the :direct-superclasses argument to collect the names of all
	the shared slots from all the supers which are of metaclass
	PER-CLASS-SHARED-SLOTS-CLASS.  Then alter the :direct-slots
	argument to add canonicalized slot specifications for such
	shared slots (see CANONICALIZE-DIRECT-SLOT, which is also
	from AMOP), and then just CALL-NEXT-METHOD.

The trick here is to utilize all the pre-existing machinery of an
implementation's support for shared slots, but to fake-out the 
interface between DEFCLASS and the actual class creation protocol
to make it look like every DEFCLASS form for the new metaclass actually
had a :ALLOCATION :CLASS specification for any inherited shared slot.

So here we are using the metaobject protocol to alter the inheritance
behaviour within an (extended) metaclass.


Refinement:  figure out how to put the method on MAKE-INSTANCE, or
on INITIALIZE-INSTANCE, instead of on ENSURE-CLASS-USING-CLASS.

More refinement: figure out how to collate all the actual direct slot
specifications from the set of all superclasses so as to resolve  _each 
and every potential slot specification_  item in the automatically
generated slot spec list.




-- JonL --
From: cutting@skye.parc.xerox.com (Doug Cutting)
Newsgroups: comp.lang.clos
Subject: Re: class variables
Date: 30 Sep 92 17:22:23 GMT
Article-I.D.: skye.CUTTING.92Sep30102223
Organization: Xerox PARC, Palo Alto, CA

In article <HALTRAET.92Sep30032338@monsun.si.no> haltraet@monsun.si.no (Hallvard Tr{tteberg) writes:
>   (2) that you cannot have something in between class and instance
>       slots, e.g. subclass slots, so that different (sub)classes can
>       have different class slot values, while all instances of a
>       subclass have share the same value.
> 
> (I just found out that if a class slot is mentioned in a subclass
> definition, the subclass gets its own class slot, with its own value.
> So (2) above seems to be possible.

Class slots as they stand are really just global variables.  Every
time (... :allocation :class ...) is specified only one slot is ever
created.  It is unfortunate that the standard does not include a
mechanism which causes a new slot to be allocated per subclass.  This
would add new functionality to the language.  As it stands, class
allocation approximates DEFVAR.

	Doug
From: jonl%kuwait@lucid.com (Jon L White)
Newsgroups: comp.lang.clos
Subject: class variables
Date: 30 Sep 92 15:15:33 GMT
Organization: The Ohio State University Department of Computer and Information Science

re:   (1) that you cannot change class variables through the class object,
	  you have to have an instance

Because of the existence of CLOS:CLASS-PROTOTYPE, this matter is mostly
moot.  I say "mostly" for two reasons:

   (1) there are optimization technology matters that are directed towards
       explicit calls like (SLOT-VALUE instance 'A) which probably won't 
       "work" on calls like (SLOT-VALUE (CLOS:CLASS-PROTOTYPE class) 'A);
       
   (2) Although CLOS:CLASS-PROTOTYPE seems to be accepted as a de facto
       standard, it isn't mentioned in the draft ANS proposal; probably
       the widespread acceptance of CLIM has forced the vendors to make
       this one work, despite some fundamental problems with it's 
       semantics.

The synthetic applications that abound in texts and tutorials well 
illustrate the purpose for this concept  -- that the interface to them 
from within a body of code is uniform, as a "slot" access, regardless
of how the information is implemented [i.e., whether it is :instance or
:class].  The goal is to permit the programmer to change the implementation
of the information without having to pore over all his code altering the
access forms.


-- JonL --
Newsgroups: comp.lang.clos
From: lange@lanai.cs.ucla.edu (Trent Lange)
Subject: Re: class variables
Organization: UCLA Artificial Intelligence Laboratory
Date: Thu, 1 Oct 92 07:16:05 GMT

In article <CUTTING.92Sep30102223@skye.parc.xerox.com> cutting@skye.parc.xerox.com (Doug Cutting) writes:
>
>Class slots as they stand are really just global variables.  Every
>time (... :allocation :class ...) is specified only one slot is ever
>created.  It is unfortunate that the standard does not include a
>mechanism which causes a new slot to be allocated per subclass.  This
>would add new functionality to the language.  As it stands, class
>allocation approximates DEFVAR.

I have to agree with this.  Though the current :allocation :class option
is certainly more useful than defvar (as Barry points out), it would be
*very* useful if there was an slot :allocation option that allocated
:class-like slots per subclass -- maybe an option called :class-class
or something.  

It would definitely add functionality to CLOS, and in a very intuitive way,
so that (setf (slot-value (class-prototype classA) 'class-class-slot) X)
would set the slot-values of all instances of classA to X, without
changing the slot-values of instances of other classes.

Such an :allocation option would be trivial to implement for vendors
given the existence of the :class option already.  In fact, knowing
the internals of PCL, it is about a three-line patch to allow a very
efficient :class-class :allocation option.  Unfortunately, it is (currently)
not possibly to make one's own :class-class option efficient in a
portable fashion.

Is this the kind of thing that might be put up for review in the proposed
dpANS Common Lisp standard?

(As a side note, I could make an efficient, but PCL-specific metaclass
that allows a :class-class option available for the next version of
PCL if people are interested.)

- Trent Lange
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.clos
Subject: Re: Built-in functions (was Re: Beginner's Question - CLOS)
Date: 5 Oct 92 13:46:24 GMT
Organization: AIAI, University of Edinburgh, Scotland

In article <1992Sep20.141802.4612@gdr.bath.ac.uk> mascdb@gdr.bath.ac.uk (C D Burdorf) writes:
>In article <9209181825.AA08510@thelonius.mitre.org> john@linus.mitre.org writes:
>>
>>True, but many (most?) of the "built-in" functions in a Lisp
>>implementation are neither implemented in assembly language, nor are
>>they usually open-coded into calling code. 
>
>I'm suprised people are arguing with me on this point.  I C coded
>the exponential distribution function and did a foreign function
>interface to CMU Lisp and it was many times faster than what the
>CMU common lisp compiler could produce with declares and speed at 3
>and safety at 0.  

1. The question was whether functions you write yourself can be as
fast as (equivalent) built-in functions.  And the answer is very
often "yes".

2. It happens to be the case that most built-in functions are
written in Lisp or C, not assembler (at least in most Lisps where I
know something about the implementation).

3. Neither 1 nor 2 is in any way an argument that compiled Lisp is
always as fast as hand-coded assembler.  They're not even an argument
that compiled Lisp is as fast as C.

4. Nonetheless, there are cases where Lisp is as fast, or faster 
than, C.  There are also times when compiled code is faster than
hand-coded assembler.  (Indeed, not all assembly code is designed
for max speed; sometimes readability considerations intervene.)

>I've seen over and over again cases where people can write
>assembly code that is faster than what Lisp compilers produce.
>
>HCL is a very fast (on sun3's) lisp and part of the reason is
>that much of it is written in assembly language.

Is it faster than other Lisps?  How much faster?  Is it faster
than C?

-- jd
From: mark@whizbang.wariat.org (Mark W. Schumann)
Newsgroups: comp.lang.c++
Subject: A few glitches in Borland C++ 3.1 
Distribution: world
Date: Tue, 06 Oct 92 04:46:01 GMT
Organization: The Software Sweatshop, Cleveland, Ohio USA


In article <1992Oct4.173758.26139@ra.msstate.edu> cee1@ra.msstate.edu writes:

  ! 2       When the Warning: function must return a value, (DOS IDE) at the 
  !         top of the Warning box above the name of the Warning (first line),
  !         there seems to be garbled characters:
  ! 
  !         <3 filled boxes> <space> -wrvl <space> <3 filled boxes> 
  ! 
  !         not sure of the ASCII character for the 'filled boxes'. Anyway, just
  !         a minor thing.. Does this occur on others? My file dates are:
  !         06-10-92 (3:10).

Translation: "If you want this warning to be disabled, use the -wrvl
command-line switch."
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Problems with Abstract base class and pure virtual functions.
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 29 Sep 1992 15:26:27 GMT

In article <8-+p9xr.kmr@netcom.com> kmr@netcom.com (KMR) writes:
>I could not find an answer to my problem  of abstract base class
>and pure virtual functions in ARM, any help will be appreciated.
>
>Consider the following:
>
>class A {
>    public :
>	int i;
>	virtual void foo1() = 0;
>	virtual void foo2() = 0;
>	virtual void g() {} 
>};
>
>class C : virtual public A {
>    public :
>	virtual void foo2() = 0;
>	virtual void gG() {}
>};
>
>class B : virtual public A {
>    public :
>	virtual void foo1() {}
>	virtual void foo2() {}
>};
>
>class D : public B, public C {
>    public :
>	virtual void foo2() {}
>};
>
>main()
>{
>    D	*bb = new(D);
>
>    bb->i = 1;
>    bb->foo1();  
>    bb->foo2();  
>}
>
>When compiling the above on SUN 2.1 Cfront, the compiler fails 
>informing me that D is an abstract class and thus cannot be "newed"
>I can rationalize the cause of failure (though I am still not certain)
>however seeing it documented and the case explianed will help.
>

	The compiler is broken. The case you gave is more complex 
than necessary. Try this:

	class A { public: virtual void foo()=0; };
	class B : public virtual A {};
	class C : public virtual A { public: void foo(){} };
	class D : public B, public C {};

Bet that doesnt work either. But D is plainly concrete.

BorlandC3.1  has this bug. Zortech too I'm told. I think cfont 3 also.
(Any verification on that?)
MSC has it right (I'm told).

The definition of Abstract class in the ARM is subject to misinterpretation,
and requires rewording.


-- 
;----------------------------------------------------------------------
        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: "Philippe F. Bertrand" <pfbertra@watcgl.uwaterloo.ca>
Subject: char ptr in templates
Organization: Computer Graphics Lab [CGL], University of Waterloo
Date: Thu, 1 Oct 1992 18:30:42 GMT
X-Mailer: ELM [version 2.3 PL11]


Here are two version of the same test program.  Both generate errors.  I am
basically trying to pass a ptr to a string as a template constant.  
Suggestions ?

VERSION 1
=========

template < char * b >
class C {
     char * B;
   public:
   C( );
};

template < char * b > C<b>::C( ) {
  B = b;
  printf( "%s\n", b );
}

void test( ) {

  C<"wewe"> bar;			// this is line 16

}

----------
junk.c: In function `void  test ()':
junk.c:16: invalid pointer constant for template parameter
junk.c: At top level:
junk.c:6: please fix above error, and try recompiling.

VERSION 2
=========

template < char * b >
class C {
     char * B;
   public:
   C( );
};

template < char * b > C<b>::C( ) {
  B = b;
  printf( "%s\n", b );
}

void test( ) {

  const char *foobar = "FooBar";
  C<foobar> bar;

}

---------------------------
junk.c: In function `void  test ()':
junk.c:17: warning: initialization of non-`const *' pointer from `const *'
junk.c:17: invalid pointer constant for template parameter
junk.c:17: please fix above error, and try recompiling.

removing the 'const' still results with the 'invalid pointer' error

- Philippe F. Bertrand                          pfbertrand@watcgl.uwaterloo.ca 
Computer Graphics Lab, Department of Computer Science,
University of Waterloo, Waterloo, Canada  N2L 3G1
Newsgroups: comp.lang.c++
From: brendan@cygnus.com (Brendan Kehoe)
Newsgroups: comp.lang.c++
Subject: Re: C++ Review in Unix Review
Date: 6 Oct 92 18:54:00 GMT
Reply-To: brendan@cygnus.com
Organization: Cygnus Support, Palo Alto, CA
In-reply-to: 's message of Tue, 6 Oct 1992 08:04:58 EDT

In article <92280.080458MKK2@psuvm.psu.edu> <MKK2@psuvm.psu.edu> writes:

   The current issue of Unix Review reviews three "native code C++
   compilers for Intel".  Naturally 8-) they didn't include the GNU
   C++ compiler.  Besides the fact that FSF rarely advertises in Unix
   Review, can anyone think of a good argument for not including the
   GNU compiler?

Because nobody's spending advertising dollars on the GNU C++ compiler?
Between that article and the previous really shoddy review that
included (and trashed) the GNU C compiler, I've lost all faith in Unix
Review's ability to live up to its name.

GNU C++ works just fine on the reviewed platform, by the way.

  It is a "native code" compiler, isn't it?

Yes.
--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Palo Alto, CA                                  +1 415 322 3811
                                                 Re-elect Clinton/Gore in '96!
Newsgroups: comp.lang.c++
From: sam4628@zeus.tamu.edu
Subject: HELP: Q about using new w/ multi-dimensional arrays
News-Software: VAX/VMS VNEWS 1.41    
Organization: Texas A&M University, Academic Computing Services
Date: Thu, 1 Oct 1992 12:29:00 GMT

Hello,
   Here's my oppurtunity to show off my ignorance:  I'm trying to
create an array of strings using the new command:

   Names = new char[25][81];

The problem is, my C++ "manual" (the thin thing that came with BC++)
doesn't go into detail about how Names should be declared.
char *Names;  doesn't seem to work (the error is that the compiler
doesn't know how big Names is -- although it shouldn't have to).
So what am doing wrong?  Thanks for any light you can shed!

------------------------------------------------------------------------
| Steven A. McCluney                 |"Strange women lying in ponds    |
| sam4628@zeus.tamu.edu              | distributing swords is no basis |
| I'm a grad student, so my opinions | for a system of government!"    |
|    are worthless anyway            |          Dennis, to King Arthur |
------------------------------------------------------------------------
From: mark@sdd.hp.com (Mark Overton)
Newsgroups: comp.lang.c++
Subject: Only 'public' stuff in .h file?
Date: 7 Oct 1992 00:31:52 GMT
Organization: Hewlett-Packard, San Diego Division
Distribution: world
NNTP-Posting-Host: hpsdl157.sdd.hp.com

I'm really hoping that C++ will let me totally hide all implementation
info from the "user" of a class.  This means the .h file for the class
must contain solely the public interface, and not contain any private
members (which would be in the .cpp file).

Is such separation of public and private members possible?

I'm afraid the answer is 'no' because such separation would require that the
layout of memory for a source file be decided at link-time instead of at
compile-time (the compiler wouldn't know how much space to allocate for
private instance-variables).

So it seems to me that 60's compiler+linker technology has trapped us into
a serious violation of the principle of information-hiding.  I don't want
to force all the users of my container class to recompile their files just
because I added a private variable, or switched from binary trees to
skip-lists.

Please tell me I'm wrong!

  _________________________________________________________________________
 |                                                                         |
 | Mark Overton,  Hewlett-Packard (San Diego Div),  mark@sdd.hp.com        |
 |                                                                         |
 |                 C code.                                                 |
 |                 C code run.                                             |
 |                 Please code run!                                        |
 |                             -- the C User's Journal                     |
 |_________________________________________________________________________|
From: daemon@bnr.co.uk
Newsgroups: comp.lang.c++
Subject: C++ style and enumerations
Date: 30 Sep 92 10:15:32 GMT
Organization: BNR Europe Limited

I am in the process of porting a library to C++ and wonder how other
poeple address two problems 

a) 'Enumerations' with shared values [non disjoint sets of members]. 
   i)  Obviously you can simply rename enumeration values to avoid this,
       but this may do some violence to the interface you are porting.
   ii) Break the enumeration values into disjoint sets, realised as enums.
       Define a new class (not an enum) with an integer variable, with
       assignment defined for itself and appropriate enums.

b) Iterators over enums. It is obviously quite easy to write an iterator
   class over the values of an enumeration. But what do you return when
   the enumerations values are exhausted?  0 seems reasonable, but cannot
   be a member of the enum [if you want to do this for more than one enum].
   So, do you return zero or what?

Regards, Peter
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Conceptual Constness
Date: 29 Sep 92 10:52:51 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

pkturner@world.std.com (Prescott K Turner) writes:
: 
: > In article <BRENNAN.92Sep28124052@yosemite.hal.com> brennan@hal.com (Dave Brennan) writes:
: > >My complaint is that C++ doesn't provide a way to indicate this conceputal
: > >"constness."  [ugly work-arounds deleted]
: 
: Another workaround is to have two classes, the conceptually const class
: being the base of the regular class.

I don't understand how this helps you avoid cast-from-const.
Could you provide an example?

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Newsgroups: comp.lang.c++,comp.std.c++
From: aldavi01@starbase.spd.louisville.edu (Arlie Davis)
Subject: Re: Conceptual Constness
Date: Fri, 2 Oct 1992 05:37:10 GMT
Organization: University of Louisville

In <1afrmuINN93r@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe Buck) writes:

> For such objects, "delete" would
> do nothing, since no action is required to free the statically allocated
> memory.  This would only be permissible if operators new and delete
> were not overloaded.

You assume that the constructor and the destructor do nothing but modify
the state of the object.  This is very often not the case.  Many objects
register themselves in a collection of other objects on construction, and
remove themselves from the collection on destruction, or do other such things.

> --
> Joe Buck	jbuck@ohm.berkeley.edu
-- 
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null
Newsgroups: comp.lang.c++
From: pjl@sparc22.cs.uiuc.edu (Paul Lucas)
Subject: Re: The concept of templates considered ill designed
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 28 Sep 1992 20:08:20 GMT

In <RAYMOND.92Sep28145010@cobra.es.ele.tue.nl> raymond@es.ele.tue.nl (Raymond Nijssen) writes:

>Given:

>  ---- ape.h --------------------------------------------------------
>  template <class T> class ape
>  {
>  public:
>            ape();
>  };


>  ---- ape.cc -------------------------------------------------------
>  #include "ape.h"
>  
>  template<class T> ape<T>::ape () {};


>  ---- main.cc ------------------------------------------------------
>  #include "ape.h"

>  #ifdef unnecessary
>  #include "ape.cc"
>  #endif

>  int main()
>  {
>     ape<int> chimp;
>  }
>  -------------------------------------------------------------------


>Now, if the _definition_ of the constructor of the ape class isn't textually
>included in the file in which the template is instantiated, the linker will
>complain that there's no code for this constructor in ape.o.

>And, indeed:

>  % nm ape.o
>  
>  Symbols from ape.o:
>  
>  Name                    Value   Scope  Type    Subspace
>  
>  LS$START_001_000$   |         0|static|data   |$CODE$
>  LS$START_002_000$   |1073741824|static|data   |$DATA$
>  LS$START_001_001$   |         0|static|data   |$LIT$

>That's all ... no code was generated for the ctor!


>This, and other observations lead to the conclusion that templates are to be
>regarded as almost old-fashioned macros, in contrast to what the ARM made me
>believe (or should I say `hope'?).

>Accordingly, the only way to make this work is to #include all files
>containing _definitions_ (so just the _declarations_ is not enough, as the ARM
>implicitly suggests) in files in which those templates are used.

>If this is true, then I'm afraid the design of the concept of templates has
>some heavy repercussions for any programmer using it: you'll have to #include
>almost all *.h and *.cc files into most .cc files, which is little different
>from putting all your code into one big file, particularly wrt. compiling it.

>Bjarne, are you listening? Or can somebody else explain:

>  1) Should the programmer regard templates as old-fashioned macros?
>  2) How are templates dealt with by the compiler?
>  3) How does this affect coding style?

>Or... is gcc 2.2.2 flaky wrt. templates?

*****>	It's implementation-dependent.  For example, in AT&T's C++, you
	don't include the .c files, you just tell it where they are via
	the usual -I directive...it does the rest.  The only difference
	is that you put the .c files into the include directory right
	along with the .h files...hardly a change in coding style or
	anything else.

	Macros are not type-safe; macros have no knowledge of the underlying
	language, etc.

	I'd suggest a more inquisitive tone, rather than accusatory in
	future.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++