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

Add support for C++ reference type for return values (but not arguments) #317

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Tuc-an
Copy link
Contributor

@Tuc-an Tuc-an commented Jul 20, 2020

No description provided.

@Tuc-an
Copy link
Contributor Author

Tuc-an commented Aug 19, 2020

@mvandervoord This adds functionality I can use to test some of my projects

@phonetagger
Copy link
Contributor

phonetagger commented Dec 9, 2020

Hi @Tuc-an, I see your CMock change for supporting C++ references in return values "(but not arguments)". Does this mean CMock does not yet support references at all (for arguments)? And if so, do you have any thoughts about how to make it support reference arguments as well as return values? I've done a small amount of work on CMock a long time ago to make it properly handle pointers-to-const, but I'm not at all an expert in Ruby.

@Tuc-an
Copy link
Contributor Author

Tuc-an commented Dec 9, 2020

@phonetagger that's correct: CMock does not support reference types. I have not investigated how to handle reference arguments yet, but plan to after (if?) this PR is accepted. I wanted to keep this PR as small as possible in the hope of it being reviewed and accepted faster, which is why I did not attempt it all at once.

@Tuc-an Tuc-an mentioned this pull request Jan 8, 2021
@mvandervoord
Copy link
Member

I'm actually thinking I want to open a support_cpp branch and merge this into that. I'd like to see how far down this road we can get before merging it to main. Once "in main" people are going to expect it to work with most situations. Anything we can do towards making sure that is true is going to help in the long run.

The goal would be to keep the branch in sync with main (taking any updates from it) but continuing to refine the cpp support a bit more. How does that sound to you? @Tuc-an ?

@Tuc-an
Copy link
Contributor Author

Tuc-an commented Jan 8, 2021

Sounds good to me 👍

@phonetagger
Copy link
Contributor

A separate support_cpp branch sounds fine to me, but I wouldn't be able to use it until it supports references in function parameters as well as return types. If it did that, I would definitely switch to that branch, as long as it happened in the next couple months. After that I'll be on a different project anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants