Opened 6 years ago
Last modified 3 months ago
#133 new enhancement
Better signature for copy constructors.
Reported by: | Thierry Delisle | Owned by: | |
---|---|---|---|
Priority: | major | Component: | cfa-cc |
Version: | 1.0 | Keywords: | |
Cc: |
Description (last modified by )
Copy constructors now have a weird C copy as a parameter. This is due to historical reasons and should use const reference instead.
I.e. this:
void ?{}(char &, char); char ?=?(char &, char);
Instead of
void ?{}(char &, char const &); char const & ?=?(char &, char const &);
Change History (2)
comment:1 Changed 3 months ago by
Description: | modified (diff) |
---|
comment:2 Changed 3 months ago by
Description: | modified (diff) |
---|
Note: See
TracTickets for help on using
tickets.
There was a typo in the original copy assignment signature.
After a discussion about wanting the return value of an assignment to be value like, it was agreed that we should change it to be a constant reference. You could still take the address (unless a check is added to prevent it) but it is logically closer to a value.
There was some talk of allowing different signatures be used for different types (for instance, C primitive types could accept and return values) but this interferes with polymorphism and properly lowering from Cforall to C in the last stages of the compiler should take care of performance issues in the remaining cases.
If we allowed operators to not be 1-to-1 with the underlying functions (which is a big change), then we could translate "a = b" into "?=?(a, b), a", that is to say, have the operator return void and provide the return value by comma expression. This forces the behaviour to be consistent, means the user does not have to worry about it and may give more control to the optimizer.