Impacts de la norme C++11 sur le cours de programmation (SMA+SPH)

Impact détaillé cours par cours

Remarque : la description ci-dessous correspond au cours tel qu'il était à l'époque (2011-2012). Certaines semaines ont maintenant été un peu décalées.

Voir plus bas pour les explications détaillées de chaque aspect.

Ayant un impact

(inpired from C++0x Support in GCC - GNU Project - Free Software Foundation (FSF)).

Sans impact (trop avancé, non abordé) ou mineur

Liens

• C++ Committee
• Lastest public draft (N3242 as of this writing 2011-02-28; last working non-public draft being N3291, dated 5 April 2011)
• B.S.'s opinion on C++0x
• C++0x g++ status
• C++0x compilers status

Commentaires

On changes that do affect the course

Uniform initialization syntax and semantics, Initializer lists:
use it, but don't abuse it!

Use it: en particulier l'initialisation des tableaux dynamiques est
        maintenant simplifiée !
Do not abuse: int i{4}; (déjà possible avant) ne me semble pas des plus clairs
  conceptuellement ni pédagogiquement...

Notice that init lists prevent narrowing, see here.

Attention à la différence :
vector v1(7);          
vector v1{7};

X x{e} est la même chose que X x({e}).
Je préfère présenter {e} comme un ensemble de valeurs.
Recommendation (débutants) : toujours écrire X x({e})
(voir Stroupstroup pour toutes les équivalences (ici et
ici)
  ( "C++ offers several ways of initializing an object depending on its
     type and the initialization context. When misused, the error can be
     surprising and the error messages obscure." )
)

Generalized const expressions (consexpr) :
je ne parle pas des fonctions constantes  : cela présente
à mon avis peu d'intérêt pour les débutants
(utilisation d'un appel dans un cas de constante syntaxique,
 e.g. switch). Me semble vraiment pertinent pour
l'optimisation des constructeur et peut être la surcharge
des opérateurs. Trop subtil pour un premier cours.

Boucles : range for : http://www.stroustrup.com/C++11FAQ.html#for
auto
-> introduire de suite les boucles par itérateurs ??

see also Container improvements @ BS'

Container improvements: ne pas parler de emplace : trop avancé.
La move semantics de push_back suffit pour ce cours.

(implicit) ctor inheritence : recommendation : ne le faire que si pas
de nouveaux attributs !! Sinon : faire appel explicite du Ctor de la
super classe (sinon nouveaux attributs ne seront pas init par using
superclasse::ctr !!)

enum class : TB

deprecated throw-specifications (e.g., throw(), throw( Base, Derived1)).
Added noexcept (minor : ´A non-inline function is the one place a
‘throws nothing’ [i.e., throw()] exception-specification may have some
benefit with some compilers)

Rvalue-ref and move semantic:
(In C++03, non-const references can bind to lvalues, const references to
 lvalues or rvalues, but there is nothing that can bind to a non-const
  rvalue.)

From a casual programmer's perspective, what we get from rvalue
references is more general and better performing libraries.

/!\ Explicitely defaulting a copy ctor like, e.g.,
       A(const& A) = default;
    will REMOVE the default move ctor

    (and same for the other way round,
     and same for operator=)

/!\ *NAMED* rvalue references are treated as lvalues when used
(e.g. X&& x...; f(x) => uses f(const X&), not f(X&&)  !)
==> au niveau débutant : ne pas utiliser explicitement de rvalue ref.
Résumé :
lvalues and lvalue references, both const and non-const, bind to foo(const A&)
const rvalues and const rvalue references                bind to foo(const A&)
named rvalue references                                  bind to foo(const A&)
ONLY non-const rvalues or unnamed rvalue references      bind to foo(A&&)

a non const lvalue reference CAN NOT bind a rvalue reference

move semantics is not useful for classes that do not own ressources
(e.g. contains only PODs), copy construction is already optimal when
copying from rvalues.

move(): 
The most important implication of this is that we can efficiently
return a container from a function

move(x) : attention rend x invalide !!

When explicitely declare f(X&& x) ? (as opposed to f(X const& x) )
  -> when x has to be modified even as a TEMPORARY (otherwise f(X&) is fine enough)
  -> when the use of TEMPORARY can be chained (otherwise f(X const&) is fine enough).
     E.g. compare
           add(Matrix const& x, Matrix const& y)
       with any of these
           add(Matrix&& x, Matrix&& y)
           add(Matrix&& x, Matrix const& y)
           add(Matrix const& x, Matrix&& y)
     In the first case, a NEW matrix (the result a+b) MUST be constructed/allocated.
     In the 3 other cases, an optimization can take place, using
     the place already allocated for the temporary (using e.g. operator+=).
     This is what I call "chaining the use of temporary" (maybe a bad expression)

Advanced tricky notice: what about f(X const&& x) ?

-> this is only usefull if you want to force lvalues, i.e. make sure
   something DOES NOT bind to an rvalue (remember that an rvalue binds
   to a const lvalue reference). Then do
     f(X const&& x) = delete
   so that
     f(X const& x)
   will only get "real" lvalues, not rvalues (as rvalues strongly
   prefer binding to rvalue references and modifiable expressions
   prefer weakly binding to non-const references. Thus even non-const rvalues
   will bind to the deleted prototype)

std::forward_list (instead of list, qui est 2bled linked [en mentionner l'existence])

default init values (In-class member initializers) :
Je ne suis pas sûr de vouloir montrer cela : confusion de concepts,
mais d'un autre coté sont déjà utilisés spontanément par les étudiants
(les moins à l'aise)...
...semble donc intuitif.

On changes that should not affect the course

decltype() : pb de confusion avec decltype(v[0]), decltype((x)) [qui sont des REF !]