Live data from Hacker News

How does D improve on C++17?

p0nce.github.io

21–30 of 77 posts

Re: How does D improve on C++17?

#21

> D has no need for a preprocessor How does this work, specifically conditional compilation? I have lots of code like this: #if __APPLE__ /* do things the OS X way */ #else /* do things the Linux way */ #endif Where the OS X way calls functions that do not exist on Linux, and vice-versa. How does D handle this?

In many cases you don't need preprocessor for this even in C++. For example you can detect the availability of system functions using function overloading as described in http://zverovich.net/2015/03/13/reliable-detection-of-strerr...

Re: How does D improve on C++17?

#22

> D has no need for a preprocessor How does this work, specifically conditional compilation? I have lots of code like this: #if __APPLE__ /* do things the OS X way */ #else /* do things the Linux way */ #endif Where the OS X way calls functions that do not exist on Linux, and vice-versa. How does D handle this?

Maybe someone with more D experience can chime in, but D has conditional compilation (ie "static if")

http://dlang.org/version.html

Re: How does D improve on C++17?

#24

> D has no need for a preprocessor How does this work, specifically conditional compilation? I have lots of code like this: #if __APPLE__ /* do things the OS X way */ #else /* do things the Linux way */ #endif Where the OS X way calls functions that do not exist on Linux, and vice-versa. How does D handle this?

Check out https://github.com/D-Programming-Language/phobos/blob/master... at line 33 and on. You'll see: version (Windows) { ... } etc. For the specification on how this works:

http://dlang.org/version.html

The salient point is that conditional compilation in D is not text based, it is AST based. Furthermore, for 'static if', the conditional expression has access to the full symbol table and power of the D language - it is not a separate preprocessor language with its own rules and separate symbol table.

Re: How does D improve on C++17?

#25

> D has no need for a preprocessor How does this work, specifically conditional compilation? I have lots of code like this: #if __APPLE__ /* do things the OS X way */ #else /* do things the Linux way */ #endif Where the OS X way calls functions that do not exist on Linux, and vice-versa. How does D handle this?

Lack of a preprocessor does not imply lack of conditional compilation:

http://dlang.org/version.html

The constructs are simply built into the language.

This has considerable benefits: you can use e.g. `static if` to enable/disable code based on conditions which refer to constants declared in the program (there is no longer a separate namespace for preprocessor defines and program constants), and with CTFE, you can use any expression that can be evaluated during compilation.

Re: How does D improve on C++17?

#26

> D has no need for a preprocessor How does this work, specifically conditional compilation? I have lots of code like this: #if __APPLE__ /* do things the OS X way */ #else /* do things the Linux way */ #endif Where the OS X way calls functions that do not exist on Linux, and vice-versa. How does D handle this?

Check out https://github.com/D-Programming-Language/phobos/blob/master... at line 33 and on. You'll see: version (Windows) { ... } etc. For the specification on how this works: http://dlang.org/version.html The salient point is that conditional compilation in D is not text based, it is AST based. Furthermore, for 'static if', the conditional expression has access to the full symbol table and power of the D language -…

Thank you for the reply. That's very elegant!

Re: How does D improve on C++17?

#27
D looks great, but I feel like depending on a GC is kind of a deal-breaker. If that is accurate, then D fills the same niches as Google's Go rather than C++'s. Rust looks more like a proper replacement for C++.

Re: How does D improve on C++17?

#28

I'm curious how many people out there on HN actully use D and what for? I don't typically see D based projects here on HN so it would be interesting to find out about any use cases where D was found a perfect fit.

95% of the code I work on is D.

D fits lots of purposes (more than C++), but I'm only going to talk about scripting.

The minimalistic approach for the C++ standard library makes C++ inappropriate to replace, for example, Bash scripts. In C++, you can't do any operation on the file system (erase a directory, get file size, list files, create pipes, ..) in a portable way. You can't create processes in a portable way.

The D standard library (aka Phobos) doesn't suffer these limitations. Which means you can write very high-level code using only a few (readable) lines. By adding a shebang "#!/usr/bin/env rdmd" at the beginning of your D programs, you can execute them without prior explicit compilation, like: ./myProgram.d

I've been porting all my Bash scripts to D. The code runs incredibly faster, and now I can have structs again!

Re: How does D improve on C++17?

#29

Earlier quoted context omitted.

Check out https://github.com/D-Programming-Language/phobos/blob/master... at line 33 and on. You'll see: version (Windows) { ... } etc. For the specification on how this works: http://dlang.org/version.html The salient point is that conditional compilation in D is not text based, it is AST based. Furthermore, for 'static if', the conditional expression has access to the full symbol table and power of the D language -…

Thank you for the reply. That's very elegant!

[deleted]

Re: How does D improve on C++17?

#30
post #17

Earlier quoted context omitted.

I'm always on the look out for improvements to C++, and it's been a while since I looked at D... Hope you don't mind if I ask you a couple questions. Can you still turn off the GC? Lets say I don't like exceptions, and that I don't mind implementing library code on my own, would turning GC off impact anything else? How is the story for deploying executables to mac/win/lin? Is it as easy as C/C++? Also, do you know if…

> Can you still turn off the GC? Lets say I don't like exceptions, and that I don't mind implementing library code on my own, would turning GC off impact anything else? You can turn off the GC in the sense that memory allocation will always request more memory from the OS instead of occasionally starting a collect cycle. However, you can alternatively use manual memory management (malloc/free, allocators/RAII on top…

Well, a couple things about it make me nervous, but CTFE and a not horribly broken compilation model might make it worth trying out next weekend...
Post reply on HN