0

I'm having some issues understanding the following behavior of GTest. When I have some members inside the fixture class that are initialized in the initializer list and I use them to initialize another member from the fixture, the following behavior happens.

In the first version the Copy Constructor from B is called and then the Parametrized Constructor of B. In the second version first the Parametrized constructor and then the Copy Constructor is called. My understanding is that the behavior should me similar in the first version and in the second version, however the right behavior is seen only in the second version. If I want to add some members like in the first version how should I do?

class ConfigEndpoint
{
    ConfigEndpoint (const B&  f_bar0 = B(),
                    const B&  f_bar1 = B(),
                    const B&  f_bar2 = B() )
};

ConfigEndpoint::ConfigEndpoint (const B&  f_bar0 = B(),
                                const B&  f_bar1 = B(),
                                const B&  f_bar2 = B() ) 
                            : array {f_bar0, f_bar1, f_bar2}  {}

Class B has two types of constructors:
// Default one:             
B::B()
    : m_space(MEMORY),
      m_type(32BIT),
      m_isConfigured(false)
{}
// Parametrized one:
B::B(int f_barSpace,
     int  f_barType)
    : m_space(f_barSpace),
      m_type(f_barType),
      m_isConfigured(true)
{}

**//TestFixture  -> version 1.**
class CConfigTest : public ::testing::TestWithParam<std::tuple<driverStartAddress, bool>>
{
  public:
    CConfigTest() : 
          bar0(MEMORY, 32BIT),
          bar1(MEMORY, 32BIT),
          bar2(MEMORY, 32BIT),
          configEndpoint(bar0,
                         bar1,
                         bar2)
    { }

    ConfigEndpoint configEndpoint;
    const B bar0;
    const B bar1;
    const B bar2;
};


**//TestFixture  -> version 2.**
class CConfigTest : public ::testing::TestWithParam<std::tuple<driverStartAddress, bool>>
{
  public:
    CConfigTest()
    :
          configEndpoint( B(MEMORY, 32BIT),
                          B(MEMORY, 32BIT),
                          B(MEMORY, 32BIT) )
    { }

    ConfigEndpoint configEndpoint;
};
AndyE
  • 77
  • 5

1 Answers1

0

You haven't described what actually happens in both versions (i.e. what you expect vs. what you observe). At the first glance: you create bar[1|2|3] but you pass mock_bar[1|2|3] in the version no. 1.

On a side note: you have a bug in the class A: if you call it without parameters, you bind the temporary object to the const &A. This is fine on the stack, but not for the classes' members. And what is worse, you don't use it in tests (because you pass proper references there), so it will only fail in production or some integration test. See:

Does a const reference class member prolong the life of a temporary?

Quarra
  • 2,527
  • 1
  • 19
  • 27
  • Sorry, I didn't write the pseudo code well, It's corrected now. In the first version I expect that configEndpoint to be initialized with bar0, bar1 and bar2. This does not happens because the default constructor for class B is called. In the second version configEndpoint is as expected initialized with the wanted values. What goes on here? – AndyE Jan 04 '21 at 19:59
  • Still, your example is not clear: what's the relation between class A and ConfigEndpoint? I don't see ConfigEndpoint definition. Also, without class A ctor definition (not only declaration) it's hard to say what's going on. Last but not least: there is a bug in the code, you cannot even try to bind temporary objects (like const B& f_bar0 = B() etc) to references in the initialization list. – Quarra Jan 05 '21 at 07:32
  • Thank you for the quick response and sorry for the confusion provoked. I think that now it's better. Regarding the binding of temporary objects to references in the initializer lists, do you have some links so I can better delve into it? Thanks once again. – AndyE Jan 05 '21 at 13:52
  • Please see the link in my answer, question is "Does a const reference class member prolong the life of a temporary?" – Quarra Jan 06 '21 at 10:32