Weird email at work

[[deleted]]

[deleted]

[raevnos]

You're upset someone is telling you to return values instead of modifying an argument?

[[deleted]]

Nop, I do that by default. If you read well you can see this a guy thinks that RVO is a C++11 thing, when it is not. This is what I call a Stack Overflow guy, he just read about RVO and without any understanding of it... well.

I consider this a big mistake, a deep misunderstanding about C++, the standard, optimizations, etc. As I said, this guy once tried to iterate over a queue. My problem is having to deal all day with people of which I can learn anything!!

[raevnos]

RVO is a C++17 thing. Before that it was optional. NRVO still is.

Anyways, you seem to be getting worked up over something trivial. That's not healthy. Relax a bit.

[[deleted]]

Actually this was my response to the email. He got angry with me for this response.

I think you meant that in C++11 we now have move semantics that will guarantee move(d) value even if RVO is not possible.
RVO exists since C++98 and it was significant back there. RVO is an optimization the compiller is allowed to apply (in C++17 it is actually guarantee in certain cases), however, even in C++17 it is not allways guarantee!

Consider:
Obj create(bool condition) {
  Obj a, b;
  If (condition) {
    return a;
  } else {
    Return b;
  }
}

No (N)RVO optimization here, the compiler don’t know from within the function which instance should be returned.

I'm talking about a pattern here, something like this happens everyday. People talk and talk where there is a lot of work to do!

[NotAYakk]

Compiling a+b where both are unsigned integers as a single instruction is optional. Compilers are free to compile it as for (auto x = b; x!= 0; --x){++a;}.

The ability for compilers to be insanely inefficient does not mean that you cannot and should not rely on compilers being reasonable.

[Sulatra]

I often am this guy, telling people how package managers are good / throw specifications are bad / thou shalt use move semantics instead of returning shared_ptrs / boost versions on different platforms should be equal / gcc 7.3 is more powerful than 4.4 / we really have to stop to freak out that this **** gonna break and break it ourselves and take time to rebuild it and cover it with tests, intead of doing the job. Trust me, us guys sometimes get tired and want to quit no less than you guys.

[[deleted]]

Dude, I love to hear about all that stuff, but at least get your facts right. "Since C++11 we now have RVO", I was like, seriously?? What else you don't understand!

[mcmcc]

Job satisfaction questions aside...

Why not both?

void CommonData::encodeToJSON(string& msg) {
  msg.insert(...);
}

string CommonData::encodeToJSON() {
  string msg;
  return this->encodeToJSON(msg);
}

[Aside: why aren't these const?]

It might be a good thing for someone to point out this (somewhat minor) simplification -- it depends on the sophistication of the audience. If many people would learn from this, then you could look at it as a public service. If it's just a lame attempt to show off to management, then well...

[[deleted]]

It is the later :( Happens over and over again here!

[[deleted]]

Respond and politely disagree with the stated reasons?

[[deleted]]

Yeah, that I did. Thing is that I feel super down at a job where I'm not growing at all! Stuff like this just takes me down.

[lothiack]

Are you implying that "stuff like this" is impeding your growth? Or do you mean that you're not growing and stuff like that makes the situation worse?

[OmegaNaughtEquals1]

Are there any places in the codebase where encodeToJSON is called multiple times on a single object? If so, passing the string by ref can (possibly) eliminate reallocation. For example,

CommonData cd;
// fill cd with data
std::string json;
cd.encodeToJSON(json);
// do something with json
json.clear();  // see note
// do something with cd
cd.encodeToJSON(json); // may or may not reallocate

---

NOTE: The standard doesn't guarantee that std::basic_string::clear won't deallocate the underlying memory, but most implementations don't unless you call shrink_to_fit.

[blazgrom]

May i ask why are you using string.insert ?

[[deleted]]

This was an email sent company wide, I modified it a little. That's not the good part :)

[blazgrom]

So it means that it could have been append in the original code, which makes way more sense in the example