Objective-C Issues

objc-and-c++

People ( From: lines )
 
 amirdam!sv@ai.mit.edu (Sankar Virdhagriswaran)
 athan@object.com (Andrew Athan)
 billb@jupiter.fnbc.com (Bill Burcham)
 Dennis Glatting 
 gdb0@lehigh.edu (GLENN BLANK)
 Geoffrey S. Knauth 
 Gregory B. Lampshire 
 Imran Qureshi 
 jjobe@mrj.com (jason jobe)
 martin@charon.neuroinformatik.ruhr-uni-bochum.de (Martin Lades)
 martin@charon.neuroinformatik.ruhr-uni-bochum.de (martin)
 MKK2@psuvm.psu.edu
 rms@gnu.ai.mit.edu (Richard Stallman)
 shirley@gothamcity.jsc.nasa.gov (Bill Shirley [CSC])
 ssircar@canon.com (Subrata Sircar)
 Steve_Naroff@next.com (Steve Naroff)
Subjects ( 35 mails )
 Re: Objective C library, Free Software Foundation
 Re: GNU Objective-C Project Has Begun
 Re: GNU Objective-C Project Has Begun
 Re: development priorities, beta testing
 Re: C++ and Objective-C; coding from interface specs
 Re: Your mission, should you choose to accept it. . .
 Re: Your mission, should you choose to accept it. . .
 C++ wrappers
 gcc-2.2.2 based -Objective-C++ Compiler
 Re: gnu-objc (Herring, Stroustrup, Novobilski)
 Objc++
 Re: objc wrappers about c++
 Re: Objective-C + C++ -> ObjC++
 Objective-C + C++ -> ObjC++
 Objective-C + C++ -> ObjC++
 [MKK2@psuvm.psu.edu: Re: Objective-C + C++ -> ObjC++]
 Re: Objective-C + C++ -> ObjC++
 Re: Objective-C + C++ -> ObjC++
 Re: Objective-C + C++ -> ObjC++
 Objective-C + C++ -> ObjC++
 Re: Objective-C + C++ -> ObjC++
 Re: Objective-C + C++ -> ObjC++
 Objective-C + C++ -> ObjC++
 Re: Objective-C + C++ -> ObjC++
 Re: Objective-C + C++ -> ObjC++
 Re: Objective-C + C++ -> ObjC++
 Re: Automatic object variables (Was: Objective-C + C++ -> ObjC++)
 Re: Objective-C + C++ -> ObjC++
 Re: Objective-C + C++ -> ObjC++
 Objective-C + C++ -> ObjC++
 ObjC++ direction
 Re: ObjC++ direction
 Re: One way to compile GCC-2.2.2 under NeXTSTEP 3.0.
 ObjC++ direction
 Re: Objective-C + C++ -> ObjC++
Document
From: MKK2@psuvm.psu.edu
Date:    Wed, 26 Aug 92 17:42 EDT
To: gsk@world.std.com
Subject: Re: Objective C library, Free Software Foundation

One thought I've had about ObjC class libraries:  What about taking C++
libraries and putting ObjC wrappers on them?  Of course, this would be a trifle
less efficient than writing pure ObjC libraries, but it also has some
advantages:

1.  It might be quicker.  Why reeinvent the wheel?
2.  With some experience, it might be automatable.  That is, a tool could
be built that reads C++ classes, and spits out ObjC versions, probably with
flags on parts that aren't easily convertible (e.g., multiple inheritance).
3.  People who need to port between C++ and ObjC platforms would have easier
times of it.

Disclaimer:  I know *nothing*!

From: martin@charon.neuroinformatik.ruhr-uni-bochum.de (Martin Lades)
Date: Thu, 3 Sep 92 00:17:38 +0200
To: gsk@marble.com
Subject: Re: GNU Objective-C Project Has Begun

Hello Geoffrey,

since I am using the mixed Objective-C/C++ approach,
I would be very interested in plans/progress/work assignment chunks
concerning the point of the communication between
the objective-C library and libg++.
At least the side concerning libg++ is affecting me heavily at this point.

Are there any schedules yet and distributed responsibilities?
Is there code to be used for some kind of interlaced compiler or
is the interaction going on on object basis?

Thanks for a reply.

Martin Lades
martin@neuroinformatik.ruhr-uni-bochum.de

From: martin@charon.neuroinformatik.ruhr-uni-bochum.de (Martin Lades)
Date: Thu, 3 Sep 92 00:36:00 +0200
To: gsk@marble.com
Subject: Re: GNU Objective-C Project Has Begun

Geoffrey,

Could you please put me on the mailing list?
(martin@neuroinformatik.ruhr-uni-bochum.de)

I use libg++ exactly for the usefulness you mentioned.
I also use another C++ lib called LEDA for efficient graph implementation.
The third thing is using NeXTstep for display purposes.
The interaction was pretty neat, concerning, that I could send C++ classes/objects
around with objective-C calls!
The whole package does Object recognition with DSP for feature extraction/convolution
stuff and an elastic matching/neural net approach for the recognition back end
for research purposes.

Distributed Objects on the other side like NeXT has them now should be much easier
in Objective-C. Was there discussion about this point also?

But the mixed approach depends a lot on what your compiler can do!
I just sent a mail this afternoon to next-prog concerning NeXTs broken cc++ compiler.


Later,

Martin

From: Steve_Naroff@next.com (Steve Naroff)
Date: Tue, 8 Sep 92 14:06:18 -0700
To: gsk@gnu.ai.mit.edu
Subject: Re: development priorities, beta testing
Cc: snaroff@next.com


> If we can make Objective-C and C++ operate together, we can leverage off of 
things like libg++ and Interviews, which already exist as free software.

We have done this...it has been shipping since NeXTSTEP version 2.0. Our goal 
was to allow developers with an existing base of C++ code to use it with 
NeXTSTEP's Objective-C based kits/tools. The problem we have had is keeping up 
with the rapidly changing (and often buggy) g++ compiler, given the limited 
resources we place on C++ at NeXT. Is this product what you mean when you say 
"operate together"? Nevertheless, we recently finished merging the latest 
version of Objective-C with the g++ in GCC version 2.2.2.  I hope this work 
can be reused!

snaroff.

From: Steve_Naroff@next.com (Steve Naroff)
Date: Tue, 8 Sep 92 16:19:16 -0700
To: gsk@marble.com
Subject: Re: C++ and Objective-C; coding from interface specs
Cc: snaroff@next.com
Status: RO


> What people want is to message C++ from Objective-C, and vice versa. Is this 
what your changes do?

Yes. Simply stated, it replaces the ANSI-C layer with C++. Since Objective-C 
tries hard to "stay out of C's way", this works out quite nicely. See 
/NextDeveloper/Examples/AppKit/CalculatorLab++ if you are interested in a small 
example of what I am talking about.

> If NeXT is making life easier for C++ programmers, a lot of people will be 
pleased.  I remember that at NeXTWORLD Expo, the attitude was, paraphrasing, 
"we've put C++ support in there, but we haven't made it very easy, because 
basically we don't think people should be wasting their time with C++."  I 
remember thinking that I too did not care much for C++, however those who did 
would interpret such remarks as "NeXT is being arrogant again, they love to go 
their own way.

We did this to make life easier for folks who already have an investment in 
C++. We are not religious about "C++ vs. Objective-C"...we would like the 2 
languages to coexist as much as possible. C++ is, however a 2nd class citizen 
in NeXTSTEP...given our heritage, limited resources, and the complexity of C++, 
we continue to focus on support for Objective-C. If we were being "arrogant", 
we would not have ported g++ and merged it with Objective-C. Oh well...I guess 
people love to throw stones!.

On the legal side, I believe re-engineering a class (from an interface spec) 
is kosher...in fact, we (i.e. NeXT) would like the FSF runtime to be modeled 
after our API, so that port headbutts are minimized. For example, 
objc_getClass("NXFoobar") will hopefully exist...I would hope the name and 
type signitures for common runtime hooks are maintained. I will verify this
with NeXT lawyers.

snaroff.

From: Steve_Naroff@next.com (Steve Naroff)
Date: Wed, 9 Sep 92 13:56:59 -0700
To: jr@alpo.media.com (J.R. Jesson)
Subject: Re: Your mission, should you choose to accept it. . .
Cc: gnu-objc@prep.ai.mit.edu, m@crito.stanford.edu (M Carling),
        mwagner@next.com


We released the source prior to shipping NeXTSTEP 3.0, a vast improvement over 
release 2.0 (thanks to M Carling at BaNG).

The compiler is based on GCC 1.93, the debugger is based on gdb 3.95.

We have integrated our latest version of Objective-C (with protocol support) 
with GCC 2.2.2...this is close to what we will ship with NeXTSTEP 486.

NeXT is happy to provide these mods so that they can be integrated into the 
GNU source tree.

snaroff.

From: Steve_Naroff@next.com (Steve Naroff)
Date: Wed, 9 Sep 92 15:27:08 -0700
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Your mission, should you choose to accept it. . .


Here are some brief answers to questions raised in response to my previous email...

> Where are the modifications?

The mods are in the NeXT source tree...I would like to hand this work off to 
the appropriate person asap. This person (to be named by Geoffrey S. Knauth) 
would be responsible for integrating this work into the FSF source tree...we 
could help if problems arise. Objective-C++ support has been integrated as well.

> When and where can I get the integrated version?

>From FSF, once the previous work is complete...this should happen before we 
ship NeXTSTEP 486. Once the 486 product ships, you can get an updated version 
of the BaNG source disk from NeXT.

> Does this mean that NeXTStep '486 will ship with a compiler based on 
GCC 2.2.2?  How about the debugger? 

NeXTSTEP 486 wil ship with GCC 2.2.2 (or later, depending on our schedule and 
the quality of GCC 2.2.2). We have no plans to upgrade the debugger at this time.

> If so, will an update to 3.0 be released at the same time?

The GNU sources will be released coincident with NeXTSTEP 486.

> Do you know anything about the Music Kit release? 

The Music Kit is unbundled in Release 3.0...see the release notes for more info.

> Will the GNU source and Music Kit stuff be available for FTP from
Next?

Not that I am aware of...

snaroff.

From: athan@object.com (Andrew Athan)
To: gnu-objc@prep.ai.mit.edu
Subject: C++ wrappers


One problem with wrapping C++ is taking care of the semantics 
(constructor/destructor, method parameter polymorphism, etc.)

Efficiency is less of a problem.  Even the simplest wrappers

@implementation FooWrapper
{
  Foo f;
}

- objcFooMethod:(int)x
{
  f.method(x);
}
@end

etc.  are still only going to be 1 method call more time consuming than using 
the C++ object as is and only 1 function call more time consuming than using a 
straight objc class.   One can also build an objc Class object using the 
runtime functions for the C++ class where the extra function call time would 
be completely avoided (though the runtime would have to be able to avoid 
passing the SEL hidden parameter).

Just to play devil's advocate:  Can someone justify for me the need to do this 
at all, since one of the goals is the ability to call C++ as part of objective-C
code.  Yes, one has to learn yet-another-syntax, but ...

Andrew Athan



From: martin@charon.neuroinformatik.ruhr-uni-bochum.de (Martin Lades)
Date: Thu, 10 Sep 92 18:25:53 +0200
To: gsk@marble.com
Subject: gcc-2.2.2 based -Objective-C++ Compiler

Hello

Since that could/should be the base for all development with mixed
Objective-C and C++ (it is pretty complete with templates, iostreams
and only the new NeXT stuff is missing)
the compiler would be priority one in the list of necessary developments.
As the guy from NeXT also stated, he wants to hand it off ASAP.
Who is involved? What happens?
Is there a schedule yet? How much work is involved?
What is the partitioning?


Thanks,

Martin

From: Steve_Naroff@next.com (Steve Naroff)
Date: Thu, 10 Sep 92 17:06:59 -0700
To: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Re: gnu-objc (Herring, Stroustrup, Novobilski)
Cc: gsk@marble.com, snaroff@next.com


Thanks...I couldn't agree more. btw, the Objective-C++ work we did is very 
straightforward...the goal is to enable programmers to use objects developed 
in both languages within the same source module (without cumbersome "wrappers"). 
The philosophy is simple, C++ should be as convenient to use from Objective-C 
as ANSI-C is. This makes it really easy to use C++ libraries from Objective-C, 
which is an important goal. For example, C++ objects can be "a-part-of" (i.e. 
reference) Objective-C objects (and vice-versa). However C++ objects can NOT 
inherit from Objective-C objects (and vice-versa)...I thought this was strange, 
hard to solve, and not so useful.

Since both languages have very different goals (C++ a "better C"...Objective-C 
a "thin Smalltalk veneer"), there were very few syntactic or semantic 
ambiquities. Both languages retain their native syntax/semantics and performance 
characteristics. You could imagine unifying the object models, however we made 
no attempt to do this (it wasn't clear that this was a worthwhile goal).

snaroff.

Date: Sat, 12 Sep 92 05:56:49 EDT
From: jjobe@mrj.com (jason jobe)
To: gnu-objc@prep.ai.mit.edu
Subject: Objc++

As indicated in previous mail one of the objectives is to make it easy to
work with both ObjC and C++.  In line with that:

1) Some talk about ObjC class wrappers for C++ Classes. Is the real goal
   to be able to use the same method calling syntax for both? ie given
   a C++ construct "foo->draw (myCanvas);" should "[foo draw:myCanvas];"
   be permitted/encouraged/supported. If so, is it a straight translation or
   do we have some different dispatcher for C++ methods calls or something.

2) Does one want more runtime info about C++ classes? If so, what?
   I seem to recall  something along these lines discussed in the context 
   of InterViews (from Stanford).

I also have some other questions/comments:

1) If protocols use versions (a good idea) could one cleanly indicate
   compatabilty between different versions? For example,

	@protocol 
	- draw;
	- erase;
	@end
and
	@protocol 
	- draw;
	- erase;
	- cache;
	@end
Can Foo2 subsume Foo1? If I conformTo Foo2 then I also conformTo Foo1. Should
this be ok?

2) Can/will dynamically loadable objects be supported on other platforms?

3) What about some standard way resolve name space conflicts between
   lib sets? Say I have 3 different "List" classes, how can I mix and match?
   Do I, as a lib builder always have to prepend my intiails or something
   ridiculous like that? InterViews had some work around but this seems worth
   supporting.


I rather like the idea of ObjC++.  This should be fun.

Jason

Date:    Fri, 28 Aug 92 10:44 EDT
From: 
Subject: Re: objc wrappers about c++
To: gsk@marble.com

I didn't mean that wrappers around C++ was the ideal approach.  I meant
that it might be a good initial step.  1.  create the wrappers.  This gets
people something they can use.  2a.  Rewrite the most often used ones
in ObjC.  2b.  Create a tool that will take a C++ class an automagically
create a wrapper for it.  3.  Based on 2a, create a tool that translates
C++ into ObjC.

You can start with 2a, instead, but it'll be a much longer wait before
something comes out.

just thinking...

Date: Tue, 29 Sep 92 09:29:33 CDT
From: shirley@gothamcity.jsc.nasa.gov (Bill Shirley [CSC])
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Objective-C + C++ -> ObjC++

|> From: jjobe@mrj.com (jason jobe)
|> 
|> Volunteers needed.
|> To recap:
|> 
|> COMMUNICATIONS BETWEEN OBJECTIVE-C AND C++
|> 
|> Make the Objective-C library and libg++ help each other;
|> investigate language enhancements to make this easy.

First off I know Objective-C (and of course C) much better than C++
(read the following accordingly)

|> 
|> As the ObjC++ manager I thought throw out some ideas of my own.
|> (Please beware of my own NeXT bias)
|> 
|> To me this suggest several things:
|> 
|> 1 ) We want to make it easy to  equate Objc and C++ class structures.
				   ~~~~~~
Do you mean the internal representation of the classes?

|> 
|> 2)  We clearly need more info on C++ classes at runtime. 

clearly

|> I seem to recall  
|> some sort of "dossier" being suggested in the context of Stanford's
|> InterViews (anybody know about this?).

I read the thesis on Interviews and tried to learn how to use it once.
The thesis said that C++ had constrained some of it's design decisions
and that they had to work around C++ limitations to implement it as such.
There decision (on language) was based solely on availability.  (If ObjC
had been widely available (ala gcc) at the time, I can only think they
would have made a better product.)

The thesis even suggested future work with a language w/o the limitations.
Maybe someone at Stanford wants to reimplement it in ObjC?  Prob'ly not.

 *personal opinion*
(Knowing Xlib, Xt, and NeXTSTEP)
I found Interviews obtuse and contrived, even the simplest programs were
difficult to make run.  Most of the examples they included with the
release would randomly dump core, with no explanation.  I don't know
if I was working with an earlier flawwed product or if it has improved.

|> 3) Perhaps one should encourage consistent message syntax.
|>      Can/should  "[graphic draw]" be equivalent to "graphic->draw()" ?
|>     If so, what about "[canvas draw:graphic at:point]" vs. 
|> 	"canvas->drawAt (graphic, point)"

maybe the maping would be easier and straightforward if it was similar to:

canvas->drawAt (graphic, point)  ==> [canvas drawAt: graphic  :point];

that's not as simple to read, but then you should have defined it as an ObjC
class, if you wanted that.

|> 4)  Routing C++ method calls through an Objc-like dispatcher WHEN DESIRED.

Sounds good to me.  How would you denote when to dispatch or not.

|> Other Questions/Issues raised:
|> 
|> 1)  How should operator overloading be applied to Objc classes?

  a)  answer = [array operator+: another];  ?
	I think this should be (close to) the internal representation
	whether we allow the syntactic sugar of

  b)  answer = array + another;
	is another question.
  

|> 2)  Are we going to add the static object instantiation that NeXT left out?

If you want a Cpp2ObjC "processor" then this will be needed. (I think)

|> 3)  Should we try to provide method name overloading
|>   (based on argument types)  for Objc methods?

Hmm, that would be interesting.

|> 
|> 
|> Hopefully this will get the ball rolling.

roll, roll

|> 
|> Jason
|> jjobe@mrj.com
|> GNU Objc ObjC++ Manager
|> 


 Bill Shirley
 shirley@fdr.jsc.nasa.gov

Date: Mon, 28 Sep 92 23:14:05 EDT
From: jjobe@mrj.com (jason jobe)
To: gnu-objc@prep.ai.mit.edu
Subject: Objective-C + C++ -> ObjC++

Jason queries:

[ stuff deleted ]

> 1)  How should operator overloading be applied to Objc classes?

	IMHO, this is not an extraordinary added value.  I would say, just make sure 
that overloaded operators continue to work in a C++ context, but don't support 
them for Objective-C objects.
	
> 2)  Are we going to add the static object instantiation that NeXT left out?

	PLEASE!  More specifically, _automatic_ object instantiation, so that I can 
declare an object at the top of my method/function and have it automagically 
freed when I return from my method/function.
	I WOULD CALL THIS A HUGE WIN.
	
> 3)  Should we try to provide method name overloading (based on argument
> types) for Objc methods?

	Absolutely.  To tell you the truth, _I_ might only use it once in a blue moon, 
but its availability doesn't get in my way (if my style dictates no overloading, 
I just won't write overloaded methods).  Maybe have a special syntax for 
declaring overloadable parameters and return values?  I'm putting on my asbestos 
suit now . . . .  8')


	Ta-ta,
	- Kurt

Kurt Starsinic                  #   kstar@medequity.com
Director of Systems             #     (NeXTmail preferred)
MedEquity, Inc.                 #
555 North Lane, Suite 6183      #     (215) 397-0201 voice
Conshohocken, PA  19428         #           397-0203 fax

The opinions expressed by me just might be those of MedEquity, Inc.

   "There is nothing in the world that will take
    the chip off one's shoulder like a feeling of success."
       - Thomas Wolfe

Date: Mon, 28 Sep 92 23:14:05 EDT
From: jjobe@mrj.com (jason jobe)
To: gnu-objc@prep.ai.mit.edu
Subject: Objective-C + C++ -> ObjC++

Volunteers needed.
To recap:

COMMUNICATIONS BETWEEN OBJECTIVE-C AND C++

Make the Objective-C library and libg++ help each other;
investigate language enhancements to make this easy.

As the ObjC++ manager I thought throw out some ideas of my own.
(Please beware of my own NeXT bias)

To me this suggest several things:

1 ) We want to make it easy to  equate Objc and C++ class structures.

2)  We clearly need more info on C++ classes at runtime.  I seem to recall  
some sort of "dossier" being suggested in the context of Stanford's InterViews
(anybody know about this?).

3) Perhaps one should encourage consistent message syntax.
     Can/should  "[graphic draw]" be equivalent to "graphic->draw()" ?
    If so, what about "[canvas draw:graphic at:point]" vs. 
	"canvas->drawAt (graphic, point)"

4)  Routing C++ method calls through an Objc-like dispatcher WHEN DESIRED.

Other Questions/Issues raised:

1)  How should operator overloading be applied to Objc classes?
2)  Are we going to add the static object instantiation that NeXT left out?
3)  Should we try to provide method name overloading (based on argument types)
 for Objc methods?


Hopefully this will get the ball rolling.

Jason
jjobe@mrj.com
GNU Objc ObjC++ Manager


From: Geoffrey S. Knauth 
Date: Tue, 29 Sep 92 11:28:22 -0400
To: gsk
Subject: [MKK2@psuvm.psu.edu: Re: Objective-C + C++ -> ObjC++]

Return-Path: 
From: MKK2@psuvm.psu.edu
Date:    Tue, 29 Sep 92 02:07 EDT
Subject: Re: Objective-C + C++ -> ObjC++
To: jjobe@mrj.com
Cc: gnu-objc@prep.ai.mit.edu
In-Reply-To:  jjobe AT mrj.com   -- Mon, 28 Sep 92 23:14:05 EDT


>1 ) We want to make it easy to  equate Objc and C++ class structures.

One way to do this is to automate the process.  If one has C++ classes, but
wants to live in an Obj-C world, there should be a filter that reads the
C++ interface and outputs an Obj-C wrapper for it.  Pascal to C exists,
why not C++ to Obj-C and vice versa?  (It's easy for me to suggest this
because I have absolutely no qualifications to actually do it 8-) 8-)

>3)  Should we try to provide method name overloading (based on argument types)
> for Objc methods?

The math major lurking in my youth has always regretted this design decision
of Objective-C.  Surely, a function is both a name *and* a domain *and* a
range.  So I vote YES to name overloading based on argument and return value
types.  Again, I'm safe from ever being asked to implement this, at least by
people who actually want to see it done.

However, I don't think extending the language is our real mission here.
Working implementation first, redesign the language later.

>Hopefully this will get the ball rolling.

>Jason
>jjobe@mrj.com
>GNU Objc ObjC++ Manager


Date: Tue, 29 Sep 92 11:03:01 -0500
From: Gregory B. Lampshire 
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Objective-C + C++ -> ObjC++
Reply-To: gbol@rglnext.geol.vt.edu

I am confused about operator overloading, C++ and ObjC. I am not a compiler guy 
so correct me if I am wrong.


As long as the overloaded operator occured in [object msg: (arg)] construct it 
would be easy to add operator overloading in a small way in that 'msg' is just 
a string which gets looked up in a table at run time to decide which function 
to call (the function name itself doesn't have to be change to some mangled 
name if one assumes that the declaration for the selector "msg" only takes one 
type of arg). It shouldn't be that difficult to get rid of the ":" after the 
method name as long as one assumes that it is a binary message with only one 
selector and one argument.

Such a scheme is not difficult to add to ObjC. 

What would be more difficult is to add it such that the example below would work.  
Then each selector "msg" has to be mangled such that the msg name and type of 
arguments were reflected in the final function call and so that not just binary 
operators could be easily used.

This is much more difficult.

I take it the discussion is about the second way and not about the first 
limited way.

Is this right?  I have done alot of Smalltalk programming and would like to see 
the second way but realize that it is quite a stretch for the current compiler.






//----------an example---------------

#import 
@interface MyClass: Object
{
	int nInt;
	float nFloat;
}

- add: (int) a;
- add: (float) a;
- + (int) a;
- + (float) a;
@end

@implementation MyClass

- add: (int) a
{
	printf("blah int\n");
	return self;
}
- add: (float) a
{
	printf("blah float\n");
	return self;
}
- + (float) a
{
	printf("blah float +\n");
	return self;
}
- + (int) a
{
	printf("blah int +\n");
	return self;
}
@end

int main()
{
	id aMyClass;

	aMyClass = [[MyClass new] init];
	[aMyClass add: 2];
	[aMyClass add: 3.3];
	[aMyClass + 2];
	[aMyClass + 3.3];

}

Date: Tue, 29 Sep 1992 11:30:54 EDT
From: gdb0@lehigh.edu (GLENN BLANK)
Subject: Re: Objective-C + C++ -> ObjC++
To: shirley@gothamcity.jsc.nasa.gov (Bill Shirley [CSC])
Cc: gnu-objc@prep.ai.mit.edu

>|> COMMUNICATIONS BETWEEN OBJECTIVE-C AND C++
>
>(Knowing Xlib, Xt, and NeXTSTEP)
>I found Interviews obtuse and contrived, even the simplest programs were
>difficult to make run.  Most of the examples they included with the
>release would randomly dump core, with no explanation.  I don't know
>if I was working with an earlier flawwed product or if it has improved.
>
My experience with Interviews echos yours.  It is also difficult to
combine with other libraries.  I would not like to see Interviews
endorsed by association with gcc.  Imitating smalltalk's treatment
of user interface facilties 

> Bill Shirley
> shirley@fdr.jsc.nasa.gov
>

From: billb@jupiter.fnbc.com (Bill Burcham)
Date: Tue, 29 Sep 92 11:52:27 -0500
To: gnu-objc@prep.ai.mit.edu
Subject: Objective-C + C++ -> ObjC++

> Begin forwarded message:
>
> Date: Tue, 29 Sep 92 10:09:20 -0400
> From: Kurt D. Starsinic 
> To: gnu-objc@prep.ai.mit.edu
> Subject: Re:  Objective-C + C++ -> ObjC++
> Reply-To: kurt@medequity.com
>
> Begin forwarded message:
> From: jjobe@mrj.com (jason jobe)
> Jason queries:
>
> [ stuff deleted ]
>
> > 1)  How should operator overloading be applied to Objc classes?
>
> 	IMHO, this is not an extraordinary added value.  I would
> say, just make sure that overloaded operators continue
> to work in a C++ context, but don't support them for
> Objective-C objects.
>

(McMahon on) YES, YOU ARE CORRECT SIR! (McMahon off)

>
> 	Ta-ta,
> 	- Kurt
>
Bill Burcham

Date: Tue, 29 Sep 92 09:39:36 -0700
From: Imran Qureshi 
Subject: Re: Objective-C + C++ -> ObjC++
To: MKK2@psuvm.psu.edu
Cc: gnu-objc@prep.ai.mit.edu

-----
One way to do this is to automate the process.  If one has C++ classes, but
wants to live in an Obj-C world, there should be a filter that reads the
C++ interface and outputs an Obj-C wrapper for it.  Pascal to C exists,
why not C++ to Obj-C and vice versa?  (It's easy for me to suggest this
because I have absolutely no qualifications to actually do it 8-) 8-)
-----

I am working on a parser that does ObjC->C++.  The parsing is completed.  Most 
of the conversion is also done.  I'll put it on the archives soon.

Ciao,

Imran

From: Steve_Naroff@next.com (Steve Naroff)
Date: Tue, 29 Sep 92 11:13:42 -0700
To: jjobe@mrj.com (jason jobe)
Subject: Re: Objective-C + C++ -> ObjC++
Cc: gnu-objc@prep.ai.mit.edu


If the goal is to improve communication between Objective-C and C++ class 
libraries, why don't you just use the Objective-C++ compiler developed by NeXT.

Objective-C++ accomplishes your stated goal. It enables programmers to use 
objects developed in both languages within the same source module (without 
cumbersome "wrappers"). The philosophy is simple, C++ should be as convenient 
to use from Objective-C as ANSI-C is. This makes it really easy to use C++ 
libraries from Objective-C, which is an important goal. For example, C++ 
objects can be "a-part-of" (i.e. reference) Objective-C objects (and 
vice-versa). However C++ objects can NOT inherit from Objective-C objects 
(and vice-versa)...I thought this was strange, hard to solve, and not so useful.

Since both languages have very different goals (C++ a "better C"...
Objective-C a "thin Smalltalk veneer"), there were very few syntactic or 
semantic ambiguities. Both languages retain their native syntax/semantics and 
performance characteristics. You could imagine unifying the object models, 
however we made no attempt to do this. It wasn't clear that "unifying the 
object models" is what developers wanted.

It just struck me that our high level goals are very similar, yet there is 
much discussion about adding language features that are orthogonal to improved 
communication between ObjC/C++. For example, adding overloading to Objective-C 
may be a worthwhile feature, however it has very little to do with improved 
communication.

I am not assuming that NeXT Objective-C++ will solve the group's problems, I 
just want to understand your goals for the project.

If the goals are fuzzy, Objective-C will start approaching the complexity of 
C++, which I know is bad. Extending C++ also seems like a loosing proposition...
isn't the popularity of C++ mostly due to its portability?

snaroff.

Date: Tue, 29 Sep 92 15:24:00 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
To: Steve_Naroff@next.com
Cc: jjobe@mrj.com, gnu-objc@prep.ai.mit.edu
Subject: Objective-C + C++ -> ObjC++

It would seem that Objective C++ would allow Objective C programs to
use C++ library classes, by means of C++ constructs.

That is useful, but I think what most Objective C programmers want is
to be able to use those library classes by means of Objective C
constructs only.  Does Objective C++ make this possible?

Date: Tue, 29 Sep 92 17:55:26 GMT-0800
From: amirdam!sv@ai.mit.edu (Sankar Virdhagriswaran)
To: ai-lab!" jjobe@mrj.com"
Subject: Re: Objective-C + C++ -> ObjC++
Cc: ai-lab!"gnu-objc@prep.ai.mit.edu"



I would like to vote for the other way also.  Use Objective-C library classes 
from C++ using C++ constructs.


Date: Wed, 30 Sep 92 01:07:46 -0700
From: Dennis Glatting 
To: uunet!next.com!Steve_Naroff@uunet.uu.net (Steve Naroff)
Subject: Re: Objective-C + C++ -> ObjC++
Cc: jjobe@mrj.com (jason jobe), gnu-objc@prep.ai.mit.edu

> If the goal is to improve communication between
> Objective-C and C++ class libraries, why don't you just
> use the Objective-C++ compiler developed by NeXT.
>

I'm doing a lot of work with this now.  There are some problems but they are 
tool bugs (compiler, gdb, DBKit header file decls, etc).  My c++ objects call 
ObjC objects, ObjC objects call c++ objects.  It works well. 

One problem though is that I can't encapsulate c++ objects in a ObjC class decl.  
The c++ objects must be pointers instantiated using 'new' in the ObjC designated 
initializer.  Complain.  Complain.


-dpg

From: billb@jupiter.fnbc.com (Bill Burcham)
Date: Wed, 30 Sep 92 09:26:59 -0500
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Objective-C + C++ -> ObjC++
Cc: ssircar@canon.com (Subrata Sircar)

Subrata Sircar  writes:
> Kurt D. Starsinic  writes:
> ! PLEASE! More specifically, _automatic_ object
> ! instantiation, so that I can declare an object at the top
> ! of my method/function and have it automagically freed when
> ! I return from my method/function. I WOULD CALL THIS A HUGE
> ! WIN.
>
> This would be nice - objects as automatic function/method variables.
>

NeXT Object class provides allocFromZone:.  I think an allocFromAutomatic would 
be an elegant approach.  allocFromAutomatic would use alloca() (see MALLOC(3)) 
to allocate memory from the stack.
---
+--------------------------------+----------------------------------+
|          Bill Burcham          | "The real world is the place     |
|     Protector of the Realm     |  between your toilet at home and |
| First National Bank of Chicago |  your toilet at work."           |
|    billb@fnbc.com  (NeXTmail)  |                                  |
+--------------------------------+----------------------------------+

Date: Wed, 30 Sep 92 11:25:14 -0400
From: athan@object.com (Andrew Athan)
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Automatic object variables (Was: Objective-C + C++ -> ObjC++)



Begin forwarded message:

Date: Wed, 30 Sep 92 11:22:53 -0400
From: athan@object.com (Andrew Athan)
To: athan
Subject: Re: Objective-C + C++ -> ObjC++

Bill Burcham writes:
>NeXT Object class provides allocFromZone:.  I think an allocFromAutomatic 
>would be an elegant approach.  allocFromAutomatic would use alloca() 
(see >MALLOC(3)) to allocate memory from the stack.

This would solve the problem only in the case of objects that do not have 
out-of-line storage associated with them.  E.g.,

@interface MyString:Object
{
  char *theBuffer;
}
@end

would end up leaving whatever "theBuffer" points to unfreed on function return.

The "problem" with automatic object allocation is that it introduces the need 
for constructor & destructor syntax/semantics.

Andrew Athan
Objective Technologies, Inc.


From: MKK2@psuvm.psu.edu
Date:    Wed, 30 Sep 92 14:35 EDT
Subject: Re: Objective-C + C++ -> ObjC++
To: gnu-objc@prep.ai.mit.edu

>That is useful, but I think what most Objective C programmers want is
>to be able to use those library classes by means of Objective C
>constructs only.  Does Objective C++ make this possible?

Not by magic.  Basically, there are so few syntax clashes between C++
and Objective-C that the OC user can just include C++ when appropriate.

To disguise C++ as Objective-C, a wrapper can be used.  Just create
an Objective-C class that has one instance variable, an instance of the
C++ class.  Then add an OC method for each of the C++ methods that you
want to appear in the interface (or perhaps internally).  Those methods just
call the appropriate C++ method.

Note that this approach allows later subclassing og the OC class.

Disclaimer:  I've thought about this, but I've never actually done it.
I could be missing a big gotcha here.  Naroff?  What do you say?

This version of "using a wrapper" is something I'd like to see
automated.  Perhaps a filter could read C++ the Foo.h file for class Foo
in C++, and spit out a Foo.[hm] in Obj-C that offers access to C++
classes as if they were Obj-C classes.  Of course, a filter that goes the
other way would be great for C++ programmers, but this is the GNU Objective-C
project now, isn't it.  8-)

I am not a compiler-knowlegeable person, so I have no idea of the ins and
outs of integrating Obj-C and C++ transparently.  This wrapper solution
appeals to the old Unix spirit of solving 70% of the problem with 20%
of the work, adding another little tool to the tollkit, and getting back
to work.

Lastly, I want to make an editorial comment:  In my opinion, this group
should steer away from inventing a new language, at least for now.  Let's
get a working Objective-C out the door, with enough tools and class
libraries that people will be inclined to use it.

Lee Sailer
GNU Objective-C Class Library Map Manager

Date: Wed, 30 Sep 92 09:28:38 -0700
From: Dennis Glatting 
To: uunet!gothamcity.jsc.nasa.gov!shirley@uunet.uu.net (Bill Shirley [CSC])
Subject: Objective-C + C++ -> ObjC++
Cc: gnu-objc@prep.ai.mit.edu

> |> 4)  Routing C++ method calls through an Objc-like
> dispatcher WHEN DESIRED. 

> 

> 

> Sounds good to me.  How would you denote when to dispatch or not.
> 


If you chose to not go thru the dispatcher then how are you going to  
handle posing and inheritance?  Perhaps my question should be:  What  
does WHEN DESIRED mean?  Perhaps an example would be useful.

-dpg


Date: Thu, 1 Oct 92 23:18:21 EDT
From: jjobe@mrj.com (jason jobe)
To: gnu-objc@prep.ai.mit.edu
Subject: ObjC++ direction

Although not directly related our objectives I would also like to ask/propose
the following:  How about providing some scoping syntax (maybe a precompiler
hack) to help resolve name space problems with regard to Class names.
InterViews used macros with some automated preporcessing to prepend every
class name with "iv". This works ok but I think some standard mechanism 
should be provided. How should I specify which "List" implementation I want
to use from which library?

And now to business.
I appreciate all the input for ObjC++. While this effort will hopefully
lead to new and interesting language features we need to pick a few
objectives to focus on initially. Also, lets get something out the door
that works and optimize later.
Here's the gist:

1) The primary focus is on the ObjC programmer.

2) Minimize linguistic changes.

3) Some sort ObjC class should "wrap" around a C++ one. This process
   should be maximaly automated.

4) Some runtime information about desired C++ classes should be provided.
   Something needs to be provided for dynamic method dispatching.
   This seems useful and desired by many respondents.

5) Forget (for now) such desirables as overloading anything in ObjC.
   Although I think C++ should recognize "id" and ObjC class pointers so
   C++ operator overloading could be applied to ObjC objects. NOTE: If this 
   becomes to complicated then skip it.
   Example:
     int operator+ (id objcObject, int x)  {
       int y = [objcObject integerValue];
       return (x + y);
     }
   This may be a non-issue. I have yet to try it.


Problems seem to revolve around the appropriate control over
construction/destruction and initialization of C++ objects.

Questions: 

1) Should a central dispatcher be provided for calling C++ methods
or should we go for simple inline wrappers that make the C++ object 
"look" like an ObjcC one?

2) Should there be a real ObjC class which stands in for its C++
counterpart? (I think so. Perhaps a new base class ObjectPlus.)

These excerpts sum it it well.

(Richard Stallman):
Using Objective C objects from C++ is a completely different problem.
I suggest separating the two problems.  The more important one is
using C++ objects from Objective C...

(Richard Stallman):
I like the idea of a tool to write a program that gets added to the
application to enable it to use a particular C++ class.

(Steve Naroff)
An interesting project from my perspective is "Dynamic C++", which is
merely C++ with a rich runtime model (like Objective-C). This would
add very little syntax to C++. It means adding the notion of a
dynamic type to C++ (like "id", which is a "void *" for objects).
Sending messages to an object of anonymous type would have the same
semantics as Objective-C.

ObjC++ compiler hackers wanted. Lots of fun but no money.
Call Jason for a good time (jjobe@mrj.com)

Regards,
Jason


From: MKK2@psuvm.psu.edu
Date:    Fri, 2 Oct 92 17:10 EDT
Subject: Re: ObjC++ direction
To: gnu-objc@prep.ai.mit.edu

>Here's the gist:

>1) The primary focus is on the ObjC programmer.

Yes, but I'd say the primary focus is on making GNU ObjC as usable as GNU
c++.

>2) Minimize linguistic changes.

Agreed.  A sure way to go astray is to invent a new language without
meaning to. 8-)

>3) Some sort ObjC class should "wrap" around a C++ one. This process
>   should be maximaly automated.

Yes.  The Map Team is going to look at doing this by hand for a while, so
we'll be able to recommend what needs to be automated.  I might add that,
as soon as useful ObjC classes appear which are of use to C++ programmers,
then C++ wrappers for the ObjC classes will be needed.  As efficiency
issues become important, wrappers can be transparently replaced by native
implementations.


>4) Some runtime information about desired C++ classes should be provided.
>   Something needs to be provided for dynamic method dispatching.
>   This seems useful and desired by many respondents.

Maybe, but only so long as it doesn't add features that aren't available
from other good C++ compilers.  That is, we don't want to redefine either
language.

>5) Forget (for now) such desirables as overloading anything in ObjC.
>   Although I think C++ should recognize "id" and ObjC class pointers so
>   C++ operator overloading could be applied to ObjC objects. NOTE: If this
>   becomes to complicated then skip it.
>   Example:
>     int operator+ (id objcObject, int x)  {
>       int y = [objcObject integerValue];
>       return (x + y);
>     }
>   This may be a non-issue. I have yet to try it.

  This is a language change.  I'm not against new languages--far
from it--and I think there are folks here who are qualified to design
(ObjC++)++, but as you said at the top, first things first.



From: martin@charon.neuroinformatik.ruhr-uni-bochum.de (martin)
Date: Sat, 3 Oct 92 18:19:41 +0100
To: Geoffrey S. Knauth 
Subject: Re: One way to compile GCC-2.2.2 under NeXTSTEP 3.0.

Hi,

maybe I can cut down some of my code, let me try. Otherwise it is pretty large.
I have about 20k in the interfacing module between several hundred kB C++
code and a Nextstep interface. I will come back to you if I have example code.

Just mixing line by line and sending C++ objects by pointers as arguments to
Objective-C is a wonderful feature, as long as it works.

Martin

Date: Fri, 2 Oct 92 20:26:41 EDT
From: jjobe@mrj.com (jason jobe)
To: MKK2@psuvm.psu.edu
Cc: gnu-objc@prep.ai.mit.edu
Subject: ObjC++ direction

>   Example:
>     int operator+ (id objcObject, int x)  {
>       int y = [objcObject integerValue];
>       return (x + y);
>     }
>   This may be a non-issue. I have yet to try it.

>  This is a language change.  I'm not against new languages--far
> from it--and I think there are folks here who are qualified to design
> (ObjC++)++, but as you said at the top, first things first.

In trying the above example I got
  "operator has no user-defined argument type"

Is it really a language change? It seems to me that "id" should be like
any other programmer defined type. If so then the example should be 
both acceptable and proper. Then we could reasonable things by passing
around ids to C++ methods and such.  In fact, why doesn't this just work?

Testing continues.
Jason



From: ssircar@canon.com (Subrata Sircar)
Date: Tue, 29 Sep 92 18:02:44 PDT
To: ObjC@canon.com
Subject: Re: Objective-C + C++ -> ObjC++

jjobe@mrj.com (jason jobe) writes:
>1 ) We want to make it easy to equate Objc and C++ class 

>structures. 


This alone would be a tremendous advantage.  I'd really like not to care about  
whether a class was one or the other until I needed a C++ advantage like  
multiple-inheiritance.

>3) Perhaps one should encourage consistent message syntax. 

>Can/should "[graphic draw]" be equivalent to 

>"graphic->draw()" ? If so, what about "[canvas 

>draw:graphic at:point]" vs. "canvas->drawAt (graphic, 

>point)" 


If this is done, shouldn't it work both ways?  i.e. no matter what type an  
object is, [graphic draw] and graphic->draw() should be the same thing.

One area where I don't support symmetry is in overloading: I don't want to see  
overloading of Objective-C methods, yet, because I don't think it adds that  
much.

>2) Are we going to add the static object instantiation 

>that NeXT left out? 


Could you elaborate?  What is lacking in the ...allocFromZone] init] type  
scheme?

Kurt D. Starsinic  writes:
! PLEASE! More specifically, _automatic_ object 

! instantiation, so that I can declare an object at the top 

! of my method/function and have it automagically freed when 

! I return from my method/function. I WOULD CALL THIS A HUGE 

! WIN. 


This would be nice - objects as automatic function/method variables.

rms@gnu.ai.mit.edu (Richard Stallman) writes:
* [...ellipis by sks ...] I think what most Objective C 

* programmers want is to be able to use those library 

* classes by means of Objective C constructs only. Does 

* Objective C++ make this possible? 


This is what I want - I don't know about the rest of you :<)
	
---
Subrata Sircar|ssircar@canon.com (NextMail ok)|Prophet & SPAMIT Charter Member
Canon Information Systems and I do not share the same views on everything.
"All I have to do is write a thesis, but how hard could that be?" - Jordan
"I seem to suffer from irrelevant flashbacks." - Paul, PAUL THE SAMURAI #1
Statistics
 filename:           objc-and-c++
 number of mails:    35
 number of writers:  17
 line count:         1229
 word count:         6775
 character count:    42371

created by Helge Hess ( helge@mdlink.de )
MDlink online service center ( www.mdlink.de )