"Ant" <Ant_member@pathlink.com> wrote in message news:btud3g$1gts$1@digitaldaemon.com...
> Superman can beat Batman anytime!

LOL, Nothing like putting things in perspective!

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:btul5l$1u8d$1@digitaldaemon.com...
> >> I assume
> >> this includes, in addition to factual language differences, things
> >> like usability and applicability for the end user, which includes
> >> the easily accessible libraries, number and quality of tools,
> >> whether you can ask the guy in the next cubicle for help, etc., etc.
> >
> >All new languages have a major uphill battle with that. And I believe
2004
> >is the year in which we'll get solidly into the game on that.
> >
> Than you have to do a lot. Do you think you can do something that can be compaired to .NET? This is the libray that comes with a new language (C#)
today.
> Javas library isn't bad as well. I think it will be hard.

There's just no way D will get a library comparable in breadth to .net and java in 2004. But I don't see that as necessary to the near term success of D. However, I expect to see the emergence of tools to aid in getting existing C and C++ libraries to work with D. And that will help a lot.

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:btu8i7$198d$1@digitaldaemon.com...
>
> > > Also, C++ interfaces with C++ quite well. :)
> >
> > That's cheating <g>.
>
> Actually, gcj, the GNU java compiler, has a cool ability to interface directly with C++ (at least C++ compiled with g++) through their own CNI mechanism - a Java class is compiled down to the same ABI as a C++ class. You can write typical C++ or Java and it looks pretty much the same. With
D
> I don't know how well this would work but I think it would "help the
cause"
> tremendously. That was one feature I wanted to shoot for while I'm playing around with gnu D.

D objects don't have the same layout as C++ objects. One could, though, fiddle with C++ objects to make them map onto D objects, but it won't work the other way. There is the same problem with Java objects, perhaps that's what CNI does.

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:btukae$1sq6$1@digitaldaemon.com...
> Inline assmbly isn't realy (at least for
> me). Most C++ compilers have this ability, too.

True, most C++ compilers  have it, but as an extension. It is not part of the language.

> I use stuff like template-templates from time to time. This is a VERY
powerfull
> thing. And AFAIK only C++ supports this.

D supports it now! (The template alias parameters.)

> Anyway D's generic ability are much better in the new version. This is the
first
> version of D that I realy like.
> Maybe version 1.0 will be a real alternative.
> BTW, what about mixins? Are they alredy implemented (seen anything about
them).
> If not, are they still planed to be implemented?

2.0!

C wrote:
> http://hp.vector.co.jp/authors/VA028375/contents/D_windows.h.html
> 
> Can we PLEASE execpt this is at the standard ?  These are generated by a
> perl script , so updating would not be a problem , and I have yet to find a
> function thats not covered by this library.  I've been using for months with
> no problems at all!
> 
> C

I agree.  Y. Tomino's headers are probably the best set to use as a "standard".  I've used them some and I like that they are produced from a public script, they don't depend on std.c.windows.windows, and there's an ansi set AND a Unicode set (so everybody's happy).

Something I've noticed is that -- as far as I can tell -- COM isn't included in this set. I suppose someone (possibly myself) could modify Mike Wynn's COM library to make use of Tomino's headers (and not depend on std.c.windows.com). Mike's stuff is found at http://www.geocities.com/one_mad_alien/dcom_not_dcom.html

By the way, I don't have anything against std.c.windows.com.  The problem using it is that when Walter improves it by including new constants, aliases, and declarations, stuff in the previously-working file starts causes conflicts.

http://www.dprogramming.com/dwindows.php
Also, I haven't tried it out yet, but Vathix has created some header files, too. It also looks like he's updated Pavel's old windows.d (the old version is still at http://int19h.tamb.ru/files.html).

-- 
Justin
http://jcc_7.tripod.com/d/

Ohhh if you could get Mike's COM work to work with Y.T's win32 that would be sweet.  Get to it! :)

C
"J C Calvarese" <jcc7@cox.net> wrote in message
news:btvrb7$r8e$1@digitaldaemon.com...
> C wrote:
> > http://hp.vector.co.jp/authors/VA028375/contents/D_windows.h.html
> >
> > Can we PLEASE execpt this is at the standard ?  These are generated by a perl script , so updating would not be a problem , and I have yet to
find a
> > function thats not covered by this library.  I've been using for months
with
> > no problems at all!
> >
> > C
>
> I agree.  Y. Tomino's headers are probably the best set to use as a "standard".  I've used them some and I like that they are produced from a public script, they don't depend on std.c.windows.windows, and there's an ansi set AND a Unicode set (so everybody's happy).
>
> Something I've noticed is that -- as far as I can tell -- COM isn't included in this set. I suppose someone (possibly myself) could modify Mike Wynn's COM library to make use of Tomino's headers (and not depend on std.c.windows.com). Mike's stuff is found at http://www.geocities.com/one_mad_alien/dcom_not_dcom.html
>
> By the way, I don't have anything against std.c.windows.com.  The problem using it is that when Walter improves it by including new constants, aliases, and declarations, stuff in the previously-working file starts causes conflicts.
>
> http://www.dprogramming.com/dwindows.php
> Also, I haven't tried it out yet, but Vathix has created some header
> files, too. It also looks like he's updated Pavel's old windows.d (the
> old version is still at http://int19h.tamb.ru/files.html).
>
> --
> Justin
> http://jcc_7.tripod.com/d/

In article <btuv9l$2g2j$3@digitaldaemon.com>, Walter says...
>
>
>"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:btul5l$1u8d$1@digitaldaemon.com...
>> >> I assume
>> >> this includes, in addition to factual language differences, things
>> >> like usability and applicability for the end user, which includes
>> >> the easily accessible libraries, number and quality of tools,
>> >> whether you can ask the guy in the next cubicle for help, etc., etc.
>> >
>> >All new languages have a major uphill battle with that. And I believe
>2004
>> >is the year in which we'll get solidly into the game on that.
>> >
>> Than you have to do a lot. Do you think you can do something that can be compaired to .NET? This is the libray that comes with a new language (C#)
>today.
>> Javas library isn't bad as well. I think it will be hard.
>
>There's just no way D will get a library comparable in breadth to .net and java in 2004. But I don't see that as necessary to the near term success of D. However, I expect to see the emergence of tools to aid in getting existing C and C++ libraries to work with D. And that will help a lot.
>
>


Adding a D generator to the SWIG package would surely go a long way to alleviating many of these problems.

Ian

>There's just no way D will get a library comparable in breadth to .net and java in 2004. But I don't see that as necessary to the near term success of D. However, I expect to see the emergence of tools to aid in getting existing C and C++ libraries to work with D. And that will help a lot.
>
Bad for me, as I haven't seen any library written in C, that I realy liked.

>Can you use the current phobos win32 headers on Linux / Mac ?

Do we have to make mistakes we did in the past again and again?

Compiler-vendors may deliver something like this with their compiler, but making it a part of the standard-library is stupip. Perhaps a special definition of library-extentions for specific platforms would be an idea, so you have an advanced set for Windows (Win32 stuff), Unix (POSIX, ...) and so on.

It's OK, if there is a stanrad, but IMO it mustn't be a part of THE D-Standard.

>This would go into the platform-specific section of the standard runtime library, much as Win32 headers are included with every C/C++ compiler on the Windows platform.  You wouldn't use them and probably wouldn't even have them available on Linux or Mac.
>
>But those of us who write Windows apps NEED a full suite of Win32 functions. The existing Phobos one is far too incomplete to make any sort of simple app with, let alone a real app.
>
There are Java-coders that belong to "those ... who write Windows apps". And they DON'T "NEED a full suite of Win32 functions". There are .NET-coders who don't need it. There are people using gtk or Qt who don't need it. So you DON'T NEED a full suit of Win32 functions to write Windows apps.

>Yeah, Win32 is going to go the way of the dinosaur soon, everything will switch to .NET, but for now we have to have it.
>
For now nobody realy codes D. (At last I think so.) We experiment around with D. We concentrate on the language itself, so we learn how to use it and to make suggestions how to improve it. We don't concern any platformspecific extensions, as they don't help us in developing the language itself. We think about general librarys and language-fatures that enable us to develope these librarys or or help us in general.