Google a publié la sixième version stable de son langage de programmation Go. Go 1.5 inclut des changements significatifs dans son implémentation. Parmi eux, Google cite le fait que « l’outil de chaîne de compilation a été traduit de C vers Go, enlevant les derniers vestiges du code C dans la base de code de Go ». Ce qui a pour effet de créer une intégration plus étroite entre les parties du langage.

De plus, le récupérateur de mémoire a été complètement repensé, conduisant à une réduction conséquente des pauses observées dans la gestion automatique de la mémoire. Russel Cox, un ingénieur supervisant le développement de Go, a expliqué que Google voit désormais des pauses dans une fourchette comprise entre 10 et 20 millisecondes pour un programme de 10Go, contre 1 à 2 secondes de pauses pour la version précédente du récupérateur de mémoire.

Le planificateur a été amélioré de sorte que le nombre de routines Go qui s’exécutent simultanément (valeur par défaut de GOMAXPROCS) puissent être modifié, allant de 1 au nombre de processeurs disponibles. En clair, les développeurs utilisant Go 1.5 n’auront plus à spécifier l’utilisation des cœurs du processeur ; cela sera fait par défaut. « Le récupérateur de mémoire et le programme principal peuvent fonctionner sur des threads et des cœurs différents », a précisé Cox.

Notons également que le linker a été modifié pour permettre la distribution de packages Go sous forme de bibliothèques partagées afin de relier des programmes Go.

Cette mouture embarque également des améliorations des outils développeurs. Le support des paquets dits « internes » vous permet de partager les détails de mise en œuvre entre les paquets. Le support expérimental des paquets de dépendances externes est une étape vers un mécanisme standard de la gestion des dépendances dans les programmes Go. La nouvelle commande « go tool trace » permet la visualisation des traces de programmes générées par la nouvelle infrastructure de traçage dans le runtime. La nouvelle commande « go doc » fournit pour sa part une interface de ligne de commande améliorée pour l’affichage de la documentation du package Go.

Avec « l’expérience mobile Go » de Google améliorée dans cette mouture, les développeurs pourront écrire un programme C qui appelle Go comme une bibliothèque. La version 1.5 supporte également les architectures arm64 pour les systèmes d’exploitation Darwin (iPad et iPhone) et Linux mais également arm pour Darwin. La combinaison de la capacité à appeler Go depuis des programmes C / C++ ainsi que le support ARM sur Darwin permet à l'expérimentation mobile de Go, qui « explore l'utilisation de Go comme un langage NDK (Native Development Kit), un langage natif sur les dispositifs mobiles qui tournent sur Android mais également iOS », a expliqué Cox.

Go pourrait être utilisé comme un langage NDK pour concevoir la logique en arrière-plan pour des applications Android et iOS. De nombreuses applications, en particulier les jeux, font appel à Java ou à Objective-C pour l’interface utilisateur, mais le code natif est utilisé pour concevoir la logique principale de l’application, a expliqué Cox. Pour lui, « l’idée ici est que là où vous utilisez C++, vous pouvez utiliser Go à la place ».

• Télécharger Google Go 1.5
• Go Mobile (Github)
• Rubrique Go, Forum Go, & tutoriels Go.

Source : note de version

Si vous devez réaliser quelques petits scripts automatisés qui consistent à faire cliquer la souris un peu partout, et que vous ne voulez pas vous lancer dans du code de macro trop complexe, sachez qu'il existe un petit outil baptisé Sikuli, qui tourne sous Windows, Mac et Linux et qui permet de créer ce genre de script, simplement en prenant des captures écran.

Oui, ça peut sembler étranger et c'est pourtant ce que fait ce logiciel. Au lieu de lui dire "Click sur le bouton1 de l'application MachinTruc", on lui dit "Click sur ____ (et là on met une capture écran du bouton)". Amusant non ?
Voici une démo en vidéo pour que vous puissiez mieux vous rendre compte de la puissance du truc :

Il y a 3 ans, les développeurs C++ avaient accueilli la nouvelle standardisation du langage avec beaucoup d'enthousiasme. Avec ce nouveau standard, plusieurs fonctionnalités avaient été ajoutées ou mises à jour pour faire du C++ un langage plus moderne et efficace, tout en conservant les anciens avantages tels que l'accès bas niveau à la mémoire par exemple.

Cependant, d'autres améliorations ont été reportées, car il aura fallu quand même 13 ans pour finir cette normalisation!
Une des améliorations possibles, qui restent toujours intéressantes, c'est de repenser le système d'inclusion de fichiers. C'est en tout cas ce que propose l’équipe CoderGears dans un billet de blog. Ils sont même allés plus loin en proclamant que « le C++ doit moderniser son mécanisme d’inclusion pour devenir vraiment un langage moderne ».

Jusqu'à présent, lorsqu'un fichier d'entête est inclus grâce à la directive #include, le préprocesseur analyse le contenu du fichier ainsi que tous les autres fichiers qu'il inclut lui-même. Et ceci est répété à chaque #include rencontré. Ce qui conduit parfois à un grand volume de travail redondant lorsque deux fichiers incluent la même bibliothèque, et que celle-ci n’est pas entourée de #ifndef et #endif. Mais ce n'est pas le seul problème, car lors de l’analyse, si une macro par exemple porte le même nom qu'un autre composant dans cette bibliothèque, c'est toute la compilation qui échoue. « Des problèmes se produisent dans des projets réels lorsque les entêtes pour deux bibliothèques différentes interagissent en raison de collisions macro, et les utilisateurs sont obligés de réorganiser les directives #include ou introduire des #undef pour briser le lien », explique CoderGears.

Certains programmeurs, avec le temps, ont développé de nouvelles habitudes pour éviter ça. Dans la documentation de Clang, on peut lire que « les programmeurs C++ ont adopté un certain nombre de conventions pour travailler autour de la fragilité du modèle de préprocesseur […] Les noms de macros sont écrits avec de LONG_PREFIXES_EN_MAJUSCULES pour éviter les collisions, et certains développeurs de bibliothèques utilisent même un double tiret dans les en-têtes pour éviter les collisions avec des noms "normaux"». Cette pratique, qui ne respecte pas les conventions du langage, est apparemment utilisée par certains pour contourner le problème.

Heureusement, une solution existe depuis la proposition de la norme C++ox, mais elle n'a pas été implémentée et a été retardée pour la norme C++11, puis renvoyée une nouvelle fois à une prochaine standardisation du langage de programmation.

Cette solution devrait alléger grandement le code des entêtes ainsi que leur traitement, puisqu'elle propose de ne plus inclure les fichiers d'une bibliothèque séparément. Par exemple : au lieu de charger les fichiers de la bibliothèque standard du C++ un à un, un simple import std suffira. L'entête gagnera donc beaucoup en clarté. De plus, cela inclura directement le fichier binaire de la bibliothèque (en tant que module déjà prêt), ce qui évitera au préprocesseur de le réanalyser à chaque fois, et évitera en même temps de tomber sur des conflits lors de la compilation.

« L’introduction de modules en C ++ ne sera pas une tâche facile », avoue l’équipe CoderGears. « Nous espérons que ce ne sera pas comme jisgaw (le système modulaire de Java) qui a été reportée de nombreuses années ».

Source : developpez.com