Breaking changes in Visual C++ 2015
Chris via Digitalmars-d
digitalmars-d at puremagic.com
Fri May 8 04:57:35 PDT 2015
On Friday, 8 May 2015 at 10:56:22 UTC, Walter Bright wrote:
> On 5/8/2015 2:52 AM, Jonathan M Davis wrote:
>> the fact that it's built-in makes it extremely easy to use and
>> embarrassing if you don't.
> That's the game changing part, and what's missing from other
>> After all, what other language has unit tests built in at all?
> Yup. I haven't done anything remotely resembling an exhaustive
> search, but Go and Ruby have testing as add-on packages. JUnit
> is an add-on the user must download and install. There's not a
> word in the C and C++ specs about unit testing. And so on.
> Unit testing, coverage analysis, documentation generation, and
> profiling are very deliberately built in to the core compiler
> and language. They are always there, always available, and
> always the right version.
> One can dismiss that as trivia, that any professional won't be
> stopped by having to find the right download, install, and
> integration procedure. But the reality is that having this all
> built-in has seismically changed how D code is written.
True. If it ain't easy to use, nobody will use it.
First I was a bit sceptical about the unittests, cos you have
tests for the finished product anyway ... But unittests are
a) a documentation of the code and
b) simple and easy to use in D
c) make you think about your code more carefully.
c) is very important. Designing a unittest often makes me realize
that there are shortcomings in my code, or make me think of
further possibilities. Having coverage, unittests and performance
tests built in makes you think more about your code in general.
Take a program that starts out as a command line tool like "open
file, parse, analyze". You start with something that just
"works", you need it fast, you need it now. But it doesn't harm
you to add a unittest (the same stuff you would more or less test
for anyway with `writeln(output)`. Your little tool becomes more
reliable and well-documented, and can later grow into something
bigger. I know, you should treat a simple command line tool as
something that might possibly grow anyway, but D makes it so much
easier. And let's be honest, we're all human, we're all lazy. If
we weren't lazy, we wouldn't bother with programming - after all
what else is programming than having a machine do something for
More information about the Digitalmars-d