Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose only model description through execution #603

Merged
merged 4 commits into from
Jul 1, 2020

Conversation

eidekrist
Copy link
Member

This closes #602.

execution.get_simulator() has been replaced with execution.get_model_description(). If this gets approved, I will create separate PR's for libcosimc and cosim4j updating the usage of the replaced method.

I also did a change in observer.hpp, returning const references for the name() and model_description() methods. Please let me know if that was a bad call!

@eidekrist eidekrist added the enhancement New feature or request label Jun 23, 2020
@eidekrist eidekrist self-assigned this Jun 23, 2020
@markaren
Copy link
Contributor

markaren commented Jun 23, 2020

Change looks fine to me. I double checked cosim4j, and the get_simulator call is only used as you say to get the model_description.

I will create separate PR's for libcosimc and cosim4j updating the usage of the replaced method.

No need (for cosim4j). I can do it, as the natives should be built and checked in for both windows and linux.

@@ -26,10 +26,10 @@ class observable
{
public:
/// Returns the entity's name.
virtual std::string name() const = 0;
virtual const std::string& name() const = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is something I've thought a lot about: whether, as a rule of thumb, virtual functions should return objects by value or reference.

If a function is non-virtual, so it is implemented in the class itself and not overridden by subclasses, it is common to return a reference if you can. After all, as the class implementer, you know whether there is some internal variable that you can return a reference to.

But if a function is virtual, and especially in an interface which is intended to be implemented by others, then it's not so clear anymore. Basically, you're forcing whoever implements your interface to have an internal buffer for the returned object in their class. This may be a hassle, especially if they wanted to generate the value on the fly or return a constant.

Was there a particular reason to switch to return-by-reference here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My sole motivation for doing this was to avoid unnecessary copies of said objects; I did not think about that it forces implementers to do things a certain way. I have no problem reverting this!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think any of these functions will be called in performance-critical situations, so I don't see the extra copies becoming a problem.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And with C++11 if the value is generated in the function it might not even be a copy (https://en.cppreference.com/w/cpp/language/copy_elision)

Copy link
Contributor

@hplatou hplatou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Member

@kyllingstad kyllingstad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@eidekrist eidekrist merged commit af8570d into master Jul 1, 2020
@eidekrist eidekrist deleted the feature/602-expose-model-description branch July 1, 2020 08:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Expose model_description through execution
4 participants