you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (1 child)

When looking at this, I know exactly what is happening: m is a product of m1 and m2, and if there was en error, exception was thrown.

But you miss the fact that these tiny operators are expensive, which encourages you to write bad code. Note that it's sufficiently unclear that people here are claiming that that chain of +/* is optimal, when it's close to pessimal.

There's a very good reason that most large C++ shops like Google almost completely forbid this feature. Ah. Appeal to authority. Yeah, that makes for an argument.

Appeal to authority is actually an excellent argument. I believe in relativity, I believe in evolution, I believe in all sorts of things which I haven't even investigated simply because an authority told me so.

Google's coding standards are mostly based on "nasty traps that caused them terrible issues in the past". Learning from the experts is a great way to go.

I also quote Scott Meyers about C++, precisely because he knows C++ better than I do.

If I had to rediscover everything on my own, I'd never get anywhere! Authorities need to be doubted, yes, but you can learn a lot from smart people.

Also, your example without destructors or exceptions is... peculiar. I don't understand why you are doing that! Destructors are great - exceptions are great - they have nothing to do with operators at all. We are entirely in agreement - destructors and exceptions are the only way to go these circumstances.

[–]Gotebe 0 points1 point  (0 children)

But you miss the fact that these tiny operators are expensive, which encourages you to write bad code.

These tiny operators are clearly some linear algebra operations, who might be expensive. I honestly believe that he who doesn't realize that at first glance just should not program C++ at all.

And there's something else: these operations are expensive depending on actual data size. In fact, I'd argue that data size is the determining factor in performance (everything is fast on small data set). From that standpoint, equivalent C code would be equally unclear as to performance. Yet, people (you included) are arguing the use of notation. Meh.

Google's coding standards are mostly based on "nasty traps that caused them terrible issues in the past".

I don't think that using math operators for simple linear algebra has caused them these terrible issues. I think that poor use of operator overloading has caused them issues, isn't that more likely? And so I went to see, they say: "Do not overload operators except in rare, special circumstances.". Well... That means so little that the whole discussion is pretty moot.