Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 107 sur 107 PremièrePremière ... 7579799100101102103104105106107
Affichage des résultats 3 181 à 3 201 sur 3201
  1. #3181
    Bon, j'ai un problème qui me prends le chou aujourd'hui, j'ai besoin de l'aide des canard parce que j'ai beau fouillé j'y arrive pas.

    J'ai une librairie dynamique qui dépend d'une seconde librairie dynamique.

    Je charge cette seconde librairie dynamique avec dlopen et paf, je récupere un message d'erreur façon "undefined symbol : sem_post" ou "undefined symbol shm_unlink", ce genre de chose.

    Malheureusement ma science du fonctionnement des librairies dynamiques n'est plus ce qu'elle était.

    Normalement, si je ne me trompe pas, quand on charge une librairie avec dlopen on a absolument pas besoin de la charger à la compilation avec des "-lmalib", j'ai bon ?

    Ensuite, la question, c'est comment on peut utiliser une lib dynamique chargé ainsi avec une autre lib dynamique. Avant Ubuntu 20.04 ça marchait parfaitement mon bazare, mais maintenant je ne me souvient même plus comment ça marchait

    Prenons un exemple : j'utilise des fonction de la librairie mathématique dans lib1.so . J'utilise lib1.so dans lib2.so . A ce moment là lib1.so étant une lib dynamique il n'y a pas de lien entre lib2 et lib1 (si je fais ldd on ne trouve pas les noms lié). Quand je compile mon main.c j'ai beau faire ce que je veut, inclure -lm pour lui fournir les fonction mathématique ou quoi, la compilmation passe, mais à l’exécution il ne trouve pas les fonctions qui vont bien.
    Ce qui me parait normal à vrai dire, mais je ne sais plus comment c'est censé fonctionner bien

  2. #3182
    Ouais c'est la confusion entre Dynamic Linking et Dynamic Loading, là tu mélanges.

    On va prendre ce cas:
    App <- Lib1 <- Lib2

    Donc Lib2 est standalone, Lib1 dépend de Lib2 et App dépend de Lib1.

    Dans ce cas tu peux dlopen Lib1 dans App (dynamic loading) mais Lib1 doit (a priori) être linkée avec Lib2 (dynamic linking).

    Dans les deux cas c'est de la résolution de symbole au runtime mais les modalités sont un peu différente, en gros Dynamic Loading c'est le faire "manuellement".

    T'as un exemple complet là

    https://dwheeler.com/program-library...OWTO/x172.html

    (ou ici: https://tldp.org/HOWTO/html_single/C++-dlopen/)

    DL Library Example

    Here's an example from the man page of dlopen(3). This example loads the math library and prints the cosine of 2.0, and it checks for errors at every step (recommended):


    #include <stdlib.h>
    #include <stdio.h>
    #include <dlfcn.h>

    int main(int argc, char **argv) {
    void *handle;
    double (*cosine)(double);
    char *error;

    handle = dlopen ("/lib/libm.so.6", RTLD_LAZY);
    if (!handle) {
    fputs (dlerror(), stderr);
    exit(1);
    }

    cosine = dlsym(handle, "cos");
    if ((error = dlerror()) != NULL) {
    fputs(error, stderr);
    exit(1);
    }

    printf ("%f\n", (*cosine)(2.0));
    dlclose(handle);
    }

    If this program were in a file named "foo.c", you would build the program with the following command:

    gcc -o foo foo.c -ldl
    Donc là on voit bien que la librairie n'est pas linkée à la compilation, mais loadée au runtime "manuellement", et très certainement que la lib dépend d'autres lib, a priori via du dynamic linking.

    ---

    Ensuite chainer du dynamic loading, c'est autre chose, a priori ça marche mais bon faudra bien loader les dépendances dans l'ordre etc.

    Important de noter que le Dynamic Loading en "temps normal" n'est quasiment jamais nécessaire, si tu dynamic link, tu peux hotswap tes librairies, pas durant le runtime mais tu peux juste stopper l'appli, hotswap la lib, et relancer.

    Le seul avantage du Dynamic Loading c'est la possibilité de hotswap durant le runtime, qui très honnêtement est un cas auquel il est très difficile de trouver un intérêt, tu gagnes extrêmement peu à faire ça, voire rien. Et charger des comportements dynamiques au runtime ça s'appelle...: programmer une application!

    Donc je te conseille de toujours rester sur du Dynamic Linking, c'est bien plus solide.

  3. #3183
    Citation Envoyé par Kamikaze Voir le message
    [...]

    Le seul avantage du Dynamic Loading c'est la possibilité de hotswap durant le runtime, qui très honnêtement est un cas auquel il est très difficile de trouver un intérêt, tu gagnes extrêmement peu à faire ça, voire rien. Et charger des comportements dynamiques au runtime ça s'appelle...: programmer une application!

    Donc je te conseille de toujours rester sur du Dynamic Linking, c'est bien plus solide.
    Globalement très d'accord, et j'ajouterai que le Dynamic Loading peut être aussi souvent utilisé dans les mécanismes de plugins (sans pour autant utiliser la possibilité de les recharger plusieurs fois pendant la vie de l'application).
    Dernière modification par Mr Slurp ; 25/09/2020 à 17h53.
    La programmation est une course entre le développeur, qui s’efforce de produire des applications à l’épreuve des imbéciles, et l’univers qui s’efforce de produire de meilleurs imbéciles... L’univers a une bonne longueur d’avance !!!

  4. #3184
    Citation Envoyé par Kamikaze Voir le message
    Ouais c'est la confusion entre Dynamic Linking et Dynamic Loading, là tu mélanges.

    On va prendre ce cas:
    App <- Lib1 <- Lib2

    Donc Lib2 est standalone, Lib1 dépend de Lib2 et App dépend de Lib1.

    Dans ce cas tu peux dlopen Lib1 dans App (dynamic loading) mais Lib1 doit (a priori) être linkée avec Lib2 (dynamic linking).

    Dans les deux cas c'est de la résolution de symbole au runtime mais les modalités sont un peu différente, en gros Dynamic Loading c'est le faire "manuellement".

    T'as un exemple complet là

    https://dwheeler.com/program-library...OWTO/x172.html

    (ou ici: https://tldp.org/HOWTO/html_single/C++-dlopen/)



    Donc là on voit bien que la librairie n'est pas linkée à la compilation, mais loadée au runtime "manuellement", et très certainement que la lib dépend d'autres lib, a priori via du dynamic linking.

    ---

    Ensuite chainer du dynamic loading, c'est autre chose, a priori ça marche mais bon faudra bien loader les dépendances dans l'ordre etc.

    Important de noter que le Dynamic Loading en "temps normal" n'est quasiment jamais nécessaire, si tu dynamic link, tu peux hotswap tes librairies, pas durant le runtime mais tu peux juste stopper l'appli, hotswap la lib, et relancer.

    Le seul avantage du Dynamic Loading c'est la possibilité de hotswap durant le runtime, qui très honnêtement est un cas auquel il est très difficile de trouver un intérêt, tu gagnes extrêmement peu à faire ça, voire rien. Et charger des comportements dynamiques au runtime ça s'appelle...: programmer une application!

    Donc je te conseille de toujours rester sur du Dynamic Linking, c'est bien plus solide.
    Ok merci pour les éclaircissement.
    En fait j'ai fini par trouver ce qui n'allez pas. La "lib2" dans ton exemple dépendaient de pthread et ltr, mais ce n'était pas indiqué à la création de la librairie. Sauf qu'en fait il faut que ça le soit au linkage lorsqu'on créé la librairie lib2 pour que lib 1 puisse gérer la chose et que le App comprenne ce qu'il se passe.

    Maintenant la grande question c'est : pourquoi ce programme fonctionnait parfaitement sous Ubuntu 16 et ne fonctionne plus sous Ubutu 20 (gcc 10) . ... il y a eu un changement autour de pthread et ltr ?

    Bon sinon je crois que l’intérêt ici c'était, dans l'idée d'avoir une appli qui ne charge que le minimum, c'est une appli qui fonctionne en lisant des script qui lancent des sous parties de code C (des "boites") et selon le script on a pas besoin de toutes les boites.
    C'était l'idée à la base, mais en vrai on l'utilise pas trop donc c'est un peu obsolète... (mais je peut pas vraiment changer ça aisément).

    Le but c'était, je pense, de pouvoir avoir un exécutable très petit accompagné juste des .so nécessaire en fonction du script utilisé à cet instant précis. Pour faire de l'embarqué notamment. (oui parce qu'il y a beaucoup de boites, donc ça économise des tonnes de codes).
    Mais avec l'évolution du matériel un exécutable de plusieurs mo ne pose plus vraiment de soucis, même en embarqué.

  5. #3185
    Généralement la pratique c'est de faire du Static Linking pour de l'embarqué. Le truc c'est que le Dynamic Loading n'affecte que la mémoire vive grosso merdo, sur le disque ça prendra la même place, donc l'argument embarqué n'est pas vraiment pertinent, d'autant plus que même avec du Dynamic Linking le truc n'est pas complètement idiot, puis bon ces considérations de "mémoire vive" c'est plus dans le programme lui même, tu gères ta mémoire comme tu veux, sans oublier le paging , y'a plein de systèmes embarqués sans cette distinction mémoire vive vs disque, etc.

    Mais bref on s'éloigne.

    Pour ton problème faudrait que tu redécrives tout à plat, j'arrive pas à suivre tes dépendances exactes. Regarde le code, si y'a une référence à un header, faudra le fournir à la compilation, si c'est du dlopen c'est dynamic loading mais il faudra que le truc loadé fonctionne déjà en standalone, donc qu'il compile et qu'il run en premier lieu.

    Honnêtement si tu poses tout à plat t'es garanti de réussir à faire tourner ton truc, surtout si c'est du C.

    Là je comprends pas si t'essayes de bouger les binaires d'une machine à l'autre, ou autre chose, s'pas clair, c'est la même famille de processeur au moins? Si tu compiles un truc sur du X86 t'sais ça tournera pas sur de l'ARM (bon là ça foire à la résolution de symbole mais s'pour l'exemple)?

    Si tu recompiles tout sur une nouvelle machine c'est garanti que ça fonctionne, si y'a eu une update de pthread qui brise la compatibilité (m'étonnerait mais bon) ça pétera à la compilation et tu verras l'erreur directement.

    En résumé: décris correctement tes dépendances, compile tes trucs dans l'ordre sur la nouvelle machine, du moins dépendant au plus dépendant, si ça casse tu répares.

    Ensuite exécute le bazar et ça devrait être bon, si à l'exécution ça foire je serai surpris.

    En regardant vite fait on dirait qu'il est possible que pthread ait changé d'une version à l'autre. pthread ça veut dire POSIX thread, donc c'est juste une spécification, implémentée différemment selon chaque OS qui est POSIX compliant.

    Donc ouais tu peux pas forcément juste bouger ton binaire, si c'est ce que tu as fait (après je suis pas un expert concernant les garanties de compatibilité qu'ils offrent, perso j'utilise toujours un niveau d'abstraction genre cmake ou autre, et je me soucis pas de ça).

    Ubuntu 16, z'ont ça:
    libc6-dev (2.23-0ubuntu11.2)
    GNU C Library: Development Libraries and Header Files

    Ubuntu 20:
    libc6-dev (2.31-0ubuntu9)
    GNU C Library: Development Libraries and Header Files

    D'après ce thread libc est backward compatible donc je doute qu'on soit sur la bonne voie:

    https://stackoverflow.com/questions/...sions-of-glibc

    ---

    Là ce que j'ai compris c'est

    Lib2 standalone (juste des dépendances système quoi), linkée à Lib1, et l'App dynamic load Lib1 ?

    Donc là il faudrait compiler Lib2, compiler Lib1, compiler l'App puis la lancer.
    Dernière modification par Kamikaze ; 26/09/2020 à 09h11.

  6. #3186
    Citation Envoyé par Kamikaze Voir le message
    Généralement la pratique c'est de faire du Static Linking pour de l'embarqué. Le truc c'est que le Dynamic Loading n'affecte que la mémoire vive grosso merdo, sur le disque ça prendra la même place, donc l'argument embarqué n'est pas vraiment pertinent, d'autant plus que même avec du Dynamic Linking le truc n'est pas complètement idiot, puis bon ces considérations de "mémoire vive" c'est plus dans le programme lui même, tu gères ta mémoire comme tu veux, sans oublier le paging , y'a plein de systèmes embarqués sans cette distinction mémoire vive vs disque, etc.
    Ouais, je sais pas trop l'objectif de l'époque mais c'est comme ça maintenant et j'ai pas vraiment le temps de le retravailler.

    Citation Envoyé par Kamikaze Voir le message
    ...
    Pour le reste le cas précis c'est ça :


    Lib2 :
    C'est la librairie en bout de chaine, elle utilise des fonctions de pthread (sem_post etc.) et ltr (shm_xxx).
    Depuis 1990 que ce programme existe ( ) le programme était compilé très simplement SANS préciser la dépendance à pthread et ltr. En gros c'était un linkage très simple de quelques caractères. (gcc les .o et pif fait le .so)

    Lib1 :
    C'est une librairie qui utilise Lib2 via un linkage dynamique : en gros c'est simplement compilé avec gcc blabla -lLib2 et voila c'est tout et dans la Lib1 on inclut les h de lib2 et on utilise les fonctions de Lib2 et tout marche bien.

    App :
    C'est une app qui charge Lib1 en faisant un dlopen. De 1990 à 2020, sans changement de notre part, ça marchait parfaitement et là paf : unresolved symbol sur sem_post et cie (les symboles venant de la Lib2 via la Lib1)

    Au final j'ai résolu le problème en précisant explicitement à la création de Lib2 qu'il y avait pthread (-pthread) et ltr (-ltr). Et là paf, tout marche.

    Mais pourquoi tout marche maintenant et pas avant, c'est un mystere. Et je confirme que c'est bien QUE sous Ubuntu 20 et gcc 10, puisque j'ai relancé la compilation puis l'execution sur un Ubuntu 16 et ça marchait parfaitement.
    Note que tu peut simplifier grandement le problème si tu veut, sans que ça ne change le problème de fond, puisque j'ai fait un programme test qui charge Lib2 directement en dlopen depuis App et que c'était exactement le même bug. Donc ce n'est pas le chainage le soucis, c'est vraiment le dlopen de Lib2 qui pose problème.

    Sinon pour tes question : on compile toujours le programme en local dans notre cas, même sur embarqué. Comme ça aucun problème.

    Donc ici je parle bien du cas 1 qui marche :
    - compilation sous Ubuntu 16 puis lancement sous Ubuntu 16

    et du cas 2 qui ne marche pas :
    - compilation sous Ubuntu 20 (gcc 10) et lancement sous ubuntu 20.

    Le unresolved symbol était toujours au lancement, aucun problème à la compilation de lib 2, lib1 et app dans les deux cas.
    Alors pourquoi faut-il préciser pthread et ltr de manière exhaustive maintenant, c'est un grand mystère. Et en soit c'est assez chelou. J'avais enregistrer pour ma part que ça ne servait à rien de précise les dépendance à la création d'une librairie mais qu'il fallait plutot les redonner au programme final ...

  7. #3187
    Pas de changements des autres dépendances de ton application ? Peut-être qu'un de ces dépendances préchargeait libpthread et librt pour toi.

  8. #3188
    Ouais a priori pthread et consors étaient linkés silencieusement, possible selon le compilo ou autre (chaines de dépendances, du coup system specific). Il faut toujours linker pthread explicitement de manière générale, ou quelque dépendance que ce soit (faut bien un moyen de résolution)

    J'ai trouvé une histoire similaire ici: https://gcc.gnu.org/legacy-ml/gcc-he.../msg00263.html

  9. #3189
    Citation Envoyé par Cwningen Voir le message
    Pas de changements des autres dépendances de ton application ? Peut-être qu'un de ces dépendances préchargeait libpthread et librt pour toi.
    Nop comme je l'ai précisé, j'ai fait ctrl-c ctrl-v de l'appli sur un Ubuntu 16 et ça a compilé alors que ça ne fonctionnait pas sous Ubuntu 20 + gcc 10

    - - - Mise à jour - - -

    Citation Envoyé par Kamikaze Voir le message
    Ouais a priori pthread et consors étaient linkés silencieusement, possible selon le compilo ou autre (chaines de dépendances, du coup system specific). Il faut toujours linker pthread explicitement de manière générale, ou quelque dépendance que ce soit (faut bien un moyen de résolution)

    J'ai trouvé une histoire similaire ici: https://gcc.gnu.org/legacy-ml/gcc-he.../msg00263.html
    OK, c'est quand même surprenant ce changement "silencieux" sur les versions récentes, j'ai rien trouvé de spécial de mon coté
    Enfin bon, quoi qu'il en soit ça fonctionne ...

  10. #3190
    Putain, la dernière fois sur le topic je découvrais à quel point les mecs qui développent les drivers uboot sont des tanches, et là je découvre la programmation à la pisse de ffmpeg, c'est impressionnant de coder aussi mal, j'ai du mal à croire que le truc tourne tellement c'est laid.

    La documentation est en lice pour le titre du pire torchon jamais sorti, côte à côté avec cette moisissure d'OpenSSL. J'arrive pas à y croire, quand je pense que j'idolatrais à moitié les mecs qui faisaient ce genre de projet.

    Je comprends mieux toutes les news de vulnérabilités sur tel ou tel projet, c'est tellement le bazar, déjà un miracle que ça s'écroule pas, que la vérification de la solidité du truc que ce soit en terme de perf ou de sécurité tu peux oublier

  11. #3191
    Un soucis avec les projets communautaires, c'est que parfois la gestion des collaborateurs est délicate. Il y a des projets où des gens fournissent une fonctionnalité dans un gros bout de code, tout moche, difficile à relire. Mais au moins il y a une contribution, et les bonnes âmes se faisant rares lorsqu'il sagit de se retrousser les manches et coder, les responsables peuvent être tentés d'accepter les contributions, même les pires. Ce n'est pas une très bonne idée, mais c'est parfois ce qui maintient le projet en vie.

    Il y a aussi le problème des contributeurs qui n'assurent pas le suivi, sur le long terme ni sur le court terme, par exemple en ne répondant même pas aux retours sur une merge request (c'est je t'ai envoyé le code, tu l'acceptes ou tu le jettes, en gros). Je ne pourrais pas le leur reprocher, c'est très difficile, ni engageant (personne n'aime déboguer, alors que pousser de nouvelles features, c'est sympa et, surtout, c'est ça qui est visible ; et je ne parle pas du manque de temps libre...) surtout si tu touches à plein de projets, mais voilà, ça laisse le projet dans un mauvais état.
    Bref, sur un projet pro j'aurais du mal à excuser une mauvaise base de code, mais sur de l'opensource, j'ai envie de mettre une main sur l'épaule d'un mainteneur et lui dire avec plein de compassion "t'inquiète, je souffre avec toi". L'opensource, c'est rarement un groupe de barbus qui code ensemble dans un garage en regardant des comics. Pas mal se prennent pour les fils spirituels de Torvald, et ce n'est pas un bon exemple le type (d'après sa réputation, du moins). Il y a évidemment de bonnes communautés, peut être plus sympas/connes selon les technos, ché pas...

    Enfin, peut être que certains projets trop vieux (ça joue) ou mal en point devraient annoncer leur mort publiquement, faire un reset et repartir sur des bases saines.
    Par ex sur GitHub, combien de projets sans commit depuis 5 ans ? Sont-ils encore utilisables ? Parfois oui car la techno n'a pas bougé, parfois plus du tout. GitHub a pourtant une fonctionnalité d' "archivage", qui freeze le projet et le marque comme arrêté, mais trop peu de monde ne prend la peine de s'en servir, et préfère laisser son projet là, comme un zombie.
    Ffmpeg est peut être dans ce cas là : commencé (je n'affirme rien) à une époque ou les bonnes pratiques n'étaient pas ce qu'elles sont aujourd'hui, trop peu de sérieux ou de compétences, c'est devenu du bricolage. Un bon reset lui ferait du bien. Y'a d'ailleurs une lib SSL connue qui a fait ça nan ? LibreSSL ou un truc comme ça je crois, qui s'est fait connaître pour être jeune, plus petite et plus sûre que les grandes libs SSL toutes vieilles et moches. On en reparlera après un audit de sécurité ^^, mais ça fait du bien je trouve.

    Bon, après y'a aussi de vraies quiches hein ^^
    Dernière modification par gros_bidule ; 08/10/2020 à 00h27.

  12. #3192
    Ouais clairement, pour balancer mes propos FFMPEG donne l'impression de bien fonctionner en tout cas, c'est tout a fait utilisable a priori.

    Puis je me plaindrais jamais vraiment des projets open source, souvent c'est des mecs qui prennent sur leur temps sans vraie contrepartie.

    Simplement que c'est vraiment implémenté n'importe comment à tel point que ça donne des doutes quant à certaines fonctionnalités. Mais bon c'est aussi le style C old school j'imagine ou chacun fait ses abstractions à sa sauce. Et en effet on a l'impression sur certaines parties que c'est le travail d'une seule personne qui s'est pas soucié des gens qui allaient passer derrière.

    Faut quand même que j'aille jeter un oeil aux algos core voire si ça fait le travail correctement

  13. #3193
    Rien ne t’empêche de participer. Enfin j’écris ça mais je n’ai pas le niveau.
    une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
    Canard zizique : q 4, c, d, c, g, n , t-s, l, d, s, r, t, d, s, c, jv, c, g, b, p, b, m, c, 8 b, a, a-g, b, BOF, BOJV, c, c, c, c, e, e 80, e b, é, e, f, f, f, h r, i, J, j, m-u, m, m s, n, o, p, p-r, p, r, r r, r, r p, s, s d, t, t
    Canard lecture

  14. #3194
    Oui tout à fait, c'est ce que j'entendais notamment par: "je me plaindrais jamais vraiment des projets open source". Le principe c'est que tu peux contribuer.

    Mais en effet y'a moyen que j'y contribue, là en ce moment j'adapte toute cette soupe derrière une API claire (et je convertis ça en C++, mais ça c'est clairement un no-go pour eux, j'imagine qu'ils veulent la compatibilité du C), et je posterai p'têt ça sur Github à part.

  15. #3195
    Bin ffmpeg, c'est un projet qui a quasi 20 ans, ce n'est pas rien.
    Et il est aussi possible qu'une partie du code "moche" soit du à une nécessité d’extrême optimisation du code .

  16. #3196
    Citation Envoyé par olih Voir le message
    Bin ffmpeg, c'est un projet qui a quasi 20 ans, ce n'est pas rien.
    Et il est aussi possible qu'une partie du code "moche" soit du à une nécessité d’extrême optimisation du code .
    Ça joue mais c'est clairement pas la seule raison.

    Faut pas oublier que pas mal de contributions viennent de gens avec un background recherche/vidéo/signal/bas niveau et assez rarement "génie logiciel" (pour ce que ça peut vouloir dire).

    J'ai plusieurs potes qui ont fait des thèses dans la compression vidéo, avec des contributions pour HEVC/AVC et/ou ffmpeg. Et autant les mecs sont pointus dans leur domaine, autant j'aurais vraiment du mal à les considérer comme de "bons" dévelopeurs (et encore, avec les ressources actuelles c'est toujours plus propre que dans le code legacy qui a 20ans).
    C'est la faute à Arteis

  17. #3197
    Bonjour ! Je suis récemment tombé sur l'IDE Microsoft Visual Studio Code sur lequel j'ai pu bosser sur mes projets en python, pour changer de Jupyter Notebook. Franchement, j'aime beaucoup, surtout avec les modules disponibles.

    J'ai vu qu'il existe aussi Microsoft Visual Studio, également gratuit pour les particuliers. Mais, même en cherchant sur le net, j'ai pas trop compris la différence entre les deux (je ne comprends pas non plus tout ce qui est dit dans les fonctionnalités). Un truc qui m'intéresse dedans est le fonctionnement avec la suite Azure, si je me forme à ça. Est-ce que le premier est une sorte de version light du second ?

    Est-ce qu'un expert CPC a une idée ?

  18. #3198
    VS Code est compatible Linux et se veut plus généraliste : +facile de trouver des modules pour tout un paquet de langages via les modules. Visual Studio est plus tourné autour de C# et VB.net (même si des modules existent pour d'autres langages, notamment python/IronPython) et du developpement pour Windows, même si ce dernier point est de moins en moins vrai. Visual Studio est aussi plus "lourd", plus gourmand que VS Code.

    Je travaille principalement sur Linux et utilise plusieurs langages (bash, python, SQL, Lua ) et j'utilise VS Code mais ça dépend des usages donc.

  19. #3199
    Visual Studio n'est pas qu'un éditeur de texte, c'est toute l'ensemble des outils de développement Microsoft en plus de l'IDE : compilateurs, bibliothèques, ...

  20. #3200
    VS : c'est l'IDE historique, qui dit IDE dit un ensemble d'outils et d'intégrations diverses (tests unitaires, analyse performance, mémoire, tests d'infrastructure/de charge, etc)
    VS Code : c'est le petit nouveau, entre l'éditeur de texte avancé (type Sublime text/Atom) et le véritable IDE.

    En fonction de ce que je fais j'utilise l'un ou l'autre.
    Découvrez les Frontières Virtuelles - Mon Portfolio Photo - Utilisateur de Spotify ? Essaye donc ce soft !

  21. #3201
    Ah merci ! Bah j'imagine que je suis trop noob en programmation pour avoir besoin de VS du coup, je vais continuer à utiliser VS Code

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •