New answers tagged

2

Should setters only set the values of class properties, and not perform any other logic? No. Following this rule makes having setters pointless. The only reason we put up with this tragic preemptive clutter is because some languages (also looking at you Java) have forced us to provide setters even when their side effects don't exist yet because allowing ...


1

Side effects are OK and one of the reasons for having properties instead of straight public member variables in the first place. Your example is not compelling though. But you can think of a private update method that gets called each time a property value is set. The update method could change some color in the UI or perform a new search using the new ...


-1

For me, this is about communication. If I took your question by word: Should setters only set values? I would say, they should because one expects a setter to be something that sets a value. I would distinct these two: what is thought to be a setter - intention in creation what looks like a setter - the code has a commonly used naming pattern (1) I ...


7

The overall problem you're having is that you're letting the implementation of this object guide its interface. That's almost always a bad idea (and is pretty much only justifiable for performance reasons). This almost certainly stems from a lack of understanding of what this object is for. What purpose it serves within the overall design of your system. ...


-3

Beyond simply assigning the value to a member variable, a setter should validate the value beyond the simple type checking. For example, if I have a percentage value stored as an integer, then chances are I want to check the value passed in to insure it's no more than 100 and no less than 0. Even if I use an unsigned int I still need to check to insure ...


3

Continuing to #ifdef is perfectly fine in C++. These kind of feature toggles are a good fit for the preprocessor. Alternatively, you can extract the optional features into a separate struct/class and then either use compile-time templates or run-time polymorphism to select the correct implementation. Here, the closest equivalent would be to define a ...


0

isn't anyone using the class expecting the value_type to be T, and only ever T anyway? Anyone using the class shouldn't be expecting that a T even exists, or that the class itself exists (maybe some other class will work better instead) :) Generic code will expect a container to fulfill some sort of a high-level concept, like Iterable. In particular, the ...


0

main called IsDoubleString, then IsDoubleString called IsDoubleString. When IsDoubleString returns, it returns to IsDoubleString because IsDoubleString called IsDoubleString. In fact IsDoubleString will return to IsDoubleString as many times as IsDoubleString called IsDoubleString... then IsDoubleString returns to main. That is probably confusing. So let us ...


3

Refactor for maintainability, and only try for more efficiency if needed. So, extract the index-calculation: static constexpr int smallestIndex(glm::ivec3 v) noexcept { return v.x < v.y && v.x < v.z ? 0 : v.y < v.z ? 1 : 2; } A more literal transcription might be optimized differently though: static constexpr int smallestIndex(glm::...


3

If you use C++11, you can wrap the duplicated code in a local lambda function. Since a lambda is guaranteed to be inlined, performance won't be affected. auto step = [&](int index) { rayStep(ray, rayLength, distanceFactor, currentVoxelCoordinates, raySign, rayPositive, positionInVoxel, index); }; if (d.x < d.y && d.x < d.z) { ...


0

I need a limited amount of objects = instances from a class, and I don't want to expose the option to create more. I also want easy access to them from everywhere That is an unnecessary constraint that seems motivated by apriori notions of how you can design and implement a game of chess -- be it a two player chess game or a three player chess game. What ...


Top 50 recent answers are included