HDTenEightyP/NetNews huggingface dataset:
From: jonl%kuwait@lucid.com (Jon L White)
Subject: CHANGE-CLASS on specialized metaclass
Organization: The Ohio State University Department of Computer and Information Science
Date: Wed, 11 Nov 1992 01:56:47 GMT

re: STANDARD-CLASS has the interesting property that it is an instance of 
    itself.  Suppose I want to make a specilized metaclass that also has 
    this property:
    . . . 
    Lucid 4.0.2  Sparc2/SunOS 4.1.1  Throws into debugger during CHANGE-CLASS.
                                     "Expanding stack due to overflow..."
                                     FINALIZE-INHERITANCE not implemented.

FINALIZE-INHERITANCE is in Lucid's 4.1 release, but as you noted, not in
the 4.0 release.  However, this should be irrelevant to the basic quest
of making a STANDARD-CLASS isomorph.

In fact, Kim Barrett reported the stack-overflow behaviour in the fall
of 1990 as bug #5645:

    05645) RFE :: want to be able to make circular CLASS-OF link

and a patch was prepared some months later.  It appears as though this
fix didn't make it into the 4.0.2 release; but it is certainly in the 
February 1992 "re-packing" of CLOS (which has been distributed with 
CLIM 1.1 since that time).  You could specifically ask for the later CLOS.


Incidentally, before you do your call to:

    (change-class (find-class 'my-class) (find-class 'my-class))

I think you might have to do something like:

    (defmethod validate-superclass ((x my-classs) (y standard-class)) 
      't)

Super-class "validation" isn't discussed in the 1988 CLOS specification;
and a careful reading of AMOP shows that it isn't a defaultly enabled
property.



-- JonL --
Newsgroups: comp.lang.clos
From: zen@syl.dl.nec.com (zen kishimoto)
Subject: calling C routines from CLOS
Summary: How can I call C routines from CLOS?
Keywords: C program
Organization: NEC Systems Lab., C&C Software Technology Center (Dallas, TX)
Date: Fri, 6 Nov 1992 17:32:10 GMT

We are writing a set of CLSO interface to call a set of C rutines.
These C routines include complex parameters, such as a pointer to struct
or struct itself.  Is this FAQ?  If so, where is it?
Any lead will be greatly appreciated.

Zen Kishimoto (zen@syl.dl.nec.com)
Newsgroups: comp.lang.clos,comp.lang.lisp
From: haltraet@monsun.si.no (Hallvard Tr{tteberg)
Subject: setf methods
Date: Thu, 12 Nov 1992 01:20:39 GMT
Organization: Center for Industrial Research, Dept. of Knowledge Based Systems

Hi Lispers,

When I learned about object oriented programming one of the views that
was taught was that the set of methods of a class should preserve a
set of invariants related to the class. I.e. the object state before
and after a (official or exported) method is run should satisfy a set
of constraints, which of course could be violated while running the
method. I like this view, since it defines clearly the responsibility
of the method writer with respect to the method user.

With CLOS the methods don't belong to a class but I think the view
could be adopted, especially in the non-multi method case. E.g. if a
slot has an accessor before/after and around methods could be used for
ensuring that constraints are satisfied. However, there are often
inter-class constraints that needs to be preserved. In my graph editor
application, each node has an out-edges slot with a list of edges and
each edge has a from-node slot which point back. A constraint for the
node-edge relation could be formulated as:

(member edge (out-edges node)) <=> (eq (from-node edge) node),

which means that whenever an edge is in the out-edges list of a node,
the from-node slot of edge should point to this node. I have written a
macro, define-slot-relation, that expands such a constraint into two
setf-around-methods, one for each slot.

My question is whether it's best to generate setf-around-methods to
take care of such a constraint, or should I make another layer of
methods, e.g. set-node-out-edges and set-edge-from-node. Personally, I
prefer using setf-methods, if they shouldn't be used for such things
what should they be used for? In addition, we already have a layer
below, (setf slot-value). A problem I see, is that the user of the
setf-method perhaps expects the implementation to have low
computational complexity e.g. O(1) instead of my O(n). Anyway, I have
discussed this with my colleagues and we don't agree, so I thought I'd
ask other lispers for their opinion.

Regards, Hallvard
--
Hallvard Traetteberg
Dept. of Knowledge Based Systems
Center for Industrial Research
Box 124 Blindern, 0314 Oslo 3
NORWAY

Tlf: +47 2 45 29 83 or  +47 2 45 20 10
Fax: +47 2 45 20 40
Email: Hallvard.Tretteberg@si.no
Newsgroups: comp.lang.clos
From: john@linus.mitre.org
Subject: Re: SETF methods
Organization: The Ohio State University Department of Computer and Information Science
Date: Thu, 12 Nov 1992 17:21:05 GMT

Hallvard Tr{tteberg (haltraet%monsun.si.no@uunet.uu.net) writes:

  ... the set of methods of a class should preserve a set of
  invariants related to the class. I.e. the object state before and
  after a (official or exported) method is run should satisfy a set of
  constraints, which of course could be violated while running the
  method.
  With CLOS the methods don't belong to a class but I think the view
  could be adopted, especially in the non-multi method case.

I agree that this is a useful way to look at things.  Some languages,
notably Eiffel, give you ways to make this explicit.  The addition of
such mechanisms to Dylan is also being discussed.  It's nice to be
able to turn the constraint-checking machinery off, especially
selectively.  I don't know if your framework would easily support that
sort of thing.

  My question is whether it's best to generate setf-around-methods to
  take care of such a constraint, or should I make another layer of
  methods, e.g. SET-NODE-OUT-EDGES and SET-EDGE-FROM-NODE ...
  A problem I see, is that the user of the setf-method perhaps expects
  the implementation to have low computational complexity ...

I think SETF methods are perfectly appropriate for this.  The user of
a generic function should have no expectations about its
implementation, unless you state some.  Even if all of the methods are
slot-accessors, there still may be many more than one of them.  I
often write SETF generic functions in which NO methods correspond to
slot-access.  I also use :AROUND, etc., methods on SETFs in which the
primary methods are slot-accessors, often to do exactly the sort of
thing you discuss.

I feel very strongly that one of the strengths of CLOS is that slot
accessors are just methods (a Lisp implementation's special treatment
of them notwithstanding).  Any user who makes such assumptions about
them just doesn't get it.  Anyway, such a user would probably make the
same assumptions about functions named SET-NODE-OUT-EDGES and
SET-EDGE-FROM-NODE.

John Burger
john@mitre.org
From: john@linus.mitre.org
Newsgroups: comp.lang.clos
Subject: Re: clos initforms
Date: 10 Nov 92 14:53:22 GMT
Organization: The Ohio State University Department of Computer and Information Science

jbk@world.std.com (Jeffrey B Kane) writes:

  (defclass test-class ()
    ((slot-1	:initarg :slot-1
		:accessor slot-1)
     (slot-2	:initarg :slot-2
		:accessor slot-2)))

  (defun make-test-class (&key (slot-1 3) slot-2)
    (unless (boundp slot2)
      (setf slot-2 slot-1))
    (make-instance 'test-class :slot-1 slot-1 :slot-2 slot-2))

  The problem with this approach is that the function "boundp" does
  not test if the user typed in a particular key word.

  Calling:

  (make-test-class :slot-2 4)

  results in the error:

  > Error: Unbound variable: SLOT2
  > While executing: SYMBOL-VALUE

Uh, that's 'cause you mistyped SLOT-2 as SLOT2.  But the variable SLOT-2 would
be bound in any case.  You can't use BOUNDP to tell if a keyword or optional
parameter was supplied, because they have default values.

That aside:

  The reason I think that the constructor approach is bettter is than
  using initialize-instance :after is that it allows other key word
  and a higher level of abstraction.

But it doesn't allow you to specialize the class.  And it assumes that
SLOT-1 is only initialized in one way, through the initarg :SLOT-1.
Hardly more abstract.

  The the bottom line question is:

  Other than defining a keyword with some kind of a value to flag it
  hasn't been used, how can you test if it was used similar to
  slot-boundp for slots?

I'm not sure what this means, but are you asking how to tell if a
keyword was used?  Use what CLtL calls "svars" (page 76, CLtL2),
presumably "s" for "supplied".  Minimally modifying your constructor:

  (defun make-test-class (&key (slot-1 3) (slot-2 NIL SLOT-2-SUPPLIED?)
    (unless SLOT-2-SUPPLIED?
      (setf slot-2 slot-1))
    (make-instance 'test-class :slot-1 slot-1 :slot-2 slot-2))

John Burger
john@mitre.org
Newsgroups: comp.lang.clos
From: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
Subject: Re: setf methods
Organization: The Ohio State University Department of Computer and Information Science
Date: Thu, 12 Nov 1992 19:38:52 GMT

> When I learned about object oriented programming one of the views that
> was taught was that the set of methods of a class should preserve a
> set of invariants related to the class. I.e. the object state before
> and after a (official or exported) method is run should satisfy a set
> of constraints, which of course could be violated while running the
> method.

This is a good idea, but it's not clear that it should apply to
accessors (or readers or writers).  (1) It's reasonable to do all
slot access via accessors and never use SLOT-VALUE and (2) it's
often necessary to make several state changes before you're back in
a consistent state.

Obviously, there are some, even many, accessors that could be asked
to maintain the invariant, but I don't think it can work as a general
rule for all public accessors.  This sort of thing works better in
languages wiht "instance variables", I suspect.

-- jd
Newsgroups: comp.lang.clos
From: charest@Aig.Jpl.Nasa.Gov (Len Charest)
Subject: CHANGE-CLASS on specialized metaclass
Keywords: metaclass finalization 
Reply-To: charest@aig.jpl.nasa.gov
Organization: NASA/Jet Propulsion Laboratory
Date: Wed, 11 Nov 1992 01:02:39 GMT

Now that the discussion on class-prototype has died down, I thought I'd throw
this on the fire:

STANDARD-CLASS has the interesting property that it is an instance of itself. 
Suppose I want to make a specilized metaclass that also has this property:

(defclass my-class (standard-class) 
  ((arbitrary-slot :initform (gensym)))  ;to keep things interesting
  )

;;; now make my-class be an instance of itself
(change-class (find-class 'my-class) (find-class 'my-class))

;;; test the result (if any...)
(slot-value (find-class 'my-class) 'arbitrary-slot)

Should this work in a correct implementation of CLOS? Should it matter whether
MY-CLASS has been finalized before the call to CHANGE-CLASS? My intuition is that
the above code should perform as expected--even in the absence of a MOP since the
functions involved (DEFCLASS, CHANGE-CLASS and SLOT-VALUE) are all part of the
'regular' CLOS programmer interface. My experience shows otherwise:

Lisp         Platform            Result
----         --------            ------
Lucid 4.0.2  Sparc2/SunOS 4.1.1  Throws into debugger during CHANGE-CLASS.
                                 "Expanding stack due to overflow..."
                                 FINALIZE-INHERITANCE not implemented.
PCL July 92  Sparc2/SunOS 4.1.1  Works as expected regardless of whether
on Lucid                         MY-CLASS is finalized.
Allegro 4.1  Sparc2/SunOS 4.1.1  Throws into debugger during CHANGE-CLASS.
                                 "No methods applicable for gf: CLOS:CLASS-DIRECT-
                                 SLOTS with args (#<CLOS:FORWARD-REFERENCED-CLASS 
                                 STANDARD-CLASS...> of classes (CLOS:FORWARD-
                                 REFERENCED-CLASS)"
                                 Same error occurs if attempt to finalize MY-CLASS
                                 before CHANGE-CLASS.
MCL 2.0      Quadra 700/Sys 7    Throws into debugger during CHANGE-CLASS, but
                                 will work if MY-CLASS has no local slots.
                                 FINALIZE-INHERITANCE not implemented.

Comments?
..................................................
                                  Len Charest, Jr.
                 JPL Artificial Intelligence Group
                          charest@aig.jpl.nasa.gov
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: Invoking functions passed as parameters
Date: 11 Nov 92 02:55:39 GMT
Article-I.D.: alice.24149
Organization: AT&T Bell Laboratories, Murray Hill NJ



dx@netcom.com (dx @ Netcom - Online Communication Services) writes

 > In standard C, function pointers passed as paramters are invoked with
 > the standard C syntax, e.g.,
 > 
 > 	foo(void (*pf)(parmeters))
 > 	{
 > 		pf(paremeters)
 > 	}
 > 
 > Now suppose I have a class PFCLASS, and pf points to a member function of
 > this class, and within foo I want to apply the method pointed to by pf to
 > an instance of PFCLASS, pointed to by pInstance.
 > 
 > In standard C syntax, I would make the member function take the pointer to
 > the instance as a parameter, and use the standard way to call the function:
 > 
 > 	pf(pInstance);
 > 
 > But I wonder if there is some way to invoke the method pointed to by pf
 > in a more C++ like way, such that pInstance turns up as the 'this' pointer
 > in the method, rather than having to pass it as a parameter.
 > 
 > Any ideas?

First of all: Naturally, the C style works. You only need to go further
if there is a real need.

Consider:

	class X {
		// ...
	public:
		// ...
		virtual int f1(int);
		virtual int f2(int);
	};


Solution #1:

	int g1(X* p, int i)
	{
		return p->f1(i);
	}

The C-style function g1() calls f1 for a given object. A pointer to g1()
can be passed. This is inelegant in some contexts, but have the advantage
that g1() might be passed to a C program if declared extern "C".

Solution #2:

	typedef int (X::* PMF)(int);

PMF is a pointer to member of X type. We can use it like this:
	
	int g2(X* p, PMF f, int i)
	{
		return (p->*f)(i);
	}

g2() calls the member function pointed to by `f' for the object
pointed to by `p.' For example:

	int (X::* f)(int) = &X::f1;
	int (X::* ff)(int) = &X::f2;
	X obj;

	void m()
	{
		g2(&obj,f,2);	// obj.f1(2)
		g2(&obj,ff,4);	// obj.f2(4)
	}

Pointers to members are described in sec5.5 of the reference manual (pg71
of the ARM , pg502 and 167 of ``The C++ Programming Language (2nd edition)'').

This solves the problem as stated, but just for fun let's explore this a bit:

Solution #3:

	class XFunc {
		PFM f;
		X* p;
	public:
		XFunc(PMF ff, X* pp) { f=ff; p=pp; }
		int operator()(int i) { return (p->*f)(i); }
	};

That is, an object of class `XFunc' contains the information needed to
call a member function for an object and can be called:

	XFunc xf(&X::f1,&obj);
	XFunc xff(&X::f2,&obj);

	xf(2);	// obj.f1(2)
	xff(4);	// obj.f2(4)

Note that objects of type `func' can be passed around easily and safely:

	int xcall(XFunc& x, int i)
	{
		x(i);	// call whatever member function x holds
			// for whatever object x holds a pointer to
	}

	void m1()
	{
		xcall(xf,2);	// obj.f1(2)
		xcall(xff,4);	// obj.f1(4)
	}

Such ``functional objects'' can be very useful, but as usual one
should only use a technique if there is a real need.
Newsgroups: comp.lang.c++
From: ykim@cs.columbia.edu (Yong Su Kim)
Subject: g++ warning - destructor non virtual in inheritance relationship
Organization: Columbia University Department of Computer Science
Date: Fri, 6 Nov 1992 05:12:38 GMT


I have a class which inherits from two separate classes.

eg class B: public c, public d

and when I compile using g++, I get warning messages which say
something about d's destructor being non virtual in inheritance
relationship with B in the header file.

It's just a warning, but I don't understand what is causing the
problem.  If someone could point out what I am doing wrong, it would
be great.  It's annoying having to see the same warnings again and
again every time the .h file is included in a .cc file.
-- 
===============================================================================
Yong Su Kim, Class of 1993		|  Internet: yk4@cunixb.cc.columbia.edu
Columbia College, Columbia University   |        or  ykim@cs.columbia.edu
			
Newsgroups: comp.lang.c++,comp.std.c++
From: duanyang@cs.columbia.edu (Duanyang Guo)
Subject: operator [][]
Organization: Columbia University Department of Computer Science
Date: Mon, 9 Nov 1992 07:10:02 GMT

for multiple dimension array, is it possible to define 
an operator [][](say for two dimensions)? I try to define 
it as 
int & operator[][] (int, int);

which g++ complains about it. 

any idea or just sth is wrong with my try? 


-- 
Duanyang Guo 	         |     (212)939-7098(O),   663-8904(H)   
CS Dept, Columbia Univ.  |      Rm 625, CEPSR
New York,     NY 10027   |      Email:duanyang@cs.columbia.edu  

Newsgroups: comp.lang.c++
From: alex@elvis.sitka.sun.com (Alexander G. Smith)
Newsgroups: comp.lang.c++
Subject: Re: C++ on Mac
Date: 6 Nov 1992 22:34:37 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: alex@elvis.sitka.sun.com
NNTP-Posting-Host: elvis.sitka.sun.com

In article 1crr5tINN8d1@overload.lbl.gov,
chris@carnival.lbl.gov (Chris Moll) writes [of MPW C++]:

>
>It'll cost you on the order of $750, if you don't have MPW.  That seems
>fairly expensive to me.  But I don't know of an alternative.
>

The current APDA catalog (Nov. 92) lists the MPW C/C++ CD-ROM for $575.00,
including MPW.

Alex Smith
Sitka Corp.


Newsgroups: comp.lang.c++
From: ae007@yfn.ysu.edu (Daniel Newcombe)
Subject: Class Queue for any data type?
Organization: Youngstown State University/Youngstown Free-Net
Date: Tue, 10 Nov 1992 22:14:05 GMT


Hi, I have a class queue that is a queue structure for int's.
I would like to expand it so that it can use any data type
without having to rewrite the code for each data type. What
would be the best way to do this?  Have it be a queue of  
addresses?  Thanks...
-Dan
-- 
    -Dan Newcombe
Internet Address:  STDN@VM.MARIST.EDU
Youngstown Freenet: ae007@yfn.ysu.edu
GOAL: To put the world on 3.5" diskettes...  :)
Newsgroups: comp.lang.c++
From: gfung@vegas.daisy.com (gfung@dazixca.ingr.com)
Subject: Re: the COOL library
Reply-To: gfung@vegas.daisy.com
Organization: Dazix an Intergraph Company
Distribution: usa
Date: Wed, 11 Nov 1992 22:00:27 GMT


I also found out there was a bug in the vector class in the ice package.
In the Vector.h class :

 
template <class Type>
class Vector<Type> : public Vector {
protected:
  Type* data;                   // Pointer to allocated storage
  static Type##_Vector_Compare compare_s;   // Pointer operator== function
  void grow (long min_size);            // Make the Vector bigger
 
public:
  Vector<Type> ();              // Vector v;
  Vector<Type> (unsigned long);         // Vector v(10);
  Vector<Type> (void*, unsigned long);      // Vector with static storage
  Vector<Type> (unsigned long, const Type&);    // Vector v(10,x);
                               ^^^^^^^^^^^^
  Vector<Type> (unsigned long, int, ...);   // Vector v(10,3,x,y,z);
                               ^^^
  ....

If I declare a Vector<int> class with only two arguments.
i.e. Vector<int> v(10,3)

This declaration will satisfy both of the above constructors and causes 
compilation error.

Does anyone have the fixes for it?


Thanks
Glenn

---
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Glenn Fung                   | Email: gfung@dazixca.ingr.com
Intergraph Electronics       | 
381 East Evelyn Avenue       | Tel: (415)691-6420
Mountain View, CA 94041      | Fax: (415)691-0138
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Newsgroups: comp.lang.c++
Subject: Pretty Printer for C/C++
From: mmangieri@vitro.com (Mikey)
Date: 9 Nov 92 10:35:39 -0500
Distribution: world
Organization: Vitro Corporation

Does anyone know where I can get a copy of a pretty printer for C++?
Extendability would be nice but not absolutely necessary. What I am really
looking for is a program to indent my nested functions, etc.

         __________________________________________________________________
        / Michael J. Mangieri                 Internet: mmangieri@vitro.com
__     /  Vitro Corporation                      Voice:      (301) 231-3016
  \   /   MX-SP 4-2311                             FAX:      (301) 231-1233
   \ /    14000 Georgia Ave.              
    *     Silver Spring, MD 20906-2972    

         "Everything should be made as simple as possible, but not simpler."
                                                       - A. Einstein
From: ameesh@lsil.com (Ameesh Desai)
Newsgroups: comp.lang.c++
Subject: Re: Objects in shared memory
Date: 6 Nov 92 19:24:51 GMT
Reply-To: ameesh@lsil.com
Organization: LSI Logic Corporation

In article 8973@sol.ctr.columbia.edu, leo@avs.com (Leo O'Donnell) writes:
>
>    This question has been asked before but...
>
>    I need to pass pointers to objects between processes. I have a
>    few ideas that might work, but would really welcome any suggestions
>    that you may have. In the cases that I am considering, the classes
>    will all be self-describing (ie will have a class type member).
>
>Leo O'Donnell                Email: leo@avs.com
>Advanced Visual Systems      Voice: (617) 890-4300 ext 2120
>Waltham, MA


Take a look at NetClasses library. If you need to pass objects between
processes, they have what you need.

Call  Thane E. Plambeck
PostModern Computing Technologies, Inc.
Tel: (415) 967-6169
Fax: (415) 967-6212

I have not used this libary, but have looked at some of their technical info.

Ameesh


---
______________________________     o__            
| _   /|     Ameesh Desai     \    ,>/_                              
| \`O.o'     LSI Logic Corp.   \__(_)`(_)_              email: ameesh@lsil.com
| =(_|_)=    MS E192, 1501 McCarthy Blvd. \             fax  : (408) 433-6802
|____U_______Milpitas, CA 95035____________\____________voice: (408) 433-4097 
Newsgroups: comp.lang.c++
From: erc@netcom.com (Eric Smith)
Subject: Re: 32 bit compiler
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Tue, 10 Nov 1992 13:57:52 GMT

In article <1992Nov9.153133.27084@philabs.philips.com> kkt@philabs.philips.com (Kim-Kiat Tan) writes:
>        Anyone knows whether Borland has any plan to develop 32 bits compiler 
>for dos ? If they have plan, I might develop my software with Borland c++ and
>wait for their 32bit compiler, or else most likely I will go with Zortech or
>Meta C. My feeling is that Borland has grown and is showing sign of the "big"
>corporation, I requested information thro' the magazines' info. request card,

Borland growing?  Their stock went from around 80 to around 30.  I would say
they are shrinking rather than growing.

I have been using Zortech for 32 bits, but am now porting my code to NT.  The
$69 CD-ROM includes the complete 32-bit Microsoft C/C++ compiler version 8.

The only real complaint I have is that Zortech and Microsoft are so
incompatible with each other, I have to keep rebooting my computer to
switch back and forth while porting.  Programs compiled with Zortech's
32-bit X model apparently won't work with NT, even though they are
supposed to be Windows compatible.  And every time I reboot to NT, I
have to log in, because I haven't yet found out how to bypass the login
screen.  I would like to somehow automate the process such that I can
reboot from one O/S to the other in the middle of a makefile and have it
automatically continue the makefile, but I haven't figured out how to
get past the login screen.
Newsgroups: comp.lang.c++