Breaking changes in Visual C++ 2015

[Chris via Digitalmars-d]

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 
> languages.
>
>
>> 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 
you.