3

I have a C++ class, Foo. When I run gcov on my unit tests, it reports good coverage data for Foo's methods, but on the class declaration itself is reports nothing:

  14           0 : class DllExport Foo: public Bar {
  15             : protected:
  16             :     float field1;
  17             :     long field2;
  18             : public:
  19          21 :     virtual bool operator==(const Foo& other) const override { return field1 == other.field1 && field2 == other.field2; };

I note that this happens for a few of my classes.

I'm using lcov to generate my reports:

lcov --base-directory . --directory . -c -o foo.info
lcov --remove foo.info "/usr*" -o foo.info
rm -rf ../cov_report
genhtml -o ../cov_report -t "Foo Test Coverage" --num-spaces 4 foo.info

I know the class is being used because I can see the coverage values for the class' methods (see the operator overload above).

How can I fix this so correct coverage data are reported?

Nathan
  • 1,218
  • 3
  • 19
  • 35
  • Make the data members private - protected data is A Bad Thing. –  May 23 '17 at 17:11
  • 1
    @NeilButterworth Yes, that is generally a bad idea, but so is naming a class `Foo` or `Bar`, or naming the data members `field1` or `field2`. There might be reasons to do it in this instance, and I highly doubt it has anything to do with the coverage statistics. – Daniel H May 23 '17 at 17:15
  • @Daniel I made a comment, not an answer. And it _could_ have something to do with the coverage, as just about anything can access those variables, making any test on them possibly invalid. –  May 23 '17 at 17:17
  • 1
    @NeilButterworth Thanks for the advice. As Daniel H noted, this example has been heavily sanitized for SO. I really just included those lines for context. It shouldn't affect the coverage results (in fact, I have another class that's not part of an inheritance hierarchy and which has no protected fields or methods at all that has the same problem). – Nathan May 23 '17 at 17:20
  • 1
    A class declaration doesn't have any coverage because it doesn't generate any executable code. What do you expect exactly? – n. m. could be an AI May 23 '17 at 17:26
  • 2
    @n.m. I expect it to not report 0 and not lower my coverage results – Nathan May 23 '17 at 17:28
  • Please show your exact compilation and gcov commands. – n. m. could be an AI May 23 '17 at 18:29
  • @Nathan You mean like the other quoted lines not having any numbers at all because they also don’t generate code, or do you think there is a non-zero number which makes sense? – Daniel H May 23 '17 at 18:30
  • I'm sorry what I have said initially is somewhat misleading. It looks like g++ generates lots of functions that may or may not end up being executed. – n. m. could be an AI May 23 '17 at 18:41
  • @DanielH Correct, I would expect that to be 0 as well. Let me update the example with a line that's not zero too – Nathan May 23 '17 at 19:05
  • 2
    I have exactly the same problem. So far I have found out that GCC version plays a role in this, i.e. on a system with GCC 7 (or older) everything is as it should be. But on a system with GCC 8 I get precisely the same results you got. Did you manage to find the solution for this? – AmokHuginnsson Sep 20 '18 at 17:18
  • It's not clear this is happening here, because we don't have a full example, but I learned today that if I don't exercise the implicitly-created members (destructor, copy ctor, etc), this can happen. – burlyearly May 08 '19 at 15:46

0 Answers0