• John Carter (26/26) Sep 01 2013 So I'm a reasonably experienced C/C++/Ruby/... programmer and D
• maarten van damme (6/31) Sep 01 2013 1) afaik you can't cross compile to arm with dmd. I know it's possible w...
• bearophile (28/44) Sep 01 2013 I think you could use D for embedded area, but I think of D more
• Adam D. Ruppe (15/18) Sep 01 2013 If you mean my little libs, I'm not really aiming for complex
• John Carter (30/34) Sep 01 2013 Here is the documentation...
• bearophile (14/16) Sep 01 2013 Porting C code to D is not hard, it's mostly mechanical work, you
• Craig Dillabaugh (26/42) Sep 04 2013 While I just had a brief look at CImg and am thus far from an
• Dicebot (9/20) Sep 02 2013 dmd is usually used only as development compiler because it is a
• Ramon (38/38) Sep 05 2013 Maybe I'm somewhat disturbed but I'd rather go the other way

"John Carter" <john.carter taitradio.com> writes:

So I'm a reasonably experienced C/C++/Ruby/... programmer and D 
is looking very Good to me...

So, time to get serious and sit down and learn it.

Ultimately it won't pay me to learn it unless I can ultimately 
take my colleagues along.

Currently they are itching to move from C to C++, and I'm trying 
to convince them not to.

We work in the embedded linux real time area, so here are a few 
newbie questions that I couldn't spot the answer to...

1) Which D compiler should we start with? We use gcc/g++ for 
everything else, is gcd a good choice or should we stick with 
Digital mars one? (We would be cross compiling to sparc or arm)

2) The traditional argument against garbage collected languages 
in real time environments is that they sporadically lock up while 
collecting resulting in missed real time deadlines. Certainly the 
"state of the art" in GC has moved beyond this, and also there 
are workarounds for the problem. Is it possible to do real time 
programming in D?

3) A good starter project for me would be to take a well known 
cpu-intensive C++ template rich project and convert it to D and 
then present that side-by-side to my colleagues.

I like playing around with CImg, http://cimg.sourceforge.net/

CImg it is one huge template with chunks of macro magic to do 
image processing.

Before I start, has anyone converted CImg to DImg yet?

Thanks!

maarten van damme <maartenvd1994 gmail.com> writes:

1) afaik you can't cross compile to arm with dmd. I know it's possible with
gdc.
2) There are people who successfully use d without gc. I think andrei
posted a stub gc that throws an exception every time the garbage collector
is tried to get used. You can't use whole phobos (yet) without gc.


2013/9/2 John Carter <john.carter taitradio.com>

 So I'm a reasonably experienced C/C++/Ruby/... programmer and D is looking
 very Good to me...

 So, time to get serious and sit down and learn it.

 Ultimately it won't pay me to learn it unless I can ultimately take my
 colleagues along.

 Currently they are itching to move from C to C++, and I'm trying to
 convince them not to.

 We work in the embedded linux real time area, so here are a few newbie
 questions that I couldn't spot the answer to...

 1) Which D compiler should we start with? We use gcc/g++ for everything
 else, is gcd a good choice or should we stick with Digital mars one? (We
 would be cross compiling to sparc or arm)

 2) The traditional argument against garbage collected languages in real
 time environments is that they sporadically lock up while collecting
 resulting in missed real time deadlines. Certainly the "state of the art"
 in GC has moved beyond this, and also there are workarounds for the
 problem. Is it possible to do real time programming in D?

 3) A good starter project for me would be to take a well known
 cpu-intensive C++ template rich project and convert it to D and then
 present that side-by-side to my colleagues.

 I like playing around with CImg, http://cimg.sourceforge.net/

 CImg it is one huge template with chunks of macro magic to do image
 processing.

 Before I start, has anyone converted CImg to DImg yet?

 Thanks!

"bearophile" <bearophileHUGS lycos.com> writes:

John Carter:

 We work in the embedded linux real time area,

I think you could use D for embedded area, but I think of D more 
like a low level application language.


 1) Which D compiler should we start with?

dmd is more updated and it's the reference one, it compiles fast, 
but it produces less optimized binaries. All D compilers have 
some advantages and disadvantages. Also take in account the ldc2 
compiler.


 (We would be cross compiling to sparc or arm)

I don't know about Sparc, but arm is being worked on gdc, but I 
don't expect the libraries to work well.


 2) The traditional argument against garbage collected languages 
 in real time environments is that they sporadically lock up 
 while collecting resulting in missed real time deadlines. 
 Certainly the "state of the art" in GC has moved beyond this, 
 and also there are workarounds for the problem. Is it possible 
 to do real time programming in D?


engines): you have to not allocate in the real-time parts of the 
code. Heap allocations in geeral, and GC allocations in 
particular are not yet designed for realtime work.


 3) A good starter project for me would be to take a well known 
 cpu-intensive C++ template rich project and convert it to D and 
 then present that side-by-side to my colleagues.

To do that you have to learn D first, learn the D idioms, and 
then write the translation. It will take some time. Do you 
already have an idea for what code to translate?


 I like playing around with CImg, http://cimg.sourceforge.net/

I have used CImg in past, and it's a cute huge header. I like it 
for its lack of dependences. Importing a header is (or was) 
enough.


 CImg it is one huge template with chunks of macro magic to do 
 image processing.

I didn't know it uses significant macros. Could you show some of 
such code pieces?


 Before I start, has anyone converted CImg to DImg yet?

I think no one has converted CImg to D. There is a graphics 
project for D, perhaps named simplegraphics, that contains about 
0.01% of CImg.

I don't know but perhaps the conversion CImg to D could take a 
year or two of work for a person that knows D :-)

Bye,
bearophile

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Monday, 2 September 2013 at 00:32:52 UTC, bearophile wrote:
 I think no one has converted CImg to D. There is a graphics 
 project for D, perhaps named simplegraphics, that contains 
 about 0.01% of CImg.

If you mean my little libs, I'm not really aiming for complex 
drawing. simpledisplay.d has the basic functions that all 
operating systems have (lines, rectangles, etc.) and as of 
recently, some OpenGL support for drawing on screen, but not much 
beyond that.

I am working on a generic drawing library that works entirely in 
memory without OS assistance, but again my plan is to keep it 
simple and just do the basics so it won't be anywhere near what 
cimg does. Some of this code is now in color.d on my github, and 
more is in a file called image_basicdrawing that I haven't posted 
online yet.

But I use words like "simple" and "basic" in the filenames 
hopefully to keep people from getting their hopes too high so 
they aren't disappointed when it doesn't do what they want :)

"John Carter" <john.carter taitradio.com> writes:

Thanks for your reply!

On Monday, 2 September 2013 at 00:32:52 UTC, bearophile wrote:

 I didn't know it uses significant macros. Could you show some 
 of such code pieces?

Here is the documentation...
http://cimg.sourceforge.net/reference/group__cimg__loops.html
// Macros to perform various image loops.
//
// These macros are simpler to use than loops with C++ iterators.
#define cimg_for(img,ptrs,T_ptrs) for (T_ptrs *ptrs = 



Probably more interesting are the neighbourhood ops like...
#define cimg_for2(bound,i) \




#define cimg_for2x2(img,x,y,z,c,I,T) \
   cimg_for2((img)._height,y) for (int x = 0, \

    (I[0] = (T)(img)(0,y,z,c)), \

    1>=(img)._width?(img).width()-1:1);  \




    I[0] = I[1], \
    I[2] = I[3], \


 I don't know but perhaps the conversion CImg to D could take a 
 year or two of work for a person that knows D :-)

I guess one of the interesting questions it would answer is "How 
easy is it to convert both C++ programs and C++ programmers to D?"

"bearophile" <bearophileHUGS lycos.com> writes:

John Carter:

 "How easy is it to convert both C++ programs and C++ 
 programmers to D?"

Porting C code to D is not hard, it's mostly mechanical work, you 
just have to keep an eye on few things (like passing fixed-sized 
arrays to functions by reference, global floating point data not 
initialized to zero, etc).

I think that for a C++ programmer it's not too much hard to learn 
D. But converting C++ code to D could be very hard (and a slow 
work) if the code uses lot of small things that are specific of 
C++ and missing or different in D. If the C++ code is more plain, 
then it's probably not hard, despite the missing multiple 
inheritance and struct inheritance.

Converting CImg to D seems a multi-years work.

Bye,
bearophile

"Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:

On Monday, 2 September 2013 at 02:38:35 UTC, bearophile wrote:
 John Carter:

 "How easy is it to convert both C++ programs and C++ 
 programmers to D?"

 Porting C code to D is not hard, it's mostly mechanical work, 
 you just have to keep an eye on few things (like passing 
 fixed-sized arrays to functions by reference, global floating 
 point data not initialized to zero, etc).

 I think that for a C++ programmer it's not too much hard to 
 learn D. But converting C++ code to D could be very hard (and a 
 slow work) if the code uses lot of small things that are 
 specific of C++ and missing or different in D. If the C++ code 
 is more plain, then it's probably not hard, despite the missing 
 multiple inheritance and struct inheritance.

 Converting CImg to D seems a multi-years work.

 Bye,
 bearophile

While I just had a brief look at CImg and am thus far from an
expert I wonder if developing a similar project in D would be
quite that bad.  There seems like a lot of the code isn't core
functionality for an image processing library.

The whole header file is 40+K lines of code.

The system seems to include its own cross-platform image/graphics
rendering system. There are 1100+ loc are just static arrays
storing fonts.

Furthermore, while it does seem to include a tonne of image
processing functions, I am sure a basic library could initially
omit many of these.
For example there is a math formula parser that accounts for a
huge chunk of the library.  Certainly something you would want to
have in the long run, but might be omitted initially.

Finally, the use of templates seems fairly straightforward - at
least by my brief perusal, and the code is more C like that C++
like.  It doesn't appear to have a complex object hierarchy at
all.


So, I think this might be doable if:

1. You skipped the image display system (that shouldn't be part
of a library in my opinion anyway).

2. You identified what your priority functionality would be and
(initially at least) dropped the others [eg. the math formula
parser].

Craig

"Dicebot" <public dicebot.lv> writes:

On Sunday, 1 September 2013 at 23:35:16 UTC, John Carter wrote:
 We work in the embedded linux real time area, so here are a few 
 newbie questions that I couldn't spot the answer to...

 1) Which D compiler should we start with? We use gcc/g++ for 
 everything else, is gcd a good choice or should we stick with 
 Digital mars one? (We would be cross compiling to sparc or arm)

dmd is usually used only as development compiler because it is a 
reference one and because if fast compilation times. ldc and gdc 
code gen is much better and cross-compilation to arm is a serious 
indication that gdc is a best option.

 2) The traditional argument against garbage collected languages 
 in real time environments is that they sporadically lock up 
 while collecting resulting in missed real time deadlines. 
 Certainly the "state of the art" in GC has moved beyond this, 
 and also there are workarounds for the problem. Is it possible 
 to do real time programming in D?

I have answered this some time ago on SO: 


It is possible but not convenient. And requires good knowledge of 
D internals.

"Ramon" <spam thanks.no> writes:

Maybe I'm somewhat disturbed but I'd rather go the other way
round, i.e. (ab)use D as a comfortable and less error prone way
to create C Code. But oh well that's wet dreaming anyway for
quite some time.

To your questions:

Considering that you are new to D (like myself), come from gnu
compiler world and are doing embedded, you will most likely be
used to and want debugging. Therefore -> GDC.
It's simply the only option that allows for painless debugging.
Furthermore, support by the developer(s) is excellent and
friendly.

DMD is the ref. and is, besides some quirks, nicely working and
uncannily fast.
LDC (haven't had a closer look at it myself) is interesting for
llvm alone.

Right now, though, GDC is what you might want to have good look
at.

Ad "GC": As some pros already indicated, it's possible; well,
many things are possible - but it wise?

I think it depends a whole lot on factors like CPU, RAM, RT'ness.
For something highly RT critical on a 16bit, 20K RAM MCU GC is a
no-go and so quite probably is D.
For a "fat" Cortex M4 or a SPARC (what a beauty!) with RAM in the
MB range and real-time needs/criticality being not so high or
even sporadic D could quite well be the way to go, if only phobos
were completely ported.
Even a certain level of RT-crit. must not necessarily be a reason
to stay away from D, if e.g. one could split the job in a low
layer C and the major part in D with all its strengths and
comfort.

In summary though, it - unfortunately - seems somewhat early to
switch to D for embedded on Arm and Sparc.

Should you learn D or at least have an extended look at it,
anyway? Definitely yes. And if it was only to see what's
possible, how C-like programming can and should be done, and to
better and more deeply understand paradigms and concepts related
to reliability.

A+ -R