HDTenEightyP/NetNews huggingface dataset:
From: gregor@parc.xerox.com (Gregor Kiczales)
Newsgroups: comp.lang.clos
Subject: Re: Metaclass inheritance?
Date: 9 Jan 93 01:37:51 GMT
	<1993Jan8.220317@di.epfl.ch>
Followup-To: comp.lang.clos
Organization: Xerox Palo Alto Research Center


In article <1993Jan8.220317@di.epfl.ch> matomira@di.epfl.ch (Fernando Mato Mira) writes:

   Here is a way of implementing the rule for implementing metaclass
   inheritance proposed in my previous post...

   (defmethod ensure-class-using-class :around ((class t) name 
						&rest args
						&key (direct-superclasses nil)
						     (metaclass nil))
     ...)


This is a nice hack, and it is probably good enough to get some work
done, but I guess I should point out that it is illegal, in portable
code, according to the rules on pages 142, 143 and 144 of AMOP.
Specifically the rule that:

  Any method defined by a portable program on a specified generic
  function must have at least one specializer that is neither a
  specified class nor an {\bf eql} specializer whose associated
  value is an instance of a specified class.

The basic problem with methods like this is that two programs, written
separately, which both have methods like this, will interfere with each
other if they are loaded together.  That is why this rule is there.  We
talk about this, and the origin of all these rules, in more detail in
our OOPSLA'92 paper.
Newsgroups: comp.lang.clos
From: john@linus.mitre.org
Subject: Re: Metaclass inheritance?
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 8 Jan 1993 19:38:57 GMT

Gregor says:

  ... the rule that says you can't change the class of a metaobject
  once it has been initialized.

Doesn't this already happen, exactly with forward-referenced classes?
I don't have the MOP handy: is this an allowed exception, or am I
misunderstanding what you mean by "initialize"?

John Burger
john@mitre.org
Xref: sparky comp.lang.clos:1061 comp.lang.lisp:3208
From: matomira@di.epfl.ch (Fernando Mato Mira)
Newsgroups: comp.lang.clos,comp.lang.lisp
Subject: Metaclass inheritance?
Keywords: CLOS, MOP, :METACLASS (a REAL keyword!! :-) )
Date: 8 Jan 93 14:42:39 GMT
Followup-To: comp.lang.clos
Organization: Ecole Polytechnique Federale de Lausanne

Let's say you have a metaclass ATTRIBUTED-CLASS, so when you do

(defclass foo () () 
 (:metaclass attributed-class))

you get something like
#<ATTRIBUTED-CLASS SCHEMA @ #x10f7f26a>

Then somebody comes and does  
(defclass bar (foo) ())

and he gets
#<STANDARD-CLASS BAR @ #x10f82c02>

when what he really needs is
#<ATTRIBUTED-CLASS BAR @ #x10f82c02>

and you would like to hide the implementation-dependent metaclass.

I think that in many cases, if you can resolve the set of common subclasses of
the set of metaclasses of the direct superclasses of a class to a hierarchy,
taking the root of that hierarchy as the default metaclass is the way that you want to go, and not getting just STANDARD-CLASS instead.
For disambiguating more complicated cases, or for getting some other metaclass than this default one, the :metaclass option is there.
If you do not disambiguate by using the :metaclass option, then getting STANDARD-CLASS as the default would be OK.
When a direct superclass of the class being defined  is a forward-referenced class, it is treated by the previous algorithm as if its metaclass were STANDARD-CLASS instead of FORWARD-REFERENCED-CLASS.

It seems that the only way of implementing this today is by defining an :around
method on ENSURE-CLASS-USING-CLASS which is not exactly great to specialize, so
maybe taking a look again at this part of the CLOS specification would be a good
idea.

-- 
Fernando D. Mato Mira
Computer Graphics Lab			   "Bury GIFs!! Get JPEGed!!!"
Swiss Federal Institute of Technology
matomira@di.epfl.ch

NeXTMail : matomira@lignext.epfl.ch
FAX 	 : +41 (21) 693 - 5328
Xref: sparky comp.lang.clos:1064 comp.lang.lisp:3213
From: davis@passy.ilog.fr (Harley Davis)
Newsgroups: comp.lang.clos
Subject: Re: Metaclass inheritance?
Date: 11 Jan 93 10:36:52 GMT
Followup-To: comp.lang.clos
Organization: ILOG S.A., Gentilly, France
In-reply-to: matomira@di.epfl.ch's message of 8 Jan 93 14:42:39 GMT


In article <1993Jan8.154239@di.epfl.ch> matomira@di.epfl.ch (Fernando Mato Mira) writes:

   Let's say you have a metaclass ATTRIBUTED-CLASS, so when you do

   (defclass foo () () 
    (:metaclass attributed-class))

   you get something like
   #<ATTRIBUTED-CLASS SCHEMA @ #x10f7f26a>

   Then somebody comes and does  
   (defclass bar (foo) ())

   and he gets
   #<STANDARD-CLASS BAR @ #x10f82c02>

   when what he really needs is
   #<ATTRIBUTED-CLASS BAR @ #x10f82c02>

   and you would like to hide the implementation-dependent metaclass.

   I think that in many cases, if you can resolve the set of common
   subclasses of the set of metaclasses of the direct superclasses of
   a class to a hierarchy, taking the root of that hierarchy as the
   default metaclass is the way that you want to go, and not getting
   just STANDARD-CLASS instead.  For disambiguating more complicated
   cases, or for getting some other metaclass than this default one,
   the :metaclass option is there.  If you do not disambiguate by
   using the :metaclass option, then getting STANDARD-CLASS as the
   default would be OK.  When a direct superclass of the class being
   defined is a forward-referenced class, it is treated by the
   previous algorithm as if its metaclass were STANDARD-CLASS instead
   of FORWARD-REFERENCED-CLASS.

   It seems that the only way of implementing this today is by
   defining an :around method on ENSURE-CLASS-USING-CLASS which is not
   exactly great to specialize, so maybe taking a look again at this
   part of the CLOS specification would be a good idea.

I think the justification for this would be to allow the compiler to
use knowledge of the metaclass at compile time to make certain
optimizations.  In practice, I'm not sure how much CLOS
implementations could use this information given other constraints,
and I'm pretty sure none currently do.

The workaround is to define your own class
definition macro for your metaclass which could be just like DEFCLASS
but inserts its own metaclass in the :METACLASS option.

-- Harley Davis
--

------------------------------------------------------------------------------
nom: Harley Davis			ILOG S.A.
net: davis@ilog.fr			2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66			94253 Gentilly Cedex, France
From: gregor@parc.xerox.com (Gregor Kiczales)
Newsgroups: comp.lang.clos
Subject: Re: Metaclass inheritance?
Date: 8 Jan 93 19:05:32 GMT
Followup-To: comp.lang.clos
Organization: Xerox Palo Alto Research Center


You have hit on a real problem in the CLOS MOP, at least as far as I am
concerned.  Unfortunately, given the current specification, it is pretty
hard to fix.  It depends a bit on how you look at it, but I guess I
would say the primary reason this can't be fixed is ``forward referenced
superclasses;'' or perhaps a combination of them and the rule that says
you can't change the class of a metaobject once it has been initialized.

If we got rid of forward referenced superclasses, your problem could be
fixed by providing a generic function called SUBCLASS-CLASS, which would
be called to determine the appropriate class of a subclass.  Some hair
would be needed to handle multiple inheritance, but that would be easy.

But, with forward referenced superclasses, we might not know that a
class needs to be an instance of something other than standard-class
until long after it is created, which causes problems with the change
class rule.  We might be able to get out of that by saying that one can
change the class of a class up until the time it is finalized; maybe
that is worth considering.

How serious a problem do people think this is?

One final note, in your message, you propose a fix that I don't
understand: 

   It seems that the only way of implementing this today is by
   defining an :around method on ENSURE-CLASS-USING-CLASS which
   is not exactly great to specialize, so maybe taking a look
   again at this part of the CLOS specification would be a good
   idea.

Can you elaborate on this?


Gregor
From: stefans@bauv.unibw-muenchen.de (Stefan Schwarz)
Newsgroups: comp.lang.c++
Subject: Template-instantiation fails with references
Date: 5 Jan 93 11:55:49 GMT
Organization: University of the armed forces, Munich
NNTP-Posting-Host: bauv106.bauv.unibw-muenchen.de

Hi all,

just came to a serious problem with templates. Simple code:

#include <iostream.h>
template <class T> class Collection
{
private:
        T *_buffer;
        T _endtag;
public:
        Collection (size_t size, T endtag) {
                _buffer = new T [size];
                _endtag = endtag; }
};

class Foo
{
};

main()
{
        Foo end;
        Collection<Foo&> coll (10,end);
}

This fails with:
line 3: error:  reference member  Collection <Foo&>::_endtag needs initializer

Replacing Foo& with Foo* (and end with &end) succeeds.

So, is there a chance to get my template used with references?

BTW: I'm using C++ 3.0 on SGI Irix 4.0.5

	Stefan
--
Stefan Schwarz                            University of the armed forces
Laboratory for graphical data processing  W-8014 Neubiberg, FRG
--
Newsgroups: comp.lang.c++
From: markham@brtph597.bnr.ca (Andrew Markham P205)
Subject: Looking for comprehensive C++ text (esp. ver 3.0 and I/O)
Organization: BNR Inc. RTP, NC
Date: Tue, 12 Jan 1993 19:34:50 GMT

We have a study group that has been meeting once a week for the
past couple of months with the hopes of becoming C++ gurus.  
During this time, we have come to the conclusion that Lippman's
'C++ Primer' (which we have been using up until now because there
were enough copies around the department to keep us from going 
out and buying another text) is less than adequate.  It has 
served as a decent starting point, but is in no way comprehensive.  
The second edition is somewhat better, but we feel that a different
text from a different author would be a more worthwhile investment
(considering the second edition will contain mostly what we have 
already seen with a little bit more).

What we would like are YOUR opinions on texts that you have used/read.

Our only basic requirements include coverage of C++ version 3.0 
(through templates and exception handling) and some measure of 
completeness, since most texts seem to cover some things well, yet
leave others untouched.

The texts that we have researched and aren't impressed with
are as follows:
	Lippman's, C++ Primer (1st and 2nd editions)
	Stroustrup, ARM (covers version 2.1, but no I/O)
	Eckel, Using C++ (covers version 2.1)
	Herbert/Schildt, C++ The Complete Reference (covers version 2.1)
	Barkakati, OOP in C++ (covers version 2.1)
    Dewhurst/Stark, Programming in C++

Also, we are wondering if anyone has a text that covers C++ I/O
in its entirety.  So far all texts either don't cover it, or 
only cover parts.

Thanks.

markham@bnr.ca
-- 
Andrew W. Markham (markham@bnr.ca)
Bell Northern Research, Inc.
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Restatement: Virtual base class & reference initialisation
Organization: TauMetric Corporation
Date: Mon, 11 Jan 1993 19:02:33 GMT

ajp@dsl.eng.cam.ac.uk (A. J. Piper) writes:

|My original question on this did not include an example which is probably why I
|was misunderstood. The scenario is this:
| 
|class A {
|        const int& a;
|        A(const int& i) : a(i) {}
|        A() : a(0) {}
|};
| 
|class B : virtual public A {
|        B(const int &i) : A(i) {}
|};
| 
|class C : public B {
|        C(const int& i) : B(i) {}
|};
| 
|The reason I asked is that if you create an object of type C then B's
|initialisation of A is ignored and the default constructor is used instead ...

That's correct.

|So how do I initialise the reference ? Well cfront
|3.0.1 allows me to access the constructor of A directly from the constructor
|of C so I can write:
| 
|class C : public B {
|        C(const int& i) : B(i), A(i) {}
|};
| 
|Which solves my original question.

Right.  This area of the language changed, and older compilers might
not work this way.  Relatively recent compilers should support this
code, and so should all future compilers.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c++
From: Morten Irgens <morten.irgens@si.no>
Subject: Re: where to find a good class string?
X-Useragent: Nuntius v1.1.1d5
Date: Mon, 11 Jan 1993 14:01:34 GMT
X-Xxdate: Mon, 11 Jan 93 15:03:59 GMT
X-Xxmessage-Id: <A7773CDF0F02401E@appleton.si.no>
Organization: Senter for Industriforskning

Where can I find a robust 'class string' package
(commercial or non-commercial)?  

I know that there's one in g++ (GNU C++), but I don't know
if it is easily portable.  

I've looked through Marshall Cline's C++ FAQ at
sun.soe.clarkson.edu without any luck.  Forgive me if this
should be a well-known thing - this is my second week with
C++.

Morten Irgens, SINTEF-SI
morten.irgens@si.sintef.no
From: wright@staff.tc.umn.edu (Mark Wright)
Subject: Re: Pros and cons of C++
Organization: University of Minnesota
Date: Fri, 8 Jan 1993 00:26:18 GMT

In article <1993Jan7.160959.9381@eua.ericsson.se> euamts@eua.ericsson.se writes:
>In article vp@gpu.utcs.utoronto.ca, yjohn@gpu.utcs.utoronto.ca (John Ross) writes:
>
>// Deleted
>
>#Why then is it becoming so popular?  Why the deluge of texts, articles,
>#magazines, news groups, compilers, etc?  It seems to me that C++ _will_
>#be the language of choice for programmers (except in specialized areas
>#where other languages will continue to be used). It would be nice to get a
>#balanced view of where C++ fits into the scheme of things.
>#Unfortunately, language issues often assume the aspect of a religious
>#war, with rabid supporters and detractors.
>
>I think someone ought to do some sociological research on this. I can agree
>with people claiming C++ is very complex, but I don't know any other OO
>language, so I cannot say if it is overly complex or not.

Well, for those of us in the dos world (which is the largest software market,
and therefore if it isn't setting the trends, it definitely determines which
ones will survive), I'm sure that alot of us switched to C++ just because it
was there - Borland's been packaging C++ with their very popular C compiler
for a long time now, and eventually people just start to wonder what it's all
about.  
>
>Mats Henricson
>Ellemtel
>Sweden


-- 
Mark Wright
wright@epx.cis.umn.edu
Newsgroups: comp.lang.c++
From: suresh@papaya.iss.nus.sg (Suresh Thennarangam - Research Scholar)
Subject: Re: Overloading [] for 2d+ matrixes
Reply-To: suresh@iss.nus.sg (Suresh Thennarangam - Research Scholar)
Organization: Institute Of Systems Science, NUS
Date: Tue, 5 Jan 1993 09:46:47 GMT

In article <1iarmlINN882@ub.d.umn.edu> cbusch@ub.d.umn.edu (Chris) writes:
>   I been programming in C++ for quite a while now, but something
>occurred to me, how can you overload [] for 2d or 3d plus matrices?
>Apparently the only allowable syntax is:
>   myclass::operator [] (int);

Yes, that is so but it is quite easy if you adopt the following approach:

1> Define an operator[] function for  vector class (1 d array) which returns 
    a reference to the correct element 

2 >Your 2D matrix class is derived from this class and also has it's own
   operator[] function that returns a reference to an instance of the 
   vector class

so if you have

class vector
{
public:
  vector(int) { ... };
  int& operator[](int) { ...} // return appropriate data value 
protected:
int * data;
  :
  :
};

class matrix: public vector
{
public:
  matrix(int,int) { ... };
  vector& operator[](int) { ...}

}

matrix  a(3,3) ;

a[2][2] = 10 ;

cout << a[2][2] ; // not sure if cout will accept a reference to an integer.
                  // will someone confirm please ? 


A simpler way would be for the matrix class to return an array which
can already accept the subscript operator( i.e. []). This can be
extended to higher dimensions so a matrix_3d class can return a
int ** pointer which can already accept the [] operators so 
you can have a statement like

class matrix_3d
{
 public:
 int ** operator[]( int) { ....} 
:
:
:
}
matrix_3d m_3d(3,3,3) ;
  m_3d[2][2][2] = 0 ; 

This is rather inelegant because you can't do range checking on
some of the subscripts and also you are exposing the private 
data of the classes. The first method is type safe and can be
nicely extended to higher dimensions( albeit a bit tedious to
implement).  


Hope that answers your question.

      __                  
     (_   / /  o_   o  o |_
     __)/(_( __) (_(_ /_)| )_

***************************************************************************
* Suresh Thennarangam               *  EMail: suresh@iss.nus.sg(Internet) *
* Research Scholar                  *         ISSST@NUSVM.BITNET          *
* Institute Of Systems Science      *  Tel:  (065) 772 2588.              *
* National University Of Singapore  *  Facs.: (065) 778 2571              *
* Heng Mui Keng Terrace             *  Telex: ISSNUS RS 39988             *
* Singapore 0511.                   *                                     *
***************************************************************************
From: jar@solva.ifi.uio.no (Jo Are Rosland)
Newsgroups: comp.lang.c++
Subject: Re: xdr layer above iostream's
Date: 10 Jan 93 15:24:42 GMT
Organization: Dept. of Informatics, University of Oslo, Norway
X-Md4-Signature: 998719afc70bc82f213d281d10eb0eda
Originator: jar@solva.ifi.uio.no

In article <1ih5puINN4fj@buzz.bmc.uu.se> Mats Sundvall writes:
   I have implemented an Xdr class with the help of the xdr_rec. I have
   a constructor Xdr(iostream*) and can then put a XDR layer above a stream.
   All the operator input and output methods are then implemented to read
   from and write to Xdr.

   Another way to implement it would be to implement a new iostream subclassing
   from ios and streambuf.

   I now wonder what pros and cons there is with these different approches, and
   if there are other ways to do it that I haven't thought about.

I think the best solution is to make xdrstream an independent class
with an interface similar to ios, and a constructor (among others)
looking like xdrstream(streambuf*).  Then you implement the << and >>
operators for all the types you need (at least the primitive types.)

There are a number of reasons for this:

The ios class doesn't seem to offer xdrstream very much, so it's not
much use in having it as a subclass.  All the formatting functionality
(things like field widths etc.) are just superfluous in xdrstream.  It
would just be unnecessary baggage to carry around.

Since ios formatting (all the << and >> defined for ios) is mainly
text based, while xdr is binary, you need to implement all the >> and
<< whatever solution you choose.

With the xdrstream(streambuf *) constructor (and a corresponding
streambuf* member) you can perform xdr IO with all your excisting
streambuf subclasses, including your tcp and tli classes if they are
implemented correctly.  Outputting to standard output would be
possible by creating the xdrstream with xdrstream(cout.rdbuf()), if
you want to output to a file, you could do it like this: xdrstream(new
filebuf("file")). (Or whatever the constructor for filebuf looks
like :-)).

Hope this helps,

--
Jo Are Rosland
jar@ifi.uio.no
Newsgroups: comp.lang.c++
From: suresh@papaya.iss.nus.sg (Suresh Thennarangam - Research Scholar)
Subject: C++/X11/Motif Problems
Originator: suresh@papaya
Organization: Institute Of Systems Science, NUS
Date: Wed, 6 Jan 1993 13:09:16 GMT

Hi netters:

I am using cfront3.0  on SGI, X11R4 and Motif 1.1.

I have these problems .. I hope someone can help. 

Briefly:

 

1>  Here is an excerpt from the file /usr/include/X11/ShellP.h

================================
typedef struct {
    char *class; // -----> note this
    XrmClass xrm_class;
    int argc;
    char **argv;
} ApplicationShellPart;
================================

Note that there is a member declared by the name class which is a
C++ reserved word. The X11 and Motif release header files contain
several such code fragments which will prevent code from passing thro'
the C++ compiler. Does anyone know any solution or workaround for this
problem ?

2> 
I have some source lines in my program like so, 

#include    <Mrm/MrmAppl.h>
:
:
:
        if ( MrmRegisterClass ( MrmwcUnknown,
                                "GlxMDraw" ,
                                "GlxCreateMDraw",
                                GlxCreateMDraw,
                                glxMDrawWidgetClass ) != MrmSUCCESS )
            XtAppError( app_context, "Can't register GL widget.");
----------------------

If I compile this source the compiler says:

==============================================================

"iface2.c", line 89: error: bad argument  4 type for 
MrmRegisterClass(): Widget( *)(Widget, char *, ArgList, Cardinal) 
( Widget(*)() expected)
*** Error code 1

==============================================================

How do I resolve this problem ? Do I just cast away like so ?

if ( MrmRegisterClass ( MrmwcUnknown,
                                "GlxMDraw" ,
                                "GlxCreateMDraw",
                                ((Widget(*)()) GlxCreateMDraw ,
                                GlxCreateMDraw,
                                glxMDrawWidgetClass ) != MrmSUCCESS )
            XtAppError( app_context, "Can't register GL widget.");


This compiles but I'm not sure if it will cause any other problems.

In fact several functions accept pointer to function arguments 
and the compiler always insists on checking if the argument types
match .. isn't this rather unneccessary ? 


Thanks,

      __                  
     (_   / /  o_   o  o |_
     __)/(_( __) (_(_ /_)| )_


***************************************************************************
* Suresh Thennarangam               *  EMail: suresh@iss.nus.sg(Internet) *
* Research Scholar                  *         ISSST@NUSVM.BITNET          *
* Institute Of Systems Science      *  Tel:  (065) 772 2588.              *
* National University Of Singapore  *  Facs.: (065) 778 2571              *
* Heng Mui Keng Terrace             *  Telex: ISSNUS RS 39988             *
* Singapore 0511.                   *                                     *
***************************************************************************
Newsgroups: comp.lang.c++
From: kwlee@conan.snu.ac.kr (Kwang-Woo Lee)
Subject: Want to Know Something About GNU C Compiler
Date: Wed, 6 Jan 93 10:11:09 GMT

To Everyone who knows GNU C compiler(gcc) well :

I want to know something about GNU C compiler. Followings are my questions.

	1) Internal structure of dynamic array
	2) Relation between pointer and dynamic array
	3) Precise syntax concerning dynamic array

I am not satisfied with GCC manual.
Please send the answers to me.

E-Mail: kwlee@conan.snu.ac.kr

Thanks in advance for your kind and quick reply.


Newsgroups: comp.lang.c++