It is the year 2020: why should I use / learn D?

[H. S. Teoh]

On Wed, Nov 14, 2018 at 04:47:16PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, November 14, 2018 4:25:07 PM MST Walter Bright via 
> Digitalmars-d wrote:
[...]
> > 5. What size is an `int`?
> 
> While I agree with the point that you're trying to make, that
> particular type actually isn't really a problem on modern systems in
> my experience, since it's always 32 bits.
[...]
> It's long that shoots you in the foot, because that still varies from
> system to system, and as such, I've always considered long to be bad
> practice in any C++ code base I've worked on. [...] But even then,
> when you're dealing with something like printf, you're screwed,
> because it doesn't understand the types with fixed sizes. So, you're
> constantly fighting the language and libraries.

Haha yeah, using printf with variable-sized integral types like long is
a nightmare in C/C++.  Though in my current project, a hack solution has
been devised by making use of the otherwise-evil preprocessor:

	long l = ...;
	printf("Long value is: %"PRIlong"\n", l);

where PRIlong is a macro defined in a suitable global header file that
defines the correct format specifier for 'long'.  It's a workaround as
ugly as sin, but it does save you from the utter headache of trying to
figure out which of %d, %ld, %lld you need to use.  (Unfortunately, it
doesn't stop people from continuing to write %ld where they really
should be writing %"PRIlong"... programming by convention rears its head
again with all of its ugly consequences.)


> D's approach of fixing the size of most integer and floating point
> types is vastly superior, and the problems that we do have there are
> from the few places where we _didn't_ make them fixed, but since that
> mostly relates to the size of the memory space, I'm not sure that we
> really had much choice there.

Yeah, recently I've had size_t bite me in the rear: I had code
cross-compiled to 32bit Android/ARM and my size_t's were working nicely
with int parameters... then I wrote a test driver for testing non-OS
specific modules on the host PC, and suddenly I have a whole bunch of
compile errors because size_t no longer converts to int.


> The main outlier is real, though most of the controversy there seems
> to have do with arguments about the efficiency of the x87 stuff rather
> than having to do with differences across systems like you get with
> the integers.
[...]

Yeah, 'real' is a blemish in D's otherwise beautifully-designed basic
types.  (Just don't get me started on int promotion rules, and I'll
pretend everything else is beautiful too. :-D)

Confession: I used to love 'real'... but after researching more
thoroughly into its performance characteristics recently (esp. on recent
hardware), I've started to realize it wasn't quite what I had expected.


T

-- 
What's a "hot crossed bun"? An angry rabbit.