"C++14 Is Here: Summary of New Features"

[Lynn McGuire]

"C++14 Is Here: Summary of New Features"
http://www.infoq.com/news/2014/08/cpp14-here-features

"C++14, the new C++ standard succeeding C++11, has been
finally approved and is heading to ISO for publication
this year. While improvements in C++14 are "deliberately
tiny" compared to C++11, says C++ creator Bjarne
Stroustrup, they still "add significant convenience for
users" and are a step on the route to make C++ "more
novice friendly.""

Looks like C++ is trending more verbose to me.

Lynn

[Melzzzzz]

Example?

>
> Lynn
>



--
Click OK to continue...

[Chris Vine]

On Tue, 26 Aug 2014 16:09:04 -0500
Lynn McGuire <l...@winsim.com> wrote:

[snip]

> Looks like C++ is trending more verbose to me.
>
> Lynn

Well, I guess we can all enjoy a good troll.

Language "trending" is a slightly odd way of putting it, but taking the
word at its face value and having used C++11 quite a bit now, I would
say that C++11 definitely encourages the writing of simpler code than
C++98, and so is "trending" less verbose than C++98. I would be very
surprised if C++14 wasn't moving in the same direction.

Chris

[Lynn McGuire]

The first trend that increased the verbosity of C++
code for me was the addition of namespaces to the
standard libraries. We gave up adding std:: all
over the place and just added a "using namespace std;"
to our global include. We were porting to C++ from
Smalltalk in 2003 and the std:: just about broke the
port for us.

I just see a lot of new keywords coming in and little
new functionality. Of course, we are still using
Visual Studio 2005 and have no opportunity to try out
all of the new items in our code base.

Lynn

[Victor Bazarov]

Oh, so adding new keywords means more verbosity? And you haven't had a
chance to try anything yet? In my book it's called "prejudice". Stop
trolling, get yourself a modern compiler and study the new stuff
seriously (instead of just skimming over somebody else's articles).

"- Caruso? I don't like the voice...
- Where did you hear him? Perhaps it was a bad recording?
- Nah. Johnny sang me a couple o'tunes."

V
--
I do not respond to top-posted replies, please don't ask

[Jorgen Grahn]

On Wed, 2014-08-27, Lynn McGuire wrote:
> On 8/27/2014 6:28 AM, Chris Vine wrote:
>> On Tue, 26 Aug 2014 16:09:04 -0500
>> Lynn McGuire <l...@winsim.com> wrote:
>> [snip]
>>> Looks like C++ is trending more verbose to me.
>>>
>>> Lynn
>>
>> Well, I guess we can all enjoy a good troll.
>>
>> Language "trending" is a slightly odd way of putting it, but taking the
>> word at its face value and having used C++11 quite a bit now, I would
>> say that C++11 definitely encourages the writing of simpler code than
>> C++98, and so is "trending" less verbose than C++98. I would be very
>> surprised if C++14 wasn't moving in the same direction.
>>
>> Chris
>
> The first trend that increased the verbosity of C++
> code for me was the addition of namespaces to the
> standard libraries. We gave up adding std:: all
> over the place and just added a "using namespace std;"
> to our global include. We were porting to C++ from
> Smalltalk in 2003 and the std:: just about broke the
> port for us.

Unless the compiler/standard library was broken WRT namespace std
(like at least gcc was a few years before that) I find that hard to
believe.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Lynn McGuire]

We moved from Visual Studio 2003 to Visual Studio 2005
in the middle of the port to solve other problems in
the STL. Visual Studio 2005 required the std:: on all
the standard library functions. I hated and still hate
the "using namespace std;" but it sure did save our
bacon for a half million lines of C++ code. One of
these days, I am going to get an intern to add that
std:: all over the place and get rid of the
"using namespace std;".

Lynn

[Jorgen Grahn]

On Wed, 2014-08-27, Lynn McGuire wrote:
> On 8/27/2014 2:44 PM, Jorgen Grahn wrote:
>> On Wed, 2014-08-27, Lynn McGuire wrote:

...

>>> The first trend that increased the verbosity of C++
>>> code for me was the addition of namespaces to the
>>> standard libraries. We gave up adding std:: all
>>> over the place and just added a "using namespace std;"
>>> to our global include. We were porting to C++ from
>>> Smalltalk in 2003 and the std:: just about broke the
>>> port for us.
>>
>> Unless the compiler/standard library was broken WRT namespace std
>> (like at least gcc was a few years before that) I find that hard to
>> believe.
>>
>> /Jorgen
>
> We moved from Visual Studio 2003 to Visual Studio 2005
> in the middle of the port to solve other problems in
> the STL. Visual Studio 2005 required the std:: on all
> the standard library functions. I hated and still hate
> the "using namespace std;" but it sure did save our
> bacon for a half million lines of C++ code. One of
> these days, I am going to get an intern to add that
> std:: all over the place and get rid of the
> "using namespace std;".

Yeah, that was the use case for 'using namespace std'. And yes, when
it has saved you, you're still left with the problem to get rid of it
(if it's worth it).

[Juha Nieminen]

Lynn McGuire <l...@winsim.com> wrote:
> Looks like C++ is trending more verbose to me.

I think you are delusional. Most of the features added since C++11 have
helped make the code *less* verbose. Range-based for, the 'auto' keyword,
lambdas, variadic templates...

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Lynn McGuire]

On 8/28/2014 2:45 AM, Juha Nieminen wrote:
> Lynn McGuire <l...@winsim.com> wrote:
>> Looks like C++ is trending more verbose to me.
>
> I think you are delusional. Most of the features added since C++11 have
> helped make the code *less* verbose. Range-based for, the 'auto' keyword,
> lambdas, variadic templates...

Ok, I do not understand the personal attack here.

If you disagree with me, just state so. However,
a personal attack is a sign of a person who cannot
make a logical statement. I tend to ignore
anything else past the personal attack on anyone.

Lynn

[Lynn McGuire]

Namespaces, nullptr, a few other items. I must admit
that I do not understand the purpose of lambdas yet.

Nor the purpose of the auto keyword. I moved to C++
from Smalltalk for the strict typing (and 100X
execution speed).

Thanks,
Lynn

[Victor Bazarov]

On 8/28/2014 2:09 PM, Lynn McGuire wrote:
> On 8/28/2014 2:45 AM, Juha Nieminen wrote:
>> Lynn McGuire <l...@winsim.com> wrote:
>>> Looks like C++ is trending more verbose to me.
>>
>> I think you are delusional. Most of the features added since C++11 have
>> helped make the code *less* verbose. Range-based for, the 'auto' keyword,
>> lambdas, variadic templates...
>
> Ok, I do not understand the personal attack here.

<< delusional (comparative more delusional, superlative most delusional)
1. Suffering from or characterized by delusions >>

<< delusion
...
b : a persistent false psychotic belief regarding the self or persons
or objects outside the self that is maintained despite indisputable
evidence to the contrary; also : the abnormal state marked by such
beliefs >>

There is no personal attack. Juha says that *he thinks* you're
suffering from a delusion. If anything, it's a statement of fact. You
may or may not be delusional. However, it cannot be disputed that Juha
is free to *think so* and express his thinking so.

> If you disagree with me, just state so. However,
> a personal attack is a sign of a person who cannot
> make a logical statement. I tend to ignore
> anything else past the personal attack on anyone.

You're free to do as you wish AFA ignoring anything goes. If instead of
arguing the technical side of things (i.e. countering his statements
about range-based for, etc.) you turn to arguing aspects of perceived
conduct of the other side ("personal attack"), it is *you* who cannot
make a logical statement.

Ignore the "personal attack" rather than "anything else past" it. Try
it, and you will see the difference.

[Victor Bazarov]

On 8/28/2014 2:15 PM, Lynn McGuire wrote:
> On 8/26/2014 4:36 PM, Melzzzzz wrote:
>> On Tue, 26 Aug 2014 16:09:04 -0500
>> Lynn McGuire <l...@winsim.com> wrote:
>>
>>> "C++14 Is Here: Summary of New Features"
>>> http://www.infoq.com/news/2014/08/cpp14-here-features
>>>
>>> "C++14, the new C++ standard succeeding C++11, has been
>>> finally approved and is heading to ISO for publication
>>> this year. While improvements in C++14 are "deliberately
>>> tiny" compared to C++11, says C++ creator Bjarne
>>> Stroustrup, they still "add significant convenience for
>>> users" and are a step on the route to make C++ "more
>>> novice friendly.""
>>>
>>> Looks like C++ is trending more verbose to me.
>>
>> Example?
>
> Namespaces, nullptr, a few other items. I must admit
> that I do not understand the purpose of lambdas yet.

Except 'std' namespace (that has been around for more than a decade and
a half now), nobody forces you to use 'nullptr' or lambdas. The
language as you know it has not really gone anywhere. New things in it
are for those who are able to use them.

> Nor the purpose of the auto keyword. I moved to C++
> from Smalltalk for the strict typing (and 100X
> execution speed).

So, writing "nullptr" instead of "NULL" is more verbose, and the rest is
what you don't understand (lambdas, 'auto')? And you base your
conclusions about the language *trends* on namespaces (that aren't
actually new) and a keyword? <shudders>

[Lynn McGuire]

BTW, please do not get me wrong. I like the concept
of namespaces very much even though they add to the
verbosity of the code. Namespaces solve a very
serious problem that I have run into at least once.

But the using command is imprecise. And dangerous
for a large program like ours. So, it needs to go
out of our code. Someday. Probably when the sun
is halfway through its long cool down.

Thanks,
Lynn

[David Harmon]

On Thu, 28 Aug 2014 14:57:18 -0500 in comp.lang.c++, Lynn McGuire
<l...@winsim.com> wrote,

>But the using command is imprecise. And dangerous

You can always choose the more specific using directive if you prefer.

using std::cout;

[David Brown]

"auto" does not change the strong typing of C++, it just adds type
inference. Everything still has its specific type, and the type does
not change - you just don't have to write out the type explicitly if the
compiler already knows what it has to be.

[Ian Collins]

In addition "auto", especially when coupled with the range-for
statement, helps to significantly reduce code verbosity.

--
Ian Collins

[Alain Ketterlin]

Lynn McGuire <l...@winsim.com> writes:

> [...] I must admit that I do not understand the purpose of lambdas
> yet. [...] I moved to C++ from Smalltalk

Smalltalk blocks and C++ lambdas are really similar concepts, all
originating in what is usually called a closure. C++ lambdas have some
peculiarities due to the way memory is used, but you will get the idea
if you remember ST blocks.

-- Alain.

[Jorgen Grahn]

On Fri, 2014-08-29, Ian Collins wrote:
> David Brown wrote:
...

>> "auto" does not change the strong typing of C++, it just adds type
>> inference. Everything still has its specific type, and the type does
>> not change - you just don't have to write out the type explicitly if the
>> compiler already knows what it has to be.
>
> In addition "auto", especially when coupled with the range-for
> statement, helps to significantly reduce code verbosity.

Does anyone have any stories about overuse yet, though?

C++11 is theoretical to me so far: been reading about it off an on,
and considering rewriting some code. I can see myself using range-for,
while still specifying the element type. In that case, supplying the
type doesn't seem to increase verbosity much: the worst part was

std::vector<std::string>::const_iterator

and range-for itself would eliminate that.

I have used trye type inference in the past (Standard ML), but my gut
feeling says you can have too many 'auto' in a C++ program.

[Öö Tiib]

Certainly we can have too many auto. Usual recommendation is to use
'auto' only when type is "clear enough" for the context. However that
is so subjective what is clear enough. The well-known C++ book authors
discuss and answer that question:
http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Scott-Andrei-and-Herb-Ask-Us-Anything#time=25m03s

Related issue is that some people tend to use too many 'auto&&'. It
should be only used when it is clear to what we get that reference.

Flexibility of 'auto' is bit bigger than just avoiding writing (or
repeating) too much type names and that causes other confusions
sometimes. For example we can create variables of inaccessible
(private in other class) type name with it. It is legal, but
confusing to some and it is not too easy to back-port that to
C++03.

[SG]

On Friday, August 29, 2014 4:58:02 AM UTC+2, David Harmon wrote:

> On Thu, 28 Aug 2014 14:57:18 -0500 in comp.lang.c++, Lynn McGuire wrote:
> > But the using command is imprecise. And dangerous

I guess you meant "using directive" (using namespace soandso).
the using directive is more of a tool to make the transition
from a non-namespace-aware codebase to a namespace-aware
codebase easier.

> You can always choose the more specific using directive if you prefer.
>
> using std::cout;

AFAIK this is called a "using declaration".

[rsteele]

I agree with the statement that more keywords does not necessarily imply a more verbose language. I would think that the addition of keywords to the language would be to reduce the code necessary to accomplish a task, making the language appear less verbose. I think that adding targeted functionality is what ISO C++ is all about.

[Vir Campestris]

On 27/08/2014 20:19, Lynn McGuire wrote:
> Of course, we are still using
> Visual Studio 2005

Why?

Do MS even still support it?

Andy

[Lynn McGuire]

Because we still have customers running Windows
2000. We could probably move to VS 2008 but just
do not have the time right now.

Nope, other than make it available for download
on the MSDN site.

Lynn

[Vir Campestris]

On 03/09/2014 23:48, Lynn McGuire wrote:
> Because we still have customers running Windows
> 2000. We could probably move to VS 2008 but just
> do not have the time right now.

I do hope they're nowhere near the Internet.

IIRC when we moved from 2005 to 2008 we got a number of compilation
errors. Most of them were just the new compiler being fussy - but a
couple were where we were doing something wrong. Might be worth making
it compile - when you have the time of course...

Andy

[glen stark]

On Sat, 30 Aug 2014 04:36:48 +0000, Jorgen Grahn wrote:

> On Fri, 2014-08-29, Ian Collins wrote:
>> David Brown wrote:
> ...
>>> "auto" does not change the strong typing of C++, it just adds type
>>> inference. Everything still has its specific type, and the type does
>>> not change - you just don't have to write out the type explicitly if
>>> the compiler already knows what it has to be.
>>
>> In addition "auto", especially when coupled with the range-for
>> statement, helps to significantly reduce code verbosity.
>
> Does anyone have any stories about overuse yet, though?
>

I don't have a good snippet to show you, but I worked on a codeset where
I thought "way too much use of auto". Essentially the coder had used
auto as a tool to save typing.

I think the general rule should be: use auto to make code more readable,
not more writeable. Following that rule should get you good results.

[Wouter van Ooijen]

>
> I don't have a good snippet to show you, but I worked on a codeset where
> I thought "way too much use of auto". Essentially the coder had used
> auto as a tool to save typing.
>
> I think the general rule should be: use auto to make code more readable,
> not more writeable. Following that rule should get you good results.
>

IMO that is actually the second law of software engineering!

(The first one being 'conform to your requirements'.)

Wouter van Ooijen

[Victor Bazarov]

On 9/5/2014 8:04 AM, glen stark wrote:
>[..]

> I think the general rule should be: use auto to make code more readable,
> not more writeable. Following that rule should get you good results.

^^^^^^^^^^^^^^^^^^
I think what you meant to say is "not less readable". And I think that
is what you ought to have said. "More writeable" makes no sense. Code
cannot be "made more writable" once it's been written. And before it's
written, it's not code yet.

[Wouter van Ooijen]

Victor Bazarov schreef op 05-Sep-14 3:07 PM:> On 9/5/2014 8:04 AM, glen

stark wrote:
>> [..]
>> I think the general rule should be: use auto to make code more
readable,
>> not more writeable. Following that rule should get you good results.
> ^^^^^^^^^^^^^^^^^^
> I think what you meant to say is "not less readable". And I think that
> is what you ought to have said. "More writeable" makes no sense. Code
> cannot be "made more writable" once it's been written. And before it's
> written, it's not code yet.

But you can achieve the same functionality with different code. Some of
that will be easier to write, some will be easier to read. What Glen
stated is that "easier to read" is a better way to choose among the
alternatives than "easier to write".

Wouter van Ooijen

[Victor Bazarov]

I think my objection is with the choice of words. "Make code easier to
read" is OK, "make code more difficult to read" is OK (as far as choice
of words goes), "make code easier to write" is nonsense when used as
*the opposite* of "make code easier to read."

The keyword "auto" allows for easier writing of the code. Always. It's
one of the purposes of that keyword. Does it allow for easier reading
of the code? I don't know, depends on whom you ask. But I am not
arguing about that either.

"Use <some language feature> to make code more readable, not more
writable" is bullshit, no matter how nice it might sound. I am against
those bullshit slogans. "Work smarter, not harder" - similar bullshit.

That's all.

[Lynn McGuire]

I have not verified that they are still running Windows
2000 lately. They may have moved to XP or 2003 Server by
now <grin>.

All of the compile errors that I got on my FreeBSD box
turned out to be just warnings when we upgraded to version
7. But, lots and lots of warnings obscure any real
problems. We've got the must upgrade "char *" to
"const char *" warnings all over the place, thousands of
them in our old C code that was converted to C++ more than
a decade ago.

Lynn

[Christopher Pisz]

Personally I don't like it much, but I understand the language isn't
being written for my personal preferences. It makes it harder for me to
track down what is going on when reading other people's code, similar to
when they typedef a container and typedef a container of containers,
etc. It's one more right click->find definition that I have to perform.

I'd rather be everyone write out

for(std::vector<std::map<int, std::string> >::const_iterator it =
m_something.begin(); it != something.end(); ++it)

because then I know exactly what I am dealing with as soon as I see it.
Maybe I am becoming one of the old man coders I used to complain about,
I'm not sure.

[Ian Collins]

Don't forget we can now write "std::vector<std::map<int, std::string>>" :)

> because then I know exactly what I am dealing with as soon as I see it.
> Maybe I am becoming one of the old man coders I used to complain about,
> I'm not sure.

Maybe you are thinking at too low a level too quickly? I find that more
often than not the exact type of something is a distraction when reading
and and understanding code flow. If I want to modify the code, then
I'll dig into the lower level details.

I few shortcuts like auto or typedefs in a similar vein to using CSS in
web development rather than embedding style information in tags.

--
Ian Collins

[Öö Tiib]

However (you might know but) there are rather lot of developers
who do not know that 'std::string' is actually typedef of that
'std::basic_string<char, std::char_traits<char>, std::allocator<char> >'
... or what was it. It does not matter on general case. So authors
of standard library (IMHO wisely) decided to use typedef here as
soft form of encapsulation.

> because then I know exactly what I am dealing with as soon as I see it.
> Maybe I am becoming one of the old man coders I used to complain about,
> I'm not sure.

'typedef' like 'auto' is exactly for to reduce information that should
not matter on abstraction level used or that should be is known clearly
enough locally. The irrelevant details of type may make code close to
unreadable with class templates that have lot of parameters and flexibility
like 'boost::adjacency_list' or 'boost::multi_index_container'.

[Lynn McGuire]

> However (you might know but) there are rather lot of developers
> who do not know that 'std::string' is actually typedef of that
> 'std::basic_string<char, std::char_traits<char>, std::allocator<char> >'
> ... or what was it. It does not matter on general case. So authors
> of standard library (IMHO wisely) decided to use typedef here as
> soft form of encapsulation.

I did not know that!

Thanks,
Lynn

[J. Clarke]

In article <lucgdl$9dn$1...@dont-email.me>, v.ba...@comcast.invalid
says...

It's amazing how resistant management can be to any suggestion of a
means of actually working smarter.

[Victor Bazarov]

I know nothing about that. My objection to that phrase is due to the
fact that working harder is *opposed* to working smarter (or vice
versa). Slackers invented those slogans, and slackers keep pushing
them. I say, instead of inventing slogans work both harder *and* smarter.

[Wouter van Ooijen]

> I know nothing about that. My objection to that phrase is due to the
> fact that working harder is *opposed* to working smarter (or vice
> versa). Slackers invented those slogans, and slackers keep pushing
> them. I say, instead of inventing slogans work both harder *and* smarter.

I try to teach my students to work smarter and less harder, and still
achieve the same effect. Somehow that lands better than working smarter
and harder :)

Wouter

[Öö Tiib]

Depends what guru you are and who are your listeners. ;)

1) Lot of software is barely passable; it is made by masses of dumb or
lazy or both tied together by tight process. India has built its whole
booming software industry on making those things. Your sentence is
golden truth there.
2) When engineer is working both harder and smarter then it results
with bit better than passable product. Most outstanding carrier of
that ideology is Apple and your sentence is lie there.

So it all depends ... what market you prepare participants for? :D

[woodb...@gmail.com]

I prefer your school but admit I'm lazy.

"Unless the L-rd builds the house, they labor in vain who build it;
Unless the L-rd guards the city, the watchman waketh but in vain.
It is vain for you to rise up early, to retire late, to eat the
bread of painful labors; for He gives to His beloved even in his sleep."

Psalms 127:1,2


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Victor Bazarov]

Two thoughts.

First, "still achieve the same effect": as what? Working harder and
dumber? How about achieve superior heights by working both harder and
smarter? Ever tried teaching them that?

Second, "lands better": with slackers it's always that way. How many of
your students are actually hard workers? I venture a guess that not so
many. Five per cent, ten, maybe, if you're lucky. I was a student. I
remember how much effort I personally expended and I knew how much my
fellow students worked. I've been a teacher, too. They don't see being
a student as hard work. They don't realize what it means to stay
competitive on the market nowadays. Hell, I didn't myself, until I
started working for an actual commercial company (and not a college or a
state-funded academical institution).

Don't take it the wrong way, please. If you only aim to teach them what
"lands better", they aren't leaning anything. You simply reaffirm in
their minds the stereotypes they already developed from years of
pampering before coming to college. Instead of giving them what "lands
better", maybe try to break it to them gradually that they will need to
change their attitudes and start pushing themselves.

Or not.

[glen stark]

>
> I think my objection is with the choice of words. "Make code easier to
> read" is OK, "make code more difficult to read" is OK (as far as choice
> of words goes), "make code easier to write" is nonsense when used as
> *the opposite* of "make code easier to read."
>
> The keyword "auto" allows for easier writing of the code. Always. It's
> one of the purposes of that keyword. Does it allow for easier reading
> of the code? I don't know, depends on whom you ask. But I am not
> arguing about that either.

It may be my wording could be better, I'll put some thought into it.
What I wanted to convey was that it's possible to imagine a case where
auto saves you some effort typing, but makes the code less readable.
This is a bad usage of auto. On the other hand, it may make the code
more readable, an obvious example being using auto declare an iterator.
This is good usage of auto.

[J. Clarke]

In article <18027e5b-7d91-4bc0...@googlegroups.com>,
oot...@hot.ee says...

But working hard and smart may often be percieved by those who do not
understand "working smart" as slacking off. Like when you recgonize
that you have gone stale on a problem and need to do something else to
take your mind off of it for a while so you can come back with fresh
insights.