lockidor a écrit 161 commentaires

AFAIK, il n'y a pas d'API haut niveau de ce genre embarquées dans « Linux », tout simplement parce qu'il n'y a pas de « Linux », il n'y a que des distributions (en gros, Linux == Darwin, Arch/Debian/Fedora/… == macOS).

Donc pour avoir un équivalent à une pile complète comme macOS, on assemble généralement un noyau Linux, les utilitaires GNU, le serveur graphique Xorg ou Wayland et toute une kyrielle de librairies.

quelles sont les équivalent sous les système GNU/Linux les plus populaires? Les développeurs ne s'appuient-ils que sur les librairies, ou existe-t-il ce type de API généralistes?

Je connais très mal l'environnement macOS, mais d'après les noms, je dirais que Core Image ~= lib{png/jpg/…}, Core Audio ~= OpenAL, SceneKit ~= Ogre/Irrlicht/OpenSceneGraph. Autant certaines de ces librairies (OpenAL, Freetype, lib{jpg/png} par exemple) sont plus ou moins des intitution, même s'il est toujours possible d'en utiliser d'autres ; autant d'autres rassemblent moins le consensus et cohabitent dans la joie et la bonne humeur, étant généralement taillées pour des rôles différent (les moteurs 3D, les librairies de GUI comme GTK et Qt, etc.).

Qui pilote leur développement?

Les gens qui leurs rajoutent ce dont ils ont besoin ;) Blague à part, généralement, il y a une équipe principale réduite qui coordonne le développement du projet concerné.

DNSSEC ne devrait pas plutôt être généré au niveau du service de résolution de l'OS ?

Pour quelqu'un comme moi, qui se débrouille à peu près en soft mais qui n'a jamais osé se lancer dans l'électronique, ce journal est une mine d'or.

J'espère en voir plus dans le futur !

Ça devient bien plus difficile de faire beaucoup d'argent avec ces conditions :p

AFAIK, pdfgrep ne fonctionne que sur la partie texte des PDF, pas sur les images embarquées, qui sont typiquement produites par les logiciels de scan.

Même le futur Vulkan n'est pas une alternative, mais un successeur.

Globalement d'accord avec le reste du post ; mais si je ne dis pas de bêtise, Vulkan n'est ni une alternative ni un successeur, mais une API parallèle pour le dev plus bas-niveau sur GPU ?

Ne pas oublier non plus qu'il n'y a pas que Webkit. Webket est utilisé par Apple, Qt et GTK, mais Google et Opera, par exemple, utilisent le fork Blink. Lequel tend de plus en plus (logique) à s'éloigner de son papa.

Si seulement c'était restreint à la Russie…

Ici en France aussi je reçois parfois des appels non sollicités d'entreprises auxquelles je n'ai jamais fourni mon numéro de téléphone.

C'est une orthographe erronée de « quand même », ici probablement utilisée à but ironique.

C'est en tâtonnant et en tentant des trucs parfois tordus qu'on avance finalement…

On a ici une simple projection d'objets sur un espace vectoriel et utilisation de la norme associée.

Ce n'est pas forcément la chose la plus intuitive qui soit pour un néophyte, mais c'est une des opérations les plus vites tentées quand on cherche à comparer des objets.

j'avoue qu'au début j'ai cru que c'était une silhouette de femme en cape, mais je crois que c'est la silhouette inversée d'un flanc du Cervin.

tu es bien content d'avoir erase et ton delete_at serait parfaitement inutile.

Je n'ai jamais dit que c'est mutuellement exclusif.

la bibliothèque de C++17.

Oui, donc un standard qui n'est pas encore d'actualité.

Maintenant, que tu n'aime pas Rust, c'est ton droit le plus complet. Que tu aimes C++, c'est aussi ton droit le plus complet. Par contre, sortir des attaques ad hominem comme dans tes autres commentaires et pré-supposer que tes interlocuteurs sont des billes en C++, c'est un manque de courtoisie des plus élémentaires.

OK, merci pour la correction.

Mais si tu veux, on peut parler de go qui est directif et permet d'écrire des OS

AFAIK, Go utilise un GC et a donc besoin d'un runtime en dessous. Alors techniquement parlant, on pourrait aussi réécrire le runtime en bare-metal (je suppose ?), mais dans ce cas, je pense qu'on pourrait écrire un OS avec pratiquement n'importe quel langage.

arrêtez de venir pour pomper l'air pour nous expliquer que C++ c'est de la merde.

Si tu penses au thread auquel je pense, il partait de quelqu'un qui demandait quels étaient nos reproches envers le C++ ; forcément, les bons aspects n'apparaîtront pas.

Pour reprendre tes mots, arrête de venir nous pomper l'air et fait un thread pour mettre en avant ce que nous aimons dans le C++.

des trucs qui datent de plus de 10 ans

En même temps, quand la pérennité est un des arguments pour le C++ et que nombre de librairies se traînent des trucs vieux de plus de 10 ans (tousse Qt tousse), ça va forcément revenir dans les discussions.

Un truc comme vector::erase qui existe depuis 98 ?

Je suis peut-être exigeant là-dessus, mais entre vec.erase(vec.begin() + 32); et vec.delete_at(32), je trouve le second bien plus lisible. Et je trouve d'autant plus dommage que le second ne soit pas dans la stdlib au vu de sa facilité d'implémentation.

Personne ne t'oblige à l'utiliser.

Le thread part d'un gars qui demandait ce que l'on reprochait au C++, ce n'est pas dans ce thread que je vais donner toutes les parties que j'aime bien.

Si justement, on en a une maintenant.

De ce que je vois, c'est une “optional technical specification”.

Sauf que C++ ne part pas, il est déjà très bien installé et n'est pas près de bouger. Des projets C++ se créent tous les jours.

Tu déformes ma phrase. Je ne parle pas de son existence dans le monde du dev, c'est évidemment un des langages pilier de notre milieu. Je parlais de réduire les frictions de développement.

Donc ce n'est pas un problème si C++ ne gère pas les GUI, puisqu'on peut aussi interfacer avec du "Java/Kotlin/C#"

C'est peut-être de la pure paresse de ma part, mais j'avoue qu'utiliser un langage relativement bas niveau pour le GUI me gonfle :)
C++ a Qt qui est extrêmement bien fichu donc je l'utilise régulièrement, mais j'ai de plus en plus tendance à passer à Python+PyQt pour les GUI et interfacer avec un backend à plus hautes performances.

même s'il faut passer par du C++/Céifié

On ne pourra pas passer par du C++ (ou n'importe quel autre langage qui utilise autre chose que pointeurs + types machines) tant qu'une ABI n'aura pas été définie ; ce n'est même pas une question de stabilité, c'est une question d'inexistence :/

En ce qui concerne Rust, il a une FFI plutôt correcte avec le C (avec les mêmes limitations que les autres langages), même si des gens ont commencé à profiter des capacités de méta-programmation pour faire des trucs kikoo.

Du coup, ce qui serait objectif, c'est de comparer compilation + temps de première exécution, non?

Si on compare à un langage à VM, effectivement. Mais dans ce cas, je faisais une comparaison implicite de mon expérience avec Rust (parce que c'est celui que j'utilise le plus en ce moment), qui est aussi compilé comme C++.

Donc, si je te suis bien, le seul langage dans la même catégorie que C++ est Rust

Dans mon cas d'utilisation. Il y a sûrement d'autres langages que je ne connais pas, ce n'est pas spécialement mon domaine de prédilection, je suis un simple dilettante sur le sujet.

Par contre, même si la pérennité n'est pas assurée, il y a deux facteurs à prendre en compte. Premièrement, Mozilla n'est pas vraiment une petite boîte, des gens sont payés pour bosser dessus, les versions se succèdent, la doc est de bonne qualité, et la communauté excellente, donc c'est plutôt bien parti. Ensuite, tous les programmes ne sont pas destinés à durer 20 ans, et si tout le monde ne prenait en compte que les langages pérennes, nous serions tous probablement encore en train de programmer en Fortran ou en Cobol.

Car par "genre Swift, go ou rust", tu dis justement qu'il n'y a pas de remplaçant viable à long terme

Il y a deux choses. D'abord, l'équivalence entre les objectifs des langages. Swift et Go n'ont pas les mêmes objectifs que C++, ne serait-ce que pour les modèles mémoires (GC + ARC).

Ensuite, la pérennité. Pour Rust, c'est à voir. Pour Swift et Go, par contre, avec Apple et Google derrière, je pense qu'on peut supposer que ce ne sera pas trop un souci.

GTK a des bindings C, donc tout le monde peut l'utiliser.

Ensuite, un GUI c'est large comme domaine. On parle des GUI natives à la GTK/Qt, des GUI OpenGl, de l'interfaçage avec du HTML/CSS/JS, … ?

Je ne travaille qu'avec Rust, mais je n'ai pas eu pour le moment besoin de GUI. Et si je devais en faire une, je pense que je m'en ferais une en Java/Kotlin/C# interfacé avec le backend Rust.

c'est à dire ? Si tu fais référence aux accès mémoires invalides, il est facile aujourd'hui d'écrire du code qui ne génère pas plus de segfault que de NULLPointerException.

Je voulais parler des messages d'erreurs, mais je ne me suis rendu compte de l'ambiguïté après avoir validé. Par contre, je rebondis sur la prétendue facilité : quand définir un membre statique (encore un exemple de syntaxe absconse d'ailleurs) au mauvais endroit fait segfault le programme totalement ailleurs, ce n'est pas facile d'écrire du code sans segfault. Par ailleurs, il y a plein de facilités pour écrire du code qui segfault (arithmétique des pointeurs, casts à l'arrache, padding des structs, pas de garantie de la durée de vie des objets, …).

je ne rentre pas çà dans les lacunes très importantes ; de plus encore une fois pour avoir vu de l'environnement Java complexe

Ce n'est pas parce que c'est un potentiel défaut de Java (je ne connais pas assez le langage pour en juger) que ce n'en est pas un pour C++.

j'ai pas souvenir de préprocesseur qui soit meilleur ailleurs, quand il y a ; qu'est-ce qui te manque et qui existe ailleurs ?

Il devrait simplement disparaître. Les #include c'était bien en 1960, mais on fait mieux maintenant (même Turbo Pascal avait déjà un système de modules) et les macros sont un cauchemar de lisibilité et de maintenance, sans oublier qu'elles pourrissent le scope global.

je partage ton sentiment mais est-ce réellement un problème ? Le templating pose problème aux gens utilisant vraiment le template (les boss quoi), car pour les cas les plus simple j'ai le sentiment que c'est pas plus compliqué que Java pour la très grande des développeurs

Premièrement, Java n'a AFAIK que les génériques et pas le côté méta-programmation, ce n'est donc pas comparable. Ensuite, l'ordre et la nécessité des mots-clefs sont imbitables et les erreur souvent incompréhensibles (cf. l'exemple du post d'ailleurs). Enfin, je doute fortement qu'il faille être un « boss » pour utiliser des génériques (ou alors je suis un dieu de la programmation qui s'ignore :p).

il n'a qu'à utiliser les smart pointer ; non ?

Non, parce que l'ABI des smart pointers n'est pas définie ; donc l'interopérabilité du code n'est garantie que pour des libs headers-only.

la question est plutôt qu'est-ce qui devrait être là aujourd'hui ?

Récupérer boost en dépendance pour pouvoir gérer le FS correctement, c'est tout de même un peu fort ; d'autant plus quand on trouve dans la stdlib des trucs complètement chiadés, mais rien de portable pour récupérer le $HOME. Ensuite, si la culture c'est de récupérer des libs externes pour faire des trucs de base, alors qu'il y ait un gestionnaire de paquets correct (comme pip/gem/cargo/…). On en a vu défiler une kyrielle ces dernières années, mais aucun n'est resté.

pas d'accord car c'est surtout une manière de coder

Pas d'accord, parce que soit on a une stdlib simple et on rajoute plein de trucs en dépendances (comme Rust), mais on se débrouille pour que rajouter des dépendances ne soit pas infernal ; soit un a une stdlib bien remplie (comme python, et pourtant il a pip) et on pense à introduire une fonction pour enlever un élément d'un vecteur avant le générateur de gaussiennes.

pour quelqu'un codant en C++ c'est pas gênant ; je vois pas où est le problème

Parce que ça implique de maintenir plein de choses dans le langage juste pour conserver cette compatibilité, ce qui freine l'évolution du standard.

Je ne vois rien là dedans de catastrophique

Tant mieux pour toi, et je suis sincèrement ravi que tu aies trouvé un langage qui te convienne. Toutefois, je me porte bien mieux depuis que j'ai remplacé C++ par Rust dans ma boîte à outils (instant pub, je conseille à tous les C++-eux d'y jeter un coup d'oeil).

et il me semble qu'ils y travaillent

Depuis 2011, on a réussi à avoir Go, Rust, Swift, Elixir, Nim et sûrement plein d'autres que j'oublie. En C++, on a toujours pas de librairies pour le système de fichiers. Donc s'ils y travaillent, soit ils prennent beaucoup de temps, soit ils n'en ont rien à carrer, soit il passent leur temps à tirer la couverture à eux (de ce que j'ai pu lire par-ci par-là, cette dernière hypothèse serait la plus probable).

le C++ n'a pas vocation à remplacer/dominer tous les autres langages.

Ce n'est pas une question de dominer qui que ce soit ou de savoir qui a la plus grosse qui pisse plus loin, c'est une question de fournir un environnement de travail agréable à l'utilisateur. Et pour ça, C++ ne part pas gagnant.

Je ne suis pas l'OP, mais :

• erreurs catastrophiques ;
• temps de compilation ;
• le préprocesseur, vraiment ?
• le langage de templates qui est parmi les plus abscons, parce qu'il mélange les génériques et la métaprogrammation (ou alors je suis le seul à trouver les templates récursifs imbitables) ;
• parfois de la complexité superfétatoire (= delete, un destructeurs privé virtuel par exemple) ;
• les restrictions contre-intuitives (pourquoi on ne peut pas définir une classe template ailleurs que dans son header ?) souvent dues au préprocesseur ;
• l'évolution rachitique (de l'aveu même de la dépêche, les gars n'ont pas réussi à définir une lib standard réseau ou fichiers en 10 ans) ;
• la gestion mémoire qui accumule plusieurs couches au fil des années (pointeurs nus, références, puis pointeurs intelligents [unique_ptr/shared_ptr/etc.]) ;
• lib standard parfois surprenante (on a une distribution gaussienne, mais pas de vector::delete_at)
• rétro-compatibilité avec le C, mais pas vraiment non plus.

Personnellement, j'aime bien le C++ et je le préfère à bien d'autres langages, mais il faut reconnaître ses défauts ; dont une bonne partie sont ÀMHA imputable à son âge.

C’est notre œil, notre regard, qui nous dicte notre façon d’agir par rapport aux autres. Mais on peut être myope.

Techniquement parlant, les kernels modernes sont à l'aise dans ~100MB RAM (ce qui est partiellement explicable par le plus grand nombre de fonctions, les drivers divers et variés, les caches, les FS, etc.). Ce qui a besoin de 4GB de RAM, ce sont les DE, les navigos, les jeux, etc.