Live data from Hacker News

C++ braced initializers and type deduction

scottmeyers.blogspot.ca

21–30 of 38 posts

Re: C++ braced initializers and type deduction

#21

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…

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 9…

Their should be a guide about how to write modern and unclutered C++ without the 90% of it.

Re: C++ braced initializers and type deduction

#22

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…

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 9…

Your 10% is going to be different to my 10%. Almost all the C++ code I write includes new templates. Almost none of it includes inheritance.

I rarely use smart pointers that aren't implementation details (private class members)

Re: C++ braced initializers and type deduction

#23
post #15

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…

Maybe for programmers that are only used to reading C, pre-C++11 and the likes. On the other hand when you are used to read more dynamic languages where typenames are much less written down literally (say C#/Python/Matlab just to name what comes up in my head), it doesn't make much difference. I'm also not sure if it makes that much of a difference for templates? Those are already quite type-agmostic. E.g. if your template typename is T, there's not much difference in writing `auto x = T()` vs `T x = T()`. Except the (imo) improvement that you are not repeating yourself in the auto case.

Re: C++ braced initializers and type deduction

#24

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…

Part of this is Scott Meyers style. I have nothing against him personally, he just presents a different perspective, which is important, but for me he doesn't really write or talk about C++ in a way that is very useful to me as a C++ programmer.

Several of the techniques he promoted in 'Effective C++' (an old book now, I will concede) are and were, imho, somewhat unhealthy for the sake of being cautious. Another example are his recent talks on "universal references", introduced a whole fuzzy concepts to paper over one simple rule when rvalue references are combined with templates and type deduction.

His 'grunt on the ground' comment is typical of his humour, but he's really a bit of a navel-gazer... I don't think the difference between direct and copy initialization for type deduction of initializer lists is really going to make a difference to most C++ programmers work. The C++ committee generally does a very good job, and the fixes introduced by this change will most likely make a much greater positive impact.

Re: C++ braced initializers and type deduction

#25
post #23
post #15

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…

Maybe for programmers that are only used to reading C, pre-C++11 and the likes. On the other hand when you are used to read more dynamic languages where typenames are much less written down literally (say C#/Python/Matlab just to name what comes up in my head), it doesn't make much difference. I'm also not sure if it makes that much of a difference for templates? Those are already quite type-agmostic. E.g. if your te…

Yes, certainly as you say, which is what concerns me - the notion that types are something that is best buried, by an influx of new users.

And certainly - the case of auto x = T(); is not too bad. It's when the type is determined by template overload, or Koenig lookup, or template traits, that it becomes murky. It will take years for tool to catch up - now when I put my cursor on a variable, it will show me the type in the status bar. For the first few years this will always show 'auto' I'm afraid. In other languages, a collection is a collection (mostly) - in C++ it depends on whether you use a vector, set, hash or list what methods are available. That's quite a difference, from a programming comfort point of view.

Re: C++ braced initializers and type deduction

#26
post #25
post #23

Earlier quoted context omitted.

Maybe for programmers that are only used to reading C, pre-C++11 and the likes. On the other hand when you are used to read more dynamic languages where typenames are much less written down literally (say C#/Python/Matlab just to name what comes up in my head), it doesn't make much difference. I'm also not sure if it makes that much of a difference for templates? Those are already quite type-agmostic. E.g. if your te…

Yes, certainly as you say, which is what concerns me - the notion that types are something that is best buried, by an influx of new users. And certainly - the case of auto x = T(); is not too bad. It's when the type is determined by template overload, or Koenig lookup, or template traits, that it becomes murky. It will take years for tool to catch up - now when I put my cursor on a variable, it will show me the type…

the notion that types are something that is best buried

that was not really my claim though - types should not be buried in C++. Either the context should be clear enough to know what type it is. Or, like for lots of template code, the type simply should not matter. Obviously in those cases auto shines. In other words: if the code is written properly it shouldn't matter if auto is used or not. (and in my experience if all your functions are nice and short, as they should be 99% of the time)

You do have a good point about the tooling though (which tooling is it you use btw? Haven't used anything but VS lately, and it's ok for the way I use it, but I can imagine having to go from clearly seeing all types to not being able to is an awful experience)

Re: C++ braced initializers and type deduction

#28

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…

Ah, I found the inevitable "C++ haters" thread.

Re: C++ braced initializers and type deduction

#29
post #23
post #15

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…

Maybe for programmers that are only used to reading C, pre-C++11 and the likes. On the other hand when you are used to read more dynamic languages where typenames are much less written down literally (say C#/Python/Matlab just to name what comes up in my head), it doesn't make much difference. I'm also not sure if it makes that much of a difference for templates? Those are already quite type-agmostic. E.g. if your te…

auto is a godsend for iterators.

Re: C++ braced initializers and type deduction

#30
post #21

Earlier quoted context omitted.

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 9…

Their should be a guide about how to write modern and unclutered C++ without the 90% of it.

"C++: The Good Parts"
Post reply on HN