Shared library - parameters as pointers or not?
-
wrote on 19 Dec 2019, 10:17 last edited by
Hi,
I really think that what I am about to ask is a newbie question but I am not sure what would be best practice and why:- in my current project I'll have some parts of the code, common methods operating on struct filled with integers, bools and a QVector of bools reused throughout three different standalone applications working as a kind of software suite.
- Methods return either mentioned struct or QByteArray taking the other as a parameter (so either you have a struct as a parameter and method returns QByteArray or the other way around).
- I came to the conclusion that it might be better to move those methods to the shared, dynamically loaded library.
The question: is it ok to just use QByteArray and struct or I should use QByteArray* and struct*?
-
It depends on what you want - I don't see a reason why to pass an object as pointer instead as const ref when you don't want to return something in the given object.
-
It depends on what you want - I don't see a reason why to pass an object as pointer instead as const ref when you don't want to return something in the given object.
wrote on 19 Dec 2019, 10:48 last edited by@Christian-Ehrlicher Me neither. Parameter is irrelevant and is discarded just after the method finishes, I care only about the return value. But I am often not sure what would be considered good, healthy practice by more experienced fellows in art, so I prefer to ask just to be sure.
-
Returning plain pointers results in questions about ownership. Returning objects may be a bottleneck when the object is huge.
-
Returning plain pointers results in questions about ownership. Returning objects may be a bottleneck when the object is huge.
wrote on 19 Dec 2019, 11:19 last edited by@Christian-Ehrlicher got it, thank you!
1/5