First alpha release of d2c CodeWarrior plugin available 
Author Message
 First alpha release of d2c CodeWarrior plugin available

Dear Dylan Enthusiast,

I am glad to announce the availability of the d2c v2.3.3 translator plugin
for CodeWarrior.

Gwydion Dylan is a Dylan to C language translator.
"Gwydion Dylan PPC" is a compiler plugin for the Metrowerks CodeWarrior
integrated development environment, derived from the open source code base
of the Gwydion Dylan project.

Please visit http://www.*-*-*.com/ for details.
Please visit http://www.*-*-*.com/ for details to CodeWarrior.

This is a power-user release.
You have to know what you do.
Bear in mind that this is an alpha quality release.
Timly release was more important than thorough testing.
Several bugs are known.
It is strongly recommended that you have MacsBug installed.
It is strongly recommended that you have experience with mac-d2c v2.3.3r2.

Requirements:

- Power Macintosh with 96 MB RAM
- CodeWarrior Pro 5.3 for Mac (earlier versions may work, but not tested)
- 50 MB memory partition assigned to CodeWarrior

Features:

- Translator plugin
- Preference panel
- Gwydion Dylan Release 2.3.3 functionality

Non-Features:

- Preference panel not fully functional
- no support library files
- No source code (yet)

Download:

- ftp://berlin.ccc.de/pub/gd/MacOS/d2cPlugin2.3.3a1.sit.hqx
- iDisk: public area of: gabor, file: d2cPlugin2.3.3a1.sit,
   at: http://www.*-*-*.com/

Bugs:


- success stories also welcome :-)

Thanks:

- Gwydion Dylan Maintainers, for great work
- Rob Myers, for mac-d2c and being my first tester
- Gareth Baker, for testing
- Silke Klein, for patience

Other:

- Dylan(tm) is a trademark of Apple Computer, Inc.
- Metrowerks(tm) and CodeWarrior(R) are (registered) trademarks of
  Metrowerks, Inc.
- Read the release notes.
- USE AT YOUR OWN RISK.
- Have a nice day.
- Today is my 32nd birthday.

Enjoy,

    Gabor



Wed, 16 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available
        Just curious, why do we need to go from Dylan to C ? I would think
C/C++ to Dylan would be more useful ? Can this take C and go the other way ?

Shawn



Fri, 18 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available

Quote:

> Just curious, why do we need to go from Dylan to C ?

For the same reason that there exist compilers for C++, fortran, Ada,
Scheme, Eiffel (and many other languages) that produce output in C rather
than in machine code or assembly language:

- it's easier

- every machine in the world has a C compiler

- you don't need to worry about instruction set styles and encodings and
register architectures on jillions of different machines (or even on one)

- you don't need to worry about instruction selection and scheduling and
so forth either.

- you don't need to worry about runtime conventions such as how to call
functions and which registers to save and so forth

- you don't have to worry about how to call OS functions and standard libraries

The C compiler already knows all that stuff.  Someone worked {*filter*} it.

Quote:
> I would think C/C++ to Dylan would be more useful ? Can this take C
> and go the other way ?

The C output isn't intended to be human-readable (although d2c takes some
care to preserve function and variable names etc in the generated code --
much better than, say, CFront -- the original C++ compiler -- did).

You don't use d2c to convert your Dylan program to C and then work on it
some more in C.  You program in Dylan.  d2c compiles Dylan into C, and
then automatically calls the C compiler to produce a runnable program.
You usually never even look at the C code.

The problem of taking a program in one language and turning it into a
human readable, idiomatic, maintainable program in another programming
language is a *much* harder one.  Well beyond the current state of the
art, I'd say.

-- Bruce



Fri, 18 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available

Quote:
> For the same reason that there exist compilers for C++, FORTRAN, Ada,
> Scheme, Eiffel (and many other languages) that produce output in C rather
> than in machine code or assembly language:

> - it's easier

Benefit then to using Dylan ? Because its simpler to learn and utilize ?

Quote:

> - every machine in the world has a C compiler

Then why not just use one of them ?

Quote:

> - you don't need to worry about instruction set styles and encodings and
> register architectures on jillions of different machines (or even on one)

> - you don't need to worry about instruction selection and scheduling and
> so forth either.

> - you don't need to worry about runtime conventions such as how to call
> functions and which registers to save and so forth

> - you don't have to worry about how to call OS functions and standard
libraries

> The C compiler already knows all that stuff.  Someone worked {*filter*} it.

Then there is an advantage to using the C code relating to portability,
functionality, and speed optimizations ? It would be to much work to make an
optimized Dylan compiler for every situation ?

Quote:
> > I would think C/C++ to Dylan would be more useful ? Can this take C
> > and go the other way ?

This is an important topic I think, Eiffel has a C/C++ legacy interface as
well as Dolphin, why not Dylan ?  I can see the benefits above in being able
to use existing C tools to aid in efficient programming from Dylan, but what
about all the code written in C++ that could be used in the Dylan. I have
about five different rendering libraries all optimized for speed that can
not be used in Dylan because they are coded in C++. This is a waste to have
to rewrite them in Dylan.

Quote:

> The C output isn't intended to be human-readable (although d2c takes some
> care to preserve function and variable names etc in the generated code --
> much better than, say, CFront -- the original C++ compiler -- did).

> You don't use d2c to convert your Dylan program to C and then work on it
> some more in C.  You program in Dylan.  d2c compiles Dylan into C, and
> then automatically calls the C compiler to produce a runnable program.
> You usually never even look at the C code.

Please excuse my ignorance on programming details, I am not a professional
programmer with years of experience. I REALLY like Dylan and I am very happy
using it, but I see so many other languages trying to bridge the barrier
between C++ and themselves. Dylan is extremely weak (unless I have missed
something) when it comes to integrating with the most popular one of all
C++.

Quote:

> The problem of taking a program in one language and turning it into a
> human readable, idiomatic, maintainable program in another programming
> language is a *much* harder one.  Well beyond the current state of the
> art, I'd say.

I am not asking for a direct translation of C++ to Dylan in human readable
form, just the same thing as the D2C, a compilation of a C++ project with
headers etc. to a useable module that can be easily called and used in Dylan
without having to manually code 100+ header files into Dylan equivalents.

Please I am not trying to be rude its just ignorance on my part,  why can we
not use SWIG to generate interfaces or something similar automatically ? I
looked at SWIG but you need to be well versed in both C++ and Dylan to make
it work, I am trying to stay away from C++ and just concentrate on Dylan.

Sincerely,

Shawn



Fri, 18 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available


Quote:

>> - every machine in the world has a C compiler

>Then why not just use one of them ?

I'm not sure what you are saying here. Are you saying, 'Why not use one
of those machines for Dylan programming' or 'Why not use C'?

Quote:
>> > I would think C/C++ to Dylan would be more useful ? Can this
>> > take C and go the other way ?

>This is an important topic I think, Eiffel has a C/C++ legacy
>interface as well as Dolphin, why not Dylan ?  

I know how to integrate Eiffel and Dolphin Smalltalk with C, but how do
you do it with C++? There are very few languages out there with C++
integration as far as I know. Do Eiffel and Dolphin Smalltalk really
allow instantiation of C++ classes, inheriting from them, calling
methods of them, etc?

Quote:
>I can see the
>benefits above in being able to use existing C tools to aid in
>efficient programming from Dylan, but what about all the code
>written in C++ that could be used in the Dylan. I have about five
>different rendering libraries all optimized for speed that can not
>be used in Dylan because they are coded in C++. This is a waste to
>have to rewrite them in Dylan.

If your code is in C then it is unlikely that you will have much of a
problem integrating it with Dylan. Whether or not you use a Dylan
compiler that compiles to C. For example, Functional Developer does not
compile to C. It is a native code compiler and it integrates with
external libraries written in C without a problem.

C++ is a problem because of the different name mangling schemes used by
compilers, different binary layouts of C++ classes, etc. Any language
that wants to integrate with C++ libraries will have to deal with this.
I don't know of many that do.

Quote:
>Dylan is extremely weak (unless I have missed something) when it
>comes to integrating with the most popular one of all C++.

Can you show me some languages that are strong in this area? How do
they overcome the issues outlined above?

Chris.



Sat, 19 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available


Quote:
> >Dylan is extremely weak (unless I have missed something) when it
> >comes to integrating with the most popular one of all C++.

> Can you show me some languages that are strong in this area? How do
> they overcome the issues outlined above?

Indeed. Even C++ is extremely weak when it comes to integrating with C++ from
another compiler. This is (in part) why interoperability technologies like COM
and SOM (IBM) were invented.

__Jason

_____________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Control Centre. For further information visit-
http://www.messagelabs.com/stats.asp



Sat, 19 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available

Quote:

> > For the same reason that there exist compilers for C++, FORTRAN, Ada,
> > Scheme, Eiffel (and many other languages) that produce output in C rather
> > than in machine code or assembly language:

> > - it's easier

> Benefit then to using Dylan ? Because its simpler to learn and utilize ?

We're not talking about languages and their benefits (Dylan wins...), we're
talking about compiler technology.

Functional Developer is a full, thoroughbred Dylan to native machine code
compiler. It parses, produces an intermediate representation, then reduces this
to assembler for the platform it's on. It does it very well, too, by all
accounts. Once it's done this, it uses a third party linker, either GNU or MS
to link the code with any other code libraries that are needed, and make the
final executable.

For those with more limited resources, there is a different way of doing things
that is available. It has nothing to do with the language being implemented,
it's a resource issue. The language is parsed, and intermediate representation
is produced, this is reduced to assembler then linked, all the same steps as
before. The difference is that the intermediate representation is C. C makes a
good intermediate representation because C compilers are ubiquitous, C is a
well understood language for implementors (the end users don't have to know
it's even there...), and C compilers have been around long enough that they do
a good job of optimizing code.

End-users need never see the C code, they need never know the C compiler is
being used (in theory...). The C compiler is just a convenient object code
producer, we are not interested in reading or working with C. Translating Dylan
to C is  not the aim, compiling Dylan is. There are Lisp, Eiffel and other
compilers that work in the same way.

Quote:

> > - every machine in the world has a C compiler

> Then why not just use one of them ?

Because we want to use a Dylan compiler. I don't want to go into langauge war
teritory, so I'll stick with tautology...

Quote:

> > - you don't need to worry about instruction set styles and encodings and
> > register architectures on jillions of different machines (or even on one)

> > - you don't need to worry about instruction selection and scheduling and
> > so forth either.

> > - you don't need to worry about runtime conventions such as how to call
> > functions and which registers to save and so forth

> > - you don't have to worry about how to call OS functions and standard
> libraries

> > The C compiler already knows all that stuff.  Someone worked {*filter*} it.

> Then there is an advantage to using the C code relating to portability,
> functionality, and speed optimizations ? It would be to much work too make an

> optimized Dylan compiler for every situation ?

For a group of volunteers working on code from an academic project, yes.

Quote:
> > > I would think C/C++ to Dylan would be more useful ? Can this take C
> > > and go the other way ?

> This is an important topic I think, Eiffel has a C/C++ legacy interface as
> well as Dolphin, why not Dylan ?

Functional Developer can link quite happily to COM objects, and both FD and
Gwydion Dylan have elegant systems for interfacing to C code and normal
libraries/shared libraries. As other posters have already pointed out, C++
interoperability is a real minefiled for any language. Different C++ compilers,
ANSI or not, cannot talk to each other without an object model shim. The name
mangling and vTables are different.
Dylan handles all this as well as can be expected, better even for C,
especially if the C++ programmer knows what extern "c" does. Since d2c compiles
to C as an intermediate representation, a notional d2c++ could link to C++
compiled using the same compiler, but this isn't planned as far as I know.

Quote:
> I can see the benefits above in being able
> to use existing C tools to aid in efficient programming from Dylan, but what
> about all the code written in C++ that could be used in the Dylan.

It can't be used in other C++ code either, unless it's COM in which case FD has
no problem, or a well-structured shared library in which case d2c has no
problem.

Quote:
> I have
> about five different rendering libraries all optimized for speed that can
> not be used in Dylan because they are coded in C++. This is a waste to have
> to rewrite them in Dylan.

OpenGL can be used with no problem form FD and d2c. It's a waste to rewrite
rendering libraries now full stop.

- Show quoted text -

Quote:

> > The C output isn't intended to be human-readable (although d2c takes some
> > care to preserve function and variable names etc in the generated code --
> > much better than, say, CFront -- the original C++ compiler -- did).

> > You don't use d2c to convert your Dylan program to C and then work on it
> > some more in C.  You program in Dylan.  d2c compiles Dylan into C, and
> > then automatically calls the C compiler to produce a runnable program.
> > You usually never even look at the C code.

> Please excuse my ignorance on programming details, I am not a professional
> programmer with years of experience. I REALLY like Dylan and I am very happy
> using it, but I see so many other languages trying to bridge the barrier
> between C++ and themselves. Dylan is extremely weak (unless I have missed
> something) when it comes to integrating with the most popular one of all
> C++.

C++ interoperability is a problem the C++ community has not yet addressed. I
can call C or Pascal or Dylan code from other languages with no problem. C++
has only itself to blame.

Quote:

> > The problem of taking a program in one language and turning it into a
> > human readable, idiomatic, maintainable program in another programming
> > language is a *much* harder one.  Well beyond the current state of the
> > art, I'd say.

> I am not asking for a direct translation of C++ to Dylan in human readable
> form, just the same thing as the D2C, a compilation of a C++ project with
> headers etc. to a useable module that can be easily called and used in Dylan
> without having to manually code 100+ header files into Dylan equivalents.

Compile it as a COM object or write a procedural front end. I know neither is
ideal, but it's doable.  The same advice would apply to C++ compilers from
different vendors or other language compilers.

Quote:

> Please I am not trying to be rude its just ignorance on my part,  why can we
> not use SWIG to generate interfaces or something similar automatically ?

You can use melange or the FD equivalent to generate Dylan imports for C code.
C++ is an interoperability minefield: source won't compile with ANY other
langauge unless it has a procedural front-end, object code won't work WITH
OTHER C++ COMPILERS, never mind other language compilers, without an object
model shim or a procedural front end.
This is probably one reason why Apple have stuck with Procedural front ends to
all their modern, internally object-oriented systems.

Quote:
> I looked at SWIG but you need to be well versed in both C++ and Dylan to make

> it work, I am trying to stay away from C++ and just concentrate on Dylan.

Does SWIG do Dylan? I'm ignorant as to what SWIG is...

- Rob.



Sat, 19 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available
[Rob Myers and others may already have answered your questions but I'll
have a go too ...]

Quote:

> > ... there exist compilers for [many languages] that produce output in
> > C rather than in machine code or assembly language:

> > - it's easier
> >...
> > - every machine in the world has a C compiler

> Then why not just use one of them ?

As Rob says, d2c just uses C as an intermediate representation because
it's an easy way for a group of (originally academics and now) volunteers
to do the back end of a compiler and gain free portability.  Native code
generation like FunDev does is harder for the compiler writer but (I'd
hope!) faster/smaller/etc. when executed.

Quote:
> > > I would think C/C++ to Dylan would be more useful ? Can this take C
> > > and go the other way ?

> This is an important topic I think, Eiffel has a C/C++ legacy interface as
> well as Dolphin, why not Dylan ?

From looking at
  <http://www.eiffel.com/tech/questions/page.html>
and
  <http://www.eiffel.com/doc/manuals/library/cecil/page.html>
it seems that Eiffel does offer more than Dylan in terms of C/C++
interfacing.  As well as calling back and forth between Eiffel and C
(including manipulating Eiffel objects from C, I think), you can
instantiate C++ classes from Eiffel and even create Eiffel wrapper
classes.

(I found Dolphin Smalltalk (is that what you meant?) at
  <http://www.object-arts.com/DolphinSmalltalk.htm>
but couldn't find any details on their C/C++ interface.)

At the moment, the C-FFI supported by FunDev and d2c (I think they've
pretty much converged by now, no?) just lets you call C functions from
Dylan (with automatic type conversion) and present Dylan objects with
"C-callable" wrappers.  You can't mess around with the structure of Dylan
objects from C (but then you can't in Dylan either -- everything goes via
method calls) and you can't talk directly to C++ at all.

Why not?  It's just a development choice, I suppose.  I can't speak in
detail for anyone (I worked on Harlequin Dylan but didn't design tht
C-FFI!) but I suppose it was thought that a combination of C, COM and
CORBA interfaces would be good enough (for now).  AFAIK (which may not be
that far ;-) lots of other languages have done the same; e.g., Java has
the JNI, conceptually similar to Dylan's C-FFI, but no C++ interface.

Quote:
> ... what about all the code written in C++ that could be used in the
> Dylan. I have about five different rendering libraries all optimized for
> speed that can not be used in Dylan because they are coded in C++. ...

As Rob said, all Dylan can offer you for now is interface via a COM
wrapper (which you'd have to write and I suspect might be too slow
and/or non-portable for you) or via an 'extern "C" { ... }' wrapper
(again, you'd have to write the C-to-C++ part of this yourself).

If you go the COM route, FunDev can automatically generate the Dylan
interface code.  There's a not-quite-finished project called "Pidgin",
which will be available with FunDev and d2c, to do the same for C.  At the
moment you have to translate the relevant C header file to Dylan C-FFI
definitions yourself.

(FunO have some tools to mostly-automate this internally at the moment,
which is how all the Win32 interface libraries were made -- perhaps you
could sweet-talk them into helping you do the translation, once you've
written the C-to-C++ part :-)

Quote:
> ... I REALLY like Dylan and I am very happy using it, but I see so many
> other languages trying to bridge the barrier between C++ and themselves.

By all means provide us all the links/info you can find on languages which
already talk directly to C++.  The better we understand how to go about
it, the better we can estimate the effort involved, which would be the
first step to actually making it happen :-)

Quote:
> I am not asking for a direct translation of C++ to Dylan in human readable
> form, just the same thing as the D2C, a compilation of a C++ project with
> headers etc. to a useable module that can be easily called and used in Dylan
> without having to manually code 100+ header files into Dylan equivalents.

Well, that isn't quite what D2C does (automatically make a C project
accessible from Dylan) -- as I've said, what you want for that is the
half-written "Pidgin" tool.  AFAIK, FunDev and the Gwydion volunteers are
co-operating on getting that finished but I don't know if it's actively
being worked on right now.  Both groups are eager to please Dylan users,
though, so if enough people ask for it (and/or offer development skills
:-) it could be pushed up the priority list, I'm sure.

Quote:
> Please I am not trying to be rude its just ignorance on my part, why can
> we not use SWIG to generate interfaces or something similar
> automatically ? ...

No rudeness inferred, don't worry :-)  I confess I also know very little
about SWIG; but that may be something else you and others can persuade us
Dylan developers to devote our efforts to.

Hope that helps (and feel free to ask for more info),
Hugh



Sat, 19 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available

Quote:

> > Please I am not trying to be rude its just ignorance on my part, why can
> > we not use SWIG to generate interfaces or something similar
> > automatically ? ...

> No rudeness inferred, don't worry :-)  I confess I also know very little
> about SWIG; but that may be something else you and others can persuade us
> Dylan developers to devote our efforts to.

Hi Hugh,

SWIG ( www.swig.org or http://www.cs.utah.edu/~beazley/SWIG/swig.html both
unavailable as I write ) is an tool inventing by some scientific programming
types at the University of Utah for glueing compiled C/C++/FORTRAN? libraries
to scripting languages like TCL/Python/Perl/Guile etc.

Basically it parses (annotated) C/C++ header files and produces glue for a
variety of scripting languages.

In theory SWIG could be told about Dylan's C-FFI. I don't know what it does
with C++ and OO scripting languages like Python.

__Jason

_____________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Control Centre. For further information visit-
http://www.messagelabs.com/stats.asp



Sat, 19 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available

Quote:

> SWIG ( www.swig.org or http://www.cs.utah.edu/~beazley/SWIG/swig.html both
> unavailable as I write )

It's at:

swig.sourceforge.net

(we just had this one on comp.lang.python).

Cheers,
M.

--
  "declare"?  my bogometer indicates that you're really programming
  in some other language and trying  to force Common Lisp into your
  mindset.  this won't work.           -- Erik Naggum, comp.lang.lisp



Sat, 19 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available

Quote:

> you can instantiate C++ classes from Eiffel and even create Eiffel wrapper
> classes.

Cool. How on Earth does it do that?

Quote:
> If you go the COM route, FunDev can automatically generate the Dylan
> interface code.  There's a not-quite-finished project called "Pidgin",
> which will be available with FunDev and d2c, to do the same for C.  At the
> moment you have to translate the relevant C header file to Dylan C-FFI
> definitions yourself.

Gwydion has the "Melange" C interface generator: interfaces to OpenGL and various
UNIX libraries have been generated using it, but it will be phased out in favour
of Pidgin when that's finished. It is not compatible with FD.

Quote:
> > I am not asking for a direct translation of C++ to Dylan in human readable
> > form, just the same thing as the D2C, a compilation of a C++ project with
> > headers etc. to a useable module that can be easily called and used in Dylan
> > without having to manually code 100+ header files into Dylan equivalents.

> Well, that isn't quite what D2C does (automatically make a C project
> accessible from Dylan) -- as I've said, what you want for that is the
> half-written "Pidgin" tool.  AFAIK, FunDev and the Gwydion volunteers are
> co-operating on getting that finished but I don't know if it's actively
> being worked on right now.  Both groups are eager to please Dylan users,
> though, so if enough people ask for it (and/or offer development skills
> :-) it could be pushed up the priority list, I'm sure.

I volunteered to work on Pidgin, but it proved to be outside my area of
competence so I'm working on Gwydion's version of DUIM instead. :-(
I think Pidgin still needs volunteers and it's very clean code to work with, so
if anyone wants to take a look it's included with the current Gwydion Dylan
release in the tools directory (along with Melange).

As an aside, there's an old project in the tools folder called "lisp2dylan" (or
something) that translates a limited subset of Lisp to Dylan. It's fossilized but
may be of interest to some people.

- Rob.

--

MacOS wonderfulness for The Hitch Hiker's Guide to the Galaxy Game.
"Arthur bought the Apple anyway."-So Long & Thanks For All The Fish.



Sat, 19 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available

Quote:

> As other posters have already pointed out, C++ interoperability is a real
> minefiled for any language. Different C++ compilers, ANSI or not, cannot
> talk to each other without an object model shim. The name mangling and
> vTables are different.

It's even worse than that.  The above can be avoided if you wrap all
method calls with a c wrapper function.  However you still can"t link
because every C++ implementation has a run time system to support new,
exceptions, streams, and so on.  These differ so on Solaris, code
compiled with  gcc, Sparcworks 4.2, and Sparcworks 5.0 can not be
mingled.

Bruce Seiler



Thu, 24 Oct 2002 03:00:00 GMT  
 First alpha release of d2c CodeWarrior plugin available
Which is why many (every one I've used) C++ libraries are distributed as
source. C++ is just not fit for integration of libraries distributed as
binary.

Which brings us to another possibility. Forget support for C++ binaries.
First make sure that the code gen'd by d2c can be compiled by a C++
compiler. Then think about integration based on that. It should then be
pretty easy to allow creation and deletion of C++ objects from Dylan,
and calling methods on them, and overloaded friends. Of course, there's
a whole lotta issues about actually managing the C++ classes and
instances, but I think that given a pretty simple core in "d2cpp" that
most other issues could then be handled with Dylan code.

Of course, you still have the problem that every C++ library uses
different strategies for memory management, error handling, and object
instantiation. So as soon as you add the 2nd C++ library you have as
many issues to deal with as, well, as with C++ ;-( But I would expect
that wrapping them in Dylan would at least make these issues easier to
deal with ;-) Although, of course, we really shouldn't have to put up
with this kind of c++rap at all ;-(

Quote:


> > As other posters have already pointed out, C++ interoperability is a real
> > minefiled for any language. Different C++ compilers, ANSI or not, cannot
> > talk to each other without an object model shim. The name mangling and
> > vTables are different.

> It's even worse than that.  The above can be avoided if you wrap all
> method calls with a c wrapper function.  However you still can"t link
> because every C++ implementation has a run time system to support new,
> exceptions, streams, and so on.  These differ so on Solaris, code
> compiled with  gcc, Sparcworks 4.2, and Sparcworks 5.0 can not be
> mingled.

> Bruce Seiler




Fri, 25 Oct 2002 03:00:00 GMT  
 
 [ 35 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Second alpha release of d2c CodeWarrior plugin available

2. First beta release of d2c CodeWarrior plugin available

3. Second beta release of d2c CodeWarrior plugin available

4. ANNOUNCE: First Alpha release of Tcl Plugin 2.0

5. mac-d2c release 2 now available

6. Mac-d2c Release 1 Now Available

7. ANNOUNCE: First alpha of the Tcl Plugin v2.0 for the Mac

8. RegularExpression plugin (alpha) for DR2 released

9. Tcl Plugin 2.0 first beta release

10. ANN: First alpha release of Jython-2.1

11. Ada Cryptographic Framework (ACF). First alpha release

12. pyDox 0.5a - first Alpha release

 

 
Powered by phpBB® Forum Software