What does style look like, part 7

Larry Osterman s WebLog What does style look like part 7 | Outdoor Decor

Larry Osterman s WebLog What does style look like part 7 | Outdoor Decor — Fri, 19 Jun 2009 07:10:27 GMT

PingBack from http://outdoordecoration.info/story.php?id=4496

Larry Osterman s WebLog What does style look like part 7 | Hair Growth Products

Larry Osterman s WebLog What does style look like part 7 | Hair Growth Products — Sat, 13 Jun 2009 15:11:38 GMT

PingBack from http://hairgrowthproducts.info/story.php?id=7103

Larry Osterman s WebLog What does style look like part 7 | Portable Greenhouse

Larry Osterman s WebLog What does style look like part 7 | Portable Greenhouse — Mon, 01 Jun 2009 22:40:39 GMT

PingBack from http://portablegreenhousesite.info/story.php?id=14525

Larry Osterman s WebLog What does style look like part 7 | Wood TV Stand

Larry Osterman s WebLog What does style look like part 7 | Wood TV Stand — Mon, 01 Jun 2009 20:42:45 GMT

PingBack from http://woodtvstand.info/story.php?id=7041

re: What does style look like, part 7

Larry Osterman — Tue, 30 Nov 2004 01:59:00 GMT

Sean,
That only works if Method1() doesn't have side effects (like allocating memory).

re: What does style look like, part 7

Sean Malloy — Tue, 30 Nov 2004 01:57:00 GMT

IMO, I would break the single return point rule rather than use a goto.

#define HANDLE_FAILURE(hr) if ((hr) != S_OK) return hr;
HRESULT MyFunction()
{
HRESULT hr;

hr = myCOMObject->Method1();
HANDLE_FAILURE(hr);

hr = myCOMObject->Method2();
HANDLE_FAILURE(hr);

hr = myCOMObject->Method3();
HANDLE_FAILURE(hr);

hr = myCOMObject->Method4();
HANDLE_FAILURE(hr);

hr = myCOMObject->Method5();
HANDLE_FAILURE(hr);

return hr;
}

ofcourse, if you have cleanup code there's an issue that can be solved by a goto (as you suggested)

re: What does style look like, part 7

Norman Diamond — Mon, 22 Nov 2004 04:07:00 GMT

11/18/2004 6:21 PM Larry Osterman

> There IS a semantic difference between i++
> and ++i in the language,

Right.

> but there isn't a semantic difference
> between i++ and i+=1 (assuming that they
> appear in a statement with equivilant
> operator precedence).

Wrong. There isn't a semantic difference between ++i and i+=1 (assuming your ssumption). There is a semantic difference between i++ and i+=1 except when you're discarding the result. (Of course style and readability do call for discarding the result and only letting i benefit from the side effect, but the language definition doesn't.)

re: What does style look like, part 7

Larry Osterman — Sat, 20 Nov 2004 06:14:00 GMT

Actually my issues with templates are directly related to my issues with operator overloads: They hide complexity. Templates add the additional problem of hiding code size.

It's not always clear to people that having:

std::vector<std::string> stringArray;
std::vector<int> intArray

brings in two complete copies of std::vector (and two copies of everything that std::vector uses) into their application. That's the biggest evil of templates. I've seen real-world examples of unbelievable code bloat brought on by templates.

The good news is that current linkers help to ameliorate this problem (by collapsing identical functions), which means that CComPtr<IUnknown> and CComPtr<IDispatch> can share implementations (otherwise you'd have a separate completely identical implementations of CComPtr for every single COM object your program used).

re: What does style look like, part 7

James — Sat, 20 Nov 2004 01:50:00 GMT

Larry,

While I don't necessarily agree with all of your sentiments, I do agree with your rationale that ease of maintenance is critical.

Please allow me to suggest the Bulka and Mayhew book "Efficient C++" to people who are concerned about operator overloading in C++ after reading your reply. Overloading is syntactic sugar for making a function call, but as you suggest, you should understand the implications of making such a call.

As for templates, that's a discussion for another day. I could argue strongly in their favour (compare std::sort to qsort), but no doubt you have arguments as to their complexity (for authors at least).

re: What does style look like, part 7

Larry Osterman — Fri, 19 Nov 2004 02:21:00 GMT

James,
<snarky>STL? What's that? It's not part of the core language, is it?</snarky>

My comment's snarky but it's relevent. Just because the STL authors chose to ignore the semantics of the language isn't the fault of the language.

There IS a semantic difference between i++ and ++i in the language, but there isn't a semantic difference between i++ and i+=1 (assuming that they appear in a statement with equivilant operator precedence).

Remember my comment about style in the final post in the series: Style's about improving the maintainability of code. Any use of constructs that do NOT improve the readability of code should be avoided at all costs.

And I personally consider operator overloads of all sorts to be a classic example of a situation where complexity is unnecessarily added (it's without a doubt my least favorite language feature, closely followed by templates). We've been through that particular discussion before (see the all developers must know assembly language post for more info, it's in the archives).

Just consider that one senior developer spent literally a year doing nothing but dealing with the consequences of a development team choosing to use operator overloads in a performance critical portion of the operating system, and you'll understand where my issues come from. Operator overloads hide code and thus hide complexity, which is utterly unacceptable in high performance systems code.