10 ms·

C++ braced initializers and type deduction

50 points by krsna 13y ago

eru 13y ago
How does the C++ committee actually work, if the experts can have these kinds of open questions?
- pjmlp 13y ago
  Like any ANSI/ISO committee, you need to be a member to seat on those meetings and discuss everything language related. To become a member you need to pay for it, so most members are employees from compiler vendors. Everyone else only gets access to what gets published as public information, hence the doubts due to not being present in those meetings.
  - eru 13y ago
    Thanks! (In my naive ways, I would have guessed that perhaps speaking rights were restricted, but that everyone was allowed to read and listen.) The ANSI/ISO way seems like the opposite of what you'd want in a (open) programming language, doesn't it?
    - pjmlp 13y ago
      You get to know what is going on by posts from members, like this one https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/the_view_from_the_c_standard_meeting_september_2013_part_2?lang=en https://www.ibm.com/developerworks/community/blogs/5894415f-... The ANSI/ISO way is the best way to standardize technology. The alternative being a reference implementation subject to a benevolent dictator with everyone discussing what the right license should be. Any implementor knows what is supposed to be compliant with, as long as, its implementation follows a well defined standard, regardless of what license it decides to publish under and what type of implementation (compiler/interpreter/JIT/,...)
      - eru 13y ago
        Thanks for the link! > The ANSI/ISO way is the best way to standardize technology. The alternative being a reference implementation subject to a benevolent dictator with everyone discussing what the right license should be. That's a false dilemma. You can have a standard that's discussed and decided on in a forum that's not ANSI/ISO.
        roel_v 13y ago
        That's just nitpicking. Maybe the GP could have said "The model of the ANSI/ISO way is the best way to standardize technology.", but the sentence after that described in a very apt way the vast majority of "standards" not build by a formal committee, with actual travel budgets and a commitment to make things work for the medium term (10 years, at a minimum).
    - Sharlin 13y ago
      The C++ working group is one of the most open ones, though. All proposal papers, meeting minutes, even the draft standard documents are freely available at http://www.open-std.org/jtc1/sc22/wg21/ http://www.open-std.org/jtc1/sc22/wg21/, as are the archives of the various mailing lists. (BTW, if anyone upvotes this, I'm going to lose my 1337 karma. Oh well.)
- anon4 13y ago
  Imagine in general the bikeshed problem, or more recently the "midnight evaluates to false" saga on the python mailing list, then add in the fact that every person on the committee is an expert (in fact, the world's best expert) on the entire list of issues being discussed.
- cbsmith 13y ago
  I presume you are unfamiliar with how committees work.
fauigerzigerk 13y ago
The entirety of C++ initialization rules has become a byzantine mess of epic proportions and any change is bound to add another level of combinatorial explosion. There's just no way out of it. I can tell you how C++ will die. It will die because all C++ programmers will soon be dead for one simple reason: Our brains are incapable of knowing C++ well enough to write safe C++ code and knowing something else at the same time. Knowing all the rules and exceptions to those rules in C++ will overwhelm the neocortex of C++ programmers and start to usurp older parts of the brain to the point where heart rate and body temperature get out of control and they/we all die an agonizing death. As a C++ programmer I am struggling right now trying to leave this path to seemingly inevitable doom. But the insane complexity of C++ has this addictive allure of making me feel so incredibly competent and important, a bearer of secret knowledge that underpins the world's most important systems.
- asdkl234890 13y ago
  Same here. C11 has driven me into mobile app development with Java and Objective C. And that's after 10+ years of C++ experience and most people consider me a C++ expert.
  - dbaupp 13y ago
    Do you mean C++11, rather than C11?
    - asdkl234890 13y ago
      Yes.
- nhaehnle 13y ago
  Honestly, writing safe C++ code means just following a few rules of thumb. Most importantly: never do pointer arithmetic, always use smart pointers. Basically, 99% of your work should use only about 10% of the feature set of C++ explicitly. The vast majority of the time, you shouldn't even write templates (just use the ones in the STL and project-specific ones that make sense). But it's really nice that those other 90% of features are there when you need them.
etfb 13y ago
Oh dear. Scott Meyers calls himself "just a grunt on the ground". I think we're all doomed.
- etfb 13y ago
  (To clarify, Scott is one of my heroes from my days following the ever-evolving C++ standard. Anything that leaves him feeling like a "grunt" is, to a fair approximation, hairier than Chewbacca.)
72deluxe 13y ago
I love Scott's hair. It looks like an exciting blend of a 1970s progressive rock band and one of Robin Hood's merry men. It's cool.
roel_v 13y ago
Only slightly related, but I feel (I do not yet have the experience) that 'auto' is going to make the lives of those reading code 10x harder, for the benefit of those writing code to have to think and type tiny amounts less, and for the writers of template libraries to have to think 10 times less. Especially that last part concerns me great amounts. I'm not looking forward to the first time I will have to work myself into a code base build around heavy 'auto' use.
- nikbackm 13y ago
  OTOH, with auto the reader never have to worry about narrowing conversions. And any decent IDE should show the deduced type for an auto variable on demand.
  - roel_v 13y ago
    "And any decent IDE should show the deduced type for an auto variable on demand." Eh... That can only be done by compiling the code in the background, while you're typing. Which is possible, of course, but it sets a very high barrier for tools. It will mean that only the top-3 of IDE's will provide this functionality, and even then, it will take them years to get it working well.
- ygra 13y ago
  (C++ beginner here) I tend to use the actual type for simple enough types, typdef those template instantiations I use frequently and use auto more or less only for iterators (which are horrible to write otherwise, especially for things like map<foo, vector<bar>>).
  - roel_v 13y ago
    It's for iterators, and similar template-heavy types, that you need them the most. Well not for an iterator over an std::vector<double> obviously, but the worse the amount of typing for the type gets, the more you need to know the actual type to save you from having to do the type deduction in your head every time. (well not 'you' in the sense of 'the author', the whole problem it's that it's the people who need to read the code afterwards need the full type the most, the incentives are so misaligned). I guess the more I think about it, that that's what scares me the most about 'auto' - instead of having the original author do the type deduction once (which is something he intended in the first place, hopefully), you now (as a maintainer) have to go chase it down, just to save the original author from typing out a hairy type. Now I do realize the real use case for 'auto' - it's the cases where you don't actually know the type yet, because you're providing an extensible framework through template specialization. I have written quite a bit of such code myself. And yet, despite having suffered through all the 5-line typedefs that that sometimes required, I'd be willing to keep doing that to save myself from code by people who mistake 'auto' for a convenient way to save a few keystrokes (this is not meant as a jab at the parent, I'm just talking in general, in case anyone would interpret me wrong).
peterbotond 13y ago
the way i handle c++ complexity is to limit its feature usage to exercise its strength letting it help me solve the problem. c++ is a big language with big grammar, as such offers a lot of different ways to say the same thing. each different construct is understood by a different set of code-readers, same way as in a complex human language. commenting c++ code is part of writing c++ due to this complexity, in my practice. in a complex grammar, the order of words makes a difference and certain relation of grammatical constructs must be obeyed to remain comprehensive and understandable by most people. communications using formal grammar makes it more understandable, versus slang. however both formal and informal convey the same information for the respective group of people. in a programming language, pondering publicly about good and bad practices and their merit helps reading code, of course, with comments.
- danielweber 13y ago
  > c++ is a big language with big grammar, as such offers a lot of different ways to say the same thing This is what I hate about Perl, so why do I like C++? I'm quite willing to admit I'm irrational, but it feels like there's a big difference between the "there's more than one way to do things" style of both languages.

50 points by krsna 13y ago

eru 13y ago

How does the C++ committee actually work, if the experts can have these kinds of open questions?

pjmlp 13y ago
Like any ANSI/ISO committee, you need to be a member to seat on those meetings and discuss everything language related. To become a member you need to pay for it, so most members are employees from compiler vendors. Everyone else only gets access to what gets published as public information, hence the doubts due to not being present in those meetings.
- eru 13y ago
  Thanks! (In my naive ways, I would have guessed that perhaps speaking rights were restricted, but that everyone was allowed to read and listen.) The ANSI/ISO way seems like the opposite of what you'd want in a (open) programming language, doesn't it?
  - pjmlp 13y ago
    You get to know what is going on by posts from members, like this one https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/the_view_from_the_c_standard_meeting_september_2013_part_2?lang=en https://www.ibm.com/developerworks/community/blogs/5894415f-... The ANSI/ISO way is the best way to standardize technology. The alternative being a reference implementation subject to a benevolent dictator with everyone discussing what the right license should be. Any implementor knows what is supposed to be compliant with, as long as, its implementation follows a well defined standard, regardless of what license it decides to publish under and what type of implementation (compiler/interpreter/JIT/,...)
    - eru 13y ago
      Thanks for the link! > The ANSI/ISO way is the best way to standardize technology. The alternative being a reference implementation subject to a benevolent dictator with everyone discussing what the right license should be. That's a false dilemma. You can have a standard that's discussed and decided on in a forum that's not ANSI/ISO.
      - roel_v 13y ago
        That's just nitpicking. Maybe the GP could have said "The model of the ANSI/ISO way is the best way to standardize technology.", but the sentence after that described in a very apt way the vast majority of "standards" not build by a formal committee, with actual travel budgets and a commitment to make things work for the medium term (10 years, at a minimum).
  - Sharlin 13y ago
    The C++ working group is one of the most open ones, though. All proposal papers, meeting minutes, even the draft standard documents are freely available at http://www.open-std.org/jtc1/sc22/wg21/ http://www.open-std.org/jtc1/sc22/wg21/, as are the archives of the various mailing lists. (BTW, if anyone upvotes this, I'm going to lose my 1337 karma. Oh well.)
anon4 13y ago
Imagine in general the bikeshed problem, or more recently the "midnight evaluates to false" saga on the python mailing list, then add in the fact that every person on the committee is an expert (in fact, the world's best expert) on the entire list of issues being discussed.
cbsmith 13y ago
I presume you are unfamiliar with how committees work.

fauigerzigerk 13y ago

The entirety of C++ initialization rules has become a byzantine mess of epic proportions and any change is bound to add another level of combinatorial explosion. There's just no way out of it. I can tell you how C++ will die. It will die because all C++ programmers will soon be dead for one simple reason: Our brains are incapable of knowing C++ well enough to write safe C++ code and knowing something else at the same time. Knowing all the rules and exceptions to those rules in C++ will overwhelm the neocortex of C++ programmers and start to usurp older parts of the brain to the point where heart rate and body temperature get out of control and they/we all die an agonizing death. As a C++ programmer I am struggling right now trying to leave this path to seemingly inevitable doom. But the insane complexity of C++ has this addictive allure of making me feel so incredibly competent and important, a bearer of secret knowledge that underpins the world's most important systems.

asdkl234890 13y ago
Same here. C11 has driven me into mobile app development with Java and Objective C. And that's after 10+ years of C++ experience and most people consider me a C++ expert.
- dbaupp 13y ago
  Do you mean C++11, rather than C11?
  - asdkl234890 13y ago
    Yes.
nhaehnle 13y ago
Honestly, writing safe C++ code means just following a few rules of thumb. Most importantly: never do pointer arithmetic, always use smart pointers. Basically, 99% of your work should use only about 10% of the feature set of C++ explicitly. The vast majority of the time, you shouldn't even write templates (just use the ones in the STL and project-specific ones that make sense). But it's really nice that those other 90% of features are there when you need them.

etfb 13y ago

Oh dear. Scott Meyers calls himself "just a grunt on the ground". I think we're all doomed.

etfb 13y ago
(To clarify, Scott is one of my heroes from my days following the ever-evolving C++ standard. Anything that leaves him feeling like a "grunt" is, to a fair approximation, hairier than Chewbacca.)

72deluxe 13y ago

I love Scott's hair. It looks like an exciting blend of a 1970s progressive rock band and one of Robin Hood's merry men. It's cool.

roel_v 13y ago

Only slightly related, but I feel (I do not yet have the experience) that 'auto' is going to make the lives of those reading code 10x harder, for the benefit of those writing code to have to think and type tiny amounts less, and for the writers of template libraries to have to think 10 times less. Especially that last part concerns me great amounts. I'm not looking forward to the first time I will have to work myself into a code base build around heavy 'auto' use.

nikbackm 13y ago
OTOH, with auto the reader never have to worry about narrowing conversions. And any decent IDE should show the deduced type for an auto variable on demand.
- roel_v 13y ago
  "And any decent IDE should show the deduced type for an auto variable on demand." Eh... That can only be done by compiling the code in the background, while you're typing. Which is possible, of course, but it sets a very high barrier for tools. It will mean that only the top-3 of IDE's will provide this functionality, and even then, it will take them years to get it working well.
ygra 13y ago
(C++ beginner here) I tend to use the actual type for simple enough types, typdef those template instantiations I use frequently and use auto more or less only for iterators (which are horrible to write otherwise, especially for things like map<foo, vector<bar>>).
- roel_v 13y ago
  It's for iterators, and similar template-heavy types, that you need them the most. Well not for an iterator over an std::vector<double> obviously, but the worse the amount of typing for the type gets, the more you need to know the actual type to save you from having to do the type deduction in your head every time. (well not 'you' in the sense of 'the author', the whole problem it's that it's the people who need to read the code afterwards need the full type the most, the incentives are so misaligned). I guess the more I think about it, that that's what scares me the most about 'auto' - instead of having the original author do the type deduction once (which is something he intended in the first place, hopefully), you now (as a maintainer) have to go chase it down, just to save the original author from typing out a hairy type. Now I do realize the real use case for 'auto' - it's the cases where you don't actually know the type yet, because you're providing an extensible framework through template specialization. I have written quite a bit of such code myself. And yet, despite having suffered through all the 5-line typedefs that that sometimes required, I'd be willing to keep doing that to save myself from code by people who mistake 'auto' for a convenient way to save a few keystrokes (this is not meant as a jab at the parent, I'm just talking in general, in case anyone would interpret me wrong).

peterbotond 13y ago

the way i handle c++ complexity is to limit its feature usage to exercise its strength letting it help me solve the problem. c++ is a big language with big grammar, as such offers a lot of different ways to say the same thing. each different construct is understood by a different set of code-readers, same way as in a complex human language. commenting c++ code is part of writing c++ due to this complexity, in my practice. in a complex grammar, the order of words makes a difference and certain relation of grammatical constructs must be obeyed to remain comprehensive and understandable by most people. communications using formal grammar makes it more understandable, versus slang. however both formal and informal convey the same information for the respective group of people. in a programming language, pondering publicly about good and bad practices and their merit helps reading code, of course, with comments.

danielweber 13y ago
> c++ is a big language with big grammar, as such offers a lot of different ways to say the same thing This is what I hate about Perl, so why do I like C++? I'm quite willing to admit I'm irrational, but it feels like there's a big difference between the "there's more than one way to do things" style of both languages.