C++ Avoiding accidental allocations (and copies)

This topic is 421 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

After seeing

" rel="external">this talk (and combined with similar experiences in other languages), I got to thinking just how many times I pointlessly copy variables around.  I'm sure it's a lot, and I'm sure more experienced C++ programmers are better at catching these things (especially given how off-handed he remarks these -- like they're "duh" to everyone in the room), but it feels like I'm a bit lost as to how to actually find these sorts of mistakes.  Right now it sort of feels like an "experience through code review" thing, and that's a bit disconcerting.  Are there tools or techniques to track this sort of thing, so that I can find whether I'm spuriously making copies where I didn't intend to?

In context, the very first example he gives is the sort of thing I'd do if I thought I was being clever.

Share on other sites
On 14/10/2017 at 3:12 AM, Hodgman said:

Pretty much any complex class (where copying would be an issue) of mine will inherit from NonCopyable by default. If at some point later I actually run into a situation where I need to copy or move them, which honestly is actually very rare, I'll remove the NonCopyable base and actually think about the problem

Also, just say no to string processing in C++ ;D

Agree.

A more modernish version of these classes would be just to declare the constructors deleted instead of making them private and having no definition. There, it makes also no interest to put them in a public or private section.

Also, note that all inherited classes can inherit in a protected way, thus not perverting the IS-A inheritance idiom.

Edited by _Silence_

Share on other sites

If a type is literally non-copyable due to its semantics or other constraints, then you should certainly delete the copy constructor and assignment operators (or otherwise hide them if you're not using C++11).

Otherwise, just implement the proper behavior and use a profiler to determine if you're performing extra copies and they're causing performance issues. If so, think about how you can optimize the copy, or prevent the copies from occurring at the specific places in code where they're a problem. Don't assume ahead of time there will be a problem, or change the semantics of the type to fix a usage issue. Just fix the usage if, when, and where it becomes a problem.

To address the original question, I personally like to think in terms of a value vs reference type dichotomy. One key difference between them is that value types are copy/move assignable, while reference types are not. Note that copy/move construction is still fine; you're just not allowed to assign to an already constructed instance. I adopted this mindset over the years because I found that the issue with copy/move semantics isn't that their implementations are too expensive or prohibitive, but rather that I wasn't considering the semantics of the type as a whole. Once that was fixed, the issues either disappeared completely, or I was better able to focus my efforts in the right place.

Edited by Zipster

Share on other sites

I do like the idea of just inheriting from a non-copyable base object as a safety net.  It at least solves a subset of potential problems.

Does anyone use any more dynamic approaches?  I know you can overload global new, but that seems a bit hole-y, since external libraries might use C or OS-allocation functions, and I have no idea what the standard libraries do under the hood.  That also seems really noisy because it's global.

43 minutes ago, Zipster said:

To address the original question, I personally like to think in terms of a value vs reference type dichotomy. One key difference between them is that value types are copy/move assignable, while reference types are not. Note that copy/move construction is still fine; you're just not allowed to assign to an already constructed instance. I adopted this mindset over the years because I found that the issue with copy/move semantics isn't that their implementations are too expensive or prohibitive, but rather that I wasn't considering the semantics of the type as a whole. Once that was fixed, the issues either disappeared completely, or I was better able to focus my efforts in the right place.

That's sort of the approach I've traditionally taken.  But then in the video linked I saw the equivalent of this:

class Foo
{
public:
std::string m_a;
std::string m_b
Foo( const std::string& a, const std::string& b) : m_a(a), m_b(b) {}
}

If I were writing an object that took two strings prior to this video, I might write it like that.  I would think "okay, I don't need to mutate the strings, so I may as well express the parameters as const.  Since I don't want a straight copy of the string, I'm going to pass a reference".  If I had actually written this code, I probably would never have known that it copies.  In fact, I wouldn't have even thought to look at it.

In fact, the whole "take a reference to avoid a copy" mentality is so ingrained into my head that I don't even know why it copies.

...Or at least I didn't.  The irony of this is that I realized after writing that last line that the copy is made because the actual class member is a string, the copy is because of the actual initialization of the class member.  I probably wouldn't have made that sort of mistake in retrospect, but I obviously (given this thread) wouldn't have seen the mistake in code review of someone else's code, so I guess the question still stands.

Edited by SeraphLance

Share on other sites
20 minutes ago, SeraphLance said:

If I were writing an object that took two strings prior to this video, I might write it like that.  I would think "okay, I don't need to mutate the strings, so I may as well express the parameters as const.  Since I don't want a straight copy of the string, I'm going to pass a reference".  If I had actually written this code, I probably would never have known that it copies.  In fact, I wouldn't have even thought to look at it.

In fact, the whole "take a reference to avoid a copy" mentality is so ingrained into my head that I don't even know why it copies.

...Or at least I didn't.  The irony of this is that I realized after writing that last line that the copy is made because the actual class member is a string, the copy is because of the actual initialization of the class member.  I probably wouldn't have made that sort of mistake in retrospect, but I obviously (given this thread) wouldn't have seen the mistake in code review of someone else's code, so I guess the question still stands.

That's the thing though, the fact that the strings are copied is due to the implementation details of the type. It could just as easily printed the strings and not made its own copy at all. There's no way to tell from the declaration of the type exactly what it's going to do with those strings (assuming the constructor wasn't defined inline), so what can you really do about it? It's not as though you can remove the copy if the type really needs it. Either way, the implementation should be considered private and separate from the traits of the type itself.

1. 1
2. 2
3. 3
Rutin
15
4. 4
5. 5
khawk
11

• 9
• 9
• 9
• 11
• 11
• Forum Statistics

• Total Topics
633679
• Total Posts
3013299
×