www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D as a prototyping language (for C/C++ projects)

reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
I am a novice D programmer and use C++ in my work. One thing I
find myself doing when I need to implement some non-trivial
algorithm is that I will originally code it in D and perform
testing from there to make sure I have the logic right.
Once I have everything working in D I simply port it over to C++.

In my experience this porting is very trivial (it probably helps
there that I write D like a C++ programmer). While I don't have
hard evidence I think that the 'porting' effort to C++ is more
than offset by the productivity gains I achieve fighting with C++
syntax while trying to get the logic right. Most of the porting
effort is simply copying and pasting the D code into my C++
source files and adding headers, replacing imports with includes,
etc. Usually significant portions of the code compile without any
changes.

I was curious to know if anyone else uses D like this. If so this
might be a good way to try and get D into some C++ shops.  The
nice thing about D in my opinion is that even for people without
D experience, if they have C++ experience they can likely 'read'
D code without much trouble (of course some features might not
map over so well - but the languages are syntactically very
close).
Feb 26 2013
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 26.02.2013 16:26, schrieb Craig Dillabaugh:
 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to C++.

i don't get it you are an novice D programmer and your programs are easy to convert back to C++ so you'r not using too much D specials whats the point of doing it like this?
Feb 26 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Tuesday, 26 February 2013 at 15:43:42 UTC, dennis luehring 
wrote:
 Am 26.02.2013 16:26, schrieb Craig Dillabaugh:
 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to 
 C++.

i don't get it you are an novice D programmer and your programs are easy to convert back to C++ so you'r not using too much D specials whats the point of doing it like this?

I do it as well. In D you can write code (mostly) much faster. However, I would not attempt to implement larger projects (more) in D, because D is simply not mature enough and lacks too much. So after writing and testing in D, I port my program/code then in C++ and complete it.
Feb 26 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 26 February 2013 at 15:43:42 UTC, dennis luehring 
wrote:
 Am 26.02.2013 16:26, schrieb Craig Dillabaugh:
 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to 
 C++.

i don't get it you are an novice D programmer and your programs are easy to convert back to C++ so you'r not using too much D specials whats the point of doing it like this?

It's not about using special features. As a matter of fact, I'd think he'd purposefully stay away from special features. The point is that he *develop* the program in D in half the time it would have taken him in C++. Given this productivity gain, he can mess and improve his program much faster and with more quality than he could have in C++. Once his D program is stable and the outline/flow is clearer to him, and he knows what he wants to do, he only has to convert to C++, which can be done very fast. I do this too. It is *very* helpful when you don't know *where* you are going when you start. I'd stick to D all the way, but as namespace said, D may not be mature enough, or stable enough, or just allowed as a final language in the workplace :/
Feb 26 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Craig Dillabaugh:

 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to 
 C++.

I often write the code in D (sometimes I start from Python and then I convert it to D), get it right, write down more tests, then I slowly lower the level of the D code keeping it correct with help of the tests, and then convert it to C. When the code is quite complex, if I do this I waste some time, but it's a known amount of time, while if I follow a more direct route, writing the C code directly, I can't tell how much debugging time I will need. Bye, bearophile
Feb 26 2013
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Tuesday, 26 February 2013 at 15:43:42 UTC, dennis luehring
wrote:
 Am 26.02.2013 16:26, schrieb Craig Dillabaugh:
 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to 
 C++.

i don't get it you are an novice D programmer and your programs are easy to convert back to C++ so you'r not using too much D specials whats the point of doing it like this?

I should qualify that a bit. I don't avoid D features altogether, but I don't necessarily use many of the advanced features (eg. mixins) that might have no equivalent in C++. I work in scientific computing so I do much of my work with arrays. Working with D arrays is much, much nicer than in C++. So I save lots of time getting my algorithm working/tested. Then the porting is pretty simple, because while slices for example are not supported in C++ you can handle the same logic in C++ without too much trouble. However, the C++ code is uglier and not having to deal with that ugliness lets me focus my mental effort on the details of my algorithm. This lets me implement it correctly more quickly. Using D associative arrays vs C++ std.map is another example. Now, I would never suggest using D to prototype a full application or anything like that, but at least for the type of work I tend to do I find that using D lets me focus on my 'algorithm' without fight with awkward syntax.
Feb 26 2013
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Tuesday, 26 February 2013 at 16:15:49 UTC, bearophile wrote:
 Craig Dillabaugh:

 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to 
 C++.

I often write the code in D (sometimes I start from Python and then I convert it to D), get it right, write down more tests, then I slowly lower the level of the D code keeping it correct with help of the tests, and then convert it to C. When the code is quite complex, if I do this I waste some time, but it's a known amount of time, while if I follow a more direct route, writing the C code directly, I can't tell how much debugging time I will need. Bye, bearophile

One of the reasons I like D for this kind of work is that as a multi-paradigm language it lets you do stuff in a style closer what your final C++ code will look like. My research is in satellite image processing, so most of my work involves reading in imagery into 2D arrays and performing processing over all/or part of an image. I find being able to write code like: for(int i =0; i < rows; i++) { for(int j = 0; j < cols; j++) { } } Sometimes is the easiest way to perform certain tasks. D lets you do this and the syntax is exactly the same a C/C++ - Python? I don't know - but I imagine it would be tricker to port to C++! I have found, at least in this particular problem domain, that the C++/D style syntax is about as good as it gets.
Feb 26 2013
prev sibling next sibling parent "renoX" <renozyx gmail.com> writes:
On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh 
wrote:
 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to 
 C++.

I'm curious: is this process still useful with C++11? BR, renoX
Feb 26 2013
prev sibling next sibling parent reply "MattCodr" <matheus_nab hotmail.com> writes:
On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh
wrote:
 I was curious to know if anyone else uses D like this.

I usually do this, but in a little different way. I wrote my code in a interpreted language, and then I port to D or C languages.
Feb 26 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/26/13 11:46 AM, MattCodr wrote:
 On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh
 wrote:
 I was curious to know if anyone else uses D like this.

I usually do this, but in a little different way. I wrote my code in a interpreted language, and then I port to D or C languages.

These are great data points. We should figure how to improve D to lessen the barriers in both directions. Andrei
Feb 26 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-26 18:45, Andrei Alexandrescu wrote:

 These are great data points. We should figure how to improve D to lessen
 the barriers in both directions.

It helps by having convenient functions in the standard library. It also helps with not having to import a lot of modules just to get something simple done. I don't know if it's that I'm not so used to Phobos but it doesn't feel as intuitive to work with in comparison with say Ruby. In particular with Rails which adds a lot of convenient functions. -- /Jacob Carlborg
Feb 26 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-26 20:52, H. S. Teoh wrote:

 Do you have any specific examples?

Return the date from two days ago: Ruby on Rails: 2.days.ago Date.today Time.now D: Clock.currTime - 2.days // Not sure how to do the other two in D This is not that bad but it's a bit less intuitive. Here we also have shortening of "current" which just saves three characters, for no reason. I think it's mostly std.algorithm that is the problem. * reduce - The "reduce" function is really weird. It can't be used as a property. The signature is: reduce!(fun)(seed, range) When it should be: reduce!(seed, fun)(range) And: reduce!(fun)(range, seed) * No algorithm functions for associative arrays. * tap - Ruby has a really nice function, "tap". In D it would look like: T (func, T) (T t) { func(t); return t; } You can do things like: Foo foo () { return (new Foo).tap!((f) { f.x = 3; f.y = 3; }); } This becomes a bit tricky because we want structs to be passed by ref, but preferably we don't want to be able to change the parameter in the delegate. In Ruby it's no problem since all types are reference types. I probably can come up with more later. -- /Jacob Carlborg
Feb 26 2013
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 2/26/13 6:01 PM, Jacob Carlborg wrote:
 On 2013-02-26 20:52, H. S. Teoh wrote:

 Do you have any specific examples?

Return the date from two days ago: Ruby on Rails: 2.days.ago Date.today Time.now D: Clock.currTime - 2.days // Not sure how to do the other two in D This is not that bad but it's a bit less intuitive. Here we also have shortening of "current" which just saves three characters, for no reason. I think it's mostly std.algorithm that is the problem.

And also having to import std.algorithm. In Ruby you can do map, sort and whatever without using an import. You use it so often that an import is annoying.
Feb 26 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-26 22:10, Ary Borenszweig wrote:

 And also having to import std.algorithm. In Ruby you can do map, sort
 and whatever without using an import. You use it so often that an import
 is annoying.

Often you need std.range and std.array as well. -- /Jacob Carlborg
Feb 27 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/26/13 4:01 PM, Jacob Carlborg wrote:
 On 2013-02-26 20:52, H. S. Teoh wrote:

 Do you have any specific examples?

Return the date from two days ago: Ruby on Rails: 2.days.ago Date.today Time.now

The last two return the time right now, how come? Andrei
Feb 26 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-27 00:39, Andrei Alexandrescu wrote:

 The last two return the time right now, how come?

They're supposed to. I just accidentally put them below "Return the date from two days ago". -- /Jacob Carlborg
Feb 27 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-26 20:52, H. S. Teoh wrote:

 Do you have any specific examples?

Some more: isBlank and the opposite isPresent. These exists in Ruby on Rails, this is my D version: https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/core.d -- /Jacob Carlborg
Feb 26 2013
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On 26.02.2013 18:45, Andrei Alexandrescu wrote:
 On 2/26/13 11:46 AM, MattCodr wrote:
 On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh
 wrote:
 I was curious to know if anyone else uses D like this.

I usually do this, but in a little different way. I wrote my code in a interpreted language, and then I port to D or C languages.

These are great data points. We should figure how to improve D to lessen the barriers in both directions. Andrei

REPL?
Feb 27 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/27/13 3:29 AM, Paulo Pinto wrote:
 On 26.02.2013 18:45, Andrei Alexandrescu wrote:
 On 2/26/13 11:46 AM, MattCodr wrote:
 On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh
 wrote:
 I was curious to know if anyone else uses D like this.

I usually do this, but in a little different way. I wrote my code in a interpreted language, and then I port to D or C languages.

These are great data points. We should figure how to improve D to lessen the barriers in both directions. Andrei

REPL?

Good idea. Should be in bugzilla as an enh, although it'll take a while to get to that. Andrei
Feb 27 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-27 11:07, Andrei Alexandrescu wrote:

 Good idea. Should be in bugzilla as an enh, although it'll take a while
 to get to that.

I wonder how good the implementation will be if one just pass the line to rdmd and prints the result. -- /Jacob Carlborg
Feb 27 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/27/13 2:55 PM, Jacob Carlborg wrote:
 On 2013-02-27 11:07, Andrei Alexandrescu wrote:

 Good idea. Should be in bugzilla as an enh, although it'll take a while
 to get to that.

I wonder how good the implementation will be if one just pass the line to rdmd and prints the result.

Try it, rdmd has --eval and --loop. It's useful but not as good as a real REPL. Andrei
Feb 27 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-27 22:54, Andrei Alexandrescu wrote:

 Try it, rdmd has --eval and --loop. It's useful but not as good as a
 real REPL.

I'll give that a try, thanks. -- /Jacob Carlborg
Feb 27 2013
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Tuesday, 26 February 2013 at 16:34:01 UTC, renoX wrote:
 On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh 
 wrote:
 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to 
 C++.

I'm curious: is this process still useful with C++11? BR, renoX

Again since my work is heavily array based probably, I would guess so, but perhaps not quite so much. How long though until C++11 is broadly available?
Feb 26 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 26 February 2013 at 16:34:01 UTC, renoX wrote:
 On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh 
 wrote:
 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to 
 C++.

I'm curious: is this process still useful with C++11? BR, renoX

Have you tried it? C++11 can prototype faster than C++, but it ain't D. On Tuesday, 26 February 2013 at 16:55:50 UTC, Craig Dillabaugh wrote:
 On Tuesday, 26 February 2013 at 16:34:01 UTC, renoX wrote:
 On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh 
 wrote:
 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to 
 C++.

I'm curious: is this process still useful with C++11? BR, renoX

Again since my work is heavily array based probably, I would guess so, but perhaps not quite so much. How long though until C++11 is broadly available?

AFAIK, it's already mostly available from both GCC and VS. *Some* functionality is still missing, but nothing major.
Feb 26 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 02/26/2013 04:26 PM, Craig Dillabaugh wrote:
 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to C++.

I have to say that these days (also as someone who programs for scientific research purposes) I find that I can both write _and_ use D effectively -- the range of functionality that I need to rely on is pretty solid in D. Depending on exactly what it is you need to use, your sense of the "maturity" of D may be paranoid (but of course I appreciate paranoia as a virtue where scientific software is concerned:-). Now, that said, I can see myself doing exactly what you describe in a case where I really felt the need to use C/C++. The major reason to do so would probably be ease of access to C or C++ libraries, or collaborative requirements (most of my colleagues are C++ users for serious number crunching, although at least one typically uses FORTRAN).
Feb 26 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 We should figure how to improve D to lessen the barriers in 
 both directions.

Regarding the D => C conversions I write, time ago I have suggested a "-cstyle" compiler switch: http://d.puremagic.com/issues/show_bug.cgi?id=4580 Bye, bearophile
Feb 26 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 26, 2013 at 08:49:12PM +0100, Jacob Carlborg wrote:
 On 2013-02-26 18:45, Andrei Alexandrescu wrote:
 
These are great data points. We should figure how to improve D to
lessen the barriers in both directions.

It helps by having convenient functions in the standard library. It also helps with not having to import a lot of modules just to get something simple done. I don't know if it's that I'm not so used to Phobos but it doesn't feel as intuitive to work with in comparison with say Ruby. In particular with Rails which adds a lot of convenient functions.

Do you have any specific examples? T -- Study gravitation, it's a field with a lot of potential.
Feb 26 2013
prev sibling next sibling parent "simendsjo" <simendsjo gmail.com> writes:
On Tuesday, 26 February 2013 at 21:10:30 UTC, Ary Borenszweig 
wrote:
 On 2/26/13 6:01 PM, Jacob Carlborg wrote:
 On 2013-02-26 20:52, H. S. Teoh wrote:

 Do you have any specific examples?

Return the date from two days ago: Ruby on Rails: 2.days.ago Date.today Time.now D: Clock.currTime - 2.days // Not sure how to do the other two in D This is not that bad but it's a bit less intuitive. Here we also have shortening of "current" which just saves three characters, for no reason. I think it's mostly std.algorithm that is the problem.

And also having to import std.algorithm. In Ruby you can do map, sort and whatever without using an import. You use it so often that an import is annoying.

I often find myself importing std.algorithm, std.array and std.range even for the simplest things. std.string, std.ascii, std.conv, std.stdio is also quite common at the top of my files.. And *then* I import modules more specific for the problem I'm going to solve :) I sometimes wish I was using an editor that automatically added the imports for me.
Feb 26 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh 
wrote:
 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to 
 C++.

 In my experience this porting is very trivial (it probably helps
 there that I write D like a C++ programmer). While I don't have
 hard evidence I think that the 'porting' effort to C++ is more
 than offset by the productivity gains I achieve fighting with 
 C++
 syntax while trying to get the logic right. Most of the porting
 effort is simply copying and pasting the D code into my C++
 source files and adding headers, replacing imports with 
 includes,
 etc. Usually significant portions of the code compile without 
 any
 changes.

 I was curious to know if anyone else uses D like this. If so 
 this
 might be a good way to try and get D into some C++ shops.  The
 nice thing about D in my opinion is that even for people without
 D experience, if they have C++ experience they can likely 'read'
 D code without much trouble (of course some features might not
 map over so well - but the languages are syntactically very
 close).

I can understand why you are doing this. C++ code tends to be about 3x the volume of well written D code, so a lot of effort is wasted when coding in C++, so if you can get it right through using D, then translate to C++, you'll save a lot of time, but of course we're better off using D directly, but first the language and tool set has to be made production use ready. Once full shared library support comes about, we'll be able to integrate D libs directly into existing C/C++ code. This allows for a safe migration path away from legacy C/C++ to D. --rt
Feb 26 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 26 February 2013 at 23:46:52 UTC, Rob T wrote:
 Once full shared library support comes about, we'll be able to 
 integrate D libs directly into existing C/C++ code. This allows 
 for a safe migration path away from legacy C/C++ to D.

 --rt

Funny story, I'm doing it the other way around. I got my program fully working in D, and am porting it to C. The basic idea is that I'm going to port it "chunk by chunk" to C, while keeping my main in D. This allows me to "package" the finished parts in C, but still work on the rest in D. It also means the porting doesn't have to be done in its totality in a single pass.
Feb 27 2013
prev sibling next sibling parent "simendsjo" <simendsjo gmail.com> writes:
On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh 
wrote:
 I am a novice D programmer and use C++ in my work. One thing I
 find myself doing when I need to implement some non-trivial
 algorithm is that I will originally code it in D and perform
 testing from there to make sure I have the logic right.
 Once I have everything working in D I simply port it over to 
 C++.

I'm surprised to see many people doing this. But I'm wondering.. If you already got the code working in D, why not let it stay there and write a C interface? Company policy? Missing dynamic loading? Some build issues? If the code could stay in D, it would seem like a good way to slowly integrate D into a company.
Feb 27 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 I'm surprised to see many people doing this. But I'm wondering..
 If you already got the code working in D, why not let it stay 
 there and write a C interface?
 Company policy? Missing dynamic loading? Some build issues?

 If the code could stay in D, it would seem like a good way to 
 slowly integrate D into a company.

As we said: D isn't mature enough. As long as your code base isn't too complex, D is very nice but at some point you get many stumbling blocks, bugs or missing features which is very annoying. I like D, but it is far away from using it instead of C++.
Feb 27 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Wednesday, 27 February 2013 at 10:07:43 UTC, Andrei 
Alexandrescu wrote:
 On 2/27/13 3:29 AM, Paulo Pinto wrote:
 On 26.02.2013 18:45, Andrei Alexandrescu wrote:
 On 2/26/13 11:46 AM, MattCodr wrote:
 On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig 
 Dillabaugh
 wrote:
 I was curious to know if anyone else uses D like this.

I usually do this, but in a little different way. I wrote my code in a interpreted language, and then I port to D or C languages.

These are great data points. We should figure how to improve D to lessen the barriers in both directions. Andrei

REPL?

Good idea. Should be in bugzilla as an enh, although it'll take a while to get to that. Andrei

D would be one step closer to actually passing the "BOTCH" test! http://mathprogrammer.com/blog/?p=12
Feb 27 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Wednesday, 27 February 2013 at 08:30:18 UTC, monarch_dodra 
wrote:
 On Tuesday, 26 February 2013 at 23:46:52 UTC, Rob T wrote:
 Once full shared library support comes about, we'll be able to 
 integrate D libs directly into existing C/C++ code. This 
 allows for a safe migration path away from legacy C/C++ to D.

 --rt

Funny story, I'm doing it the other way around. I got my program fully working in D, and am porting it to C. The basic idea is that I'm going to port it "chunk by chunk" to C, while keeping my main in D. This allows me to "package" the finished parts in C, but still work on the rest in D. It also means the porting doesn't have to be done in its totality in a single pass.

I understand why your are doing this, but it must be a ton of work, and has a lot of potential for introducing bugs that do not exist in the D code base. Someone proposed that we compile D to JVM bytecode, but maybe we should have D compile to C or C++ source code instead, at least that can work fully unlike with JVM bytecode, and it would save you guys a lot of work --rt
Feb 27 2013
prev sibling parent "timotheecour" <thelastmammoth gmail.com> writes:
On Wednesday, 27 February 2013 at 19:55:41 UTC, Jacob Carlborg 
wrote:
 On 2013-02-27 11:07, Andrei Alexandrescu wrote:

 Good idea. Should be in bugzilla as an enh, although it'll 
 take a while
 to get to that.

I wonder how good the implementation will be if one just pass the line to rdmd and prints the result.

I'm assuming you're talking about REPL. That won't cut it, as one wants to keep maintain a notion of state (variables in memory etc) and not reparse lines entered everytime (which could have IO side effects etc). I've played a bit with Oskar Linde's library for that and ported it to latest DMD release and it works quite well already, something solid to build upon (see post http://forum.dlang.org/thread/fpmpa6$2muq$1 digitalmars.com).
Feb 27 2013