8

I see a lot of different places that uniform initialization is recommended. Herb Sutter recommends it, and gives a list when not to use it. It seems that the general consensus is to use this syntax.

However, I don't see why. It has the problem of std::initializer_list takes precedence. Adding a std::initializer_list to a class can break code. With templates, it is not recommended to use. It seems to have more exceptions than the "old" way. None of these problems existed with the old way.

I fail to see why uniform initialization is superior. My conclusion is to keep using () syntax, and use {} only in the case of when I want to call a constructor with std::initializer_list.

Why? What does uniform initialization give?

  • forbids narrowing: good feature. But, as I have narrowing warnings turn on for all my code (because I want to know all narrowings in my code, not just at initializations), I don't need this feature too much.
  • most vexing parse: yeah, that's a problem, but I hit this very-very rarely. So it is not a reason (for me) to switch. This places, I may use {}.
  • is there anything else (maybe, I'm still learning new features of C++)?

With the "old" way, there were no rules to remember, no possible break-of-code. Just use it, and sometimes, very-very rarely, you hit the most vexing parse. That's all.

Is my thinking wrong somewhere?

geza
  • 28,403
  • 6
  • 61
  • 135
  • 7
    It helps to know what things are functions and what things are objects. `f(g(), h(j, i));` is less clear than `f(g{}, h(i, j));`. This still matters when the variables have proper names. – nwp Sep 25 '17 at 11:14
  • @nwp: yepp, that's a valid argument. But, I have a naming convention where I can immediately see types. Furthermore, current good IDEs could show the difference between them by some means (coloring, italic, whatever). – geza Sep 25 '17 at 11:35
  • 4
    Your naming convention is not followed by the STL or various other libraries. But sure, if you replace most features of braced initializers with some external tool and work alone or force everyone around you to do the same you don't need them. Not every C++ feature makes sense for everyone. – nwp Sep 25 '17 at 11:49
  • Maybe duplicate of [Why is list initialization (using curly braces) better than the alternatives?](https://stackoverflow.com/questions/18222926/why-is-list-initialization-using-curly-braces-better-than-the-alternatives) – jdehesa Sep 27 '17 at 17:24

1 Answers1

0

It seems like you have a decent hold on the technical aspects and nwp raised the other concern I would mention, clarity, in the comments. So I think you have the information you need to make a decision.

That said, I think it's worth doubling-down and trying to highlight the importance of the clarity aspect. In my experience, code clarity is probably the single most importance thing to maintain in a code base. Particularly in terms of avoiding confusion and limiting time wasted on stupid bugs. I think we've all had the experience of spending far too long tweaking the flow of a piece of buggy code only to eventually discover that the issue was a typo or misunderstanding of the original intent.

And to be fair, it sounds like you've tried to address this by sticking to a style and tools that help address that. The standard argument, as nwp started, is that many people aren't okay with deviating from the naming conventions built into the language, nor with using IDEs. I personally sympathize with that logic but also understand why many disregard it as old-fashioned or even a non-issue (particularly for the case of IDEs).

When it comes to matters of clarity, though, I find it hard not to keep in mind that people are annoyingly good at ignoring minor details, even when they might help them. So the more context clues that can hint at where an issue might be the better. Syntax highlighting is great, but I wouldn't bet an evening of debugging on being able to notice something being yellow instead of orange. Yellow and using camel-case? Maybe. Yellow and using braces? Maybe.

Especially when you start getting into code written by someone else, or a long time ago, the more all these little hints start to matter.

At the end of the day, I think that's why people like it enough to recommend it. It's the kind of thing that might just stick out to you when it matters.

Also, a side note in response to your comment about narrowing. Enabling warnings for narrowing may allow you to ignore this benefit for now but in many cases people either 1) can't enable such warnings due to legacy code or 2) don't want to enable such warnings because they intentionally rely on such behavior in certain circumstances and would consider the warnings a nuisance. However, adopting list initialization in either case could help with not only preventing potential issues but also making clear the intent of a given line of code.

To get to the point, people all have different circumstances and preferences. Features like this increase of ways people can improve their code quality/readability while still working within whatever constraints they may have (self-imposed or otherwise).

thesquaregroot
  • 1,414
  • 1
  • 21
  • 35
  • In general, I agree with you. I just fail to see the issue here. In a lot of cases, it simply doesn't matter whether `a()` is a function call or a constructor. Both "returns" an object. The only thing I accept here is that `{}` could help understand the code a little-little better. But when you try to understand someone else code, you're better use tools for that. For example, with a a debugger, you can follow much easier the path the code takes, etc. Your point of enabling warnings for legacy code is absolutely valid. – geza Sep 27 '17 at 08:32
  • So yes, there're difference circumstances, preferences. That's why it is strange to me that `{}` is treated as something superior, and the general advice is: "use it". In my opinion, this advice must be changed to something more sophisticated. – geza Sep 27 '17 at 08:34
  • @geza That's how advice goes, I guess. I tend to read advice like that as having an implied "if you don't have a reason not to." Often I think people are cautious about explicitly including those disclaimers in case a new programmer might use that logic to write off a helpful feature. Also, especially for a language like C++, I think people tend to be in favor of features that let the compiler do extra work for you and trust that you'll learn what an error really means before continuing, and see it as a net benefit in that light. – thesquaregroot Sep 27 '17 at 11:37