Breaking changes in Visual C++ 2015

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Sat May 9 12:30:54 PDT 2015


On 9 May 2015 at 00:58, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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.
>

For the sake of argument (and genuine interest).  I'd like to see a
comparison of DMD coverage versus GDC coverage reporting.  ie: Does
DMD pick up anything GDC doesn't?  Are there areas where GDC is more
clearer?

For the latter question though, because gcov has lots of external
tooling, the latter may be an unfair bias towards gcov.

For example, using site linked at [1], I can build and run the
druntime/phobos unittests using --coverage in my DFLAGS and get
instant results with:

  # Capture all information
  $ lcov --capture --directory libphobos --output-file libphobos-cov.info

  # Generate instant web pages
  $ genhtml libphobos-cov.info --output-directory coverage

Then browse it once uploaded.

  http://coverage.dgnu.org

Regards
Iain.

[1]: http://ltp.sourceforge.net/coverage/lcov.php


More information about the Digitalmars-d mailing list