Adjust Operator::Run to take reference instead of pointer

[klecki]

Signed-off-by: Krzysztof Lecki klecki@nvidia.com

Why we need this PR?

• Refactoring to improve Operator API

What happened in this PR?

• Explain solution of the problem, new feature added.
  The Operator::Run and RunImpl signatures are changed from accepting pointer to workspace to reference to workspace.
  This is more C++ way of things and matches the signature of Setup.
• What was changed, added, removed?
  Run, RunImpl and similar signatures where changed from (Workspace *ws) to (Workspace &ws),
  access to ws changed from ws->x to ws.x. For some functions call was changed from fun(ws) to fun(&ws), as I intended to change only Run and related functions.
• What is most important part that reviewers should focus on?
  Mostly mechanical changes. Check if there is no docs mismatch.
• Was this PR tested? How?
  CI
• Were docs and examples updated, if necessary?
  Yes, dummy plugin was also updated.

Would be nice to followup with adjusting GetArgument to take a ref.

JIRA TASK: [DALI-XXXX]

[klecki]

!build

[dali-automaton]

CI MESSAGE: [857155]: BUILD STARTED

[JanuszL]

You can write something more than just yes in What was changed, added, removed?.
Other than that LGTM.

[dali-automaton]

CI MESSAGE: [857155]: BUILD FAILED

[dali-automaton]

CI MESSAGE: [857155]: BUILD PASSED

[klecki]

You can write something more than just yes in What was changed, added, removed?.
Other than that LGTM.

Done. :(
I was also considering a table:

Was before	Is now	Where used
Workspace *ws	Workspace &ws	Function argument
Workspace* ws	Workspace &ws	Function argument
Workspace * ws	Workspace &ws	Function argument
ws->x();	ws.x();	Member access to workspce
fun(ws)	fun(&ws)	Run[Impl] calling a function accepting pointer to ws

[klecki]

Regarding the Operator::RunImpl, as some users with custom ops may be using it, I can maybe provide the old overload there with [[deprecated]] attribute, leave it for one release and remove in the next one. What do you think? We don't promise that the C++ API won't change.

[JanuszL]

Regarding the Operator::RunImpl, as some users with custom ops may be using it, I can maybe provide the old overload there with [[deprecated]] attribute, leave it for one release and remove in the next one. What do you think? We don't promise that the C++ API won't change.

Sounds good. I guess we cannot put any compilation time warning for the users so they know they need to change something sooner than we remove it in the next release.

[klecki]

Regarding the Operator::RunImpl, as some users with custom ops may be using it, I can maybe provide the old overload there with [[deprecated]] attribute, leave it for one release and remove in the next one. What do you think? We don't promise that the C++ API won't change.

Sounds good. I guess we cannot put any compilation time warning for the users so they know they need to change something sooner than we remove it in the next release.

I'm still thinking about it, and it would require us to call old signature as a fallback in the new one, which makes the RunImpl not pure virtual. I don't think it is worth it.