3 ms·

Lightning talks from Meeting C++ 2015

68 points by meetingcpp 11y ago

toth 11y ago
Really cool talk on an implementation of static_if in C++14. I'd suspected something like it should be possible, but couldn't get it to work right. Great to have someone figure it out for me :). Also, cool to see that they are considering adding a version to the language in C++17. Thought they'd ruled it out. Andrei Alexandrescu has a very nice talk on how static_if is superior to concepts, this is definitely very nice to have.
- meetingcpp 11y ago
  Its going to be added to the language MAYBE. One of the problems with the first approach was, that it used {}, but did not introduce scope. A serious wtf in any c-like language.
- omaranto 11y ago
  Do you mean "static_if I Had a Hammer" [1]? [1] https://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Static-If-I-Had-a-Hammer https://channel9.msdn.com/Events/GoingNative/GoingNative-201...
  - toth 11y ago
    Yes, that was it. Thanks for finding it.
  - dcarp2 11y ago
    There is an update on that at DConf 2015: https://www.youtube.com/watch?v=mCrVYYlFTrA https://www.youtube.com/watch?v=mCrVYYlFTrA
- petke 11y ago
  I think Herb Sutter and Bjarne Stroustrup where against it. Its like a glorified ifdef. Its too low level a solution. Concepts solves the same problem in a higher level manner. Edit: https://isocpp.org/files/papers/n3613.pdf https://isocpp.org/files/papers/n3613.pdf "In this paper we consider the impact and risks of adopting static if. Some of the problems addressed by the proposed feature are real and urgent, but on balance this proposal this proposal would do much more harm than good. Language features addressing these problems must not negatively affect the language and our ability to build tools around it. We conclude that future development of static if should be abandoned, and that alternatives such as “concepts-lite” approach should be pursued instead."
  - toth 11y ago
    Yes, I'd seen that white paper, and thought static_if would never happen in C++. Concepts are nice for some things, but as Alexandrescu argues convincingly in the talk omaranto linked, they become quickly become very unwieldy if you need to consider multiple orthogonal concepts at once in the same place. You get a combinatorial explosion of things you need to name. static_if needs to much nicer and smaller code. The wait paper you link raises some valid concerns, but if it is something you can implement just as a library (as the lightning talk shows) most of them are moot. Note that this library-only version is a somewhat restricted version of static_if, the code in the branches that are not taken is still required to parse, it just is never instantiated. EDIT: looking again at the whitepaper, they were arguing against a specific proposal for static_if. I think this library-only version does not have the same issues. Nice discussion here: http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0128r0.html http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0128r0....
- kyberias 11y ago
  static_if really sounds crazy and I think Stroustrup's paper nails it down. Hopefully they don't include such idiocy in the language.
- SuperV1234 11y ago
  Author of the talk here - glad you liked it! Replying to pretty much everyone: what Bjarne and others were strongly against was the first static_if proposal, which was a glorified #ifdef and broke scope rules. The newest constexpr_if proposal does basically what I have shown in my talk (normal scope rules, no unexpected behavior), but with a nicer and cleaner syntax.
hitlin37 11y ago
i attended the conference for the first time this year. very nice and knowledgeable conference, many more talks will be available in coming weeks as they announced in closing notes.
buildops 11y ago
Was a great conference and we had a great time speaking (Parallel Computing strategies by Dori Exterman). Would love to know your feedback.

68 points by meetingcpp 11y ago

toth 11y ago

Really cool talk on an implementation of static_if in C++14. I'd suspected something like it should be possible, but couldn't get it to work right. Great to have someone figure it out for me :). Also, cool to see that they are considering adding a version to the language in C++17. Thought they'd ruled it out. Andrei Alexandrescu has a very nice talk on how static_if is superior to concepts, this is definitely very nice to have.

meetingcpp 11y ago
Its going to be added to the language MAYBE. One of the problems with the first approach was, that it used {}, but did not introduce scope. A serious wtf in any c-like language.
omaranto 11y ago
Do you mean "static_if I Had a Hammer" [1]? [1] https://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Static-If-I-Had-a-Hammer https://channel9.msdn.com/Events/GoingNative/GoingNative-201...
- toth 11y ago
  Yes, that was it. Thanks for finding it.
- dcarp2 11y ago
  There is an update on that at DConf 2015: https://www.youtube.com/watch?v=mCrVYYlFTrA https://www.youtube.com/watch?v=mCrVYYlFTrA
petke 11y ago
I think Herb Sutter and Bjarne Stroustrup where against it. Its like a glorified ifdef. Its too low level a solution. Concepts solves the same problem in a higher level manner. Edit: https://isocpp.org/files/papers/n3613.pdf https://isocpp.org/files/papers/n3613.pdf "In this paper we consider the impact and risks of adopting static if. Some of the problems addressed by the proposed feature are real and urgent, but on balance this proposal this proposal would do much more harm than good. Language features addressing these problems must not negatively affect the language and our ability to build tools around it. We conclude that future development of static if should be abandoned, and that alternatives such as “concepts-lite” approach should be pursued instead."
- toth 11y ago
  Yes, I'd seen that white paper, and thought static_if would never happen in C++. Concepts are nice for some things, but as Alexandrescu argues convincingly in the talk omaranto linked, they become quickly become very unwieldy if you need to consider multiple orthogonal concepts at once in the same place. You get a combinatorial explosion of things you need to name. static_if needs to much nicer and smaller code. The wait paper you link raises some valid concerns, but if it is something you can implement just as a library (as the lightning talk shows) most of them are moot. Note that this library-only version is a somewhat restricted version of static_if, the code in the branches that are not taken is still required to parse, it just is never instantiated. EDIT: looking again at the whitepaper, they were arguing against a specific proposal for static_if. I think this library-only version does not have the same issues. Nice discussion here: http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0128r0.html http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0128r0....
kyberias 11y ago
static_if really sounds crazy and I think Stroustrup's paper nails it down. Hopefully they don't include such idiocy in the language.
SuperV1234 11y ago
Author of the talk here - glad you liked it! Replying to pretty much everyone: what Bjarne and others were strongly against was the first static_if proposal, which was a glorified #ifdef and broke scope rules. The newest constexpr_if proposal does basically what I have shown in my talk (normal scope rules, no unexpected behavior), but with a nicer and cleaner syntax.

hitlin37 11y ago

i attended the conference for the first time this year. very nice and knowledgeable conference, many more talks will be available in coming weeks as they announced in closing notes.

buildops 11y ago

Was a great conference and we had a great time speaking (Parallel Computing strategies by Dori Exterman). Would love to know your feedback.