Hi.

I'm totally new to D, and would like to use it to prototype some compression software ideas. But everywhere in old posts I see that some XYZ feature of the language is buggy, subject to change, etc. But I don't know how it is today, and I would rather not learn what is wrong with the feature in the hard way, by stumbling in the compiler bugs. My hand will be full with my own bugs, and I would like to suppose an correctly working language...

So, is there any up to date documentation on D implementation, saying what is stable, what is beta quality (and I should use with caution), what is alpha (and I should really avoid), and what is unimplemented?

Also, witch compiler I should use? In the [url=http://dlang.org/dmd-windows.html]DMD requirements[/url], it says "32 bit Windows (Win32) operating system, such as Windows XP", so I guess I'm out of luck with Windows 7 64 bits... Do I really have to use a VM to develop in D for running in Windows? And on linux, which is the most stable? Which is the faster one for my use case?

Thanks.

ReneSac:

> My hand will be full with my own bugs, and I would like to suppose an correctly working language...

If you use more than the basic C features, you will find DMD
compiler bugs (and probably the same is true for any D compiler,
because most bugs are in the front-end, that is shared). Lately I
hit new bugs less often, but they happen still.

Bye,
bearophile

Am 05.04.2012 17:56, schrieb bearophile:
> ReneSac:
>
>> My hand will be full with my own bugs, and I would like to suppose an
>> correctly working language...
>
> If you use more than the basic C features, you will find DMD
> compiler bugs (and probably the same is true for any D compiler,
> because most bugs are in the front-end, that is shared). Lately I
> hit new bugs less often, but they happen still.
>
> Bye,
> bearophile

Well, that's true, sometimes you hit a compiler or phobos-bug, but it's not like:

uhm, today I wanna code something, let's begin … 5 minutes later … uh tha fuq another compiler bug !!!!

It has gotten pretty rare that you hit them and when you do, you normally realize it very soon that this is a bug from the compiler (e.g. cod2.c shows up in the error message).
And if you hit one, ppl in the IRC or here will help you out, with a bugfix or a workaround!

On Thursday, 5 April 2012 at 15:01:53 UTC, ReneSac wrote:
> Hi.
>
> I'm totally new to D, and would like to use it to prototype some compression software ideas.

You'll be pretty safe using features you know for C, but you can venture out pretty far from it.

While, the page isn't specific to the questions you have at hand, this does cover much of the current state. Remember, recently implemented features are more likely to have bugs.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel

On Thursday, 5 April 2012 at 18:34:05 UTC, Jesse Phillips wrote:
>
> You'll be pretty safe using features you know for C, but you can venture out pretty far from it.
>
> While, the page isn't specific to the questions you have at hand, this does cover much of the current state. Remember, recently implemented features are more likely to have bugs.

I will probably program close to C/Lua style (the languages I'm most proficient with), but "pretty far" is vague. And I haven't been following the time line of the feature additions, like old users do, and I'm not sure if I should read the entire changelog for some vague indication of the stability of a feature...

> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel

Ok, that page gives some pointers. Seems like I shouldn't use std.stream. So, std.cstream or std.stdio are safe?

Dynamic Arrays, Slicing, Unittest, conditional compilation and compile time function execution should be working well, right? What about std.paralelism and message passing, non-shared multithreading?

And I still don't know how to generate windows executables.. If it is really impossible to compile D in Windows 64 bits, then what is the best compiler for Linux?

Am 05.04.2012 23:10, schrieb ReneSac:
> Ok, that page gives some pointers. Seems like I shouldn't use
> std.stream. So, std.cstream or std.stdio are safe?

I also heared that, but actually std.stream works pretty well, especially the EndianStream. So I can recommend you to use it.

On Thursday, 5 April 2012 at 21:10:41 UTC, ReneSac wrote:

> I will probably program close to C/Lua style (the languages I'm most proficient with), but "pretty far" is vague. And I haven't been following the time line of the feature additions, like old users do, and I'm not sure if I should read the entire changelog for some vague indication of the stability of a feature...

The page I liked does have compiler versions for some of the implemented features, as you appear to have noticed.

>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel
>
> Ok, that page gives some pointers. Seems like I shouldn't use std.stream. So, std.cstream or std.stdio are safe?

Hmm, bring up a good point, I think someone is working on revamping stdio, though I would think it would mostly remain compatible. Who's doing that? Could you write the details here:

http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue

> Dynamic Arrays, Slicing, Unittest, conditional compilation and compile time function execution should be working well, right?

Yep, there are some requested improvements but, things are stable.

> What about std.paralelism and message passing, non-shared multithreading?

I'm not sure how much use they have been getting, so it is hard to say. I know there have been questions about how to use them, but they seem solid.

If you get into using shared though, you'll probably walk into areas that will require casting to get things done. I don't know what if any changes are planned, but likely it needs a closer look.

> And I still don't know how to generate windows executables.. If it is really impossible to compile D in Windows 64 bits, then what is the best compiler for Linux?

Sorry, forgot to cover that. I believe GDC will compile 64bit Windows applications, but otherwise you can still compile and run 32bit applications.

Most people use DMD, but GDC, I hear, should be on par.

On Thursday, 5 April 2012 at 22:07:05 UTC, Jesse Phillips wrote:
> On Thursday, 5 April 2012 at 21:10:41 UTC, ReneSac wrote:
>
>> I will probably program close to C/Lua style (the languages I'm most proficient with), but "pretty far" is vague. And I haven't been following the time line of the feature additions, like old users do, and I'm not sure if I should read the entire changelog for some vague indication of the stability of a feature...
>
> The page I liked does have compiler versions for some of the implemented features, as you appear to have noticed.
>
Ah, I saw "The following list of major issues dates from July 2009." So I supposed it was old, but now I see that I understood wrong.

>>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel
>>
>> Ok, that page gives some pointers. Seems like I shouldn't use std.stream. So, std.cstream or std.stdio are safe?
>
> Hmm, bring up a good point, I think someone is working on revamping stdio, though I would think it would mostly remain compatible. Who's doing that? Could you write the details here:
>
So, what I should use?

> http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue
>
>> Dynamic Arrays, Slicing, Unittest, conditional compilation and compile time function execution should be working well, right?
>
> Yep, there are some requested improvements but, things are stable.
Good! Thanks.

>
>> What about std.paralelism and message passing, non-shared multithreading?
>
> I'm not sure how much use they have been getting, so it is hard to say. I know there have been questions about how to use them, but they seem solid.
>
> If you get into using shared though, you'll probably walk into areas that will require casting to get things done. I don't know what if any changes are planned, but likely it needs a closer look.
>
I would try to avoid anything shared anyway. It is hard to program if "a++" isn't deterministic...

>
> Sorry, forgot to cover that. I believe GDC will compile 64bit Windows applications, but otherwise you can still compile and run 32bit applications.
>
> Most people use DMD, but GDC, I hear, should be on par.

I don't need a 64bit binary right now. Actually, I would even prefer a 32bit one for development because then I can't run too wild in memory usage. The problem is that DMD seems to require 32 bit windows, according to the page I linked... Is it not true?

Anyway, GDC seems to have quite better performance/optimization, so I may end up using it... But I also heard bad things about it in old posts... so...

On Fri, Apr 06, 2012 at 12:42:57AM +0200, ReneSac wrote:
> On Thursday, 5 April 2012 at 22:07:05 UTC, Jesse Phillips wrote:
[...]
> Anyway, GDC seems to have quite better performance/optimization, so I may end up using it... But I also heard bad things about it in old posts... so...

I use GDC for some of my D projects. I didn't find anything wrong with it. Plus, GCC's backend optimizer is a LOT better than dmd. Something to consider if you're writing performance-critical code.


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.

On Friday, April 06, 2012 00:07:03 Jesse Phillips wrote:
> Hmm, bring up a good point, I think someone is working on revamping stdio, though I would think it would mostly remain compatible. Who's doing that? Could you write the details here:

It's Steven Schveighoffer, but it's far from ready, since he hasn't had a lot of time to work on it of late. He put up an initial version for feedback a few weeks back, and one of the main points of feedback (which Walter felt very strongly about) was that it needed to be compatible with the current std.stdio rather than having a whole new API, so while it may do new stuff and have a better implementation, most (all?) of the stuff using the current std.stdio will continue to work with the new one whenever it's finished.

- Jonathan M Davis