New answers tagged

0

Nulls are problematic because they must be explicitly checked for, yet the compiler is unable to warn you that you forgot to check for them. Only time-consuming static analysis can tell you that. Fortunately, there are several good alternatives. Take the variable out of scope. Way too often, null is used as a place holder when a programmer declares a ...


-1

My understanding is that you want to "encapsulate" the arguments you pass to a function - the function should be able to modify only what you want it to modify. Always passing a reference and putting const in front of it is tedious and prone to errors. Also, always passing references would mean creating a local variable for each function argument (instead ...


4

For basic types, reference parameters usually offer no performance attribute at all. Memory For instance, in your example, the char requires a single byte. A reference type requires a pointer, which is usually either 4 or 8 bytes, where the size of a pointer directly correlates to the type of executable you are using (4 bytes for 32 bit, 8 bytes for 64 ...


1

If you can't do dynamic allocation, you must statically allocate all possible ImageImpl instances that could be returned by FontImpl::GetImage and return a pointer to one of those based on the parameter that gets passed in. For example: static ImageImpl image_a; static ImageImpl image_b; : static ImageImpl image_z; Image* FontImpl::GetImage(char c){ ...


6

Yes this is definitively possible. But there are two challenges to address in your design: Close() is a member function. So if the button has to call this member function, it has to know on which object to call it. If later button has to action the call, you need to have it visible somehow in you rarchitecture (either it's a GUI element that ...


2

The correct answer is: C. None of the above. Option A: void fill_array(Array<Type>* array_to_fill); This is more idiomatic for pre-C++11 code where smart pointers were troublesome due to a lack of move semantics, and still continues to be the safer of the two options. The key here is the function does not "own" the memory: it performs one ...


2

You have already an accepted answer, but I am adding a new one (because I disagree with what @ixrec said). I imagine there is a subtle difference, but I don't know what it is. Could someone explain when I might prefer one form over the other? Ideally (in a perfect world), you should use the second form, for three reasons: it composes it naturally ...



Top 50 recent answers are included