On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright wrote:
>> that does not even help you in sticking with that crippled subset.
>
> Is there a point to having a compiler flag that'll warn you if you use "pure"?

Ugh, how "pure" is relevant? (I have not tried it but would expect it to work in C-like code, it is just an annotation after all). I am speaking about control about hidden allocations / gc, referring to TypeInfo's and stuff like that. Stuff you get in C out-of-the box because it does no clever magic. In D right now all you can is to get rid of runtime and check for linker errors - not impossible to do, but clearly less convenient than compile-time errors.

> Off the top of my head:
>
> 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.

> 2. dependable sizes of basic types

Not a real issue as your platform SDK always includes some kind of "stdint.h"

> 3. unicode

Number one my list of advantages. Does not apply to plenty of projects though.

> 4. wchar_t that is actually usable

Same as (3)

> 5. thread local storage

It is lot of pain and source of problems, not advantage. Extra work to hack the druntime to get stuff working on barebone.

> 6. no global errno being set by the math library functions

This has made me smile :) It shows how different applications we have in mind speaking about "C domain".

> 7. proper IEEE 754 floating point

Potentially useful but largely mitigated by platform-specific development.

> 8. no preprocessor madness

Would have called this a feature if one could actually use something instead out of the box. But there is no way to control symbol visibility right now so templates / CTFE are often out of the toolset. And what to do without those?

> 9. modules

Other than (1) it is also more a problem than help in current implementation - you need to care also about emitted ModuleInfo.

> 10. being able to pass array types to functions without them degenerating to pointers

Agreed,

> 11. inline assembler being a part of the language rather than an extension that is in a markedly different format for every compiler

Not an issue. You almost always stick to specific compiler in barebone world (one adapted for your platform).

> 12. forward referencing (no need to declare everything twice)

Not an issue. C programmers are not tired from typing.

> 13. no need for .h files

Same as (9)

> 14. no ridonculous struct tag name space with all those silly
>
>     typedef struct S { ... } S;
>
> declarations.

Nice but just a syntax sugar yet again.

> 15. no need for precompiled headers

Same as (9)

> 16. struct alignment as a language feature rather than an ugly extension kludge

Same as (11)

> 17. no #include guard kludges

OH MY GOD EXTRA <10 LINE OVERHEAD PER HEADER

> 18. #define BEGIN { is thankfully not possible

Very tempting but partially mitigated by (8)

> 19. no need for global variables when qsorting

Doesn't matter

> 20. no global locale madness

(no idea what this means)

> And if you use D features even modestly, such as auto, purity, out variables, @safe, const, etc., you can get a large improvement in clarity in function APIs.

`auto` has no real value in C world because there are not crazy template types. @safe is a joke for barebone, you almost never be able to apply it :) Purity, transitive immutability - yeah, those are also top reasons in my list why I'd really love to see D in that domain.

But most of those advantages are high-level advantages. To get there and make use of those you need to get through issues that hit you from the very beginning and frustrate _before_ you can see how awesome high-level stuff is:

- Allocation for stuff like array literals making those unusable once you remove runtime away
- No internal linkage or reliable LTO  - no way to take care of unused symbols and control binary size / layout
- Requried to stub out TypeInfo / ModuleInfo to use literally anything

Note that those are not _fundamental_ language issues. It is possible to fix those via slight tweaks to compiler / spec. But it is state of affairs right now and I need to include time estimates to implement those any time when asked how feasible would have been to use D in that domain (some of my old colleagues have been casually asking me about it).

On Friday, 13 December 2013 at 13:07:32 UTC, Rainer Schuetze wrote:
> Implicite TLS in XP-DLLs has a workaround in druntime for a few years now (emulating it for the system). IIRC Denis has even found a solution how to unload these DLLs later.

There must still be some bugs, I tried the COM thing not long ago (I think it was October) and it worked so perfectly on Vista and Win7 yet failed so miserably on XP. D exes are fine, but the dll loaded into another program didn't work well at all.

> Usually you should not create a lot of global variables, and if I do, I mostly want them shared. But coming from C++ I often tend to forget to add the modifier. I remember a few years ago, almost every occurrence of TLS in phobos was converted to shared or immutable...

Aye.

On 13.12.2013 15:59, Adam D. Ruppe wrote:
> On Friday, 13 December 2013 at 13:07:32 UTC, Rainer Schuetze wrote:
>> Implicite TLS in XP-DLLs has a workaround in druntime for a few years
>> now (emulating it for the system). IIRC Denis has even found a
>> solution how to unload these DLLs later.
>
> There must still be some bugs, I tried the COM thing not long ago (I
> think it was October) and it worked so perfectly on Vista and Win7 yet
> failed so miserably on XP. D exes are fine, but the dll loaded into
> another program didn't work well at all.

Do you use DllMain from http://dlang.org/dll.html#Cinterface? I guess so, if it runs on Vista/Win7.

What version of XP are you running? It might be a special version of ntdll.dll that is not supported. (I'll have to dig up supported versions from an older disk, though.)

Visual D is full of COM, but it does not use the default COM implementation, see https://d.puremagic.com/issues/show_bug.cgi?id=4092.

On Thursday, 12 December 2013 at 13:17:14 UTC, Manu wrote:
> But that's not a concern for typical programmers. That the responsibility
> of sysadmins.
> What I meant was, 'what's more valuable [to a programmer]...'

Leaning dangerously close to philosophy here :)

>> Did you use many different compilers? I am afraid that doing that on a
>> common basis is feat of strength beyond my imagination :)
>
>
> Yup. Over the past 10 years, my day job involved:
> ...

Well, you are much more proficient and experienced C programmer than me :P (And than I will ever be considering I have no desire to return to that world) It is clearly beyond my imagination. I have been investigating dissassembly only to verify which stuff actually gets there and which not and debugging of course.

>> And of course I am speaking about drivers / kernels / barebone. I can't
>> imagine any other domain where using C is still absolutely necessary for
>> practical reasons.
>
> You mean C-like-native-languages? There's not really anything C offers that
> C++/D doesn't also offer at the lowest level.

Right now problem is not with stuff C offers and D not. It is stuff that D offers on top and you are forced to fight to get back to C level of simplicity.

> Our choice to use C rather than C++ was in a sense, a funny way to enforce
> a coding standard. Like I say, it forces simplicity, and a consistent
> approach to problems.

When I was speaking about "domains where C is still necessary" I was not opposing it to C++ but other modern languages in general. Even real-time service development is quite possible using stuff like Erlang these days. Okay, there is also gamedev which I won't dare to speak about :) But in general there is no much sense to speak about replacing C and imagining any "normal" userspace application, even performance-critical.

Some time ago I have been part of project that completely changed my image of what C domain can be. It remains most mind-blowing experience in my programming history (which is damn short of course but can't resist dramatical intro). Project was in mobile networking / LTE domain with huge amount of people involved all over the world. Specifically our team in Latvia was responsible for node cluster software which acted essentially as a giant router + firewall. Actual nodes were custom multi-core MIPS machines with h/w implementation of event loop and part of IP stack handling. All actual packet processing code ran as barebone executables - no OS, not virtual memory or any fancy stuff, just platform SDK you take to build single processing binary which is than loaded at hard-coded memory address (all remaining memory is pre-allocated for packet handling purposes). No really complicated processing algorithms or anything like that but everyone was extremely picky about tiny details how this binary was actually running - making sure no instruction cache misses happen under normal workflow for each core, connection context struct fits into single cache line and stuff like that. And one of my responsibilities was actual performance testing of that system so I could have observed how much of an impact those seemingly small tweaks have made.

And now every time I hear that "language X can do all stuff C can" I imagine myself trying to sell this to other guys working on that project and have an extremely hard time doing this even in my imagination.

On 14 December 2013 01:42, Dicebot <public@dicebot.lv> wrote:

> On Thursday, 12 December 2013 at 13:17:14 UTC, Manu wrote:
>
>> But that's not a concern for typical programmers. That the responsibility
>> of sysadmins.
>> What I meant was, 'what's more valuable [to a programmer]...'
>>
>
> Leaning dangerously close to philosophy here :)
>

Can you offer an alternative? :)


 Our choice to use C rather than C++ was in a sense, a funny way to enforce
>> a coding standard. Like I say, it forces simplicity, and a consistent approach to problems.
>>
>
> When I was speaking about "domains where C is still necessary" I was not opposing it to C++ but other modern languages in general. Even real-time service development is quite possible using stuff like Erlang these days. Okay, there is also gamedev which I won't dare to speak about :) But in general there is no much sense to speak about replacing C and imagining any "normal" userspace application, even performance-critical.
>
> Some time ago I have been part of project that completely changed my image of what C domain can be. It remains most mind-blowing experience in my programming history (which is damn short of course but can't resist dramatical intro). Project was in mobile networking / LTE domain with huge amount of people involved all over the world. Specifically our team in Latvia was responsible for node cluster software which acted essentially as a giant router + firewall. Actual nodes were custom multi-core MIPS machines with h/w implementation of event loop and part of IP stack handling. All actual packet processing code ran as barebone executables - no OS, not virtual memory or any fancy stuff, just platform SDK you take to build single processing binary which is than loaded at hard-coded memory address (all remaining memory is pre-allocated for packet handling purposes). No really complicated processing algorithms or anything like that but everyone was extremely picky about tiny details how this binary was actually running - making sure no instruction cache misses happen under normal workflow for each core, connection context struct fits into single cache line and stuff like that. And one of my responsibilities was actual performance testing of that system so I could have observed how much of an impact those seemingly small tweaks have made.
>
> And now every time I hear that "language X can do all stuff C can" I imagine myself trying to sell this to other guys working on that project and have an extremely hard time doing this even in my imagination.
>

Heh, this sounds pretty much like my life. The same discipline applies to
any realtime embedded software (read: video game console). I'm brutally
conscious of all the details you mention.
I don't think D is incompatible with this at all though. It was early last
year... until I convinced Walter to implement align() properly. Now we're
good! :)
I could still REALLY do with __forceinline though. D doesn't have an
effective macro.
Obviously, if by 'language X' you mean 'any non-compiled language with
pointers', then I totally agree! People who make claims like you say, don't
generally know what they're talking about, or what C is actually used for.

On Friday, 13 December 2013 at 16:28:33 UTC, Manu wrote:
> I could still REALLY do with __forceinline though. D doesn't have an
> effective macro.
> Obviously, if by 'language X' you mean 'any non-compiled language with
> pointers', then I totally agree! People who make claims like you say, don't
> generally know what they're talking about, or what C is actually used for.

I believe (and have posted it over 100 times in NG already :P) D absolutely needs either way to force internal linkage or good LTO symbol elimination. Without preprocessor there is not much you can do to eliminate code duplication other than templates / CTFE - and it bloats resulting executables damn lot, something that was very controllable in C.

On 14 December 2013 02:50, Dicebot <public@dicebot.lv> wrote:

> On Friday, 13 December 2013 at 16:28:33 UTC, Manu wrote:
>
>> I could still REALLY do with __forceinline though. D doesn't have an
>> effective macro.
>> Obviously, if by 'language X' you mean 'any non-compiled language with
>> pointers', then I totally agree! People who make claims like you say,
>> don't
>> generally know what they're talking about, or what C is actually used for.
>>
>
> I believe (and have posted it over 100 times in NG already :P) D absolutely needs either way to force internal linkage or good LTO symbol elimination. Without preprocessor there is not much you can do to eliminate code duplication other than templates / CTFE - and it bloats resulting executables damn lot, something that was very controllable in C.
>

templates aren't guaranteed to inline, and they produce horrible symbol bloat. ctfe isn't inlining, it's pre-computation/runtime elimination. mixin is the closest, but it can't be used effectively in expressions, is horribly dangerous and generally horrible, and requires much keyword pollution.

We really do need __forceinline. Walter did agreed on one occasion. He said
something like "I've been thinking on it, and I think you might be right",
which is almost a mental commitment... so there's hope! :P
Sadly it was in a hotel parking lot, and not committed to the eternal
historic record (ie, the forum).
The alt-compilers have an attribute... if only we could alias attributes
(or groups of attributes). Another thing we need... :/

On Friday, 13 December 2013 at 17:01:21 UTC, Manu wrote:
> On 14 December 2013 02:50, Dicebot <public@dicebot.lv> wrote:
>
>> On Friday, 13 December 2013 at 16:28:33 UTC, Manu wrote:
>>
>>> I could still REALLY do with __forceinline though. D doesn't have an
>>> effective macro.
>>> Obviously, if by 'language X' you mean 'any non-compiled language with
>>> pointers', then I totally agree! People who make claims like you say,
>>> don't
>>> generally know what they're talking about, or what C is actually used for.
>>>
>>
>> I believe (and have posted it over 100 times in NG already :P) D
>> absolutely needs either way to force internal linkage or good LTO symbol
>> elimination. Without preprocessor there is not much you can do to eliminate
>> code duplication other than templates / CTFE - and it bloats resulting
>> executables damn lot, something that was very controllable in C.
>>
>
> templates aren't guaranteed to inline, and they produce horrible symbol
> bloat. ctfe isn't inlining, it's pre-computation/runtime elimination.
> mixin is the closest, but it can't be used effectively in expressions, is
> horribly dangerous and generally horrible, and requires much keyword
> pollution.

What I mean is that right now symbols always make their way to object file, whenever they are inlined or not. So bloat is completely unaffected by inlining here. And spec currently kind of prevents removing those. One option could have been to fix `export` like http://wiki.dlang.org/DIP45 proposes and get some kind of LTO. Simpler solution I personally would favor is to make template symbols internally linked by default and available only if explicitly aliased. But anything is really better than the current state.

On 14 December 2013 03:07, Dicebot <public@dicebot.lv> wrote:

> On Friday, 13 December 2013 at 17:01:21 UTC, Manu wrote:
>
>> On 14 December 2013 02:50, Dicebot <public@dicebot.lv> wrote:
>>
>>  On Friday, 13 December 2013 at 16:28:33 UTC, Manu wrote:
>>>
>>>  I could still REALLY do with __forceinline though. D doesn't have an
>>>> effective macro.
>>>> Obviously, if by 'language X' you mean 'any non-compiled language with
>>>> pointers', then I totally agree! People who make claims like you say,
>>>> don't
>>>> generally know what they're talking about, or what C is actually used
>>>> for.
>>>>
>>>>
>>> I believe (and have posted it over 100 times in NG already :P) D
>>> absolutely needs either way to force internal linkage or good LTO symbol
>>> elimination. Without preprocessor there is not much you can do to
>>> eliminate
>>> code duplication other than templates / CTFE - and it bloats resulting
>>> executables damn lot, something that was very controllable in C.
>>>
>>>
>> templates aren't guaranteed to inline, and they produce horrible symbol bloat. ctfe isn't inlining, it's pre-computation/runtime elimination. mixin is the closest, but it can't be used effectively in expressions, is horribly dangerous and generally horrible, and requires much keyword pollution.
>>
>
> What I mean is that right now symbols always make their way to object
> file, whenever they are inlined or not. So bloat is completely unaffected
> by inlining here. And spec currently kind of prevents removing those. One
> option could have been to fix `export` like http://wiki.dlang.org/DIP45proposes and get some kind of LTO. Simpler solution I personally would
> favor is to make template symbols internally linked by default and
> available only if explicitly aliased. But anything is really better than
> the current state.
>

Ah I see what you mean. Yes, you are correct.
Any real embedded dev in the future will need to have these issues
addressed as a matter of practicality.

On Fri, Dec 13, 2013 at 03:30:21PM +0100, Paulo Pinto wrote: [...]
> Maybe the best way to fix this issue is to follow what other
> language standards do (C++, Ada) and only define that inline
> assembly is possible and how the entry point, e.g. asm () looks
> like.
> 
> The real inline assembly syntax is then left implementation specific.

But isn't this what Walter was arguing against? He wanted to standardize inline assembly syntax for x86 because leaving it up to implementation resulted in the current mess of Intel syntax vs. GNU syntax (which can be extremely confusing if you're not well-versed in both syntaxes, since the order of operands are swapped and there are some subtle notational differences).


T

-- 
Computers shouldn't beep through the keyhole.