On 12/14/2013 9:12 AM, bearophile wrote:
> Dicebot:
>
>>> 2. dependable sizes of basic types
>>
>> Not a real issue as your platform SDK always includes some kind of "stdint.h"
>
> On the other hand in D you have less noise. Most D modules you find around use
> and will use the built-in types, instead of choosing every time different ones.
> This uniformity is an improvement.

It's true that standard C has a zillion names for an integer, and then a typical project will layer on a mass of its own (even dmd does this). The grief comes because pretty much no C project ever uses them consistently and correctly, implicit narrowing conversions hide the bugs, and of course they get messed up with printf formats.

H. S. Teoh:

> I still do that even in D programs, because DMD's handling of forward references is, shall we say, quirky?

In the last three years it has improved :-) Please submit the remaining bugs on this.

Bye,
bearophile

Am Fri, 13 Dec 2013 18:01:10 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 12/13/2013 6:52 AM, Dicebot wrote:
> >> 1. compile speed
> >
> > Only partially true. Large projects need separate compilation and D does not behave that good in such scenario. Still better than C, but not good enough to make a difference.
> 
> Doesn't behave that good how?

Compiling optimized GtkD static libs for all three compilers and a shard lib for dmd uses 7750s user and 553s system CPU time @ 2 Ghz. That's an average of 35 minutes per complete build. I think this is mostly due to the separate compilation.

-- 
Marco

On 12/14/2013 06:39 PM, H. S. Teoh wrote:
> I still do that even in D programs, because DMD's handling of forward
> references is, shall we say, quirky? It works most of the time, but
> sometimes you get odd errors because certain symbol resolution
> algorithms used by dmd will produce unexpected results if you don't
> declare certain symbols beforehand. So it's not completely order-free,
> but also not completely order-dependent, but something nebulous in
> between. Me, I play it safe and just write things the C way, so that I
> never run into these kinds of issues.

I couldn't resist the temptation and hence I'm still stuck with 2.060. (And the code base contains quite a few hackarounds to make it compile even with 2.060.) It seems really hard to minimize a reproducible test case. Maybe I should just upload the code to github and file a regression report. (But such a bug report does not really address the underlying problem, which is that the spec is ambiguous about this as well. Most bugs related to this get fixed quickly, but the fixes introduce breakage at other points.)

On 12/14/2013 9:19 AM, Timon Gehr wrote:
> On 12/11/2013 12:46 AM, Walter Bright wrote:
>> On 12/10/2013 3:04 PM, Timon Gehr wrote:
>>> Malloc is part of the language runtime. Everything needed is known
>>> about it, in
>>> particular that it is pure (in the D sense). Also, the source code of
>>> malloc
>>> will not be standard C code.
>>
>> All right, so write your own storage allocator. How are you going to
>> tell the C compiler that it's pure?
>
> How about the D compiler?

You can cast the result to const/immutable, which is why the casting is possible. It tells the compiler things that cannot be deduced.

On 12/14/2013 9:37 AM, Paulo Pinto wrote:
> On Saturday, 14 December 2013 at 17:12:16 UTC, bearophile wrote:
>> Dicebot:
>>
>>
>>
>>> @safe is a joke for barebone, you almost never be able to apply it :)
>>
>> I think you can have some safe functions in C-style code too :-)
>
> Yes, given my experience in Turbo Pascal and Oberon, there are lots of places in
> C-style code that code be safe as well.
>
> For example, there are very few places where dark magic pointer tricks are
> really essential.
>
> Only those code sections really need to be unsafe.

Pretty much all use of pointers in C is unsafe because C cannot statically (or dynamically) verify that the pointers point to valid data, or that arithmetic on those pointers will result in pointers to valid data.

This is the huge advantage that D's dynamic arrays have.

You can write safe code in C, but you cannot mechanically verify it as safe.

On 12/14/2013 9:39 AM, H. S. Teoh wrote:
> On Fri, Dec 13, 2013 at 06:01:10PM -0800, Walter Bright wrote:
>> On 12/13/2013 6:52 AM, Dicebot wrote:
> I was so scarred from the experience that when I saw that D supported
> unicode natively, I was totally sold.

Funny story about that. Before I started D, I worked on a C++ project that had to work with Unicode. I ran into all the same issues you did, and also decided that wchar_t was unusable with Unicode. I spent a lot of time getting the Unicode stuff to work correctly. I was so scarred from the experience (!) that I decided that proper Unicode support was an absolute must for D.


>>>> 12. forward referencing (no need to declare everything twice)
>>> Not an issue. C programmers are not tired from typing.
>>
>> C programs tend to be written "bottom up" to avoid forward
>> references. This is not convenient.
>
> I still do that even in D programs, because DMD's handling of forward
> references is, shall we say, quirky? It works most of the time, but
> sometimes you get odd errors because certain symbol resolution
> algorithms used by dmd will produce unexpected results if you don't
> declare certain symbols beforehand. So it's not completely order-free,
> but also not completely order-dependent, but something nebulous in
> between. Me, I play it safe and just write things the C way, so that I
> never run into these kinds of issues.

dmd's forward reference issues come from a bad design choice in the compiler implementation. I've been gradually fixing the design, and things have gotten a lot better. For example, with the latest release you can forward reference enum members, even in the same enum definition!

On 14 December 2013 17:44, Walter Bright <newshound2@digitalmars.com> wrote:
> On 12/14/2013 6:08 AM, Iain Buclaw wrote:
>>
>> The implementation of which existed in GDC first, and was released as dual GPL/BSD license to allow into LDC devs to use and improve (they added 64bit assembler support for instance, years before DMD got 64bit support),
>
>
> I didn't know this, thanks for telling me.
>
>
>> and then subsequently dropped from GDC for a number of valid reasons:
>>
>> 1) Transition towards making a platform/target agnostic frontend implementation.
>>
>> 2) Don't and will never implement the DMD-style calling convention, so all inline assembly in druntime and phobos actually doesn't work with GDC - there's actually a bug report about GDC incorrectly pre-defining D_InlineAsm and friends because of this.
>
>
> dmd's works on multiple platforms and uses version statements to account for ABI differences. It's still easier than having a different syntax.
>

What I meant was that despite being able to handle IASM syntax at one time. eg: std.math or core.cpuid was altered to specifically work with the ABI GDC used on x86 (cdecl).  This was especially noticed from naked assembly, or normal assembly that assumed eg: EAX or the ST registers would be left untouched by the compiler on exiting the function.


>
>> 3) It is a really big WAT on having two conflicting styles, one for x86, another for everything else.
>
>
> gcc gets them wrong for everything else, too :-)
>

>From an implementors point of view, it's easier to pass off inline
assembly directly to the assembler, rather than try to manage it in the compiler.

I honestly don't know how one would be able to make AsmStatement work for non-x86 architectures.  At least this is not possible in GDC unless you want to resort to doing things in a way that are shamed upon (like checking the definition of a particular TARGET macro :)

On 12/14/2013 08:45 PM, Walter Bright wrote:
>
> dmd's forward reference issues come from a bad design choice in the
> compiler implementation. I've been gradually fixing the design, and
> things have gotten a lot better. For example, with the latest release
> you can forward reference enum members, even in the same enum definition!

Broke it.

string bb(int x, string y){ return "3"; }
enum E { foo = bb(cast(int)bar, cast(string)baz), bar=1, baz="2" }

Bring it on! :o)

https://d.puremagic.com/issues/show_bug.cgi?id=11746

On 12/14/2013 11:46 AM, Iain Buclaw wrote:
> I honestly don't know how one would be able to make AsmStatement work
> for non-x86 architectures.  At least this is not possible in GDC
> unless you want to resort to doing things in a way that are shamed
> upon (like checking the definition of a particular TARGET macro :)

I have no idea why it would be hard for non-x86?