New C++ versions

[rockx]

I know this must have been asked before, yet I am asking again. Despite searching google for answers I was not satisfied with what i got

I would like to know what are some of the new features in C++ 11, C++ 14 and C++ 17? I want the information based on the basics of console applications programming; more-so the introduction to C++.

Please avoid the following:
Strongly-typed enums
Pointers
Vectors
Lambdas
STLs
non-member begin() and end()
static_assert and type traits
and/or other dynamic storage.

Another question, prior to C++11, were were coding C++98 or something else?

I am so confused with all these new versions.

[tiliavirga]

I am so confused with all these new versions.

You don't need to know every detail. I'd say knowing the major additions in C++ 11 will take you ahead of most peers. Here's what Stroustrup himself says,

http://www.stroustrup.com/C++11FAQ.html

The previous version was C++ 98 (with an addition called C++ 03).

The standard covers the most basic input/output only but that also means the whole standard is relevant for console applications.

[OReubens]

Please avoid the following:

So you want to know about the most important changes of C++11 if you totally ignore all of the most important changes made to C++11 ?

There's lists in plenty places, simply skip over the parts you're not interested in. But what you're excluding in your OP is about 95% of the changes.

Note that all of those have their uses in console applications as well.

[rockx]

I am mostly concerned about learning the changes in the basic context, more towards the topics for an absolute beginner. somethings like:

Basic Loops: while, do-while, for
Basic Conditions: if-else, swtich-case
Basic Data types: int, long, char, string, float, double,
Basic Arrays: 1D
Basic Streams: I/O and file streams
Basic Structures
and anything else tht I have missed out on

And not on:
Pointers, vectors, Lists, maps, Trees and other intermediate to advanced topics for an absolute beginner.

I stated that those topics to be avoided because the internet searches mostly return results based on it.

[OReubens]

ok, in that case.

No changes have been made to the core language, everything that you did before still works in C++11.
that was one of the main and primary concerns for C+11 afterall:

Maintain stability and compatibility with C++98 and possibly with C
Prefer introduction of new features through the standard library, rather than extending the core language

Some of the wording in the C++ core language changed, but that's mainly just to clean up prior ambiguity, and a need to update the language to the new language constructs (which you don't want to know about).
i.e. changes to "POD types" which are now typically called "trivial types", changes to handle the modified rvalue behaviour, changes to const expressions (which are now a lot more liberal). 'sequence point' was removed from the language definition.


there's a new for-syntax (ranged based for), but you don't have to use it, the old syntax still works as well.
there's a new syntax for functions (which you don't have to use, the old one still works too).


streams are 'STL' which you said to exclude. but nothing really changed on those anyway.

[rockx]

ok, in that case.

No changes have been made to the core language, everything that you did before still works in C++11.
that was one of the main and primary concerns for C+11 afterall:

Is this the same for C++ 14 and upcoming C++ 17?

[tiliavirga]

No changes have been made to the core language, everything that you did before still works in C++11.

To be nit-picky that's not quite true. There are breaking changes in C++ 11 (that will make programs written in the earlier standard fail). They're listed in appendix C.2.

[OReubens]

Considering his OP. I doubt any of them will realistically impact him. But yes... there's a couple breaking changes.

The majority of them will cause a compiler error or if not, they're the result of poor judgement in using macro's, and then you deserve the pain :-)

THe only real problem I'm aware of is the change to dividing negative integers. But again, realistically speaking any code in this issue should already have had adjustments in place because of the 'implementation defined' issue. Any code that didn't, again, you deserve the pain :-).

All the STL related ones, I assume, are irrelevant to him.

[2kaud]

THe only real problem I'm aware of is the change to dividing negative integers. But again, realistically speaking any code in this issue should already have had adjustments in place because of the 'implementation defined' issue. Any code that didn't, again, you deserve the pain

For those of us poor souls who don't have a copy of the c++11 standard for bedtime reading, please would you elaborate on this.

[rockx]

All the STL related ones, I assume, are irrelevant to him.

well for now it is. but i got most of the resources to answer my questions on taht..

another question of mine on the versions:

When i first started to code C++, i remember not using namespace std; and using <iostream.h>, was this C++98?

[OReubens]

When i first started to code C++, i remember not using namespace std; and using <iostream.h>, was this C++98?

headers ending with '.h' are old style headers and either didn't use namespaces, or they included the standard header (<iostream> in this case) and dragged std into global.

If you want to design 'modern C++', don't use these sold style headers.

[OReubens]

For those of us poor souls who don't have a copy of the c++11 standard for bedtime reading, please would you elaborate on this.

In old C++, the result of division (and remainder or modulo) the only guarantee you get is that for any integer a and any non-zero integer b is that:
a == (a/b)*b + (a%b)
is always true.

when either operand is negative the results are "implementation defined" so long as the above remains true. the detail is in how the rounding (or truncation) of a/b happens. It was left 'implementation defined' to accomodate hardware that doesn't work with 2's complement and may be more efficient when handling this one of 2 ways.

the new C++11 behaviour is to round (truncate) the quotient towards zero (where rounding towards negative infinity used to be equally valid).

or given an example:

int a(-5);
int b(3);
int c(a/b);

in C++11 the value of c is guaranteed to be -1 (with a%b being -2), in C++98 c having the value -2 is equally valid (with a%b being 1).
something similar happens when both a and b are negative.

note that in both cases, the aforementioned guarantee on the relation between quotiënt, remainder and operands hold.


Moral of the story...
Avoid signed integers unless your integer value HAS to allow negatives.
unsigneds are guaranteed to be at least as performant as signed integers on all platforms and are faster on some operations. all operations on unsigneds have guaranteed results (except for division by zero) where some operations on signeds are still undefined or implementation defined.

[tiliavirga]

Moral of the story...
Avoid signed integers unless your integer value HAS to allow negatives.

This goes against the advice by Stroustrup in The C++ Programming Language, fourth edition (whole chapter 6.2.1).

In summary it states that the best way to represent an integral number in C++ is by int. It warns against use of unsigned in face of the implicit conversion rules. Instead unsigned is best saved for special needs such as representing a bit array.

In old C++, the result of division ...

This was one of the 35 or so breaking changes in C++ 11. Maybe it has dawned upon you by now that falling into one of these traps can happen to anyone by accident or oversight and that the pain that follows is far from "deserved" as you put it.

I suggest you are more careful in the future before you declare a new C++ version to be free of breaking changes. Besides breaking changes are wellcome. Otherwise a language cannot evolve and maybe most importantly it becomes impossible to ever remove anything.

[OReubens]

I suggest you are more careful in the future before you declare a new C++ version to be free of breaking changes.

I said that taking into account what the OP was is interested in. All of his old code should work and behave as it did before assuming it doesn't use the bits he wasn't interested in. Though there's a couple changes where he might get a compiler error where there previous was none.

On Intel machines, the division has Always worked with the "round towards zero" and there isn't an incentive for a compiler designer to change the outcome of a hardware signed integer divide if the spec allows it. so I'm pretty sure that for all compilers on PC's, even ancient once, the divide will behave as the C++11 spec prescribes. It might work the other way around on other platforms (and I have some where it does).

The pain is "deserved" if you weren't aware of the previously 'implementation defined' behaviour and didn't account for it in some way or another.



As to the unsigned vs (signed) int. he hardly makes a case of it either way just a casual mention that unsigned is better for bitsets and that unsigneds may have issues with implicit conversion rules.

I have my own reasons which are oriented towards performance and predictable behaviour across platforms. If you only consider bitsets, then you're being shortsighted. If signed is so much better/Obvious, then why did they make size_t unsigned? If you mix signed and unsigned integer math, you deserve the pain you're asking for, so the implicit conversion rules typically don't matter unless "you're asking for the hurt".

It also makes more sense to do it 'right'. if a variable can never be negative, why choose a type that allows it to be and then maybe need a ton of tests to verify it isn't accidentally negative anyway.

"use int" is the lazy and easy solution, if you don't care about performance (and on some platforms it's huge) and don't care about predictable behaviour on other platforms (or don't mind figuring out different bits of code for each platform), then sure. it's a "safe" solution to always pick int.

[rockx]

headers ending with '.h' are old style headers and either didn't use namespaces, or they included the standard header (<iostream> in this case) and dragged std into global.

If you want to design 'modern C++', don't use these sold style headers.

I was just thinking of my old days when i started using C++. back then i used to hate Ms C++, i was very dependent on Borland 5.02.

But now i can say I an MS guy.....lol

I now use <iostream> instead of the <iostream.h> and life is so much better.