Les innovations de C++26 : comment les derni�res am�liorations vont transformer le d�veloppement en C++,
dans un contexte o� plusieurs entit�s recommandent de remplacer C++ par des alternatives
Le langage de programmation C++ continue d'�voluer avec l'introduction de nouvelles fonctionnalit�s et am�liorations. La version C++26, bien que toujours en cours de d�veloppement, apporte d�j� plusieurs nouveaut�s : sp�cifier une raison pour la suppression d'une fonction, variables de remplacement sans nom, d�claration d'une liaison structur�e en tant que condition. Mais certains encouragent plut�t le passage � Rust ou Carbon, pourquoi ?
Sp�cifier une raison pour la suppression d'une fonction
Depuis le C++11, il est possible de d�clarer une fonction comme supprim�e, afin que le compilateur emp�che son utilisation. Cela peut �tre utilis� pour emp�cher l'utilisation de fonctions membres sp�ciales d'une classe, mais aussi pour supprimer toute autre fonction.
Introduits en C++11, = default et = delete ont rejoint = 0 en tant que sp�cification alternative possible pour le corps d'une fonction, au lieu d'un corps d'instructions ordinaire entour� d'accolades. La motivation initiale de la d�claration de fonction supprim�e via = delete est de remplacer (et d'annuler) la pratique courante de l'�re C++98/03 consistant � d�clarer les fonctions membres sp�ciales comme priv�es et � ne pas les d�finir afin de d�sactiver leur g�n�ration automatique. Cependant, l'ajout de = delete a acquis un pouvoir encore plus grand, car il peut �tre utilis� pour n'importe quelle fonction, et pas seulement pour les membres sp�ciaux.
Aujourd'hui, dix ans apr�s l'introduction des fonctions supprim�es, nous pouvons conclure en toute confiance que = delete est devenu l'une des fonctionnalit�s cl�s de C++11 qui a grandement am�lior� l'exp�rience des utilisateurs en cas d'erreurs dans l'utilisation des fonctions de la biblioth�que et a �t� une r�ussite de la r�volution du � C++ moderne �.
Il y a plusieurs raisons pour lesquelles les fonctions supprim�es ont �t� pr�f�r� aux fonctions traditionnelles priv�es mais non d�finies, notamment une meilleure s�mantique (friend et les autres membres sont toujours inaccessibles, ce qui transforme une erreur de l'�diteur de liens en une erreur � la compilation), de meilleurs diagnostics (au lieu d'erreurs cryptiques � fonction inaccessible �, l'utilisateur sait directement que la fonction est supprim�e) et une plus grande puissance (pas seulement pour les SMF).
Au lieu d'une erreur d�j� plus conviviale mais toujours un peu �nigmatique � calling deleted function �, les �diteurs veulent permettre directement aux auteurs de biblioth�ques de pr�senter un message suppl�mentaire facultatif qui devrait �tre inclus dans le message d'erreur, de sorte que l'utilisateur connaisse le raisonnement exact de la raison pour laquelle la fonction est supprim�e, et dans certains cas, vers quel remplacement l'utilisateur devrait se diriger � la place.
Une fonction peut �tre supprim�e comme suit (exemple tir� du document de proposition) :
1
2
3
4
5
6
7
8
9
10
| class NonCopyable
{
public:
// ...
NonCopyable() = default;
// les membres de la copie
NonCopyable(const NonCopyable&) = delete;
NonCopyable& operator=(const NonCopyable&) = delete;
}; |
En C++26, vous pouvez sp�cifier la raison pour laquelle cette fonction est supprim�e :
1
2
3
4
5
6
| class NonCopyable {
public:
NonCopyable() = default;
NonCopyable(const NonCopyable&) = delete("Cette classe gère des ressources uniques, la copie n'est pas supportée; utilisez le déplacement à la place.");
NonCopyable& operator=(const NonCopyable&) = delete("Cette classe gère des ressources uniques, la copie n'est pas supportée; utilisez le déplacement à la place.");
}; |
Variables de remplacement sans nom
Il existe des cas o� une variable doit �tre d�clar�e sans que son nom soit utilis�, comme dans les liaisons de structure ou les verrous (lock_guard). C++26 introduit la possibilit� d�utiliser un seul trait de soulignement (_) pour d�finir une variable sans nom.
Par exemple, dans l'exemple suivant, unused est une variable qui n'est pas utilis�e :
[[maybe_unused]] auto [data, unused] = get_data();
En C++26, la variable unused peut �tre nomm�e _ (simple trait de soulignement) :
auto [data, _] = get_data();
Lorsque l'identificateur de soulignement unique est utilis� pour la d�claration d'une variable, d'une variable membre de classe non statique, d'une capture lambda ou d'une liaison de structure, l'attribut [[maybe_unused]] est implicitement ajout�, il n'est donc pas n�cessaire de l'utiliser explicitement.
Une d�claration portant le nom _ est dite ind�pendante du nom si elle d�clare :
- une variable avec une dur�e de stockage automatique
- une liaison de structure, mais pas dans un espace de noms
- une variable introduite par une capture init
- un membre de donn�es non statique
Le compilateur n'�met pas d'avertissement quant � l'utilisation ou non d'une d�claration ind�pendante du nom. De plus, plusieurs d�clarations ind�pendantes du nom peuvent �tre utilis�es dans la m�me port�e (qui n'est pas une port�e d'espace de noms) :
1
2
3
4
5
6
7
| int main()
{
int _;
_ = 0; // OK
std::string _; // OK, parce que _ est une déclaration indépendante du nom
_ = "0"; // Erreur : référence ambiguë au caractère générique « _ », qui est défini plusieurs fois.
} |
En revanche, ce qui suit n'est pas possible :
1
2
3
4
5
6
| int main()
{
int _;
_ = 0; // OK
static std::string _; // Erreur : les variables statiques ne sont pas indépendantes du nom
} |
L'op�ration suivante n'est pas non plus possible, car les d�clarations se trouvent dans un espace de noms :
1
2
3
4
5
6
| namespace n
{
int f() {return 42;}
auto _ = f(); // OK
auto _ = f(); // Erreur : redéfinition de _
} |
D�claration d'une liaison structur�e en tant que condition
Une liaison de structure d�finit un ensemble de variables li�es � des sous-objets ou � des �l�ments de leur initialisateur.
auto [position, length] = get_next_token(text, offset);
Une liaison de structure peut appara�tre dans une d�claration for-range, comme dans l'exemple suivant :
1
2
3
4
| for (auto [position, length] : tokenize(text, offset))
{
std::println("pos {}, len {}", position, length);
} |
En revanche, les variables peuvent appara�tre dans la condition d'une instruction if, while ou for :
1
2
3
4
| if (auto it = std::find_if(begin(arr), end(arr), is_even); it != std::end(arr))
{
std::println("{} est le premier nombre pair", *it);
} |
Cependant, les liaisons de structure ne peuvent pas �tre d�clar�es dans la condition d'une instruction if, while ou for. Cela change en C++26, ce qui rend la chose possible :
1
2
3
4
| if(auto [position, length] = get_next_token(text, offset); position >= 0)
{
std::println("pos {}, len {}", position, length);
} |
Un cas int�ressant et tr�s utile est pr�sent� dans le document de proposition (P0963). Consid�rons l'exemple C++26 suivant pour l'utilisation de std::to_chars :
1
2
3
4
5
6
7
8
9
10
| if (auto result = std::to_chars(p, last, 42))
{
auto [ptr, _] = result;
// ok pour continuer
}
else
{
auto [ptr, ec] = result;
// gestion des erreurs
} |
Lorsque la fonction r�ussit, seul le membre ptr de std::to_chars_result nous int�resse, car il contient un pointeur sur le pointeur de fin de ligne des caract�res �crits. Si la fonction �choue, nous devons �galement examiner le membre ec (du type std::errc) qui repr�sente un code d'erreur.
Ce code peut �tre simplifi� avec des liaisons de structure, en C++26, comme suit :
1
2
3
4
5
6
7
8
| if (auto [ptr, ec] = std::to_chars(p, last, 42))
{
// ok pour continuer
}
else
{
// gestion des erreurs
} |
Le projet Carbon, un successeur exp�rimental du C++, explore une direction future possible pour le C++ �tant donn� les difficult�s � l'am�liorer
En f�vrier 2020, un vote crucial a eu lieu au sein du comit� de normalisation du C++ sur la rupture de la compatibilit� ABI en faveur de la performance. L�initiative principalement pouss�e par les employ�s de Google a �chou�. R�sultat : de nombreux Googlers ont cess� de participer � la normalisation du C++, ont d�missionn� de leur r�le officiel au sein du comit�, et le d�veloppement de clang a consid�rablement ralenti. C�est de cette rupture que na�t le projet Carbon annonc� comme successeur du C++. L�objectif : explorer une direction future possible pour le C++ �tant donn� les difficult�s � l�am�liorer. Le projet Carbon mise sur l�interop�rabilit� avec le C++ comme base de travail.
Les d�veloppeurs de Carbon expliquent que certes, le C++ est le langage dominant pour les logiciels � performances critiques, mais son h�ritage et sa dette technique signifient que son am�lioration incr�mentale est une t�che tr�s ardue. Carbon est un nouveau langage qui vise � �galer les performances de C++ et � maintenir une interop�rabilit� bidirectionnelle transparente, ainsi qu'une courbe d'apprentissage douce pour les d�veloppeurs C++.
L'�quipe promet en sus un certain niveau de traduction de source � source pour le code C++. Le projet pr�sente des parall�les avec TypeScript pour les d�veloppeurs JavaScript, ou Kotlin pour les d�veloppeurs Java, bien que la comparaison ne soit pas exacte. Carbon est con�u pour �tre interop�rable avec le code C++ et pour faciliter la migration. La cha�ne d'outils Carbon prendra en charge la compilation du code C++.
Pourquoi le C++ est-il difficile � am�liorer ? Parce que le langage lui-m�me a commenc� comme une bifurcation du C. Selon l'�quipe Carbon, les concepteurs du C++ ont ajout� plut�t que remplac� des fonctionnalit�s du langage au fil du temps, cr�ant ainsi des interactions complexes entre les fonctionnalit�s. La pr�servation de la compatibilit� binaire est un autre probl�me h�rit�. En outre, le comit� C++ et le processus d'�volution sont orient�s vers la normalisation plut�t que la conception, sont lents et ne parviennent pas toujours � prendre des d�cisions.
Carbon s'efforce de contourner ces probl�mes en adoptant une nouvelle approche fond�e sur les principes de l'open source. � Nous tenterons m�me de combler une �norme lacune dans l'�cosyst�me C++ avec un gestionnaire de paquets int�gr� �, peut-on lire dans les documents.
La Maison Blanche invite les d�veloppeurs � abandonner le C et le C++ pour passer � des langages comme le Rust
Faut-il arr�ter d�initier de nouveaux projets en C ou C++ et passer � Rust ? La question divise dans la communaut� des d�veloppeurs dont certains recommandent le langage Rust plut�t que le C ou le C++. Les raisons : la parit� du Rust en termes de vitesse d�ex�cution en comparaison avec le C ; la s�curisation et la fiabilit� du Rust en comparaison avec C ou C++. La comparaison entre Rust et C++ vient de prendre un coup de neuf avec un rapport de la Maison Blanche sur la s�curisation de la m�moire qui invite les d�veloppeurs � abandonner C ou C++ pour passer � des langages comme le Rust jug�s sup�rieurs pour s�curiser les espaces m�moire des logiciels. C�est une sortie qui fait suite � la prise de position du cr�ateur du langage C++ selon laquelle : � la s�curisation des logiciels par le Rust n�est pas sup�rieure � celle offerte par le C++. �
Sources : OpenSTD (1, 2, 3), Carbon
Et vous ?
Quelle est votre fonctionnalit� pr�f�r�e parmi celles introduites dans C++26 et pourquoi ?
Comment pensez-vous que la possibilit� de sp�cifier une raison pour la suppression d�une fonction pourrait am�liorer le d�veloppement en C++ ?
Avez-vous d�j� rencontr� des situations o� les variables de remplacement sans nom seraient particuli�rement utiles ? Pouvez-vous partager un exemple ?
Pensez-vous que ces nouvelles fonctionnalit�s de C++26 vont simplifier ou compliquer le processus de d�veloppement ? Pourquoi ?
Quels autres aspects du langage C++ aimeriez-vous voir am�lior�s dans les futures versions ?
Comment ces nouveaut�s de C++26 se comparent-elles aux am�liorations r�centes d�autres langages de programmation que vous utilisez ?
Voyez-vous des d�fis potentiels � l�adoption de ces nouvelles fonctionnalit�s dans des projets existants ? Si oui, lesquels ?
Comment ces am�liorations pourraient-elles influencer votre approche de la programmation en C++ ?
Que pensez-vous des projets comme Carbon ou des propositions comme celle de la Maison Blanche visant � se d�lester du C++ ?
Voir aussi :
Google affirme qu'il est non seulement possible, mais aussi relativement facile de remplacer C++ par Rust dans les firmwares. L'entreprise explique en quoi ce changement est avantageux
� Les �quipes Rust chez Google sont deux fois plus productives que celles qui se servent de C++ �, d'apr�s un responsable de l'entreprise qui lance le d�bat de la productivit� entre Rust et C++
Envoy� par mintho carmo
R�pondre avec citation
, Carbon ne me semble
.
Partager