Holy cow. I just downloaded the SWIG sources and I've been looking around at what it would take to write a SWIG extension for D. And this is the answer:

NOT VERY MUCH

In order to customize SWIG for any given language, there is only one source file that needs to be created. For Java, it's a file called "java.cxx" for C#, it's a file called "csharp.cxx". Each of these files is moderately complex. The java file, with all of the comments and newlines stripped out, is about 1400 lines of code (in C++). The csharp file is about 1600 lines.

That's not very much code.

Plus, I'm guessing that much of the code for the D extension would look an awful lot like the code for the Java and C# extensions, so we could borrow heavily from the existing implementation.

However, this project is not for the faint of heart. Even if it only requires writing 1500 or so lines of code, the author will have to have a pretty good command of C++ (I'm already out of the running) and an excellent understanding of D semantics (that eliminately most of us).

But, on the upside, once it's done we'll have access to millions of lines of C++ code to use as imports and libraries for our own projects. I'm just giddy at the notion that we could suddenly have access to the entire wxWindows library, after writing only 1500 lines of code.

--Benji Smith

Felix wrote:
> Hi,
> 
> I do not remember this topic's thread very well, but I think the title is very
> interesting. So, to bring the discussion back where it belongs, what about
> component programming?
> 
> Could somebody put some ActiveX programmed controls, by example? I think is the
> widest spreaded component interface. I know it is possible to program ActiveX
> controls/forms in D but I found no real example. As a beginner, I would need
> that.
> 

my code for imbedding an instance of MSIE in a D window (using my win32 wrapper classes) can be found on
http://www.geocities.com/one_mad_alien/dcom_not_dcom.html

you may have to tweek it a bit it is all 0.68 not 0.7x and my windows machine has blown up so I'm only using linux at present.

In article <bkcp02$d2r$1@digitaldaemon.com>, Walter says...
>I'm very careful not to change the language in any fundamental way, exactly because of this problem. There may be a bit of tweaking required (things like changing the names of the operator overload functions), but I seriously doubt anything more than that. I can't think of anything that would require a rewrite.

I'm glad to hear that the language is stable enough for this type of work to commence.

Apparantly, the swig wrapper generators are based on the notion of creating typemaps between the type systems of the two different languages. I'm not sure how much of that typemapping is implementation dependent, but I'm curious to hear your opinion. If another compiler vendor makes different implementation decisions about type sizes and whatnot, how do you think that might affect the mapping of types between D and C++?

I've just written an email to the guy who wrote the Java and C# language libraries for the swig project, asking him some questions about the current state of the modules and for advice about any implementation hurdles that could get in the way of a D implementation. I'll post more information when I get his reply.

--Benji Smith

In article <bkd3bl$rdh$1@digitaldaemon.com>, Benji Smith says...
>I've just written an email to the guy who wrote the Java and C# language libraries for the swig project, asking him some questions about the current state of the modules and for advice about any implementation hurdles that could get in the way of a D implementation. I'll post more information when I get his reply.

I got a reply (already!) to the email that I sent to this guy. According to
him...

<quote>
If D is very similar to C# you might have something up and running in a day or
two. To begin with don't change the source code in csharp.cxx (or a new d.cxx),
just modify the typemaps in csharp.swg. (What are you going to call it? d.cxx,
class D and d.swg is rediculously short!) I suspect that after 2 weeks it will
be in a fairly reasonable shape. A month later quite polished. It will probably
never be perfect!
</quote>

So, there's the possibility of having some swig compatibility very shortly. If anyone is interested in working on this project, let me know (through the ng, not email), and I'll forward you the rest of the above email, which has quite a few more helpful hints and suggestions for creating the D swig implementation.

--Benji

"Benji Smith" <dlanguage@xxagg.com> wrote in message news:bkd3bl$rdh$1@digitaldaemon.com...
> Apparantly, the swig wrapper generators are based on the notion of
creating
> typemaps between the type systems of the two different languages. I'm not
sure
> how much of that typemapping is implementation dependent, but I'm curious
to
> hear your opinion. If another compiler vendor makes different
implementation
> decisions about type sizes and whatnot, how do you think that might affect
the
> mapping of types between D and C++?

D specifies the sizes of all the types except real. So that shouldn't be a problem.

> I've just written an email to the guy who wrote the Java and C# language libraries for the swig project, asking him some questions about the
current
> state of the modules and for advice about any implementation hurdles that
could
> get in the way of a D implementation. I'll post more information when I
get his
> reply.

Thanks!

Cool! Also, let's start a new thread on this!

"Benji Smith" <dlanguage@xxagg.com> wrote in message news:bkctb3$j5j$1@digitaldaemon.com...
> Holy cow. I just downloaded the SWIG sources and I've been looking around
at
> what it would take to write a SWIG extension for D. And this is the
answer:
>
> NOT VERY MUCH
>
> In order to customize SWIG for any given language, there is only one
source file
> that needs to be created. For Java, it's a file called "java.cxx" for C#,
it's a
> file called "csharp.cxx". Each of these files is moderately complex. The
java
> file, with all of the comments and newlines stripped out, is about 1400
lines of
> code (in C++). The csharp file is about 1600 lines.
>
> That's not very much code.
>
> Plus, I'm guessing that much of the code for the D extension would look an
awful
> lot like the code for the Java and C# extensions, so we could borrow
heavily
> from the existing implementation.
>
> However, this project is not for the faint of heart. Even if it only
requires
> writing 1500 or so lines of code, the author will have to have a pretty
good
> command of C++ (I'm already out of the running) and an excellent
understanding
> of D semantics (that eliminately most of us).
>
> But, on the upside, once it's done we'll have access to millions of lines
of C++
> code to use as imports and libraries for our own projects. I'm just giddy
at the
> notion that we could suddenly have access to the entire wxWindows library,
after
> writing only 1500 lines of code.
>
> --Benji Smith
>
>

"Walter" <walter@digitalmars.com> escreveu na mensagem news:bkb2mm$10cd$1@digitaldaemon.com...
>
> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bkaqbj$kpl$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> escreveu na mensagem news:bkac7h$6c$1@digitaldaemon.com...
> >
> > > Even a rubber axe can chop down an oak tree if you keep on swinging,
and
> > > that is certainly what I intend to do.
> >
> > But can you do it... with... a herring?
>
> Monty Python?

Yes.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003

----- Original Message ----- 
From: "Matthew Wilson" <matthew@stlsoft.org>
Newsgroups: D
Sent: Wednesday, September 17, 2003 4:26 PM
Subject: Re: The importance of component programming (properties, signals
and slots, etc)
> > > > at how C++ libraries changed over time. How many times has iostream
> been
> > > > re-engineered from scratch? <g>
> > > There should only ever have been one reworking of the iostreams, and I
> > think
> > > you know what that would have been ...
> >
> > There have been at least three reengineerings of it. That's why DMC++
has
> > <iostream>, <iostream.h>, <iosold\iostream.h> and <oldstr\iostream.h>.
>
> The iostream include I would be looking for would involve no characters at all ...

What don't you like about it?  The overloading abuse or the layering and buffering?  Or the naming scheme for member functions?  Or the clutter that allocators and traits bring to the debug info?

Surely it can be done better, but it's not a horrible piece of engineering. Input and output iterators aren't such a bad idea.  They can let you use some of the generic data handling mechanisms in STL to manipulate file data.

for instance this probably works (though I haven't tried it, it does at
least compile):

#include <fstream>
#include <functional>
#include <algorithm>
using namespace std;
void print_int_after_first_int_in_this_file_thats_at_least(ostream& so,
istream& si, int at_least)
{
    typedef istream_iterator<int> it;
    it found = find_if(it(si),it(),bind2nd(less<int>(),at_least));
    if (!(found == it()))
        *ostream_iterator<int>(so) = *found;
}

That's a lot of power, speed be damned.  Surely it could look prettier or be
friendlier or easier to use, but this is certainly a step in the right
direction.  You can actually implement your own ostream and istream above
and hook this function up to any data pipe you can imagine.  Pass in any
function you can build for the test as unary_function<int,bool>.  There are
all kinds of algorithms too,  stuff like copy_if and replace_if, that are
useful for moving and filtering data.
Check out the notes on the operator* and operator= in the
std::ostream_iterator class.  ;)

Sean

Daniel Yokomiso wrote:

>     Best regards,
>     Daniel Yokomiso.
> 
> "(define (.sig) (cons 'my (list 'other 'car 'is 'a 'cdr)))"

I like your sig :-)
-- 
+----------------------------------------------------------------------+ I Dr. Olaf Rogalsky                         Institut f. Theo. Physik I I I Tel.: 09131 8528440                       Univ. Erlangen-Nuernberg   I I Fax.: 09131 8528444                       Staudtstrasse 7 B3         I I rogalsky@theorie1.physik.uni-erlangen.de  D-91058 Erlangen           I +----------------------------------------------------------------------+