Conférences et publications

Interventions et présentations de conférence

Nobody Can Program Correctly. A Practical and Interactive Guide to Debugging C++ Code
Sebastian Theophil

Nous aimons écrire le code, mais malgré tous nos efforts, nous commettons des erreurs. Notre programme contiendra des bugs. Parfois, nous n’écrivons pas ce que nous voulons écrire, parfois nous ne comprenons pas un aspect de notre langage de programmation et à d’autres moments, nous manquons d’informations critiques sur l’environnement système de notre programme ou nous ne les prenons pas en compte. Notre programme ne se comportera donc pas correctement. Que faire maintenant ? Au cours de cet exposé, je vous présenterai l’entièreté du processus de débogage, en commençant par le plantage d’un programme. Que faire ensuite ? Quelles questions poser ? Quelles sont les informations nécessaires ? Que peut-on faire pour trouver la cause du plantage ? Quels outils peuvent nous aider dans cette entreprise et, surtout, que faire pour s’assurer que ce bug n’arrive plus à l’avenir ? Grâce à des exemples concrets que nous avons rencontrés, et débogués, chez think-cell au fil des ans, vous apprendrez à reproduire, localiser, comprendre et corriger même les bugs les plus difficiles.


Typescripten — Generating type-safe JavaScript bindings for emscripten
Sebastian Theophil

WebAssembly est devenu une plateforme cible très populaire pour les développeurs C++. Grâce à emscripten, le portage d’applications natives vers WebAssembly est facile, à condition que l’application utilise uniquement le navigateur comme périphérique d’affichage et d’entrée. Cependant, emscripten ne fournit pas de wrappers de type safe pour les API JavaScript standard telles que l’API de manipulation DOM, et encore moins les autres API JavaScript fournies par les applications Web existantes. Notre outil open source « typescripten » a été construit sur trois technologies puissantes pour combler cet écart. Il utilise des fichiers de définition d’interface TypeScript et l’API du compilateur TypeScript pour créer des wrappers C++ compatibles avec les types basés sur emscripten. TypeScript possède déjà des fichiers de définition d’interface pour plus de 7 000 bibliothèques JavaScript que vous pouvez maintenant utiliser en toute sécurité dans C++. Notre but est de concevoir nos wrappers C++ de telle sorte que le code C++ qui les utilise ressemble au code TypeScript ou JavaScript équivalent. Cependant, la sémantique particulière du Javascript et du TypeScript basés sur des prototypes est souvent difficile à traduire dans un langage basé sur des types tel que C++. J’aborderai les défis auxquels nous avons été confrontés et les choix que nous avons faits lors de la conception de ce cadre.


« Windows, macOS and the Web: Lessons from cross-platform development at think-cell
Sebastian Theophil

think-cell est une société de logiciels fonctionnant uniquement sous Windows depuis 12 ans et notre base de code d’environ 700 000 lignes de code a accumulé de nombreuses dépendances involontaires à la plateforme. Il y a six ans, nous avons décidé de porter notre application sur Mac. Ce changement a eu un impact sur toutes les parties de notre processus de développement : l’organisation du projet, le système de construction et la façon dont nous programmons en C++ aujourd’hui. Les bibliothèques multiplateformes couramment utilisées, telles que Qt et Boost, étaient de bons outils sur lesquels construire, mais elles ne suffisaient pas à elles seules. Pour de nombreux concepts, tels que les mutex, les sémaphores ou la mémoire partagée, elles n’offrent qu’une interface commune aux objets spécifiques à la plateforme avec une sémantique et des durées de vie très différentes. Nous voulions des abstractions C++ légères et indépendantes de la plateforme avec une sémantique identique pour le rendu, l’internationalisation, les E/S de fichiers, la gestion des événements de souris, les appels RPC et les rapports d’erreurs. Le développement a été difficile. Premièrement, parce que nous devions définir la sémantique dont notre application avait besoin et, deuxièmement, nous devions l’implémenter sur chaque plateforme. Ce n’était pas un processus évident, mais je dirais qu’il a beaucoup amélioré la qualité de notre code. Nous sommes maintenant passés au défi suivant et avons commencé à déplacer certaines fonctionnalités vers les applications Web. Nous souhaitions réutiliser notre base de code existante, bien entendu, et cela signifiait écrire des applications Web en C++ expressif et de type safe. Un avantage indéniable pour nous ! Nous avons construit nos applications Web en utilisant emscripten, mais nous générons des liaisons C++ de type safe à partir de n’importe quelle définition d’interface TypeScript. Au cours de cet exposé, je vous ferai une présentation des abstractions en C++ que nous avons mis en place, et me concentrerai sur les problématiques de multiplateforme et les difficultés à définir une sémantique commune, à cause des limites imposées par l’un ou l’autre système d’exploitation. Naturellement, je vous montrerai les outils qui nous permettent de développer des applications Web en C++.


C++ rvalue lifetime disaster
Arno Schödl

Nous utilisons les références rvalue depuis C++11. Elles ont été introduites à l’origine pour rendre les objets en mouvement plus efficaces : l’objet auquel une référence rvalue fait référence est supposé sortir prochainement du champ d’application et peut donc voir ses ressources récupérées sans dommage. La bibliothèque standard C++, par exemple std::cref ou std::ranges, utilise encore un autre aspect des références rvalue : puisqu’elles sortent prochainement du champ d’application, il est supposé dangereux de les conserver au-delà de la portée de la fonction courante, alors que les références lvalue sont considérées comme sûres. Nous aussi avons trouvé cette hypothèse très utile pour la gestion intelligente de la mémoire, en particulier dans le code générique.
Malheureusement, le langage C++ lui-même ne respecte pas cette hypothèse. Rvalues bind to const&. Cela signifie que les fonctions d’apparence innocente convertissent silencieusement les références rvalues en références lvalues, masquant toute limitation de durée de vie des rvalues. L’extension temporaire de la durée de vie est destinée à sécuriser la liaison d’un objet temporaire à une référence en prolongeant la durée de vie du temporaire. Mais cela ne fonctionne que si le temporaire est une prvalue, et rompt déjà avec les références rvalue, sans parler des lvalue générées de manière erronée. Ces problèmes ne sont pas seulement théoriques. Nous avons eu des cas de corruption de mémoire difficiles à trouver dans notre code à cause de ces problèmes. Au cours de cet exposé, je décrirai les problèmes en détail, présenterai notre approche réservée aux bibliothèques pour les atténuer, et formulerai enfin une proposition incontestable de solution standard.


Better C++ Ranges
Arno Schödl

Les plages font partie du standard C++ depuis longtemps maintenant et se retrouvent dans les bases de code modernes. Chez think-cell, nous développons et utilisons notre propre bibliothèque de plages depuis 20 ans, qui est construite sur la base de la norme et est compatible avec elle, mais la dépasse sur de nombreux aspects. Les adaptateurs de plage sont souvent chaînés, un filtre au-dessus d’une transformation au-dessus de etc. Les itérateurs ne sont pas assez bons pour rendre cette chaîne efficace. Nous utilisons un nouveau concept qui est plus efficace et en même temps compatible avec les itérateurs afin que les utilisateurs de bibliothèques puissent continuer à se servir des itérateurs comme ils le faisaient auparavant. La bibliothèque standard est très stricte quant à la distinction entre les conteneurs et les vues. Or les adaptateurs de plage sont des vues qui doivent maintenir une référence aux données adaptées. Au lieu de cela, nous permettons aux adaptateurs de gamme de conserver eux-mêmes les données pour les rendre autonomes et les évaluer paresseusement en même temps. Le modèle itérateur standard permet uniquement l’itération externe. Cependant, l’itération interne est souvent beaucoup plus facile à mettre en œuvre que l’itération externe. Pour de nombreuses applications, l’itération interne est tout à fait adaptée et plus efficace que l’itération externe. C’est pourquoi nous introduisons l’itération interne dans la famille de plages, au point que l’utilisateur de la bibliothèque peut ne pas savoir ou ne pas se soucier du type d’itération utilisé. Les algorithmes standard renvoient des itérations et utilisent l’itérateur de fin pour signaler un état de singleton. En personnalisant les valeurs renvoyées, nous pouvons rendre notre code plus simple et expressif, par exemple en éliminant ces redoutables vérifications de fin d’itérateur. Ces fonctions combinées font des gammes un excellent outil pour la mise en forme de texte. Nous pouvons utiliser ces plages pour représenter les valeurs à formater, les transformant ainsi théoriquement en chaînes à l’évaluation paresseuse. Celles-ci peuvent être utilisées de la même manière que les chaînes normales actuelles : dans des retours de fonction, en tant qu’entrées d’algorithme standard, intégrées à d’autres chaînes à l’évaluation tout aussi paresseuse, etc., avant qu’elles ne soient finalement développées pour l’affichage. En choisissant les bonnes interfaces, nous pouvons optimiser cette expansion au moment de la compilation, permettant ainsi une syntaxe agréable et une performance très proche du code optimisé manuellement.


Range-Based Text Formatting - For a Future Range-Based Standard Library
Arno Schödl

Le formatage du texte représente depuis longtemps l’un des problèmes préférés des créateurs de bibliothèques C++. Lors de cette conférence, je voudrais vous convaincre que l’association des plages avec une touche de métaprogrammation permet de créer une solution très élégante au problème de formatage du texte. Vous allez découvrir une forme de plages dont l’itération est interne, et qui génère ses éléments un par un sans exposer les itérateurs internes. Nous pouvons utiliser ces plages de générateur pour représenter les valeurs à formater, les transformant ainsi théoriquement en chaînes à l’évaluation paresseuse. Celles-ci peuvent être utilisées de la même manière que les chaînes normales actuelles : dans des retours de fonction, en tant qu’entrées d’algorithme standard, intégrées à d’autres chaînes à l’évaluation tout aussi paresseuse, etc., avant qu’elles ne soient finalement développées dans un conteneur. En sélectionnant les interfaces adéquates, nous pouvons optimiser ce développement jusqu’à atteindre un niveau seulement 15 % plus lent par rapport à la création d’une chaîne équivalente utilisant un code spécifique optimisé à la main.


Why Iterators Got It All Wrong — and what we should use instead
Arno Schödl

Vous connaissez les itérateurs, n’est-ce pas ? Comment les décririez-vous ? "Les itérateurs sont utilisés pour indiquer des séquences d’éléments." Cela vous paraît juste ? Le concept de plages a récemment été mis en place pour désigner tout ce qui expose les itérateurs. Plus particulièrement, les plages incluent des adaptateurs de plage afin de transformer ou de filtrer « paresseusement » des séquences d’éléments, et possèdent également des itérateurs.
Tout va bien ? Malheureusement, non. Le concept d’itérateur qui nous utilisons depuis l’avènement du C++ est fondamentalement erroné. Certains itérateurs doivent notamment se comporter différemment en fonction de ce qu’ils sont censés indiquer, un élément ou une frontière entre des éléments. Les éléments et les frontières sont donc deux concepts véritablement distincts. Pendant cette conférence, je vais vous montrer que ce problème est bien réel et entraîne des implications pratiques, proposer une solution pour le résoudre et vous montrer en quoi la solution résout non seulement le problème, mais rend également le code plus clair et permet d’éviter les erreurs.


From Iterators To Ranges — The Upcoming Evolution Of the Standard Library
Arno Schödl

Les paires d'itérateurs sont omniprésentes dans l'ensemble de la bibliothèque C++. Il est généralement admis que la combinaison de ce type de paire en entité simple généralement nommée Plage garantit un code plus précis et lisible. Toutefois, la définition d'une sémantique spécifique d'un tel concept de « plage » s'avère étonnamment délicate. En effet, les considérations théoriques et pratiques sont incompatibles. Certains objectifs de conception ne sont pas conciliables.


A Practical Approach to Error Handling
Arno Schödl

Chaque programme peut se trouver confronté à des erreurs, certaines issues de bugs internes et d'autres provenant de l'environnement de fonctionnement du programme. Ignorer ces erreurs peut rendre le programme très incertain, mais le traitement de toutes celles que vous pourrez trouver engendre une complexité accrue pour peu d'avantages. Chez think-cell, nous utilisons et affinons notre propre approche raisonnée en termes de gestion des erreurs. Elle est d'ailleurs inédite. Cette présentation décrit notre méthode, pour qu’à votre tour vous puissiez créer un logiciel plus fiable plus facilement lors de votre prochain projet.


Épisode C++ hebdomadaire – Entretien sur CppCast
Arno Schödl

À l’occasion de l’épisode CppCast du 24 janvier 2018, Rob Irving et Jason Turner reçoivent Arno pour parler de la bibliothèque de plages think-cell et du développement en C++ chez think-cell d’une manière générale.


« Developing a simple PowerPoint Add-in, how hard can it be ? » (Jusqu’à quel point peut-il être difficile de développer un simple complément pour PowerPoint ?)
Valentin Ziegler

Le développement bureautique est largement associé aux macros VBA ennuyeuses, ou du bidouillage JavaScript. De nombreux développeurs auxquels Valentin a parlé étaient surpris d’apprendre que la base de code de think-cell avait des millions de lignes de code C++ et que nous devions créer des bibliothèques génériques au fur et à mesure afin de le garder court. Notre objectif est de mettre en œuvre l’interface utilisateur la plus simple au-dessus de PowerPoint qui permet aux utilisateurs de créer de belles diapositives en peu de temps, et pour cela nous devons nous servir d’outils très puissants. Laissez-nous vous montrer comment nous appliquons des algorithmes de pointe pour résoudre les problèmes de disposition et de positionnement, et quels défis nous avons dû relever pour une intégration transparente avec l’application hôte.


Hacking logiciel de qualité industrielle
Simon McPartlin

Les correctifs logiciels représentent une méthode puissante mais potentiellement dangereuse pour résoudre les bugs. Ils permettent d'ajouter des fonctionnalités et d'améliorer l'opérabilité et la performance du logiciel. Cette conférence a pour but d'examiner la correction du logiciel lorsque le code source n'est pas disponible. Cette activité est généralement connue sous le nom de hacking. Nous évoquerons les raisons et les moments auxquels cette activité se justifie avant d'étudier plus en détail la conception et la mise en œuvre de correctifs solides. Nous terminerons en décrivant les différents outils et techniques disponibles afin de déterminer les emplacements adaptés pour établir les correctifs.


std::cout is out — Why iostreams must go
Sebastian Theophil

Le portage de notre logiciel sur d’autres plates-formes est tout récent. Nous avons découvert à cette occasion à quel point les iostreams et les I/O type C sont pénibles à utiliser. Au cours de cette conférence, j’aimerais donner un aperçu rapide des raisons qui nous ont poussés à bannir les iostreams de notre base de code et par quoi nous les avons remplacés.


Modèle de mémoire C++
Valentin Ziegler et Fabio Fracassi

le modèle de mémoire C++ définit la manière dont plusieurs threads interagissent avec la mémoire et les données partagées, permettant aux développeurs de réfléchir sur le code concurrent indépendamment de la plate-forme. Cette conférence sera l’occasion d’aborder le multi-threading et les data races en C++, la manière dont le code concurrent est affecté par les optimisations du compilateur et du matériel et comment éviter les comportements indéterminés en utilisant des verrous et des opérations atomiques. Puis nous nous intéresserons aux ordres d’accès à la mémoire des opérations atomiques, à leurs garanties et implications sur leurs performances.


C++ et Java
Valentin Ziegler et Fabio Fracassi

Nous adorons C++ et l’utilisons tous les jours. Au cours de cette conférence, nous montrerons que C++, bien qu’il soit réputé pour sa complexité, est un langage bien meilleur que Java. Pourquoi ? Parce que C++ connaît la sémantique de valeur. Parce que C++ a un comportement indéfini. Parce que C++ n’impose pas de ramasser les miettes. Parce que C++ permet d’écrire du code à la fois abstrait et efficient.


Publications scientifiques

An Efficient Algorithm for Scatter Chart Labeling
Sebastian Theophil et Arno Schödl
Comptes-rendus de l’AAAI 2006

Dans la présente publication, nous présentons un algorithme performant et innovant de résolution du problème de création de libellés de points. L'objectif consiste à positionner le plus grand nombre possible de libellés de points en évitant toute intersection entre eux ou avec leurs points. Dans la première partie, nous présentons un algorithme gourmand en ressources dont la fonction lookahead est limitée. Nous présentons ensuite un algorithme qui regroupe les libellés de manière itérative, en appelant le premier algorithme pour chaque groupe et en définissant ensuite un ordre de création de libellés quasi optimal. L'algorithme présenté est actuellement utilisé dans un produit commercial pour créer des libellés dans des graphiques et, selon notre évaluation, il permet d'obtenir des résultats de bien meilleure qualité que ceux obtenus avec d'autres algorithmes de création de libellés.


A Smart Algorithm for Column Chart Labeling
Sebastian Müller et Arno Schödl
Comptes-rendus du SMART GRAPHICS 2005

Dans la présente publication, nous présentons un algorithme intelligent de création de libellés pour les histogrammes et leurs variantes. Pour réussir à résoudre le problème de manière efficace, nous l'avons subdivisé en deux parties. Nous présentons tout d'abord un algorithme géométrique qui permet de résoudre le problème lié à la définition d'un système de création de libellés adaptés à une colonne unique, sachant que des libellés ont déjà été créés pour certaines colonnes. Nous présentons ensuite une stratégie qui permet de définir un ordre approprié de création de libellés pour les colonnes, qui utilise à plusieurs reprises le premier algorithme pour certaines fonctions lookahead limitées. L'algorithme présenté est actuellement utilisé dans un produit commercial pour créer des libellés dans des graphiques et permet d'obtenir des résultats satisfaisants sur le plan pratique.


Graphcut Textures : Image and Video Synthesis Using Graph Cuts
Vivek Kwatra, Arno Schödl, Irfan Essa, Greg Turk et Aaron Bobick
Comptes-rendus du SIGGRAPH 2003

Dans cette publication, nous présentons un nouvel algorithme pour la synthèse de textures d'images et de vidéos. Dans notre approche, des blocs d'échantillon d'image ou de vidéo sont transformés et copiés vers la production en sortie, puis reliés le long de jointures optimales afin de générer une nouvelle production (en général de plus grande taille). Par rapport aux autres techniques, la taille du bloc n'est pas définie au préalable mais à l'aide d'une technique de découpage de graphique afin que sa taille soit optimale en fonction du décalage entre la texture d'entrée et la texture de sortie. Contrairement à la programmation dynamique, notre technique de découpage de graphique pour l'optimisation des jointures est applicable à toutes les dimensions. Nous l'étudions plus particulièrement en 2D et en 3D pour réaliser des synthèses de textures vidéo en plus des synthèses d'images traditionnelles.


Controlled Animation of Video Sprites
Arno Schödl and Irfan Essa
Comptes-rendus du SCA 2002

Nous présentons dans cette publication une nouvelle approche pour réaliser des animations contrôlées de sprites vidéo. Les sprites vidéo sont des animations créées à partir de la réorganisation d'images vidéo enregistrées d'un objet en mouvement. Notre technique permet de créer des animations à l'aide d'une fonction à coût flexible, qui est automatiquement optimisée par le remplacement répété de sous-séquences de sprites vidéo.


Video Textures
Arno Schödl, Richard Szeliski, David H. Salesin and Irfan Essa
Comptes-rendus du SIGGRAPH 2000

Nous présentons un nouveau type de support, appelé texture vidéo, dont les qualités sont à mi-chemin entre celles d'une photographie et d'une vidéo. Une texture vidéo génère un flux continu d'images qui varient à l'infini. Dans son ensemble, la séquence vidéo n'est jamais répétée à l'identique, alors que chaque image de la texture vidéo peut se répéter de temps en temps. Les textures vidéo peuvent être utilisées à la place de photographies numériques pour diffuser une image statique dotée de qualités dynamiques et d'une action explicite.

Vous souhaitez plus d'informations ?

Si vous avez des questions sur l’environnement de travail chez think-cell, nos postes à pourvoir ou les événements, veuillez contacter notre collègue Julia Zhachuk.

hr@think-cell.com
+49 30 6664731-81

Représentante des RH chez think-cell.


Partager