New answers tagged

2

If reading uninitialized memory is undefined behavior anyway, why has the C++ standard not been changed so that objects of primitive type (int, unsigned, float, double, bool, char) get default-initialized to 0? I see two important reasons compatiblity with past specifications of C++ (e.g. n3337) and past implementations (compilers like GCC) performance: ...


-2

It’s allowed because C and C++ are old. And enforcing such a rule is difficult. But C++ doesn’t allow the use of undefined variables, it’s undefined behaviour. If you look at a modern language like Swift, that enforces the rule that a variable may not be used unless it is initialised in such a way that the compiler can determine that it is initialised. It ...


2

[...] so that objects of primitive type (int, unsigned, float, double, bool, char) get default-initialized to 0? Wouldn't this prevent an entire class of typical beginner mistakes? I don’t think so. Usually the actual mistake is that the programmer either assumed the variable would be initialized to something useful after the declaration, or simply forgot ...


9

The guiding principle there is still "You don't pay for what you don't use". It has not been changed to "Let's play it safe, and hope the compiler fixes our performance". Not that zero will not always make semantic sense in every scenario, even though it's a valid value for all fundamental types. Actually, debug-modes which initialize to ...


0

Note that having the function body inside the class definition and having the body present in the header are different things. You can also write: // something.hpp class C { int func(); }; // semicolon missing in your original! // note: still in something.hpp inline int C::func() { return ... ; } And this gives you the ability for client code to ...


17

When a function is defined as part of the class definition, it is implicitly inline (regardless of whether you use that keyword). This has a number of consequences. The function may be inlined by the compiler, potentially but not necessarily resulting in a faster program. Thus, different compilation units can get different copies of this function. The One ...


5

This isn't really an issue of safety. It's mostly about readability and a little bit about compile times. If a function is very long, you'd generally prefer not to have the entire implementation in the header. Ideally the header should simply declare an interface, and leave all the implementation details hidden from the outside world. That said, when you're ...


6

The advice that the C++ standard libraries aren't slower than C code is true when the same operations are performed. A quick look at the LodePNG code shows that is loads a file like this: determine the file size allocate a buffer large enough to store the entire file read the file into the buffer in one go Based on your description, I assume you are ...


1

As already stated by others, a const function implies it should be thread-safe to call it from multiple threads simultaneously, without calling a non const function at the same time. As Herb Sutter (29:43) stated himself, this means that a const function should be bitwise const or internally synchronised, which isn't really thread-safe if other non-const ...


2

The most direct approach I know for decoupling general logic for controlling the UI (like progress indicators) from a specific UI technology (like Qt) is the Model-View-Presenter pattern. This works as follows: For each Window / Dialog / Form / View, one has to define an abstract interface class, and the Window / Dialog / Form / View class (from the ...


1

When you have a class where instances could store arbitrary amounts of data, like vector or string or a map, the class instances will not contain the actual data, but just pointers to the data. So the instance itself never changes in size as you add things, only the private pointers inside it. As a rule, the pointer to an object never changes.


1

A little bit more test code helped me to understand the great answers above, for anyone who may still be confused. std::vector<int> vect({5, 6}); std::cout << "Vect address " << &vect << std::endl; for (int i = 0; i < vect.size(); i++) { std::cout << "address " << i << " elem: &...


0

I think it is the word "composition" that is tripping you up. Composition in object orientated design means essentially that objects should be made up of other objects. They should be composed of other objects. Anything that is "in" the object for want of a better term, should also be an object (or use inheritance, but I don't think your ...


3

While this code works, the question is why do you want a pointer to a vector? If this pointer is a class member, extra care is required with a view to the rule of three. If this is a local variable somewhere, extra care is needed to avoid leaking memory when the pointer is no longer needed. The following code is much safer: std::vector<int> vect; for ...


6

No problems luckily. This code is safe. When calling “new”, a range of bytes is reserved on the heap memory. The size of that range depends on the object type and is known at compile time. That size can not grow or shrink, until you call delete, and you can count on that pointer value not to change (until you call delete). But then, how can this vector “grow”...


2

Fly Weight Wrap the individual COOKIE* in a Cookie class. eg: class Cookie { private: COOKIE* c; }; Then you can very quickly make an array of Cookies and pass that into your span. Container Instead of wrapping in a span. Wrap the array itself. You'll probably want to have a fly weight still for item access, just create these on demand. class Cookies { ...


Top 50 recent answers are included