Breaking changes in Visual C++ 2015

[Walter Bright via Digitalmars-d]

On 5/8/2015 2:51 PM, deadalnix wrote:
>> 1. unit testing
> The way D runs tests before running the app does not make any sense.

It works perfectly fine and obviates the need to create a separate test harness.


> The way you can't run them for a module without a main makes no sense.

     dmd foo -unittest -main


> The way you end runnign all kind of test with the ones you are interested in makes no sense.

    dmd std/path -unittest -main

runs just the unit tests in std/path. You can run tests in some modules, but not 
others, with:

    dmd -c a b c -unittest
    dmd d e f a.o
    ./d


>> 2. documentation generation
>
> The fact this is backed into the language the way it is mostly show a lack of
> separation of concerns.

It means it is always there and always the correct version.


> That is a side effect of the fact the frontend is completely monolithic.

Has nothing to do with how usable a tool is.


> You don't need to bake that into the language when the compiler can feed symbol
> information to 3rd party tools.

D worked with 3rd party doc tools before Ddoc. The result was that maybe 1 or 2 
people ever used such tools. You weren't using D then - the Phobos documentation 
was all of:

1. nonexistent
2. wrong
3. had no correlation with the APIs on the functions at all

Ddoc fixed all that. It's fine to gripe about this or that, but the results are 
undeniably a seismic improvement for D.


>> 3. coverage analysis
>
> I'm not sure how Go and Rust stand on that one, but all mainstream languages
> have descent code coverage, with the added bonus that this is very well
> integrated with the rest of the tooling (tolling which is non existent in D). I
> would not put this has a string point of D. Not bad either, but definitively
> what you'd expect from any serious language.

Try using gcov without going back to consult the manuals on it. Even if you have 
it installed. Coverage analyzers in other languages that I checked all required 
finding and installing some extra package, then trying to figure out how to hook 
it in.


> Last but not least, things like:
> if (foo && bar) ...;
>
> Contains 2 branches. The output we have to not provide data about this, which
> makes the coverage infos lacking in some regard.

Check before assuming -cov does it wrong. You'll find it counts the branches 
separately. It does sum them for the line count, but writing it as:

    if (foo &&
        bar)
         ....

you'll get two counts. What I am disappointed in is the repeated default 
assumption, without bothering to check, that D's tools are guilty until proven 
innocent.


> In java for instance, I could run tests (and not the whole program with test at
> startup) and get all the coverage infos directly in my editor with colors and
> stuff, include things like short circuit for boolean operators, which we don't
> have. We are miles (kilometers damn it !) away from this level of support.

Here's a slice of a D coverage report:


        |static if (allSatisfy!(hasMobileElements, R))
        |{
        |    RvalueElementType moveAt(size_t index)
        |    {
       6|        foreach (i, Range; R)
        |        {
        |            static if (isInfinite!(Range))
        |            {
0000000|                return .moveAt(source[i], index);
        |            }
        |            else
        |            {
       3|                immutable length = source[i].length;
       5|                if (index < length) return .moveAt(source[i], index);
       1|                    index -= length;
        |            }
        |        }
0000000|        assert(false);
        |    }
        |}
std\range\package.d is 91% covered

It's not in color, I concede that. Saying this report is "miles behind" is 
ludicrous, besides the incorrect statement that short circuits are not supported.


>> 4. profiler
> Same things, this is a standard tool nowaday for any language worth considering.
> In fact, even if we had no specific support in D for it, C/C++ tooling could
> probably do it for us to some extent.

Yah, I know about gprof. Try it (with a C or C++ program), without spending time 
with the manuals. Here's the manual for D:

    dmd -profile foo


>> 5. and as of last week, a memory usage profiler
> Good memory allocator like tcmalloc and/or jemalloc have detailed output.

They don't come with C or C++. Pray you can find one that works with your 
version of the compiler on your platform, and there are no conflicts with 3rd 
party libraries. No such worries with D compilers.


> And if we go back to java, you can even observe things in a graphic way in real time
> concurrently to the application running ! Once again, we are not even remotely
> close to anything like this.

It's designed so that you can write one without changing anything in the 
compiler. All you gotta do is override the default one in druntime, which merely 
aggregates the statistics and prints a report. That report is 90% of what anyone 
needs. If you want to change the report generator to produce color html output, 
probably 30 min work, feel free.