Le topic de la programmation: Et envoyez des sioux!

[Whiskey]

dois avoir un truc qui bloque l'execution, je vais tester différentes chose.

[Anonyme20240202]

Ouaip. J'ai pas d'antivirus non plus, mis à part ptet certains trucs windows par défaut

[Whiskey]

Ouaip. J'ai pas d'antivirus non plus, mis à part ptet certains trucs windows par défaut

J'ai ESET, mais ce n'est pas l'antivirus, j'ai stopper et pareil. Bon ben vais passer la soirée a chercher Merci en tout cas.

[Anonyme20240202]

Reviens nous dire quand tu trouves, c'est très curieux ton histoire

[vectra]

Si tu veux vérifier l'exécution: débogue!
Simple, efficace, rapide. Surtout sous CLion.

Au pire, si tu veux vérifier que ta ligne passe sans débogueur, tu peux écrire dans un fichier à la place...
Il n'y a pas de raison que l'affichage sur le flux ne se fasse pas à la fin du programme, surtout si tu fais un std::flush pour forcer le vidage du flux à un instant donné.

De manière générale, développer sous Windows, c'est de la grosse merde. Microsoft a sa vision conne du développement et si tu ne rentre pas dedans, ça va devenir vite compliqué.
Tu n'aurais pas le dixième de ces ennuis avec un environnement Linux. Tu débutes? Ubuntu...

Une solution intermédiaire serait de compiler et tester ton exe sur WSL: au moins tu saurais si le problème vient d'une merde subtilité windows ou d'autre chose.
Je me souviens que l'environnement d'exécution de CLion est différent de celui que tu aurais sur un terminal, mais c'est vraiment sous Win que ça pose des problèmes (applications terminal, applications graphiques: aller niquer vos mères).

[Whiskey]

@Kamikaze

Pas de soucis

- - - Mise à jour - - -

Si tu veux vérifier l'exécution: débogue!
Simple, efficace, rapide. Surtout sous CLion.

Au pire, si tu veux vérifier que ta ligne passe sans débogueur, tu peux écrire dans un fichier à la place...
Il n'y a pas de raison que l'affichage sur le flux ne se fasse pas à la fin du programme, surtout si tu fais un std::flush pour forcer le vidage du flux à un instant donné.

De manière générale, développer sous Windows, c'est de la grosse merde. Microsoft a sa vision conne du développement et si tu ne rentre pas dedans, ça va devenir vite compliqué.
Tu n'aurais pas le dixième de ces ennuis avec un environnement Linux. Tu débutes? Ubuntu...

Une solution intermédiaire serait de compiler et tester ton exe sur WSL: au moins tu saurais si le problème vient d'une merde subtilité windows ou d'autre chose.
Je me souviens que l'environnement d'exécution de CLion est différent de celui que tu aurais sur un terminal, mais c'est vraiment sous Win que ça pose des problèmes (applications terminal, applications graphiques: aller niquer vos mères).

Hum, ce qui m'étonne surtout c'est que avec Go ou Rust, j'ai aucun soucis. Mais avec g++ (le C avec gcc marche tres bien) ca merde.

J'ai testé la commande :

./main.exe > readme.txt

Il n'écris rien dedans... On dirait qu'il y a un prog qui intercepte la sortie et annule tout....

[Anonyme20240202]

J'pense pas que la compilation soit le problème vu que ça tourne chez moi. À la limite le seul truc que je verrais c'est un truc genre glibc, le runtime quoi, qui est link dynamiquement, et chez toi ça pointe sur de la merde. Pour ça que ça tourne normal chez moi et pas chez toi.

Genre tu compiles avec une version de mingw, mais quand tu run ça va pointer sur une autre version, un truc du genre.

Pour ton exe que tu m'as envoyé ça donne ça

Microsoft (R) COFF/PE Dumper Version 14.29.30151.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file main.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    libstdc++-6.dll
    KERNEL32.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-private-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll

  Summary

        1000 .CRT
        1000 .bss
        1000 .data
        1000 .debug_abbrev
        1000 .debug_aranges
        1000 .debug_frame
        1000 .debug_info
        1000 .debug_line
        1000 .debug_line_str
        1000 .debug_str
        1000 .eh_frame
        1000 .idata
        1000 .pdata
        1000 .rdata
        1000 .reloc
        3000 .text
        1000 .tls
        1000 .xdata

Donc peut être que tu as plusieurs install, un truc du genre, et que Clion a le bon environnement mais pas tes terminaux

- - - Mise à jour - - -

Ca en particulier, j'ai déjà vu un problème du genre: libstdc++-6.dll

Je suis à peu près sûr que tu vas voir quand ton $PATH, c'est dans le mauvais ordre, et que au début tu as une vielle version et que la bonne version est à la fin. (en priorité ça cherche dans l'ordre dans lequel c'est affiché dans le $PATH)

- - - Mise à jour - - -

En particulier si tu as installé Git (avec git bash là par défaut). Il me semble que leur installeur à la pisse, va modifier ton Path et ils fournissent un libstdc++-6.dll pas compatible

- - - Mise à jour - - -

echo $env:Path

- - - Mise à jour - - -

En mode bourrin tu peux installer un truc qui chercher tous les fichiers là (genre ça: https://www.voidtools.com/)

Et cherche libstdc++-6.dll, je parie que tu en verras plusieurs, genre

c/mingw64/bin/libstdc++-6.dll
c/ProgramData/mingw64/mingw64/bin/libstdc++-6.dll

Quelque chose comme ça

Et si dans ton Path ça va chercher dans le mauvais dossiers, ça fonctionnera pas

[Whiskey]

J'pense pas que la compilation soit le problème vu que ça tourne chez moi. À la limite le seul truc que je verrais c'est un truc genre glibc, le runtime quoi, qui est link dynamiquement, et chez toi ça pointe sur de la merde. Pour ça que ça tourne normal chez moi et pas chez toi.

Genre tu compiles avec une version de mingw, mais quand tu run ça va pointer sur une autre version, un truc du genre.

Pour ton exe que tu m'as envoyé ça donne ça

Microsoft (R) COFF/PE Dumper Version 14.29.30151.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file main.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    libstdc++-6.dll
    KERNEL32.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-private-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll

  Summary

        1000 .CRT
        1000 .bss
        1000 .data
        1000 .debug_abbrev
        1000 .debug_aranges
        1000 .debug_frame
        1000 .debug_info
        1000 .debug_line
        1000 .debug_line_str
        1000 .debug_str
        1000 .eh_frame
        1000 .idata
        1000 .pdata
        1000 .rdata
        1000 .reloc
        3000 .text
        1000 .tls
        1000 .xdata

Donc peut être que tu as plusieurs install, un truc du genre, et que Clion a le bon environnement mais pas tes terminaux

- - - Mise à jour - - -

Ca en particulier, j'ai déjà vu un problème du genre: libstdc++-6.dll

Je suis à peu près sûr que tu vas voir quand ton $PATH, c'est dans le mauvais ordre, et que au début tu as une vielle version et que la bonne version est à la fin. (en priorité ça cherche dans l'ordre dans lequel c'est affiché dans le $PATH)

- - - Mise à jour - - -

En particulier si tu as installé Git (avec git bash là par défaut). Il me semble que leur installeur à la pisse, va modifier ton Path et ils fournissent un libstdc++-6.dll pas compatible

- - - Mise à jour - - -

echo $env:Path

- - - Mise à jour - - -

En mode bourrin tu peux installer un truc qui chercher tous les fichiers là (genre ça: https://www.voidtools.com/)

Et cherche libstdc++-6.dll, je parie que tu en verras plusieurs, genre

c/mingw64/bin/libstdc++-6.dll
c/ProgramData/mingw64/mingw64/bin/libstdc++-6.dll

Quelque chose comme ça

Et si dans ton Path ça va chercher dans le mauvais dossiers, ça fonctionnera pas

Git n'a rien a voir avec le soucis. J'ai enlever tout les accès a git dans la variable $path et le problème reste inchangé. Ceci dit je vois le probleme que tu veux me montrer , mais malheureusement non fonctionnel.

[Anonyme20240202]

Git c'tait juste un exemple car ils shippent libstdc++-6.dll

Change ton programme et mets ça à la place

#include <cstdio>

int main() {
    std::printf("hello world");
    return 0;
}

Si ça fonctionne, ça veut dire que c'est le problème de dynamic linking que je mentionne

[Whiskey]

Git c'tait juste un exemple car ils shippent libstdc++-6.dll

Change ton programme et mets ça à la place

#include <cstdio>

int main() {
    std::printf("hello world");
    return 0;
}

Si ça fonctionne, ça veut dire que c'est le problème de dynamic linking que je mentionne

Cela fonctionne. Au moins j'avance Et c'est quoi le problème "dynamic linking" exactement ?

[Anonyme20240202]

Ouais je mets gros sur un problème avec libstdc++-6.dll, sûrement plusieurs versions et la version qui est link au runtime est différente de la version avec laquelle t'as compilé

[Whiskey]

Bon, je pense avoir résolu le problème. J'ai neovim installé sur mon systeme, il utilise aussi une version de libstd. J'ai viré ce soft (dommage) et maintenant par miracle, cela marche.....

c'est confirmé. Merci pour votre aide

[Anonyme20240202]

Si tu regardes le compilateur que tu penses utiliser dans tous tes exemples (je mets "pense" juste au cas ou tu n'as pas bien bien vérifié et qu'en fait on parle de compilos différents).

Par exemple disons que c'est le mingw de WinLibs. Il ship une version de libstdc++-6.dll

Chez moi dans C:\Users\<username>\AppData\Local\Programs\CLion\b in\mingw\bin\



Quand tu lances ton programme, il va chercher libstdc++-6.dll pour pouvoir run, je sais pas si t'es familier avec dynamic vs static linking. Tu peux te renseigner la dessus avec google.

Dans ton cas tu dois avoir une vieille install obsolète avec un autre libstdc++-6.dll qui ne fonctionne pas. Cette lib fournit des trucs de base, typiquement afficher un truc sur stdout (dans le terminal).

Tu pourrais résoudre le problème en linkant cette lib de manière statique mais c'est un peu une rustine quoi, autant régler le problème "proprement", s'pas vraiment une bonne pratique de static link ça

- - - Mise à jour - - -

Bon, je pense avoir résolu le problème. J'ai neovim installé sur mon systeme, il utilise aussi une version de libstd. J'ai viré ce soft (dommage) et maintenant par miracle, cela marche.....

c'est confirmé. Merci pour votre aide

C'est pas le soft en lui même qui pose problème, tu pourras le réinstaller sans soucis. C'est juste qu'il faut que tu gère ton $PATH pour qu'il pointe vers la bonne version.

Pour ça il faut mettre en premier dans le path, le chemin vers le compilo qui fournit libstdc machin là

[Whiskey]

Si tu regardes le compilateur que tu penses utiliser dans tous tes exemples (je mets "pense" juste au cas ou tu n'as pas bien bien vérifié et qu'en fait on parle de compilos différents).

Par exemple disons que c'est le mingw de WinLibs. Il ship une version de libstdc++-6.dll

Chez moi dans C:\Users\<username>\AppData\Local\Programs\CLion\b in\mingw\bin\

https://i.ibb.co/bB8mBbf/image.png

Quand tu lances ton programme, il va chercher libstdc++-6.dll pour pouvoir run, je sais pas si t'es familier avec dynamic vs static linking. Tu peux te renseigner la dessus avec google.

Dans ton cas tu dois avoir une vieille install obsolète avec un autre libstdc++-6.dll qui ne fonctionne pas. Cette lib fournit des trucs de base, typiquement afficher un truc sur stdout (dans le terminal).

Tu pourrais résoudre le problème en linkant cette lib de manière statique mais c'est un peu une rustine quoi, autant régler le problème "proprement", s'pas vraiment une bonne pratique de static link ça

- - - Mise à jour - - -



C'est pas le soft en lui même qui pose problème, tu pourras le réinstaller sans soucis. C'est juste qu'il faut que tu gère ton $PATH pour qu'il pointe vers la bonne version.

Pour ça il faut mettre en premier dans le path, le chemin vers le compilo qui fournit libstdc machin là

Sans doute, je vais continuer pendant les prochains jours a voir si il y a d'autre logiciel qui pourraient utiliser une version de stdc++inadéquate, mais la ca à l'air de passer dans le bon sens.

Je regrette franchement le temps ou je développait sur borland c++ 3.0, auquel tout marchait sans aucun soucis ^^

Je me répète, mais dans tout les cas, merci pour l'aide, sans cela j'aurais vite abandonné.

[Anonyme20240202]

Pas de soucis, ouais j'ai p'têt pas été clair avec mes histoires de $Path, je te fais la version complète comme ça tu pourras t'organiser comme tu veux.

Si tu affiches la variable d'environnement qu'on appelle "Path", sous windows:

echo $env:Path

Tu verras tout un tas de chemins, genre:

C:\chemin1;C:\chemin2 etc...

Quand tu lances un programme (et c'est pareil avec Go ou Rust, s'pas vraiment un problème lié au C++ en particulier)
Ton programme va dans 90% des cas charger du contenu externe, des .dll sous windows, des lib.a sous unix, peu importe.
C'est du binaire, du code compilé, que ton programme va utiliser.

Dans ton cas ton problème était le suivant en gros:

$env:Path qui ressemble à ça: C:\neovim\;C:\mon-super-compilo\

Donc quand ton programme se lance il va chercher d'abord dans neovim, car c'est ordonné (il va fouiller de gauche à droite), il va trouver C:\neovim\libstd-moisi.dll et planter.

Si tu update ton Path, pour faire en sorte que la bonne lib soit sélectionnée, en le mettant au début, du genre C:\mon-super-compilo\;C:\neovim\;

Ca résoudra ton problème.

Mais faudrait aussi vérifier toutes les combinaisons car je connais pas ton setup, ça se trouve t'étais dans une configuration où t'as un compilo obsolète, donc il s'attends à libstd obsolète (alors que neovim est à jour).
Ou alors justement t'as compilo à jour, mais neovim utilise un vieux truc pas à jour et il se trouve qu'il est au début dans le path, etc.

- - - Mise à jour - - -

Ah et pour finir il y a le cas ou le Path est modifié par certains terminaux...

Par exemple Git Bash quand tu le lances il va modifier ton Path, donc c'est pour ça que tu peux avoir le programme qui fonctionne dans un terminal et pas dans l'autre.

Donc dans chaque terminal tu peux vérifier la variable Path et voir si elle est la même partout, ou si y'a des diffs

[Whiskey]

Donc si je comprend bien si je met la lib WinLibs (dans mon cas) en premiere position cela devrait résoudre mon soucis ?


----

Bon j'ai mis WinLibs tout en haut, et reinstaller neovim, cela marche toujours, donc j'imagine que tout est bon.

[Anonyme20240202]

Yep! Si j'ai bien suivi (et que tu t'es pas emmêlé les pinceaux ) c'est ça, vérifie que le dossier que tu mets au début contiennent bien cette fameuse .dll et tu seras bon, et c'est sans risque.

Après tu as aussi l'option de nettoyer ton Path de tous les autres chemins qui contiennent une autre version de libstd et n'ont rien à faire là. Par exemple je connais pas neovim, mais ça se trouve le programme est "malpoli" et se permet d'éditer ton path lors de l'installation (un peu la même histoire de ce que je mentionnais avec git)

Après je le mentionne juste pour info, tu as l'option de static link, qui va embed (intégrer) la lib que tu as utilisée à la compilation, dans ton programme. Ton programme sera donc plus lourd (en KB), mais indépendant des libs installées sur le système

https://stackoverflow.com/a/6405064 Ils en parlent ici, le flag -static-libstdc++ apparemment

If you are using MingW to compile C++ code on Windows, you may like to add the options -static-libgcc and -static-libstdc++ to link the C and C++ standard libraries statically and thus remove the need to carry around any separate copies of those. Version management of libraries is a pain in Windows, so I've found this approach the quickest and cleanest solution to creating Windows binaries.

J'te recommande pas de static link pour le moment, mets juste ton système d'équerre

- - - Mise à jour - - -

Et aussi double check en lançant un terminal, que tu n'as pas un script qui s'amuse à éditer le Path. Donc une fois que tu as édité la variable, vérifie qu'elle est bonne dans le terminal en question.

Y'a plusieurs manière de modifier une variable d'environnement, tu peux le faire en gros de manière permanente ou temporairement

Ca c'est temporaire:

set PATH=%PATH%;C:\your\path\here\

Via la GUI c'est permanent dans tous les terminaux ouverts après l'avoir mis à jour.

J'te fais la version courte

[Whiskey]

Normalement, y a rien qui modifie le path actuellement, quand je lance le terminal. Bon ca a l'air de passer plutot bien pour le moment. Je vais croiser les doigts pour que cela reste. Dans tout les cas, la désinstallation de neovim a débloqué le soucis. Dans l'environnement $path, neovim a passé avant winlibs, ce qui peut expliquer le problème.

Par contre, entre parenthèse, winlibs est detecter comme virus par ESET (le programme ld.exe en particulier), ceci dit d'après mes recherches c'est un faux positif. J'imagine que c'est vrai.

[Anonyme20240202]

Oui ld c'est le linker, c'est banal. Je connais pas ESET mais ça doit être de la daube

- - - Mise à jour - - -

('fin j'y vais un peu fort, c'est juste que comme la majorité des antivirus il te considère comme une personne vulnérable qui ne connait rien à l'informatique, donc un linker, truc orienté dev, compilé par des gentils mecs open source ça va faire une alerte, alors qu'un malware du windows store non)

https://www.mingw-w64.org/downloads/

T'as d'autres alternatives ici, si jamais winlibs te revient pas

[Whiskey]

Oui ld c'est le linker, c'est banal. Je connais pas ESET mais ça doit être de la daube

- - - Mise à jour - - -

('fin j'y vais un peu fort, c'est juste que comme la majorité des antivirus il te considère comme une personne vulnérable qui ne connait rien à l'informatique, donc un linker compilé par des gentils mecs open source ça va faire une alerte, alors qu'un malware du windows store non)

https://www.mingw-w64.org/downloads/

T'as d'autres alternatives ici, si jamais winlibs te revient pas

De la daube, je pense pas mais juste un antivirus parmis tant d'autre qui aime faire du superflus. J'ai pris winlibs car plutot conseilllé sur la toile et surtout, celui qui a gcc le plus a jour. Cependant il est cité nulle part comme outils néfaste.

De plus ESET ne détecte aucun virus sur l'outil en lui meme. ce qui me conforte un peu sur le coté faux positif.

[Anonyme20240202]

C'est mon côté poète

- - - Mise à jour - - -

Quoique vu le prix, peut être que c'est de la daube, je réserve mon jugement à plus tard

[Whiskey]

Dans tout les cas merci pour ton aide

[Anonyme20240202]

J'tenvoie la facture par mail

Cordialement,

[Papeyo]

Hello,

J'ai une question en C. Est-ce qu'on peut faire une déclaration de variable à l'intérieur d'un test conditionnel

if (signed)
 int32_t ma_variable = 0;
else
 uint32_t ma_variable = 0;
ma_variable = autre_variable;

Bon, le compilateur me dit que non ^^
Est-ce qu'il y a un moyen simple de faire l'équivalent ?

Merci !

(J'ai un morceau de code qui sauvegarde des valeurs qui parfois sont signed et parfois unsigned et je voudrais bien un truc un peu générique)

[William Vaurien]

C'est pas à ça que servent les union ?
https://zestedesavoir.com/tutoriels/...es/les-unions/

Je fais un peu de C mais je ne me suis jamais servis de ce genre de structure mais ça ressemble à ce que tu veux.
Mais ça n'a pas l'air super pratique à utiliser et ça ressemble à une struct... avec juste un peu d'économie de stockage (donc pas forcément très utile).

[vectra]

Typage statique en C/C++.
Pour ce que tu veux faire, emploie déjà des templates C++ si tu veux des fonctions qui ont un comportement générique pour plusieurs types différents: ça sera déjà un bon début peut-être?

[Nilsou]

Faudrait un contexte probablement, je vois pas le cas d'application là ... j'ai du mal à savoir comment tu te dépatouille à avoir une variable d'entrée d'un type inconnu

De fait difficile de savoir ce qui lui irait le mieux.

Sinon je vois comment le faire à base d'allocation dynamique si tu alloue dynamiquement le machin et que tu le mets dans un pointeurs void* tu devrait avoir l'espace qui va bien en signed ou unsigned. Mais derrière pour t'assurer que c'est bien le bon format qui est rentrée dans cet espace il faudra faire des if tout partout pour faire une conversion explicite ...

Pas sur que ça fonctionne mais en gros :

void* ma_variable = NULL;
if (signed)
ma_variable = malloc(sizeof(int32_t));
else
ma_variable = malloc(sizeof(uint32_t));

if (signed)
*((int32_t*)ma_variable) = autre_variable;
else
*((uint32_t*)ma_variable) = autre_variable;


Bon, en trifouillant la syntaxe ça doit marche j'imagine, mais c'est sale.

[rOut]

Si c'est juste pour une question de signe tu peux tout foutre dans un uint, je vois pas trop le problème.

[Papeyo]

C'est pas à ça que servent les union ?
https://zestedesavoir.com/tutoriels/...es/les-unions/

Je fais un peu de C mais je ne me suis jamais servis de ce genre de structure mais ça ressemble à ce que tu veux.
Mais ça n'a pas l'air super pratique à utiliser et ça ressemble à une struct... avec juste un peu d'économie de stockage (donc pas forcément très utile).

J'ai regardé vite fait, de ce que je comprends il faut un nom de variable par type là où je voudrais avoir un nom de variable unique pour les 2 types.

Faudrait un contexte probablement, je vois pas le cas d'application là ... j'ai du mal à savoir comment tu te dépatouille à avoir une variable d'entrée d'un type inconnu

En l'occurence, c'est des données de capteurs, j'ai une information du type de capteur puis la donnée du capteur. Donc si la donnée renvoie la température, j'ai 16b signée mais si c'est l'humidité, j'ai 16b non signée. Des types de données capteur, j'en ai de toutes les formes, je veux donc faire un truc générique.
Actuellement, je convertis tout en 32b non signé, mais forcément, si ma température est négative, j'obtiens un 65530

[rOut]

La valeur en mémoire est la même, que ça soit signé ou non. C'est quand tu vas faire ton affichage ou des calculs que tu vas devoir choisir entre signé ou non. Par simplicité, ici vu que tu lis 16bits et que tu fais (peut être?) des calculs, je te suggère de tout foutre dans un int signé 32bit. Tes valeurs non-signées ou non 16bits sont toutes représentables sans problème de collision.

En gros:

int valeur;

if (signe)
  valeur = (int16_t)data;
else
  valeur = (uint16_t)data;

Et tu auras comme il convient, le bit de signe de data étendu ou non suivant le cas.