Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
My intuition and practice for a long time has been to avoid out params if at all possible. I believe that a function should have one logical purpose and that usually implies one return type (not returning multiple things). Sometimes, returning multiple things is desirable (f.e. std::map::insert). I know this can be done as a pair/tuple or as output params; the argument of which of those to use is less important to me.
What are the conceptual, design, or performance reasons to prefer either output parameters or return values?
You're right, out parameters are not really needed as RVO makes returning by value feasible, even with large types. And having to return multiple things is either a code smell, or can be sensibly packed in a structure.
I'd say the only remaining reason, and it's a biggie, is consistency. If the class already has tens of methods returning by parameter, stick to it (unless you have the liberty to refactor the darn thing :).
Depending on the context, a third alternative might be to pass a callback. The callback might have multiple methods if the called function "produces" multiple values.
Though a function that takes a callback argument doesn't really fit the definition of a "function", neither does a function that returns multiple values, IMO.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
The community is reviewing whether to reopen this question as of 1 year ago.
Improve this question
I am slowly writing an emulator for a gameboy using C++, I am currently working on the CPU side of things. I have written a generic function that takes any two registers of the CPU and returns as a Word data type. As it is necessary to access individual registers and also a combination of registers.
const Word get_word(Byte *registerOne, Byte *registerTwo)
{
return ((*registerOne << 8) | *registerTwo);
};
calling this function gets tedious as you have to specify each register
get_word(&this->registers.h, &this->registers.l)
My question is if it okay to define a macro like so
#define get_HL() get_word(&this->registers.h, &this->registers.l)
since now I can call it using
get_HL()
The reason why I want to do it like this since I don't want to create more private/public functions that just perform function calls.
I have tried compiling and it seems to work as it should since its just a pre-processor macro but I am not sure of the design implication
EDIT:
Okay I mean there are glaring flaws with this and you should just make a function, just as much work to make a function or write a macro.
const Word get_HL() { return this->get_word(&this->h, &this->l); };
Let this be a post for people who had the same idea and hopefully stop making the same mistake
No, this isn't OK in my opinion. It hides what arguments you're passing into the function, and macros don't respect scopes and as such are highly susceptible to name conflicts. This seems like an ideal use case for a non-static member function.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
In unversity, my tutor told me always use private variables in class and have a setter and getter function, because it provides better encapsulation. But what is encapsulation? Is there any resons to do so if I know my code is only going to be developed by myself? It's just simpler to use my_obj.var instead of my_obj.set_var(var)!
Encapsulation in the classroom means making an over-engineered 2D point struct. Completely contrived and useless. It does a disservice to the entire concept by teaching it with poor examples.
Encapsulation in the real world is e.g. std::vector which works how you expect and is safe due to not allowing you to tamper with its internals.
In short: no, it's not necessary. It really depends on what you're doing.
In particular, you want encapsulation if your object is handling dynamically-allocated resources directly. So all properly-implemented container types should use encapsulation to prevent you from accidentally breaking it.
But if your type is just a pair of ints or some other raw data, there's really no need.
Specifically, getters and setters should be used if the details of the implementation could potentially change at some later point in the future. E.g. a struct representing a timespan could be represented as seconds:minutes:hours, but could also just be (a lot of) milliseconds. The getters and setters would allow you to turn that into seconds/minutes/etc. without it actually having to be stored that way internally. The operating word here is internal representation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I realize this might be a controversial topic, but as a prospective developer who is entering industry in a couple of weeks, I'm trying to get an idea of the do's and dont's when writing code.
One of the things that even my professors seem to be at odds on is where should local variables be declared. I've had professors insist that the only way is to declare them all at the start of the function. This has the benefit of not reconstructing a new object every time a loop is entered, for example. But it has the draw back of making logic harder to follow since you don't know which variables are used in which scopes.
Other professors say that it is good practice to declare them when you use them. Even if it's in the middle of the lines of code. This seems to be more of a Python style of coding and could possibly clutter the code with, verbose, and unnecessary type information. Also, this could incur a performance penalty since the object will get constructed and then destructed in every iteration of the loop.
Then I had another professor say to declare them at the start of their respective scopes. So ideally, after each { there would be declarations for all the variables used in that scope. This seems to offer the best readability, and the worst performance since now the object could potentially be constructed and then assigned to (two separate, possibly expensive operations) in every loop iteration.
I hope you can see how a new programmer can get confused about what format to follow. So is there consensus in the work field about which style is the "best"?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
when I am going through the lambda function, I have seen people comparing lambda with functors & I came across a statement
users don't have to clutter their code with small functors in some accessible scope.
My doubt is
what is the problem in having small functors in some accessible scope
isn't it good idea to have a single function (functor actually) & reuse it across multiple files in our project.
Thanks.
it is unnecessary if you have to use each only once. Lambdas usually makes the code more readable, the function is defined exactly at the place it is needed.
this is not always the case, a function may be called at only one place. Of course if you needed it at different places a functor may be more appropriate.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm making a calendar application in c++ and I'm making a great number of overloaded constructors for the appointment class depending on the information provided(e.g. if i have a start time for the event but no end time, and a location, but no attached contacts)
class Appointment {
public:
//overloaded Constructors
Appointment();
Appointment(Date);
Appointment(Date,Date);
Appointment(Date,Date,std::string);
Appointment(Date,Date,std::string,std::string);
Appointment(Date,Date,std::string,std::string,Contact);
etc. etc. Is there a better way to do this?
You could either:
Create the object (a valid one) and set its properties afterwards via interface setters (since it seems an object can have a variable number of properties this seems like a good choice)
Use default parameters, e.g.
Appointment(Date=getDefaultDate(),
Date=getDefaultDate(),
std::string=getDefaultString(),
std::string=getDefaultString(),
Contact=getDefaultContact());
It really boils down to how you prefer to handle and initialize your objects.
An important sidenote: in large production codebases default parameters is a C++ feature often frowned upon because it might hinder readability and/or render debugging more difficult in particular scenarios (especially when something unwanted goes on and you didn't consider a default parameter being chosen, default parameters are specified on the declaration and that might also "hides" a potential problem from the developers)
This is totally unnecessary. As pointed out Macro A , you can default construct the object and afterwards you can use setters for them.
One more thing when designing a software you should keep in mind the rule of complete and minimal i.e you should provide all facilities in a class avoiding duplication/redundancy.