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.

(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.
 

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:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

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.

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 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 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 KlausO <oberhofer users.sf.net> writes:
Brad Roberts schrieb:
 
 It's my understanding that C# does as well, but I don't have any direct 
 knowledge or experience with it.

C# does not connect to C++ directly (via name mangling). You can invoke 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# does not connect to C++ directly (via name mangling). You can invoke 
 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 next 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.

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

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?

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?

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

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.

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

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

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

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

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.

 
 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

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

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

Man, I am allready married.
Oct 10 2007
prev sibling parent 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.

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

work out.

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

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

It's my understanding that C# does as well, but I don't have any direct knowledge or experience with it.
Oct 09 2007