[Chris]

Up

0

Down

::

Just wanted to continue the conversation and ask about the most common use cases for static data members that you have observed. And for that matter, static member functions, as well.

I’ve seen static member functions uses within a class hierarchy when a derived class provides functionality that goes beyond the interface provided by the base class, as well as static factory methods too. But beyond the Singleton pattern, static data members just isn’t something I have come across.

[Chris]

Up

0

Down

::

Yeah definitely an open-ended question intended for conversation, and tough to reply via text and comments.

I did find this in the core guidelines though, which actually fits perfectly for the code I have observed: link

Something we can chat a bit more about this Friday.

[Chris]

Up

0

Down

::

That’s really great context Rainer, thanks!

[Chris]

Up

0

Down

::

Also wanted to pass along a couple of links work reading through:

https://stackoverflow.com/questions/51705967/advantages-of-pass-by-value-and-stdmove-over-pass-by-reference

https://clang.llvm.org/extra/clang-tidy/checks/modernize/pass-by-value.html#:~:text=Pass%2Dby%2Dvalue%20in%20constructors,necessary%20to%20add%20this%20include.

[Chris]

Up

0

Down

::

Just wanted to continue the conversation about the Factory Method pattern, and the tradeoffs of using a free function vs. static class member function, plus unique ownership and shared ownership.

Here is an example using a free function (link):

Another example using a static member function returning a std::unique_ptr (link):

And a third example using a static member function returning a std::shared_ptr (link):

Mostly interested in chatting about the applicability of the shared version, and what that use case might be like. I suppose we would need some sort of clone() method to make a proper copy, but would it make sense to also have a make_clone() factory method as well?

Mostly just want to explore this idea a bit, since I don’t have much experience using factories with shared ownership.

[Chris]

Up

0

Down

::

A bit of a late entry to the forum this morning, but perhaps it could be the beginning of a conversation we have over the next week and can wrap up the following Friday.

I was reading through the C++ Core Guidelines about passing smart pointers, and in general for the use case I have below:

// Client code (#1)
void client(std::unique_ptr<AbstractClass> const& obj)
{
  obj->template_method();
}

// Client code (#2)
void client2(AbstractClass& obj)
{
  obj.template_method();
}

// Client code (#3)
void client3(AbstractClass const& obj)
{
  obj.template_method();
}

int main()
{
  std::unique_ptr<AbstractClass> object = std::make_unique<ConcreteClass>();

  // std::unique_ptr<AbstractClass> const& obj
  client(object);

  // AbstractClass& obj
  client2(*object);

  // AbstractClass const& obj
  client3(*object); // error!
}

Here is a link to the full script: https://godbolt.org/z/bz3hYseY1

For this use case, the client will not modify the object own by the smart pointer; it will only invoke a member function.

The C++ Core Guidelines R.33, R.34, R.35, and R.36 state to warn if a function takes a smart pointer by reference and does not either assign to it or call reset() on it at least once in the code path, and that taking a T* or T& is suggested instead.

Just curious to see what others have adopted as their preferred style. But nonetheless was a bit surprised by the language used within the Core Guidelines.

 

 

 

[Chris]

Up

0

Down

::

Hey Everyone,

Wanted to share a recent exchange that Rainer and I had with Klaus Iglberger about Type Erasure (Klaus’s replies in bold italics):

 

In considering your reply, and then re-working my original example, I removed the protected copy and move operations from my Concept class. This follows C.20 re: not defining any default operations, and keeping my Concept and Model class definitions super simple. With what I have remaining, does that appear to be correct? (link)

I’ve added several comments to your example:

https://godbolt.org/z/hzbYjGxv7

Overall, the implementation is already very good. The only major issue I see are the move operations in the ‘Wrapper’ class. As for any value type, you would have to think about your definition of “valid state”.

The two biggest questions I have are:
1. Do I need the virtual destructor still remaining in the Concept class?

Yes, please. Without this you would not properly destroy the derived class objects (i.e. the ‘Model’ instances) and produce resource leaks.

2. Have I provided the correct copy constructor and copy assignment operation definitions in the Model class?

Yes. The ‘Model’ class is correctly based on the “Rule of 0” (C.20). The ‘Concept’ class is correctly based on C.21 (see the example for the exception for base classes).

I hope this helps,

Best regards,

Klaus!

[Chris]

Up

1

Down

::

Hey Rainer, would you be able to ask Klaus if he can provide an example of what he is describing? In reading his reply, I believe him to be saying that, neither Model nor Concept need to define special member functions. And the class Wrapper, in order to copy the pointer to Concept, would itself need to implement a clone() member function.

It would also be interesting to hear his thoughts on a few other topics revolving around Type Erasure, such as:

• Could the class Wrapper own any data members besides the pointer to Concept? Or should the pointer to Concept be the only member?
• If a Type Erasure construct does need more data members, should they be encapsulated within the parameterized class T?
• Are there use cases where a Type Erased class (eg, Wrapper) needs to by copied? Or do they tend to follow the rules for polymorphic classes where they should only be cloned?

[Chris]

Up

0

Down

::

Great, that link works for me in CE. Thank you once again!

[Chris]

Up

0

Down

::

Glad to see I’m not the only one as well

[Chris]

Up

0

Down

::

That sounds great Rainer, looking forward to it!

[Author]

Posts