IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Google rend Abseil, une collection de bibliothèques C++ et Python, open source :
Tour d'horizon

Le , par Patrick Ruiz

532PARTAGES

3  0 
Google a rendu un certain nombre de bibliothèques utilisées en interne pour différents projets open source. Dénommée « Google Abseil », il s’agit d’une collection d’outils C++ et Python. Un dépôt GitHub est déjà disponible pour le code C++ publié sous licence Apache. Les inconditionnels de Python devront patienter encore un peu.

Il y a en effet de quoi mettre de l’eau à la bouche de ces derniers. Les outils Abseil représentent dix années d’expérience engrangée par la firme de Mountain View sur différents projets open source. De plus, il s’agit de code utilisé en production et qui sera maintenu sur les cinq années à venir. En l’état actuel, la collection de bibliothèques est (d’après Google) compatible avec la plupart des plateformes (systèmes d’exploitation, compilateurs, matériel), sans que des configurations ardues ne soient nécessaires. Il sera question de maintenir ce cap et, pour les outils C++, assurer un passage doux de C++11 comme spécification du langage à C++17 d’ici à 2019.

D’après ce que Google rapporte, Abseil s’appuie sur des abstractions du langage C++ développées en respectant le standard C++11 et compatibles de façon totale ou partielle avec les spécifications C++14, C++17 et au-delà. Adopter Abseil c’est donc bénéficier de la possibilité d’avoir accès à certaines fonctionnalités du C++ qui n’existent pas encore dans les standards, avec la promesse que Google les adaptera une fois qu’elles sont adoptées.

Le type std ::string_view du standard C++17 aurait été adopté sur la base du retour d’expérience de Google avec le type StringPiece de la bibliothèque Abseil. Le type StringPiece est désormais renommé en absl ::string_view au sein de la bibliothèque Abseil. Le préprocesseur du fichier d’entête lié permet de s’assurer que le type Abseil intègre un programme comme un alias du type standard dans le cas où ce dernier est disponible sur le système. Sinon, c’est la version compatible aux spécifications C++11 et C++14 (absl ::string_view) qui est insérée.

En programmation, la gestion des instants et des durées demeure l'un des sujets les plus épineux. La bibliothèque standard du C++ offre std ::chrono ::duration et std::chrono::time_point, des modèles de classe pour cette catégorie de problèmes. Avec Abseil, Google propose les types absl :uration et absl ::Time comme alternatives. D’après la firme de Mountain View, la résolution obtenue est, certes, moins bonne, mais permet de couvrir une palette suffisante de cas dans la pratique, pour un code plus aisé à maintenir.

Abseil contient les bibliothèques suivantes :

  • base : routines d’initialisation et dépendances pour les autres bibliothèques ;
  • algorithm : extension à la bibliothèque C++ standard du même nom ;
  • container : conteneurs de style STL additionnels ;
  • debugging : routines pour effectuer des tests de mémoire ;
  • memory : versions compatibles C++11 de std ::make_unique() ainsi que des gestionnaires de mémoire ;
  • meta : versions compatibles C++11 des tests de types disponibles sous les versions C++14 et C++17 de la bibliothèque type_traits ;
  • numeric : contient des entiers 128 bits compatibles C++11 ;
  • strings : routines de gestion des chaînes de caractères et des utilitaires au rang desquels on compte une version compatible C++11 du type C++17 std ::string_view ;
  • synchronization : contient des primitives pour les accès concurrents et des abstractions de synchronisation ;
  • time : abstractions pour manipuler les instants, les durées et les fuseaux horaires.

Source : Google Blog

Et vous ?

Que pensez-vous de cette collection de bibliothèques de Google ?
Quelles raisons pourraient vous pousser à ne pas l'adopter ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 02/10/2017 à 16:10
Google ne dit pas autre chose, en fait :

Citation Envoyé par https://abseil.io/about/philosophy
Why the world has room for another collection of C++ utility libraries
Il y a quelques grosses différences : les objectifs de la conception (voir https://abseil.io/about/philosophy, section Different Design Priorities than the Standard) et la facilité de mise à jour (Google fournira un outil pour modifier le code existant en cas de changement d'API).
3  0 
Avatar de VivienD
Membre émérite https://www.developpez.com
Le 02/10/2017 à 15:28
Je sens que je vais passer pour le rabat-joie de service mais, après avoir fait un rapide tour dans les fichiers présents sur leur dépôt, je trouve que ça ne casse pas trois pattes à un canard, surtout en comparaison avec les sources de boost.
Qui sait? Peut-être que mon avis est biaisé par le fait que je suis dans une période où je m'adonne aux mathématiques et à la physique comme un bon gros bourrin des familles.
3  1 
Avatar de
https://www.developpez.com
Le 02/10/2017 à 15:56
Je suis assez d'accord. En plus, la lib utilise bazel, qui est loin d'être le système de build standard du C++.
3  1 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 03/10/2017 à 14:32
C'est sûr que c'est plus light que boost, et c'est peut être son avantage.

Perso j'évite d'utiliser boost aujourd’hui : trop gros, trop de fichiers à inclure dans son repo (y'a quand même un côté usine à gaz dans Boost).

Donc pour moi ça van dans le sens de ce qui se fait depuis quelques années : essentiellement des petits fichiers header only quasiment indépendants. Et perso c'est ce que j'utilise de plus en plus (Catch pour les tests, la GSL, json, cmdline, ...). D'autant plus que maintenant on a optional, string_view, filesystem, variant de dispo avec les principaux compilateurs, y compris VC++, au namespcace près (std::experimental). Un petit polyfill fait l'affaire pour récupérer le bon header sur chaque compilo.

Je vais certainement intégrer leurs algorithmes adaptés aux conteneurs. J'en ai déjà adapté quelques un dans mon code, mais autant les avoir tous grâce à cette lib
2  0