www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.022 and 2.005 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
Bug fixes. New (and very modest) C++ interface. Library module overhauls 
by Andrei Alexandrescu. Brad Roberts is working behind the curtain to 
get phobos development much better organized.

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.022.zip

http://www.digitalmars.com/d/changelog.html
http://ftp.digitalmars.com/dmd.2.005.zip
Oct 05 2007
next sibling parent renoX <renosky free.fr> writes:
Walter Bright a écrit :

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to 
 get phobos development much better organized.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip
 
 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip


Nice touch for adding write and writeln to std.stdio: naming consistency 
is important indeed.

Thanks,
renoX
Oct 05 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to 
 get phobos development much better organized.



And to think I just patched some code and makefiles last night to work 
around some of these bugs :-)  Nice work!

On a semi-related note, a Tango release is planned for today.  In fact, 
it's already packaged and ready to go.  So I'll give DMD 1.022 support a 
look this evening and perhaps we'll re-release tomorrow if any changes 
are necessary.  I have jury duty so I won't be able to get to it today.


Sean
Oct 05 2007
parent Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 Bug fixes. New (and very modest) C++ interface. Library module 
 overhauls by Andrei Alexandrescu. Brad Roberts is working behind the 
 curtain to get phobos development much better organized.


 
 
 And to think I just patched some code and makefiles last night to work 
 around some of these bugs :-)  Nice work!
 
 On a semi-related note, a Tango release is planned for today.  In fact, 
 it's already packaged and ready to go.  So I'll give DMD 1.022 support a 
 look this evening and perhaps we'll re-release tomorrow if any changes 
 are necessary.  I have jury duty so I won't be able to get to it today.


So it took me a bit longer than expected to get to this.  Things were 
also a bit complicated by the fact the the timestamps for most of the 
files had changed even though the files themselves were untouched. 
Fortunately, my diff tool was up to the task, and it seems there are no 
runtime changes necessary for Tango in this release.  I love it when 
that happens :-)


Sean
Oct 11 2007
prev sibling next sibling parent reply Jascha Wetzel <firstname mainia.de> writes:
Walter Bright wrote:

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to 
 get phobos development much better organized.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip
 
 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip


neat!
maybe the docs for c++ interfacing should mention, that it requires a 
compatible c++ compiler to work (DMC or MSVC on windows and GCC 3.x on 
linux?).
Oct 05 2007
parent reply "Craig Black" <craigblack2 cox.net> writes:
"Jascha Wetzel" <firstname mainia.de> wrote in message 
news:fe63ji$10r2$1 digitalmars.com...

 Walter Bright wrote:

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to get 
 phobos development much better organized.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip

 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip


 neat!
 maybe the docs for c++ interfacing should mention, that it requires a 
 compatible c++ compiler to work (DMC or MSVC on windows and GCC 3.x on 
 linux?).


I don't think MSVC will work.  Only DMC.  Or am I wrong?

-Craig
Oct 07 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Craig Black wrote:

 
 "Jascha Wetzel" <firstname mainia.de> wrote in message 
 news:fe63ji$10r2$1 digitalmars.com...

 maybe the docs for c++ interfacing should mention, that it requires a 
 compatible c++ compiler to work (DMC or MSVC on windows and GCC 3.x on 
 linux?).


 
 I don't think MSVC will work.  Only DMC.  Or am I wrong?


It does follow MSVC's name mangling scheme and function interface. It 
should work with MSVC compile C++ DLLs.
Oct 07 2007
parent reply Aarti_pl <aarti interia.pl> writes:
Walter Bright pisze:

 Craig Black wrote:

 "Jascha Wetzel" <firstname mainia.de> wrote in message 
 news:fe63ji$10r2$1 digitalmars.com...

 maybe the docs for c++ interfacing should mention, that it requires a 
 compatible c++ compiler to work (DMC or MSVC on windows and GCC 3.x 
 on linux?).


 I don't think MSVC will work.  Only DMC.  Or am I wrong?


 
 It does follow MSVC's name mangling scheme and function interface. It 
 should work with MSVC compile C++ DLLs.


I just wonder if it wouldn't be better to allow external plugins for 
DMD. This way you could just create different plugins to allow different 
name mangling and different interpretation of data in extern() sections...

We could have then different plugins written by external vendors eg:
CPP_GCC
CPP_MSVC
Pascal
etc.

Walter, did you think about solution like this? Is there possibility to 
implement this?

Regards
Marcin Kuszczak
(aarti_pl)
Oct 07 2007
next sibling parent Aarti_pl <aarti interia.pl> writes:
Aarti_pl pisze:

 I just wonder if it wouldn't be better to allow external plugins for 
 DMD. This way you could just create different plugins to allow different 
 name mangling and different interpretation of data in extern() sections...
 
 We could have then different plugins written by external vendors eg:
 CPP_GCC
 CPP_MSVC
 Pascal
 etc.
 
 Walter, did you think about solution like this? Is there possibility to 
 implement this?
 
 Regards
 Marcin Kuszczak
 (aarti_pl)


BTW: Word plugins is used in 2.0 changelog, when mentioning about C++ 
interface, but *probably* in other meaning...

It would be nice to see real plugins for D compiler...

BR
Marcin Kuszczak
(aarti_pl)
Oct 08 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Aarti_pl wrote:

 I just wonder if it wouldn't be better to allow external plugins for 
 DMD. This way you could just create different plugins to allow different 
 name mangling and different interpretation of data in extern() sections...
 
 We could have then different plugins written by external vendors eg:
 CPP_GCC
 CPP_MSVC
 Pascal
 etc.
 
 Walter, did you think about solution like this?


No.


 Is there possibility to implement this?


I think the number of different calling conventions in use is pretty 
limited, so the benefit may not be there.
Oct 08 2007
next sibling parent Aarti_pl <aarti interia.pl> writes:
Walter Bright pisze:

 Aarti_pl wrote:

 I just wonder if it wouldn't be better to allow external plugins for 
 DMD. This way you could just create different plugins to allow 
 different name mangling and different interpretation of data in 
 extern() sections...

 We could have then different plugins written by external vendors eg:
 CPP_GCC
 CPP_MSVC
 Pascal
 etc.

 Walter, did you think about solution like this?


 
 No.
 

 Is there possibility to implement this?


 
 I think the number of different calling conventions in use is pretty 
 limited, so the benefit may not be there.


Real advantage would be that someone (some company?) could implement 
everything necessary to easily link D with C++ (you wrote that it needs 
10 man-years, so I prefer you won't do it :D ).

Also it would allow to prepare plugins for other languages, without 
bloating D compiler itself.

Maybe it would be even commercial C++ plugin. But I guess that for 
companies which want to start working with D and connect new D code with 
old C++ code, price will be no-issue.

It is possible that also some other functionality of compiler could be 
delegated to plugins, but currently I have in mind only this extern() 
thing...

BR
Marcin Kuszczak
(Aarti_pl)
Oct 08 2007
prev sibling parent reply Bruce Adams <tortoise_y4 yeah.who.co.uk> writes:
Walter Bright Wrote:


 Aarti_pl wrote:

 I just wonder if it wouldn't be better to allow external plugins for 
 DMD. This way you could just create different plugins to allow different 
 name mangling and different interpretation of data in extern() sections...
 
 We could have then different plugins written by external vendors eg:
 CPP_GCC
 CPP_MSVC
 Pascal
 etc.
 
 Walter, did you think about solution like this?


 
 No.
 

 Is there possibility to implement this?


 
 I think the number of different calling conventions in use is pretty 
 limited, so the benefit may not be there.


I was going to post a similar question. I do most of my development via gcc.
I'm only using DMD on windows rather than gdc because its more reliable
(relative to the current state of gdc on cygwin). I have a 
lot of current C++ code working under gcc which is one thing holding me back
from adopting D wholesale. A way of supporting gcc style name mangling as
opposed to M$ would be very useful. 

Regards,

Bruce.
Oct 08 2007
next sibling parent reply BCS <BCS pathlink.com> writes:
Bruce Adams wrote:


 
 I was going to post a similar question. I do most of my development via gcc.
I'm only using DMD on windows rather than gdc because its more reliable
(relative to the current state of gdc on cygwin). I have a 
 lot of current C++ code working under gcc which is one thing holding me back
from adopting D wholesale. A way of supporting gcc style name mangling as
opposed to M$ would be very useful. 
 
 Regards,
 
 Bruce.


I would not be a bit surprised if DMD linux does uses GCC naming right now.
Oct 08 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 I would not be a bit surprised if DMD linux does uses GCC naming right now.


It does :-)
Oct 08 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bruce Adams wrote:

 I was going to post a similar question. I do most of my development
 via gcc. I'm only using DMD on windows rather than gdc because its
 more reliable (relative to the current state of gdc on cygwin). I
 have a lot of current C++ code working under gcc which is one thing
 holding me back from adopting D wholesale. A way of supporting gcc
 style name mangling as opposed to M$ would be very useful.


Supporting gcc name mangling isn't enough, as dmd on Windows doesn't 
generate ELF and is incompatible with gcc on many levels.

A more practical approach is to recompile your C++ source using DMC++.
Oct 08 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:

 Bruce Adams wrote:

 I was going to post a similar question. I do most of my development
 via gcc. I'm only using DMD on windows rather than gdc because its
 more reliable (relative to the current state of gdc on cygwin). I
 have a lot of current C++ code working under gcc which is one thing
 holding me back from adopting D wholesale. A way of supporting gcc
 style name mangling as opposed to M$ would be very useful.


 
 Supporting gcc name mangling isn't enough, as dmd on Windows doesn't 
 generate ELF and is incompatible with gcc on many levels.


Correct me if I'm wrong, but if mangling was taken care of such code 
could still be linked if for example the C++ code was in a DLL, right?
Or is the C++ parameter & result passing of mingw/cygwin g++ so 
different from any method supported by DMD?
(IIRC on Linux it's basically the C calling convention with an implicit 
first 'this' argument for member functions and s/&/*/ on all types)


 A more practical approach is to recompile your C++ source using DMC++.


That would depend on how much of it there is to recompile, wouldn't it? :P
(Also, the code may use GNU extensions to C++ not present in DMC, 
requiring more work to port than a simple recompile)
Oct 08 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Frits van Bommel wrote:

 Walter Bright wrote:

 Bruce Adams wrote:

 I was going to post a similar question. I do most of my development
 via gcc. I'm only using DMD on windows rather than gdc because its
 more reliable (relative to the current state of gdc on cygwin). I
 have a lot of current C++ code working under gcc which is one thing
 holding me back from adopting D wholesale. A way of supporting gcc
 style name mangling as opposed to M$ would be very useful.


 Supporting gcc name mangling isn't enough, as dmd on Windows doesn't 
 generate ELF and is incompatible with gcc on many levels.


 
 Correct me if I'm wrong, but if mangling was taken care of such code 
 could still be linked if for example the C++ code was in a DLL, right?
 Or is the C++ parameter & result passing of mingw/cygwin g++ so 
 different from any method supported by DMD?


There's a lot more to binary compatibility than name mangling. Matching 
the names in a DLL is only the start.


 (IIRC on Linux it's basically the C calling convention with an implicit 
 first 'this' argument for member functions and s/&/*/ on all types)
 

 A more practical approach is to recompile your C++ source using DMC++.


 
 That would depend on how much of it there is to recompile, wouldn't it? :P


It depends on how portably the C++ code is written, not on how much 
there is.


 (Also, the code may use GNU extensions to C++ not present in DMC, 
 requiring more work to port than a simple recompile)


My experiences with non-standard extensions is there's almost never a 
good reason to use them, and this issue is yet another good reason not to.
Oct 08 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Walter Bright Wrote:


 Frits van Bommel wrote:

 Walter Bright wrote:

 Bruce Adams wrote:

 I was going to post a similar question. I do most of my development
 via gcc. I'm only using DMD on windows rather than gdc because its
 more reliable (relative to the current state of gdc on cygwin). I
 have a lot of current C++ code working under gcc which is one thing
 holding me back from adopting D wholesale. A way of supporting gcc
 style name mangling as opposed to M$ would be very useful.


 Supporting gcc name mangling isn't enough, as dmd on Windows doesn't 
 generate ELF and is incompatible with gcc on many levels.


 
 Correct me if I'm wrong, but if mangling was taken care of such code 
 could still be linked if for example the C++ code was in a DLL, right?
 Or is the C++ parameter & result passing of mingw/cygwin g++ so 
 different from any method supported by DMD?


 
 There's a lot more to binary compatibility than name mangling. Matching 
 the names in a DLL is only the start.
 

 (IIRC on Linux it's basically the C calling convention with an implicit 
 first 'this' argument for member functions and s/&/*/ on all types)
 

 A more practical approach is to recompile your C++ source using DMC++.


 
 That would depend on how much of it there is to recompile, wouldn't it? :P


 
 It depends on how portably the C++ code is written, not on how much 
 there is.


I try but you never know how portable your code really isn't until you try a
different platform/compiler for the first time. They all have their horrid
little quirks mostly because of the preprocessor that D gets rid of.
(Then of course anything in M$ land takes the book and throws it out the window
they then write a new book and call it gospel.)

Another problem comes when you have third party libraries in use. As a user of
gcc I naturally have made use of a number of linux type,
autoconf configure, make based libraries. I can be confident they will work
with gcc but not necessarily with anything else (especially as they tend to
written in old fashioned C). I don't want to port them as well.


 (Also, the code may use GNU extensions to C++ not present in DMC, 
 requiring more work to port than a simple recompile)


 
 My experiences with non-standard extensions is there's almost never a 
 good reason to use them, and this issue is yet another good reason not to.


In general yes. But there are a few exceptions to prove the rule. One is access
to the stack frame (e.g. for creating stack traces that customers can send
back). This is one I actually use but only in one module. It was painful at the
time and no doubt it is equally painful every time on each new (or in my case
not gnu) compiler. 
There may be other nasty little tricksy things them 'obbits' is keeping from us.

Bruce.
Oct 08 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Bruce Adams wrote:

 Walter Bright Wrote:

 It depends on how portably the C++ code is written, not on how much
  there is.
 


 I try but you never know how portable your code really isn't until
 you try a different platform/compiler for the first time.


Right. But such is worth doing once in a while, because afterwards one 
tends to implicitly avoid non-portable constructs.


 Another problem comes when you have third party libraries in use. As
 a user of gcc I naturally have made use of a number of linux type, 
 autoconf configure, make based libraries. I can be confident they
 will work with gcc but not necessarily with anything else (especially
 as they tend to written in old fashioned C). I don't want to port
 them as well.


I agree that would be a serious impediment.


 My experiences with non-standard extensions is there's almost never
 a good reason to use them, and this issue is yet another good
 reason not to.


 
 In general yes. But there are a few exceptions to prove the rule. One
 is access to the stack frame (e.g. for creating stack traces that
 customers can send back). This is one I actually use but only in one
 module. It was painful at the time and no doubt it is equally painful
 every time on each new (or in my case not gnu) compiler. There may be
 other nasty little tricksy things them 'obbits' is keeping from us.


Stack frame layouts might be comparable enough that you can port that 
bit of code.
Oct 08 2007
prev sibling next sibling parent reply BCS <BCS pathlink.com> writes:
Walter Bright wrote:

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to 
 get phobos development much better organized.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip
 
 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip



C++, coool.

--Typo from http://www.digitalmars.com/d/cpp_interface.html

	Use the limited ability described here to
	connect directly to C functions and classes.

that should be c++ functions and classes.


--To what extent does overloading work across C++/D?


--Is dmc going to get an "extern(D)" extension?
Oct 05 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 --Typo from http://www.digitalmars.com/d/cpp_interface.html
 
     Use the limited ability described here to
     connect directly to C functions and classes.
 
 that should be c++ functions and classes.


Got it.


 --To what extent does overloading work across C++/D?


Don't know what you mean.


 --Is dmc going to get an "extern(D)" extension?


No. My experience with C++ extensions is that people won't use them, so 
they're a waste of time. There are other problems, too, like C++ has no 
notion of a module, so where's the D module name going to come from?
Oct 05 2007
parent reply BCS <BCS pathlink.com> writes:
Walter Bright wrote:

 BCS wrote:
 

 --To what extent does overloading work across C++/D?


 
 
 Don't know what you mean.
 


will this work?

extern(c++)
{
	int Foo(int i);
	int Foo(int* ip);
}

void bar()
{
	int i;
	Foo(i);
	Foo(&i);
}


What about if there is a

void Foo(int[] ia){...} // non extern(c++)

Will that overload with the c++ functions?

Can D define overloaded extern(c++) function for C++ to link with?


 --Is dmc going to get an "extern(D)" extension?


 
 
 No. 


Shucks.
Oct 05 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 Walter Bright wrote:

 BCS wrote:


 --To what extent does overloading work across C++/D?



 Don't know what you mean.


 
 will this work?
 
 extern(c++)


Use a capital C.


 {
     int Foo(int i);
     int Foo(int* ip);
 }
 
 void bar()
 {
     int i;
     Foo(i);
     Foo(&i);
 }


Yes.



 What about if there is a
 
 void Foo(int[] ia){...} // non extern(c++)
 
 Will that overload with the c++ functions?


Yes. Just remember that the selection of function will follow D 
overloading rules, not C++ rules, even if the functions are labeled 
extern(C++).


 Can D define overloaded extern(c++) function for C++ to link with?


Yes.
Oct 05 2007
prev sibling next sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fe5vv7$s07$1 digitalmars.com...

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to get 
 phobos development much better organized.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip

 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip


I've noticed a few things about cpp_interface.html:

1. `Strings are not 0 terminated in D. See "Data Type Compatibility" for 
more information about this. However, string literals in D are 0 
terminated.`

However, there's nothing specific about strings in the referenced section.

2. In Data Type Compatibility:

no equivalent   type &

Is ref type not the D equivalent of this?

3. How about making it so that D dynamic array parameters become, on the C++ 
side, two parameters: length and pointer?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Oct 05 2007
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:fe6f68$1gm8$1 digitalmars.com...
<snip>

 3. How about making it so that D dynamic array parameters become, on the 
 C++ side, two parameters: length and pointer?


I've just been thinking a bit more about this.  I guess it's just a matter 
of name mangling - I haven't checked, but it would appear from the old 
printf-on-strings issue that pushing two arguments in succession is 
equivalent to pushing the concatenation of (the memory representations of) 
them in one go.  (Is this platform dependent?)

It's safer in C++ than in C, because if the writer of the C++ code 
misremembers which way round they go, the mangled names won't match.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Oct 06 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Stewart Gordon wrote:

 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
 news:fe6f68$1gm8$1 digitalmars.com...
 <snip>

 3. How about making it so that D dynamic array parameters become, on 
 the C++ side, two parameters: length and pointer?


 
 I've just been thinking a bit more about this.  I guess it's just a 
 matter of name mangling - I haven't checked, but it would appear from 
 the old printf-on-strings issue that pushing two arguments in succession 
 is equivalent to pushing the concatenation of (the memory 
 representations of) them in one go.  (Is this platform dependent?)


With printf() it probably just works because it uses C-style varargs and 
the two elements of a char[] happen to both be the "native" size of the 
processor (so there's no padding inserted).
It may not even work on all platforms.

Also, AFAIK the compiler would be well within its rights to use the 
opposite order of .length and .ptr in memory; meaning that even if the C 
calling convention allows this the order they're passed in isn't guaranteed.
Oct 06 2007
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:fe995o$3de$1 digitalmars.com...
<snip>

 Also, AFAIK the compiler would be well within its rights to use the 
 opposite order of .length and .ptr in memory; meaning that even if the C 
 calling convention allows this the order they're passed in isn't 
 guaranteed.


Not according to
http://www.digitalmars.com/d/abi.html

But one thing that might affect whether it works is if, on a given system, 
the memory layout of the stack goes the other way or is even non-linear.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Oct 06 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Stewart Gordon wrote:

 "Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
 news:fe995o$3de$1 digitalmars.com...
 <snip>

 Also, AFAIK the compiler would be well within its rights to use the 
 opposite order of .length and .ptr in memory; meaning that even if the 
 C calling convention allows this the order they're passed in isn't 
 guaranteed.


 
 Not according to
 http://www.digitalmars.com/d/abi.html


I'm not sure if that's part of the actual spec. If conformance to that 
ABI is required to be an implementation of D then only DMD qualifies, 
and non-x86 D compilers are impossible (since the ABI is x86-specific)...

And from that page: "A D implementation that conforms to the D ABI 
(Application Binary Interface) will be able to [...]" which I read to 
imply there can also be D implementations that _don't_ conform to that 
ABI. (such as GDC, and probably the compilers currently in production 
(LLVM, dil) as well as any compiler that supports non-x86 target systems)


 But one thing that might affect whether it works is if, on a given 
 system, the memory layout of the stack goes the other way or is even 
 non-linear.


Certainly. But such a system wouldn't be an x86, so see above.
Oct 07 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to 
 get phobos development much better organized.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip
 
 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip



Do Andrei and Brad have access to your code repository now?  If so -- 
that's great news!

--bb
Oct 05 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 Do Andrei and Brad have access to your code repository now?  If so -- 
 that's great news!


Yes. We've been working together for a long time, now. Andrei brings a 
fountain of new ideas and cutting edge technology, and Brad has a knack 
for applying organization and process to chaos. I think it'll work much 
better than my cowboy approach <g>.
Oct 05 2007
next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 05 Oct 2007 18:23:16 -0700, Walter Bright wrote:


 Bill Baxter wrote:

 Do Andrei and Brad have access to your code repository now?  If so -- 
 that's great news!


 
 Yes. We've been working together for a long time, now. Andrei brings a 
 fountain of new ideas and cutting edge technology, and Brad has a knack 
 for applying organization and process to chaos. I think it'll work much 
 better than my cowboy approach <g>.


Now that is a Bright idea. Kudos to all involved.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Oct 05 2007
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fe6o19$1qv2$1 digitalmars.com...

 Bill Baxter wrote:

 Do Andrei and Brad have access to your code repository now?  If so -- 
 that's great news!


 Yes. We've been working together for a long time, now. Andrei brings a 
 fountain of new ideas and cutting edge technology, and Brad has a knack 
 for applying organization and process to chaos. I think it'll work much 
 better than my cowboy approach <g>.


I see.  Do they have access to the documentation repository as well?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Oct 06 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Stewart Gordon wrote:

 I see.  Do they have access to the documentation repository as well?


That came up and is a good idea, it just hasn't been done yet.
Oct 06 2007
prev sibling next sibling parent reply nazo <lovesyao gmail.com> writes:
Walter Bright wrote:

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to 
 get phobos development much better organized.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip
 
 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip


great!

I wrote "C++ constructor/destructor" template for g++ and it works fine!
Oct 06 2007
parent Robert Fraser <fraserofthenight gmail.com> writes:
nazo Wrote:


 Walter Bright wrote:

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to 
 get phobos development much better organized.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip
 
 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip


 
 great!
 
 I wrote "C++ constructor/destructor" template for g++ and it works fine!
 
 #include <iostream>
 using namespace std;
 class D{
   public:
     D();
     ~D();
     virtual int bar(int i, int j, int k);
 };
 
 D::D(){
   printf("start\n");
 }
 
 D::~D(){
   printf("end\n");
 }
 
 int D::bar(int i, int j, int k){
       cout << "i = " << i << endl;
       cout << "j = " << j << endl;
       cout << "k = " << k << endl;
       return 8;
 };
 
 import std.metastrings;
 extern (C++){
   interface D{
     int bar(int i, int j, int k);
   }
 }
 
 extern(C){
   void* _Znwj(uint);
   void _ZdlPv(void*);
 }
 
 template cpp_decl(T){
   const cpp_decl = "extern(C) extern char*
_ZTV"~ToString!(T.stringof.length)~T.stringof~";";
 }
 
 template cpp_constructor(T, ARGS...){
   const cpp_constructor = "extern(C) void
_ZN"~ToString!(T.stringof.length)~T.stringof~"C1Ev(void*);";//fixme: mangle and
type
 }
 
 template cpp_destructor(T){
   const cpp_destructor = "extern(C) void
_ZN"~ToString!(T.stringof.length)~T.stringof~"D1Ev(void*);";
 }
 
 T cpp_new(T, ARGS...)(ARGS args){
   const fn="_ZN"~ToString!(T.stringof.length)~T.stringof~"C1Ev";//fixme: mangle
   void* rv;
   rv = _Znwj(T.sizeof);
   static if(is(typeof(mixin(fn)))){
     mixin("alias "~fn~" init;");
     init(rv, args);
   }else static if(ARGS.length==0){
     *cast(void**)rv = mixin("&_ZTV"~ToString!(T.stringof.length)~T.stringof)+2;
   }else static assert(0);
   return cast(D)rv;
 }
 
 void cpp_delete(T)(T obj){
   const fn="_ZN"~ToString!(T.stringof.length)~T.stringof~"D1Ev";
   static if(is(typeof(mixin(fn)))){
     mixin("alias "~fn~" term;");
     term(cast(void*)obj);
   }
   _ZdlPv(cast(void*)obj);
 }
 
 mixin(cpp_decl!(D));
 mixin(cpp_constructor!(D));//if D has constructor
 mixin(cpp_destructor!(D));//if D has destructor
 
 void main(){
   D d = cpp_new!(D);
   d.bar(9,10,11);
   cpp_delete(d);
 }
 


Awesome. Just... awesome.
Oct 06 2007
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Walter,


 Bug fixes. New (and very modest) C++ interface. Library module
 overhauls by Andrei Alexandrescu. Brad Roberts is working behind the
 curtain to get phobos development much better organized.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip
 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip


Now, would anyone be interested in making a dtoh program? (Find all extern 
c/c++ declaration and make a .h file for them). The name could be shortened 
to "d'oh".
Oct 06 2007
prev sibling next sibling parent Extrawurst <spam extrawurst.org> writes:
Thanks Walter. Good work.

I can finally build my Code with optimizations again, yeeeehaa.

--Extrawurst

Walter Bright schrieb:

 Bug fixes. New (and very modest) C++ interface. Library module 
 overhauls by Andrei Alexandrescu. Brad Roberts is working behind the 
 curtain to get phobos development much better organized.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip

 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip
Oct 06 2007
prev sibling next sibling parent janderson <askme me.com> writes:
Walter Bright wrote:

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to 
 get phobos development much better organized.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip
 
 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip


Neat with the C++ linkage stuff.  Now all I have to figure out 
appropriate places to incorporate D into my C++ projects :)
Oct 06 2007
prev sibling next sibling parent reply Paul Findlay <r.lph50+d gmail.com> writes:
 Bug fixes. New (and very modest) C++ interface. Library module overhauls
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to
 get phobos development much better organized.


This is all very good :)

With C++ interfaces, is D able to do anything similar to "all functions that
are not overridden can be optimized to be non-virtual"? And is the lack of
support for static and non-virtual members because it is infeasible or
in-expressible?

 - Paul
Oct 06 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Paul Findlay wrote:

 Bug fixes. New (and very modest) C++ interface. Library module overhauls
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to
 get phobos development much better organized.


 This is all very good :)
 
 With C++ interfaces, is D able to do anything similar to "all functions that
 are not overridden can be optimized to be non-virtual"?


The C++ interface only extends to the calling convention, name mangling, 
and vtbl[] layout. No other C++ rules are followed.


 And is the lack of
 support for static and non-virtual members because it is infeasible or
 in-expressible?


I thought we'd see how far we get with this first.
Oct 06 2007
prev sibling next sibling parent reply Bruce Adams <tortoise_y4 yeah.who.co.uk> writes:
Walter Bright Wrote:


 Bruce Adams wrote:

 I was going to post a similar question. I do most of my development
 via gcc. I'm only using DMD on windows rather than gdc because its
 more reliable (relative to the current state of gdc on cygwin). I
 have a lot of current C++ code working under gcc which is one thing
 holding me back from adopting D wholesale. A way of supporting gcc
 style name mangling as opposed to M$ would be very useful.


 
 Supporting gcc name mangling isn't enough, as dmd on Windows doesn't 
 generate ELF and is incompatible with gcc on many levels.
 
 A more practical approach is to recompile your C++ source using DMC++.


I doubt it is that practical. Though perhaps worth a try. gcc its well
integrated with my build system and I keep my code portable between windows and
linux. It sounds like I'm out of luck there :(.
It was hard enough to persuade myself to try dmd when gdc didn't work for me. I
know gcc's interface backwards. Jumping to another vendor (even you :-) is just
a little step too far for me. Not to mention having to swap gdb for ddbg or
whatever it is. I might try porting something simple as an exercise in
improving the portability of some code just to see what happens. As Captain
Oates said, I may be some time...

Bruce.
Oct 08 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bruce Adams wrote:

 Walter Bright Wrote:

 A more practical approach is to recompile your C++ source using
 DMC++.


 
 I doubt it is that practical. Though perhaps worth a try. gcc its
 well integrated with my build system and I keep my code portable
 between windows and linux. It sounds like I'm out of luck there :(. 
 It was hard enough to persuade myself to try dmd when gdc didn't work
 for me. I know gcc's interface backwards. Jumping to another vendor
 (even you :-) is just a little step too far for me. Not to mention
 having to swap gdb for ddbg or whatever it is. I might try porting
 something simple as an exercise in improving the portability of some
 code just to see what happens. As Captain Oates said, I may be some
 time...
 
 Bruce.


When gdc folds this in, then gdc/g++ should also work. I don't know what 
other issues there are with gdc.
Oct 08 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Walter Bright Wrote:


 Bruce Adams wrote:

 Walter Bright Wrote:

 A more practical approach is to recompile your C++ source using
 DMC++.


 
 I doubt it is that practical. Though perhaps worth a try. gcc its
 well integrated with my build system and I keep my code portable
 between windows and linux. It sounds like I'm out of luck there :(. 
 It was hard enough to persuade myself to try dmd when gdc didn't work
 for me. I know gcc's interface backwards. Jumping to another vendor
 (even you :-) is just a little step too far for me. Not to mention
 having to swap gdb for ddbg or whatever it is. I might try porting
 something simple as an exercise in improving the portability of some
 code just to see what happens. As Captain Oates said, I may be some
 time...
 
 Bruce.


 
 When gdc folds this in, then gdc/g++ should also work. I don't know what 
 other issues there are with gdc.


I started out trying to use gdc/cygwin and gave up. The general advice I was
given was don't do it use dmd. Using gdc on windows puts me in a small minority
(anyone else tried it, raise your hand now). Certainly my brief experince was
that gdc is too broken on cygwin to use. In my first day of using D I found two
compiler bugs one in DMD one in gdc. The one in DMD has a workaround the one in
gdc was fatal but I note it has been fixed so I could try again. Finding
compiler bugs with "hello world" programs is not a good sign.

Bruce.
Oct 08 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Bruce Adams wrote:

 I started out trying to use gdc/cygwin and gave up. The general
 advice I was given was don't do it use dmd. Using gdc on windows puts
 me in a small minority (anyone else tried it, raise your hand now).
 Certainly my brief experince was that gdc is too broken on cygwin to
 use. In my first day of using D I found two compiler bugs one in DMD
 one in gdc. The one in DMD has a workaround the one in gdc was fatal
 but I note it has been fixed so I could try again. Finding compiler
 bugs with "hello world" programs is not a good sign.


I agree that running into compiler bugs always sucks, but please be sure 
and report them to bugzilla if they aren't already there. Otherwise, 
they'll get forgotten and never fixed.
Oct 08 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to 
 get phobos development much better organized.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip
 
 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip


Thanks, Walter. Especially for bug fixes 1488 and 1125.
I suspect the C++ interface stuff will have a big impact on winning over C++ 
developers.
Oct 09 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don Clugston wrote:

 Thanks, Walter. Especially for bug fixes 1488 and 1125.


You're welcome.


 I suspect the C++ interface stuff will have a big impact on winning over 
 C++ developers.


It's a bit of a shot in the dark. I'm very curious to see how it will 
work out.
Oct 09 2007
parent reply janderson <askme me.com> writes:
Walter Bright wrote:

 Don Clugston wrote:

 Thanks, Walter. Especially for bug fixes 1488 and 1125.


 
 You're welcome.
 

 I suspect the C++ interface stuff will have a big impact on winning 
 over C++ developers.


 
 It's a bit of a shot in the dark. I'm very curious to see how it will 
 work out.


I think once this feature matures, another article highlighting the 
feature will go a long way to making them aware of the feature.  It will 
be interesting to see how/where people plug D into their C++ apps.

-Joel
Oct 09 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
janderson wrote:

 Walter Bright wrote:

 Don Clugston wrote:

 Thanks, Walter. Especially for bug fixes 1488 and 1125.


 You're welcome.


 I suspect the C++ interface stuff will have a big impact on winning 
 over C++ developers.


 It's a bit of a shot in the dark. I'm very curious to see how it will 
 work out.


 
 I think once this feature matures, another article highlighting the 
 feature will go a long way to making them aware of the feature.  It will 
 be interesting to see how/where people plug D into their C++ apps.
 
 -Joel


Another angle is that *no other language* provides any sort of hook into 
C++.
Oct 09 2007
parent reply James Dennett <jdennett acm.org> writes:
Walter Bright wrote:

 janderson wrote:

 Walter Bright wrote:

 Don Clugston wrote:

 Thanks, Walter. Especially for bug fixes 1488 and 1125.


 You're welcome.


 I suspect the C++ interface stuff will have a big impact on winning
 over C++ developers.


 It's a bit of a shot in the dark. I'm very curious to see how it will
 work out.


 I think once this feature matures, another article highlighting the
 feature will go a long way to making them aware of the feature.  It
 will be interesting to see how/where people plug D into their C++ apps.

 -Joel


 
 Another angle is that *no other language* provides any sort of hook into
 C++.


Felix does (and has been around for roughly as long as D).  It was
explicitly designed around C++ interoperability, and offers all
sorts of goodies including extensible syntax, GC, functional
capabilities and more.  But so far Felix has fewer than 100 users, and
probably fewer than 50.  D must be doing something right.

-- James
Oct 09 2007
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
James Dennett wrote:

 Walter Bright wrote:

 janderson wrote:

 Walter Bright wrote:

 Don Clugston wrote:

 Thanks, Walter. Especially for bug fixes 1488 and 1125.


 You're welcome.


 I suspect the C++ interface stuff will have a big impact on winning
 over C++ developers.


 It's a bit of a shot in the dark. I'm very curious to see how it will
 work out.


 I think once this feature matures, another article highlighting the
 feature will go a long way to making them aware of the feature.  It
 will be interesting to see how/where people plug D into their C++ apps.

 -Joel


 Another angle is that *no other language* provides any sort of hook into
 C++.


 
 Felix does (and has been around for roughly as long as D).  It was
 explicitly designed around C++ interoperability, and offers all
 sorts of goodies including extensible syntax, GC, functional
 capabilities and more.  But so far Felix has fewer than 100 users, and
 probably fewer than 50.  D must be doing something right.
 
 -- James



knowledge or experience with it.
Oct 09 2007
parent reply KlausO <oberhofer users.sf.net> writes:
Brad Roberts schrieb:

 

 knowledge or experience with it.



C funktions and specify struct alignments for struct used in these calls.
When it comes to interfaces and callbacks/callback interfaces you have 
to use Managed C++. COM Interop is the keyword, but IMHO, the syntax is 
sometimes weird and you have to write RCW/CCW (stands for "Runtime 
Callable Wrapper" and "COM Callable Wrapper") pairs in Managed C++ to 
support (COM) interfaces.
There is a good book about this:

http://www.informit.com/store/product.aspx?isbn=067232170X&rl=1
Oct 09 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
KlausO wrote:


 C funktions and specify struct alignments for struct used in these calls.
 When it comes to interfaces and callbacks/callback interfaces you have 
 to use Managed C++. COM Interop is the keyword, but IMHO, the syntax is 
 sometimes weird and you have to write RCW/CCW (stands for "Runtime 
 Callable Wrapper" and "COM Callable Wrapper") pairs in Managed C++ to 
 support (COM) interfaces.
 There is a good book about this:
 
 http://www.informit.com/store/product.aspx?isbn=067232170X&rl=1



D has had support for COM from day 1. But D's new support for C++ goes 
much further. Global functions can be accessed directly, non-COM 
polymorphic objects can be accessed, and the C++ calling convention is 
observed (the COM function calling convention is different).
Oct 10 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
James Dennett wrote:

 Walter Bright wrote:

 Another angle is that *no other language* provides any sort of hook into
 C++.


 
 Felix does (and has been around for roughly as long as D).  It was
 explicitly designed around C++ interoperability, and offers all
 sorts of goodies including extensible syntax, GC, functional
 capabilities and more.  But so far Felix has fewer than 100 users, and
 probably fewer than 50.  D must be doing something right.


I'd never heard of Felix :-)
Oct 09 2007
parent BLS <nanali nospam-wanadoo.fr> writes:
Walter Bright schrieb:

 James Dennett wrote:

 Walter Bright wrote:

 Another angle is that *no other language* provides any sort of hook into
 C++.


 Felix does (and has been around for roughly as long as D).  It was
 explicitly designed around C++ interoperability, and offers all
 sorts of goodies including extensible syntax, GC, functional
 capabilities and more.  But so far Felix has fewer than 100 users, and
 probably fewer than 50.  D must be doing something right.


 


Regarding C++ interop. :
Comparing Felix and D is a bit unfair. Felix *compiles* to ANSI C++


 I'd never heard of Felix :-)


http://www.digitalmars.com/d/archives/13809.html :)
Oct 10 2007
prev sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
Walter Bright schrieb:

 Bug fixes. New (and very modest) C++ interface. Library module overhauls 
 by Andrei Alexandrescu. Brad Roberts is working behind the curtain to 
 get phobos development much better organized.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.022.zip
 
 http://www.digitalmars.com/d/changelog.html
 http://ftp.digitalmars.com/dmd.2.005.zip


The C++ interface is IMO completely useless . Let me quote Walter
"In case that you want D to handle C++ you have to create a complte C++ 
frontend inside of D" (Not exactly , but I guess I have keeped the meaning)

But this is not the point .
Porting C++ to D is what should be a piece of cake.. In fact it is not..

Instead of enable us to invoke a very small piece of C++ code I would 
prefer to make D more C++ compatible. (And I really hate C++)

&references ... The Rationales do not say a anything about it
The D "compared to C" just says ... We don't have it.

Struct inheritance
Why we need an *alias here instead of just writing structA : structB;
(*D 2.x future docs.)

C++ op overloading; D is not competitive.

Well there is more. But that's not the point. The point is :  Instead of 
implementing new and outstanding features, enable us to translate (at 
least) plain C++ code.

Actually coding C++ code in D  means : rewrite it and make it D-ish, 
instead of translate it.
This is , simply said shit; and I guess you folks know it.
OkeeDok just my opinion
Bjoern
Oct 09 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"BLS" <nanali nospam-wanadoo.fr> wrote in message 
news:fegotb$1l3e$1 digitalmars.com...


 Actually coding C++ code in D  means : rewrite it and make it D-ish, 
 instead of translate it.
 This is , simply said shit; and I guess you folks know it.


Wow, harsh.  There are those of us who don't actually spend all of our time 
translating C++ into D, you know.
Oct 09 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 "BLS" <nanali nospam-wanadoo.fr> wrote in message 
 news:fegotb$1l3e$1 digitalmars.com...
 

 Actually coding C++ code in D  means : rewrite it and make it D-ish, 
 instead of translate it.
 This is , simply said shit; and I guess you folks know it.


 
 Wow, harsh.  There are those of us who don't actually spend all of our time 
 translating C++ into D, you know. 


I don't recommend anyone actually translate C++ code to D, or C code for 
that matter. If it's a debugged, working code base, translating to 
another language is usually a losing proposition.

What matters, though, is being able to interface to that existing code base.
Oct 09 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Jarrett Billingsley wrote:

 "BLS" <nanali nospam-wanadoo.fr> wrote in message 
 news:fegotb$1l3e$1 digitalmars.com...


 Actually coding C++ code in D  means : rewrite it and make it D-ish, 
 instead of translate it.
 This is , simply said shit; and I guess you folks know it.


 Wow, harsh.  There are those of us who don't actually spend all of our 
 time translating C++ into D, you know. 


 
 I don't recommend anyone actually translate C++ code to D, or C code for 
 that matter. If it's a debugged, working code base, translating to 
 another language is usually a losing proposition.
 
 What matters, though, is being able to interface to that existing code 
 base.


While that sounds like good advice in general, if the C++ library in 
question is mostly templates, there's not much hope of interfacing to it 
from D.  Porting is the only option I'm aware of.

Of course some parts don't translate well and should just be rewritten 
in a way that makes sense in D.   But once the scaffolding is in place, 
the core, tricky, algorithmic parts that are hardest to debug become 
easy to translate.  So in that way the D port benefits from the work 
that went into debugging the C++.  So it's a win over just writing from 
scratch.

OpenMesh/D is about 15-20K loc.  I ported that from C++ in about 10 
days.  No way I would have been able to write that from scratch in the 
same amount of time.


--bb
Oct 09 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 While that sounds like good advice in general, if the C++ library in 
 question is mostly templates, there's not much hope of interfacing to it 
 from D.  Porting is the only option I'm aware of.
 
 Of course some parts don't translate well and should just be rewritten 
 in a way that makes sense in D.   But once the scaffolding is in place, 
 the core, tricky, algorithmic parts that are hardest to debug become 
 easy to translate.  So in that way the D port benefits from the work 
 that went into debugging the C++.  So it's a win over just writing from 
 scratch.
 
 OpenMesh/D is about 15-20K loc.  I ported that from C++ in about 10 
 days.  No way I would have been able to write that from scratch in the 
 same amount of time.


I'll agree (from much personal experience) that translating code is a 
far better option than rewriting from scratch, in order to get it to a 
different language.
Oct 09 2007
prev sibling parent BLS <nanali nospam-wanadoo.fr> writes:
Jarrett Billingsley schrieb:

 "BLS" <nanali nospam-wanadoo.fr> wrote in message 
 news:fegotb$1l3e$1 digitalmars.com...
 

 Actually coding C++ code in D  means : rewrite it and make it D-ish, 
 instead of translate it.
 This is , simply said shit; and I guess you folks know it.


 
 Wow, harsh.  There are those of us who don't actually spend all of our time 
 translating C++ into D, you know. 
 
 


Yes sure. But in case that you want, respective need to translate, a few 
D language adjustments would help to save you a lot of time. Well, D2 
will have most of the stuff (like struct inherit., opImplicitCast) plus 
DTL. Maybe I should simply wait..
Oct 10 2007
prev sibling parent reply 0ffh <spam frankhirsch.net> writes:
BLS wrote:

 Actually coding C++ code in D  means : rewrite it and make it D-ish, 
 instead of translate it.
 This is , simply said shit; and I guess you folks know it.


Nope, actually, I don't. If you're so in love with C++, why bother with D?

Regards, Frank
Oct 10 2007
parent reply BLS <nanali nospam-wanadoo.fr> writes:
0ffh schrieb:

 BLS wrote:

 Actually coding C++ code in D  means : rewrite it and make it D-ish, 
 instead of translate it.
 This is , simply said shit; and I guess you folks know it.


 
 Nope, actually, I don't. If you're so in love with C++, why bother with D?
 
 Regards, Frank


NOOOOOoooo, clarification ;-), I don't like C++, BUT I need to translate 
some Cpp libs into D. And sometimes it is difficult to do this job 
'cause D 1.x actually lacks some of C++ features. (but D 2 comes with 
struct inheritance., opImplicitCastX, DTL, ....)
Bjoern

beside, C++ is No 2 on my personal programming language SL
Oct 10 2007
parent reply 0ffh <spam frankhirsch.net> writes:
BLS wrote:

 0ffh schrieb:

 If you're so in love with C++, why bother with D?


 NOOOOOoooo, clarification ;-), I don't like C++, BUT I need to translate
 some Cpp libs into D. And sometimes it is difficult to do this job [...]


I suppose life just isn't fair. =)


 beside, C++ is No 2 on my personal programming language SL


What is an SL?

Earlier, BLS wrote:

 &references ... The Rationales do not say a anything about it The D 
 "compared to C" just says ... We don't have it.


Yup, and good riddance I say!
IMHO even the out/ref keyword is a mistake!
(It's also the only mistake of it's kind in Pascal, btw.)


 Struct inheritance Why we need an *alias here instead of just writing 
 structA : structB;


Maybe you have a point here. I suppose mixins can't be used, as there
would probably be a problem overriding.


 C++ op overloading; D is not competitive.


Hmmmm.... I can't recall any major issues here.

Regards, Frank
Oct 10 2007
parent reply BLS <nanali nospam-wanadoo.fr> writes:
0ffh schrieb:

 BLS wrote:

 0ffh schrieb:

 If you're so in love with C++, why bother with D?


 NOOOOOoooo, clarification ;-), I don't like C++, BUT I need to translate
 some Cpp libs into D. And sometimes it is difficult to do this job [...]


 
 I suppose life just isn't fair. =)
 

 beside, C++ is No 2 on my personal programming language SL


 
 What is an SL?
 


I am pretty sure Gerhard Schroeder still has a top ten placement on 
George W. Bush's S-List, HTH :)


 Earlier, BLS wrote:

 &references ... The Rationales do not say a anything about it The D 
 "compared to C" just says ... We don't have it.


 
 Yup, and good riddance I say!
 IMHO even the out/ref keyword is a mistake!
 (It's also the only mistake of it's kind in Pascal, btw.)
 


I do not agree, but this is not the point. The problem is that C++ folks 
seems to love this feature, and I have to translate it into D (somehow).


 Struct inheritance Why we need an *alias here instead of just writing 
 structA : structB;


 
 Maybe you have a point here. I suppose mixins can't be used, as there
 would probably be a problem overriding.
 

 C++ op overloading; D is not competitive.


 
 Hmmmm.... I can't recall any major issues here.
 


For example :
// Allready translated C++ stuff
class CFont
{
public:
   HFONT m_hFont;

   this(HFONT hFont = null)
   {
     m_hFont = hFont;
   }
   ~this()
   {
     if(m_hFont !is null && !DeleteObject(m_hFont))
     m_hFont = null;
   }

// TODO How to translate this C++ construct  into D

     operator HFONT() {return m_hFont;}

// That's the problem.
But as allready said/ D 2 opImplicitCast may solve the problem.


 Regards, Frank


Thanks Bjoern
Oct 10 2007
parent reply 0ffh <spam frankhirsch.net> writes:
BLS wrote:

 0ffh schrieb:

 Earlier, BLS wrote:

 &references ... The Rationales do not say a anything about it The D 
 "compared to C" just says ... We don't have it.


 Yup, and good riddance I say!
 IMHO even the out/ref keyword is a mistake!
 (It's also the only mistake of it's kind in Pascal, btw.)


 I do not agree, but this is not the point. The problem is that C++ folks 
 seems to love this feature, and I have to translate it into D (somehow).


With the help of explicit pointers and dereferencing, I can see no trouble
except you'll need a lot of stars... :)

Regards, Frank

ps. btw. plain C doesn't have &refs either
Oct 10 2007
parent reply BLS <nanali nospam-wanadoo.fr> writes:
0ffh schrieb:


 With the help of explicit pointers and dereferencing, I can see no trouble
 except you'll need a lot of stars... :)
 
 Regards, Frank
 
 ps. btw. plain C doesn't have &refs either


Would be nice if you are willing to offer an example.
It could also be used as example on :
http://www.prowiki.org/wiki4d/wiki.cgi?PortingFromCxx
thanks in advance, Bjoern
Oct 10 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
BLS wrote:

 0ffh schrieb:
 

 With the help of explicit pointers and dereferencing, I can see no 
 trouble
 except you'll need a lot of stars... :)

 Regards, Frank

 ps. btw. plain C doesn't have &refs either


 
 Would be nice if you are willing to offer an example.
 It could also be used as example on :
 http://www.prowiki.org/wiki4d/wiki.cgi?PortingFromCxx
 thanks in advance, Bjoern


He just means have the function return Foo* instead of Foo&.  And then 
use (*foo) everwhere instead of plain foo on calling side.  That's 
pretty much the only reasonable solution I can see.

--bb
Oct 10 2007
parent reply BLS <nanali nospam-wanadoo.fr> writes:
Bill Baxter schrieb:

 BLS wrote:

 0ffh schrieb:


 With the help of explicit pointers and dereferencing, I can see no 
 trouble
 except you'll need a lot of stars... :)

 Regards, Frank

 ps. btw. plain C doesn't have &refs either


 Would be nice if you are willing to offer an example.
 It could also be used as example on :
 http://www.prowiki.org/wiki4d/wiki.cgi?PortingFromCxx
 thanks in advance, Bjoern


 
 He just means have the function return Foo* instead of Foo&.  And then 
 use (*foo) everwhere instead of plain foo on calling side.  That's 
 pretty much the only reasonable solution I can see.
 
 --bb


Thanks for clarification Bill. Wonder why Frank wrote : "except you'll 
need a lot of * " ?
Bjoern
Oct 10 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
BLS wrote:

 Bill Baxter schrieb:

 BLS wrote:

 0ffh schrieb:


 With the help of explicit pointers and dereferencing, I can see no 
 trouble
 except you'll need a lot of stars... :)

 Regards, Frank

 ps. btw. plain C doesn't have &refs either


 Would be nice if you are willing to offer an example.
 It could also be used as example on :
 http://www.prowiki.org/wiki4d/wiki.cgi?PortingFromCxx
 thanks in advance, Bjoern


 He just means have the function return Foo* instead of Foo&.  And then 
 use (*foo) everwhere instead of plain foo on calling side.  That's 
 pretty much the only reasonable solution I can see.

 --bb


 Thanks for clarification Bill. Wonder why Frank wrote : "except you'll 
 need a lot of * " ?
 Bjoern
 


I assumed he meant something like:

-- C++ --
void foo(int &i)
{
   ..lots of uses of 'i' eg "i = 5"..
}

-- D --
void foo(int *i)
{
   ..lots of uses of '*i' eg "*i = 5"..
}

each usage of a converted ref parameter will require a *.

The other problem here however is the call site:

-- C++ --
int i;
foo(i);

-- D --
int i;
foo(&i);

Regan
Oct 10 2007
parent reply BLS <nanali nospam-wanadoo.fr> writes:
Regan Heath schrieb:

 BLS wrote:

 Bill Baxter schrieb:

 BLS wrote:

 0ffh schrieb:


 With the help of explicit pointers and dereferencing, I can see no 
 trouble
 except you'll need a lot of stars... :)

 Regards, Frank

 ps. btw. plain C doesn't have &refs either


 Would be nice if you are willing to offer an example.
 It could also be used as example on :
 http://www.prowiki.org/wiki4d/wiki.cgi?PortingFromCxx
 thanks in advance, Bjoern


 He just means have the function return Foo* instead of Foo&.  And 
 then use (*foo) everwhere instead of plain foo on calling side.  
 That's pretty much the only reasonable solution I can see.

 --bb


 Thanks for clarification Bill. Wonder why Frank wrote : "except you'll 
 need a lot of * " ?
 Bjoern


 
 I assumed he meant something like:
 
 -- C++ --
 void foo(int &i)
 {
   ..lots of uses of 'i' eg "i = 5"..
 }
 
 -- D --
 void foo(int *i)
 {
   ..lots of uses of '*i' eg "*i = 5"..
 }
 


I think :
void foo(ref int i){}
will do the Job in D
( But function parameters are not part of the problem )
Thanks, Bjoern


 each usage of a converted ref parameter will require a *.
 
 The other problem here however is the call site:
 
 -- C++ --
 int i;
 foo(i);
 
 -- D --
 int i;
 foo(&i);
 
 Regan
Oct 10 2007
next sibling parent reply Regan Heath <regan netmail.co.nz> writes:
BLS wrote:

 I think :
 void foo(ref int i){}
 will do the Job in D
 ( But function parameters are not part of the problem )


I know that, I was just guessing what 0ffh (aka Frank) was referring to.

Regan
Oct 10 2007
parent BLS <nanali nospam-wanadoo.fr> writes:
Regan Heath schrieb:

 BLS wrote:

 I think :
 void foo(ref int i){}
 will do the Job in D
 ( But function parameters are not part of the problem )


 
 I know that, I was just guessing what 0ffh (aka Frank) was referring to.


Okay Sorry !

 
 Regan


The problem is ;
//C++
int value = 100;
int &rIntRef = value;

Bjoern
Oct 10 2007
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
BLS wrote:

 Regan Heath schrieb:

 BLS wrote:

 Bill Baxter schrieb:

 BLS wrote:

 0ffh schrieb:


 With the help of explicit pointers and dereferencing, I can see no 
 trouble
 except you'll need a lot of stars... :)

 Regards, Frank

 ps. btw. plain C doesn't have &refs either


 Would be nice if you are willing to offer an example.
 It could also be used as example on :
 http://www.prowiki.org/wiki4d/wiki.cgi?PortingFromCxx
 thanks in advance, Bjoern


 He just means have the function return Foo* instead of Foo&.  And 
 then use (*foo) everwhere instead of plain foo on calling side.  
 That's pretty much the only reasonable solution I can see.

 --bb


 Thanks for clarification Bill. Wonder why Frank wrote : "except 
 you'll need a lot of * " ?
 Bjoern


 I assumed he meant something like:

 -- C++ --
 void foo(int &i)
 {
   ..lots of uses of 'i' eg "i = 5"..
 }

 -- D --
 void foo(int *i)
 {
   ..lots of uses of '*i' eg "*i = 5"..
 }


 
 I think :
 void foo(ref int i){}
 will do the Job in D


Except if you try to call  foo(42).
  -- ERROR 42 is not an lvalue

(Which is another reason why they're often made const in C++ -- you can 
pass a literal or temporary to a const T&, but not to a T&.

--bb
Oct 10 2007
prev sibling parent reply 0ffh <spam frankhirsch.net> writes:
BLS wrote:

 Would be nice if you are willing to offer an example.
 It could also be used as example on :
 http://www.prowiki.org/wiki4d/wiki.cgi?PortingFromCxx
 thanks in advance, Bjoern


Okay, I am more a C type of person not C++, so I hope
I do not write anything wrong now... :)

I have a C++ function getting an int &a:

---<snip>---

void addTo(int &a,int b)
{
   a+=b;
}

void main()
{
   int a=5;
   addTo(a,3);
   printf("a=%i\n",a); // prints "a=8\n"
}

---<snap>---

IIRC this is really just syntactic sugar for passing
a pointer that is automatically dereferenced.
In C I replace the &a with an *a and dereference:

---<snip>---

void addTo(int *a,int b) // &a -> *a
{
   (*a)+=b; // a -> (*a)
}

void main()
{
   int a=5;
   addTo(&a,3); // a -> &a
   printf("a=%i\n",a); // prints "a=8\n"
}

---<snap>---

This has the added advantage, that at the point where the
function is called, I can see that a pointer is passed,
while in C++ I can't. That's why C++ coders so often write
(const T &ref) to avoid accidential side effects which
would be hard to find just looking at the function call.

This might work in D, although I have never tried it:

---<snip>---

void addTo(ref int a,int b)
{
   a+=b;
}

void main()
{
   int a=5;
   addTo(a,3);
   printf("a=%i\n",a); // prints "a=8\n"
}

---<snap>---

Regards, Frank
Oct 10 2007
parent reply BLS <nanali nospam-wanadoo.fr> writes:
0ffh schrieb:

 BLS wrote:

 Would be nice if you are willing to offer an example.
 It could also be used as example on :
 http://www.prowiki.org/wiki4d/wiki.cgi?PortingFromCxx
 thanks in advance, Bjoern


 
 Okay, I am more a C type of person not C++, so I hope
 I do not write anything wrong now... :)
 
 I have a C++ function getting an int &a:
 
 ---<snip>---
 
 void addTo(int &a,int b)
 {
   a+=b;
 }
 
 void main()
 {
   int a=5;
   addTo(a,3);
   printf("a=%i\n",a); // prints "a=8\n"
 }
 
 ---<snap>---
 
 IIRC this is really just syntactic sugar for passing
 a pointer that is automatically dereferenced.
 In C I replace the &a with an *a and dereference:
 
 ---<snip>---
 
 void addTo(int *a,int b) // &a -> *a
 {
   (*a)+=b; // a -> (*a)
 }
 
 void main()
 {
   int a=5;
   addTo(&a,3); // a -> &a
   printf("a=%i\n",a); // prints "a=8\n"
 }
 
 ---<snap>---
 
 This has the added advantage, that at the point where the
 function is called, I can see that a pointer is passed,
 while in C++ I can't. That's why C++ coders so often write
 (const T &ref) to avoid accidential side effects which
 would be hard to find just looking at the function call.
 
 This might work in D, although I have never tried it:
 
 ---<snip>---
 
 void addTo(ref int a,int b)
 {
   a+=b;
 }
 
 void main()
 {
   int a=5;
   addTo(a,3);
   printf("a=%i\n",a); // prints "a=8\n"
 }
 
 ---<snap>---
 
 Regards, Frank


Thanks Frank.
Yes the (ref int a) stuff works fine.
But function parameters are not part of the problem

The problem is ;
//C++
int value = 100;
int & rIntRef = value;

Bjoern
Oct 10 2007
parent reply 0ffh <spam frankhirsch.net> writes:
BLS wrote:

 The problem is ;
 //C++
 int value = 100;
 int & rIntRef = value;


//C
int value = 100;
int *rIntRef = value;

Regards, Frank
Oct 10 2007
parent reply 0ffh <spam frankhirsch.net> writes:
0ffh wrote:

 //C
 int value = 100;
 int *rIntRef = value;


Okay, but only if you don't mind the core dump! =)

//C
int value = 100;
int *rIntRef;
rIntRef = &value;
Oct 10 2007
parent reply BLS <nanali nospam-wanadoo.fr> writes:
0ffh schrieb:

 0ffh wrote:

 //C
 int value = 100;
 int *rIntRef = value;


 
 Okay, but only if you don't mind the core dump! =)
 
 //C
 int value = 100;
 int *rIntRef;
 rIntRef = &value;


int value = 100;
int & rIntRef = value;
if (rIntRef == 100)
   // be ashured
rIntref = 101

This is why I like refrences, they behave like an alias-name. (and are 
Not as dangerous as pointers :)
Thanks Bjoern
Oct 10 2007
parent reply 0ffh <spam frankhirsch.net> writes:
BLS wrote:

 This is why I like refrences, they behave like an alias-name. (and are 
 Not as dangerous as pointers :)


To quote Friedrich Nietzsche:
"The secret to find the most pleasure in life, is to live dangerously."

=)

Regards, Frank
Oct 10 2007
parent BLS <nanali nospam-wanadoo.fr> writes:
0ffh schrieb:

 BLS wrote:

 This is why I like refrences, they behave like an alias-name. (and are 
 Not as dangerous as pointers :)


 
 To quote Friedrich Nietzsche:
 "The secret to find the most pleasure in life, is to live dangerously."
 
 =)
 
 Regards, Frank


LOL;
Man,  I am allready married.
Oct 10 2007