Looking for a Specific Industry Standard

I couldn't decide where this best belonged.

I'm writing a rebuttal of sorts to some of the more bizarre C++ coding standards in some industry specific standard documents. Unfortunately, I can't find a copy I was passed years back.

Okay. So, I'm doing this for funsies (Mostly. I plan to put it on my website later... which usually never comes.) so can't afford to go about buying copies of lots of different documents. I'm basically just hoping someone can copy the relevant rule for me with the supporting source information. (I'm talking a few lines. I don't need the supporting rationale or anything. I know the rationale. I'm not looking for a piecewise copy so everything else is irrelevant.) If I can't get that I'm hoping someone will recognize the rule so may point me in the right direction.

The rule in question, from vague memory, allowed reference parameters (&) and references (&) to be returned from functions but does not allow a parameter passed by reference (&) to be returned from a function as a reference (&). Crucially, this allowed classes (The `this' pointer is a pointer.) but forbid many forms of useful operator overloading even though operator overloading was generally allowed by these rules.

I know this is obscure so thanks for looking this post over just the same.

Soma

I've never head of a rule like that, Soma.

Plenty of coding standards have guidelines about not returning a reference or pointer to auto data that is local to a function (since it will result in a dangling reference or pointer, which cannot be safely used by the caller). That is documented in Item 23 of Scott Meyer's "Effective C++" (don't return a reference when you must return an object) and Item 31 (Never return a reference to a local object or to a dereferenced pointer initialized by new within the function).

Other coding guidelines also discourage a class member function returning a non-const pointer or reference to private (and sometimes protected) class members, since that allows an object's private data to be modified outside control of that object's member functions or friends. That is documented in Item 30 of "Effective C++" (Avoid member functions that return non-const pointers or references to members less accessible than themselves).


If you're planning to rebut those two guidelines I've mentioned, I'd be interested to know why .... on first blush, I might even rebut your rebuttal.

[Edit]I think grumpy can take it, but yeah this did come across as pointlessly aggressive. Sorry.[/Edit]

Quote:

---

Plenty of coding standards have guidelines about not returning a reference or pointer to auto data that is local to a function.

---

Quote:

---

Other coding guidelines also discourage a class member function returning a non-const pointer or reference to private class members, since that allows an object's private data to be modified outside control of that object's member functions or friends.

---

O_o

Seriously?

Okay. Sure.

Does the bizarre standard I reference look anything like that?

The answer you're looking for is "No. The standard I'm forwarding looks nothing like the one you asked about.".

So, is the standard you are forwarding the one I asked about?

The answer you're looking for is "No. I only forwarded the standard I referenced to show that I am aware of the existence of other less insane standards.".

*shrug*

If you are going to list every standard that I didn't ask about, you are going to be here for an extremely long time.

The standard I'm looking for is in the same genre as "always catch exceptions where they are thrown".

Yeah, that is a real thing that was said by people who are in a position to set the standards for an entire company.

Quote:

---

If you're planning to rebut those two guidelines I've mentioned, I'd be interested to know why .... on first blush, I might even rebut your rebuttal.

---

Well, it seems like I made a mistake above didn't I?

The answer you were looking for wasn't "No. I only forwarded the standard I referenced to show that I am aware of the existence of other less insane standards." was it?

No. The answer you were looking for was "No. I only wanted to challenge you over an unrelated standard.".

Well, that would almost certainly be a fun game to play.

I'm being totally serious; imagine what we all might learn if all the regulars here were to play "What is good/bad with $(some_standard)?"!?

Today though I will be playing "Portal 2". You can certainly play that with me if you have a "Live" account.

Soma

Soma, I've looked at a lot of programming guidelines - both proprietary and freely available - in my time, and never come across one that exactly matches your description.

Yes, the rules I pointed out are not identical to the one you described. However, they are rules that I've seen misinterpreted in bizarre ways, which could actually explain whatever it was that you observed.

Quote:

---

However, they are rules that I've seen misinterpreted in bizarre ways, which could actually explain whatever it was that you observed.

---

O_o

Sure enough.

One hopes that such bizarre standards comes from twisting good ones.

Actually, I'm confident this one did as well.

That doesn't change how foolish it sounds, but I feel certain that this came from notion that one shouldn't try and mutate the same variable more than once between sequence points (undefined behavior).

Soma

Maybe you're thinking of a const reference to a temporary?

It sounds like you are referring to the MISRA C++ standard. Maybe this section (7-5-3)?

Quote:

---

A function shall not return a reference or a pointer to a parameter that is passed by reference or const reference.

---

Jim

Quote:

---

It sounds like you are referring to the MISRA C++ standard. Maybe this section (7-5-3)?

---

O_o

I don't know if that is the origin or not, but I'm definitely going to look at that further.

Thanks a lot for passing along such a good lead.

Soma

Quote:

---

Originally Posted by phantomotap

One hopes that such bizarre standards comes from twisting good ones.

---

just remember that bizarre != bad in every case. sometimes bizarre can be fun :)

O_o

Never forget that they can also be harmful.

Teaching or enforcing bad practices usually results in a nightmare of code.

Soma