Breaking changes in Visual C++ 2015
deadalnix via Digitalmars-d
digitalmars-d at puremagic.com
Sat May 9 20:56:09 PDT 2015
On Friday, 8 May 2015 at 22:57:54 UTC, Walter Bright wrote:
> It works perfectly fine and obviates the need to create a
> separate test harness.
>
As long as you are doing trivial toy programs, that is perfect.
> 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.
>
As mentioned elsewhere one want to compared itself to the guy in
town, not the drunk hobbo.
>
>> 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.
>
My bad. It is still clowny that I have to format my code in a
particular way to get that result. Not formatting my code that
way, I never noticed that the result even existed in the first
place.
But still, that is clowny and confirms the general impression
that these tools are bad.
See, there are iPhone and nokia phones. They do the same thing:
they load web pages, they do phone calls and sms, they runs
various apps and so on. An iPhone more than twice the price of a
nokia lumia. Still, people are willing to wait in line to buy the
new iPhone while nokia is going bankrupt. Why is that ? Because
in one case, the damn thing is thought through to the most
insignificant details once the other works and that's good.
You can do this if you format you code in some bizarre way is a
bad excuse and nothing else.
>> 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.
>
Color are beside the point. That is a good report. That is still
miles behind what you can have in java for instance.
I can't have the coverage per test case, to know what test is
testing what for instance (which is arguably mostly due to how
tests are ran in the first place). It does give me information
depending on the formatting of my code. These may not seems like
important things, but that is what makes the difference.
>>> 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
>
>
1/ I usually use callgrind based tools rather than gcov, and then
I can explore the result with something like KCacheGrind which
can show me the informations in all kind of forms.
http://edinburghhacklab.com/wp-content/uploads/2012/04/kcachegrind.png
Not only this is more convenient to explore the data, but I get
the same tool to work with PHP, C++ or whatever else.
On the other hand, I have something like:
$ cat trace.log
------------------
1 main
_Dmain 1 45 45
------------------
main 0 0 0
1 _Dmain
======== Timer Is 3579545 Ticks/Sec, Times are in Microsecs
========
Num Tree Func Per
Calls Time Time Call
1 12 12 12 _Dmain
1 0 0 0 main
For reference, the format used is named callgrind and many tools
can manipulate it: http://valgrind.org/docs/manual/cl-format.html
2/ Tested on SDC's test runner, it makes the test runner
segfault. It is not even a complicated program. That is once
against the nokia vs apple thing.
>>> 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.
>
I can use both tcmalloc and jemalloc on WAY MORE plateforms that
D supports.
>> 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.
I know it is doable. Java does it. But D does not. I'm discussing
what we have right now, not what we could hypothetically have if
you, me, and others had infinite time.
As D does not, it can't be pointed as a strong asset of D.
More information about the Digitalmars-d
mailing list