

C++ braced initializers and type deduction - krsna
http://scottmeyers.blogspot.ca/2014/03/if-braced-initializers-have-no-type-why.html

======
fauigerzigerk
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.

~~~
nhaehnle
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.

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

~~~
jejones3141
And a compiler that only accepts the 10%.

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

~~~
etfb
(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.)

------
roel_v
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.

~~~
stinos
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.

~~~
roel_v
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.

~~~
stinos
_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)

~~~
roel_v
No I realize you're not saying that, I'm afraid that some people will come to
C++ thinking that, that was what I was trying to say.

Visual Studio with Visual Assist is what I'm using - I love it but in the
future the only way to deduce some types is by compiling code, I'm afraid.

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

~~~
pjmlp
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
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
You get to know what is going on by posts from members, like this one

[https://www.ibm.com/developerworks/community/blogs/5894415f-...](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)

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
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
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).

------
peterbotond
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
> 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.

------
72deluxe
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.

