What Are the Differences Between -Std=C++11 and -Std=Gnu++11

What are the difference between * and & for objects in c++

A very big difference between pointers(*) and references(&) in nearly every situation is that a pointer is an indepedent variable and can be assigned NEW address values; whereas a reference, once assigned, can never refer to any new object until the variable goes out of scope.
Moreover a pointer can be of a null value, and a reference dosen't.

Is there a difference between these ways of initialising a C array in C++?

Is there a difference between these ways of initialising a C array in C++?

No. They're semantically equivalent.

zero initialisation, as opposed to default initialisation, but so too is int list[4]{0}, isn't it?

The first element is copy-initialized with zero. The rest of the elements are value initialized, which for int is indeed zero initialization. There is no effectual difference in value, zero and copy initialization with zero specifically in the case of int specifically. The distinction is syntactical in that case.

Does this involve an std::initializer_list behind the scenes or not?

std::initializer_list is not involved.

Difference in c_str function specification between C++03 and C++11

Except for the range increment by one element since C++11, there is still a big difference between:

data()[i] == operator[](i)

and:

data() + i == &operator[](i)

That main difference is the & operator in the prototypes.

The old prototype, allowed for copy to be made when a write operation would occur, since the pointer returned could point to another buffer than the one holding the original string.

The other difference in the prototypes between data()[i] and data() + i, is not critical, since they are equivalent.

---

A difference between C++ and C++11 is that in the former, an std::string was not specified explicitly by the standard for whether it would have a null terminator or not. In the latter however, this is specified.

In other words: Will std::string always be null-terminated in C++11? Yes.

What is the difference between '/' and '//' when used for division?

In Python 3.x, 5 / 2 will return 2.5 and 5 // 2 will return 2. The former is floating point division, and the latter is floor division, sometimes also called integer division.

In Python 2.2 or later in the 2.x line, there is no difference for integers unless you perform a from __future__ import division, which causes Python 2.x to adopt the 3.x behavior.

Regardless of the future import, 5.0 // 2 will return 2.0 since that's the floor division result of the operation.

You can find a detailed description at PEP 238: Changing the Division Operator.

What changes introduced in C++14 can potentially break a program written in C++11?

<sup>Note: In this post I consider a "breaking change" to be either, or both, of;

1. a change that will make legal C++11 ill-formed when compiled as C++14, and;

2. a change that will change the runtime behavior when compiled as C++14, vs C++11.</sup>

---

C++11 vs C++14, what does the Standard say?

The Standard draft (n3797) has a section dedicated for just this kind of information, where it describes the (potentially breaking) differences between one revision of the standard, and another.

This post has used that section, [diff.cpp11], as a base for a semi-elaborate discussion regarding the changes that could affect code written for C++11, but compiled as C++14.

---

C.3.1] Digit Separators

The digit separator was introduced so that one could, in a more readable manner, write numeric literals and split them up in a way that is more natural way.

int x = 10000000;   // (1)
int y = 10'000'000; // (2), C++14

^{It's easy to see that (2) is much easier to read than (1) in the above snippet, while both initializers have the same value.}

The potential issue regarding this feature is that the single-quote always denoted the start/end of a character-literal in C++11, but in C++14 a single-quote can either be surrounding a character-literal, or used in the previously shown manner (2).

Example Snippet, legal in both C++11 and C++14, but with different behavior.

#define M(x, ...) __VA_ARGS__

int a[] = { M(1'2, 3'4, 5) };

// int a[] = { 5 };        <-- C++11
// int a[] = { 3'4, 5 };   <-- C++14
//                              ^-- semantically equivalent to `{ 34, 5 }`

( Note: More information regarding single-quotes as digit separators can be found in n3781.pdf )

---

C.3.2] Sized Deallocation

C++14 introduces the opportunity to declare a global overload of operator delete suitable for sized deallocation, something which wasn't possible in C++11.

However, the Standard also mandates that a developer cannot declare just one of the two related functions below, it must declare either none, or both; which is stated in [new.delete.single]p11.

void operator delete (void*) noexcept;
void operator delete (void*, std::size_t) noexcept; // sized deallocation

Further information regarding the potential problem:

Existing programs that redefine the global unsized version do not also
define the sized version. When an implementation introduces a sized
version, the replacement would be incomplete and it is likely that
programs would call the implementation-provided sized deallocator on
objects allocated with the programmer-provided allocator.

^{Note: Quote taken from n3536 - C++ Sized Deallocation}

( Note: More of interest is available in the paper titled n3536 - C++ Sized Deallocation, written by Lawrence Crowl )

---

C.3.3] constexpr member-functions, no longer implicitly const

There are many changes to constexpr in C++14, but the only change that will change semantics between C++11, and C++14 is the constantness of a member-function marked as constexpr.

The rationale behind this change is to allow constexpr member-functions to mutate the object to which they belong, something which is allowed due to the relaxation of constexpr.

struct A { constexpr int func (); };

// struct A { constexpr int func () const; }; <-- C++11
// struct A { constexpr int func ();       }; <-- C++14

Recommended material on this change, and why it is important enough to introduce potential code-breakage:

• Andrzej's C++ blog - “constexpr” function is not “const”
• open-std.org - constexpr member functions and implicit const
• (open-std.org - Relaxing constraints on constexpr functions)

Example snippet, legal in both C++11 and C++14, but with different behavior

struct Obj {
  constexpr int func (int) {
    return 1;
  }

  constexpr int func (float) const {
    return 2;
  }
};

Obj const a = {}; 
int const x = a.func (123);

// int const x = 1;   <-- C++11
// int const x = 2;   <-- C++14

---

C.3.4] Removal of std::gets

std::gets has been removed from the Standard Library because it is considered dangerous.

The implications of this is of course that trying to compile code written for C++11, in C++14, where such a function is used will most likely just fail to compile.

( Note: there are ways of writing code that doesn't fail to compile, and have different behavior, that depends on the removal of std::gets from the Standard Library )

Is there a meaningful difference between running .class or .java?

In Java 11, it is now possible to run 'java <source_file>' mostly as a way to help gain familiarity with the language: https://openjdk.java.net/jeps/330

Behind the scenes it is first compiling the source file then running the compiled class. For simpler use cases (ex: 1 file java program, with no dependencies) the behavior is likely to be the same, but it is worth noting that this is not meant as a replacement of 'compile then execute' in general.

---

Related Topics