[diana]

Up

0

Down

::

Why is int the return type of Generator::next if the return type of std::coroutine_handle<Promise>::done is bool?

[diana]

Up

0

Down

::

Thanks Rainer. I see how this prevents main from trying to get a next value after the execution of the coroutine has reached the end of the body of the coroutine. In this example modified from the initial coroutine: infiniteDataStreamComments.cpp modifed

• When I have two  iterations in the coroutine and four iterations in main, I get an error
• When I have three iterations in the coroutine and four iterations in main, I get the last value repeated and no error

Is it undefined behavior to ask for a next value after we have reached the end of the body of the coroutine?

[diana]

Up

0

Down

::

Actually, maybe it is common for a class parametrized by T to:

1. have member functions requiring different concepts on T, and/or
2. Have member functions requiring concepts that are more strict than the concept that is required at the class level. From CppReference:

The requirements that are imposed on the elements depend on the actual operations performed on the container. Generally, it is required that element type meets the requirements of Erasable, but many member functions impose stricter requirements. This container (but not its members) can be instantiated with an incomplete element type if the allocator satisfies the allocator completeness requirements.

[diana]

Up

1

Down

::

Welcome Paul! Two pairs of twins is unique!

[diana]

Up

0

Down

::

Isn’t the same happening in the solution to the exercise with smart pointers where we are returning std::unique_ptr<Interface> in the derived classes, hence not using the covariant return type?

#include <iostream>
#include <memory>
#include <string>

class Interface {
 public:
    virtual std::unique_ptr<Interface> clone() const = 0;
    virtual std::string getName() const = 0;
    virtual ~Interface() = default;
};

class Implementation1 : public Interface {
 public:
    std::unique_ptr<Interface> clone() const override {
        return std::unique_ptr<Interface>( new Implementation1(*this));
    }
    virtual std::string getName() const override {
        return "Implementation1::getName";
    }
};

class Implementation2 : public Interface {
 public:
    std::unique_ptr<Interface> clone() const override {
        return std::unique_ptr<Interface>( new Implementation2(*this));
    }
    virtual std::string getName() const override {
        return "Implementation2::getName";
    }
};

int main() {
    Implementation1 my_impl1;
    std::unique_ptr<Interface> my_clone = my_impl.clone();
    //error:
    //std::unique_ptr<Implementation1> my_clone = my_impl.clone();
    

}

[diana]

Up

0

Down

::

I see now that this is discussed in the Modernes post about Null Object:

	Runtime	Compile time
Advantages	– Allows it to configure the locking strategy during run time – Is easier to understand for developers who have an object-oriented background	– Has no abstraction penalty – Has a flat hierarchy
Disadvantages	– Needs an additional pointer or reference indirection – It may have a deep derivation hierarchy	– It may generate very wordy error messages

So a (perhaps too) simplistic summary: compile time for performance and runtime for readability.

[diana]

Up

0

Down

::

In the real example of std::vector<T,Allocator>::push_back which has the strong exception guarantee: Wouldn’t you have to catch the exception that the allocation may throw by putting the push_back in a try except block?

[diana]

Up

0

Down

::

Update: I just watched the video following the example about the non-virtual interface idiom :) So I see that indeed processData doesn’t have to be virtual

 

[diana]

Up

0

Down

::

In Imran’s example the references are non-const since the functions modify the objects they are passed. What is then the modern approach for func1 and func2?

I don’t understand what passing ownership means.

[diana]

Up

0

Down

::

I prefer passing by reference because it expresses that the expectation is that the parameter is non-null.

With shared_ptr there is also the overhead of the control block which may or may not be a concern depending on the context.

[diana]

Up

1

Down

::

Thanks! I started watching the AM session in the meantime. The discussion was very interesting.

[diana]

Up

0

Down

::

In both examples we are using reference semantics right since we are using Shape* and Shape&?  Or do raw pointers model something else?

How would value semantics look like in decorator.cpp? Since we need the indirection via a pointer or a reference to get the polymorphic behavior for instance in the call shape.GetName() I don’t see how we can avoid references when using decorators.

[diana]

Up

0

Down

::

Thanks Rainer! I appreciate now the differences in the three approaches (ignoring the use of naked new vs. smart pointers) and referring to the diagram from refactoring guru

1. factoryMethodClassic.cpp  : the creator class hierarchy is replaced by a single function
2. factoryMethodUniquePtr.cpp : the creator class hierarchy is blended in with the product hierarchy (i.e. the create methods go directly in the product classes)
3. The example in the refactoring Guru: the creator is its own class with concrete classes corresponding to the concrete products

I don’t quite get this comment in the refactoring guru diagram:

“Note, despite its name, product creation is not the primary responsibility of the creator. Usually, the creator class already has some core business logic related to products.”

Is this referring for instance to the render() method in UI example?

[diana]

Up

0

Down

::

Thanks Rainer! I see also the other instance you describe in your reply to factory-method-as-static-member-of-base-class as another example of when one would use shared_ptr.

[diana]

Up

0

Down

::

Built-in types:

I think there is no performance difference but the first one has the advantage of disallowing narrowing conversions.

For std::string:
std::string s {“Hello”}; //direct initialization
std::string s = “Hello” //copy initialization
I think there is no difference:
Direct initialization: the constructor taking a const char* is called
Copy initialization: the third bullet point here applies and so the string literal is converted to a prvalue expression of type std::string and then used to direct initialize the object but this last step is optimized away (second bullet point here) and the result of the conversion is constructed directly in the memory allocated for the target object.

In general, I don’t know. I realize there are lots of details to keep in mind around initialization whenever I read cppreference pages related to initialization :P

[Author]

Posts