g++ et fichiers image/son

Version imprimable

28/01/2023, 14h46
adiya

g++ et fichiers image/son

Bonjour

j ai essayé de me renseigner... mais je ne trouve pas...

est il possible, au moyen de g++ de faire une edition de liens avec :
* les codes sources
* les bibliotheques SFML
* ET les fichiers son/images...

avec l idee d obtenir un executable contenant tout cela ?

merci de votre aide.

Je connais 2 façons de faire :mrgreen: C'est

1) de transformer chaque fichier en chaîne de caractères (avec des caractères imprimables)/ tableau de valeurs et les introduire dans le code sous forme de macro/ variable [globale]/ fonction/ ...
Édit : @jo_link_noir dans 1 commentaire en dessous me signale que 1 tableau de valeurs hexadécimales est préférable que transformer son fichier en chaîne de caractères. Cela dépend du contexte je dirais.

2) d'utiliser RC, Resource Compiler de Microsoft. Je te laisse chercher :google:
Il faut faire 1 fichier .rc [/ .res] qui va faire correspondre chaque ressource via 1 identifiant, identifiant qui sera utilisé dans le code.
Par contre, il faut sûrement utiliser 1 IDE Microsoft. Et sous Linux, il doit y avoir 1 équivalant ou passer par Qt/ Gnome-GTK.

Exemple de fichier .rc avec C++ Builder :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
#if defined(_CPP_BUILDER) || defined(_CPP_BUILDER_xe6)
#include "..\\Project\\Resources\\my_winresrc.h"
#else
#include <windows.h>
#endif
 
 
#include "Resource.h"
 
 
LANGUAGE LANG_FRENCH, SUBLANG_FRENCH
#pragma code_page(1252)
 
 
1 TEXTINCLUDE DISCARDABLE
BEGIN
  "Resource.h\0"
END
 
 
2 TEXTINCLUDE DISCARDABLE
BEGIN
   "#include ""winver.h""\r\n"
   "\0"
END
 
 
3 TEXTINCLUDE DISCARDABLE
BEGIN
  "\r\n"
  "\0"
END
 
 
VS_VERSION_INFO  VERSIONINFO
  FILEVERSION    PROJECT_IHM_VERSION
//PRODUCTVERSION PRODUCT_VERSION
  FILEOS         VOS_WINDOWS32
  FILETYPE       VFT_APP
BEGIN
  BLOCK "StringFileInfo"
  BEGIN
    BLOCK "040C04E4"
    BEGIN
      VALUE "CompanyName",      COMPANY_NAME
      VALUE "ProductName",      PRODUCT_NAME
      VALUE "ProductVersion",   PRODUCT_VERSION_STR
      VALUE "LegalCopyright",   LEGAL_COPYRIGHT
      VALUE "FileVersion",      PROJECT_IHM_VERSION_STR
      VALUE "InternalName",     PROJECT_IHM_NAME
      VALUE "OriginalFilename", PROJECT_IHM_NAME
      VALUE "FileDescription",  PROJECT_IHM_DESCRIPTION_FR
    END
  END
 
  BLOCK "VarFileInfo"
  BEGIN
    VALUE "Translation", 0x040C, 0x04E4
  END
END
 
 
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
 
 
MAINICON  ICON DISCARDABLE MY_FIRM_LOGO_MULTI
IDI_ICON1 ICON DISCARDABLE MY_FIRM_LOGO_MULTI
 
IDB_ATLAS RCDATA "atlas.png"

my_winresrc.h :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
#ifndef MY_WINRESRC
#define MY_WINRESRC
 
#define LANG_ENGLISH       0x09
#define SUBLANG_ENGLISH_US 0x01
 
#define LANG_FRENCH    0x0C
#define SUBLANG_FRENCH 0x01
 
#define LANG_NEUTRAL    0x00
#define SUBLANG_NEUTRAL 0x00
 
#define VS_VERSION_INFO 1
 
/* ----- VS_VERSION.dwFileFlags ----- */
#define VS_FF_DEBUG             0x00000001L
#define VS_FF_PRERELEASE        0x00000002L
#define VS_FF_PATCHED           0x00000004L
#define VS_FF_PRIVATEBUILD      0x00000008L
#define VS_FF_INFOINFERRED      0x00000010L
#define VS_FF_SPECIALBUILD      0x00000020L
 
/* ----- VS_VERSION.dwFileOS ----- */
#define VOS_UNKNOWN             0x00000000L
#define VOS_DOS                 0x00010000L
#define VOS_OS216               0x00020000L
#define VOS_OS232               0x00030000L
#define VOS_NT                  0x00040000L
#define VOS_WINCE               0x00050000L
 
#define VOS_BASE                0x00000000L
#define VOS_WINDOWS16           0x00000001L
#define VOS_PM16                0x00000002L
#define VOS_PM32                0x00000003L
#define VOS_WINDOWS32           0x00000004L
 
#define VOS_DOS_WINDOWS16       0x00010001L
#define VOS_DOS_WINDOWS32       0x00010004L
#define VOS_OS216_PM16          0x00020002L
#define VOS_OS232_PM32          0x00030003L
#define VOS_NT_WINDOWS32        0x00040004L
 
/* ----- VS_VERSION.dwFileType ----- */
#define VFT_UNKNOWN             0x00000000L
#define VFT_APP                 0x00000001L
#define VFT_DLL                 0x00000002L
#define VFT_DRV                 0x00000003L
#define VFT_FONT                0x00000004L
#define VFT_VXD                 0x00000005L
#define VFT_STATIC_LIB          0x00000007L
 
 
#endif // MY_WINRESRC

Resource.h :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#ifndef RESOURCE_H
#define RESOURCE_H
 
 
#define IDI_ICON1      101
#define IDB_ATLAS      102
 
 
#define COMPANY_NAME        "MY_FIRM\0"
#define PRODUCT_NAME        "MY_TOOL\0"
#define PRODUCT_NAMEW       L"MY_TOOL"
#define PRODUCT_VERSION      0
#define PRODUCT_VERSION_STR "\0"
#define LEGAL_COPYRIGHT     "2022 - 2023, MY_FIRM\0"
 
 
#define PROJECT_IHM_VERSION        1,5,1,0
#define PROJECT_IHM_VERSION_STR   "1.5.1\0"
#define PROJECT_IHM_VERSION_WSTR L"1.5.1\0"
#define PROJECT_IHM_NAME          "MY_TOOL.exe\0"
 
#define PROJECT_IHM_DESCRIPTION_FR "Lecteur/ Encodeur de badges MIFARE DESFire EV1\0"
#define MY_FIRM_LOGO_MULTI "MY_FIRM\\MY_FIRM.ico"
 
#endif // RESOURCE_H

28/01/2023, 18h09
adiya

Merci de votre reponse

a priori, la solution (1) me semble preferable...
j utilise des images .png

faudrait-il que je me cree un logiciel qui convertit le fichier.png en tableau (a 2 dimensions) pour en faire quelquechose d exploitable dans le code ?
(avec un copié/collé probablement)...
28/01/2023, 18h51
foetus

Tu as le format Portable Pixmap (fichier .pbm, .pgm, .ppm, .pnm) et + spécialement le format .pam qui gère la transparence : Netpbm, lien wikipédia en anglais

Et évidemment ce format est supporté par les logiciels de retouche, de traitement et de dessin via des extensions, par la bibliothèque Netpbm et peut-être d'autres.
Tu n'as plus qu'à transformer le fichier "ASCII" en chaîne de caractère (et voir comment passer cette chaine de caractères aux fonctions de manipulation) ou en tableau de valeurs via 1 moulinette.
28/01/2023, 19h03
adiya

Sinon, j utilise "Visual Studio Community"...

dans les proprietes du projet, il est peut-etre possible d inclure les fichiers image quelque part dans les options...

Quelqu un sait-il quelque chose a ce sujet ?
Bien sur, ca fait que je me passe alors de g++
28/01/2023, 19h42
foetus

Citation:

Envoyé par adiya

Sinon, j utilise "Visual Studio Community"...

dans les proprietes du projet, il est peut-etre possible d inclure les fichiers image quelque part dans les options...

C'est ce que je disais :mrgreen: la solution 2

Il y a de grandes chances que Visual Studio [Community] gère le(s) fichier(s) .rc/ .res automatiquement (sinon tant pis :aie: )
C'est peut-être en fonction du choix du projet :koi: que tu peux ajouter des fichiers dans l'exécutable (mais comme je le disais, je pense que ce sera 1 projet "Windows" avec la liaison d'1 grosse bibliothèque)
28/01/2023, 21h50
jo_link_noir

Aucune raison d'embarquer les fichiers avec des caractères imprimables, ça ne sert à rien. Ce qu'il faut faire, c'est mettre tous le fichier dans un tableau d'octet. Généralement un simple tableau de char où chaque octet est écrit sous forme hexadécimal pour ne pas avoir de problème de syntaxe. On doit pouvoir trouver des outils qui le font, sinon, ce n'est pas bien compliqué à écrire.

Les outils plus avancés comme ceux de Qt ajoutent par-dessus un système de fichier qui peut-être utilisé à travers les classes de manipulation de fichier du framework. C'est d'ailleurs peut-être même la seule manière de faire, je crois que les ressources de Qt sont aussi compressées.

S'il y a beaucoup de ressource, c'est intéressant d'ajouter de la compression, mais certains formats le sont déjà et le gain n'est alors pas énorme (par exemple, png le fait pas ligne et un coup de optipng donnera de bien meilleurs résultats qu'une compression supplémentaire). Sur des formats texte, le gain va être très intéressant, pour le rapport vitesse de décompression / taux de compression, zstd est très bon.
29/01/2023, 10h55
bacelar

Je comprends pas trop cette fixette de n'avoir qu'un fichier "exe" pour une solution logicielle.
C'est bien plus simple et souple d'utiliser les gestionnaires de package/msi pour installler/mettre à jour/désinstaller un logiciel.
30/01/2023, 00h36
deedolith

Citation:

Envoyé par bacelar

Je comprends pas trop cette fixette de n'avoir qu'un fichier "exe" pour une solution logicielle.
C'est bien plus simple et souple d'utiliser les gestionnaires de package/msi pour installler/mettre à jour/désinstaller un logiciel.

La peur des "pirates" ...
30/01/2023, 03h32
adiya

Citation:

Envoyé par bacelar

Je comprends pas trop cette fixette de n'avoir qu'un fichier "exe" pour une solution logicielle.
C'est bien plus simple et souple d'utiliser les gestionnaires de package/msi pour installler/mettre à jour/désinstaller un logiciel.

eh bien...
ca me semble plus simple et plus propre... surtout que je code "leger"... ;)

et puis il n y a pas besoin d etre un hacker au top pour me piquer une image gentiment disponible...
j aime bien le concept "bibliotheque statique"...
30/01/2023, 07h59
foetus

Citation:

Envoyé par adiya

et puis il n y a pas besoin d etre un hacker au top pour me piquer une image gentiment disponible...

:whistle: saches qu'avec 1 logiciel comme Resource Hacker (lien officiel) tu peux parser, extraire et modifier tes ressources.
Tu remarqueras qu'il utilise le(s) fichier(s) .rc/ .res (et sa syntaxe) : ce logiciel ne fonctionne qu'avec Windows.

De souvenirs, modifier 1 ressource est assez pénible parce que sa taille est enregistrée : donc il faut que la nouvelle ressource est la même taille (peut-être inférieure avec du bourrage).
À moins que maintenant, les logiciels "recompilent" tout.

Citation:

Envoyé par jo_link_noir

S'il y a beaucoup de ressource, c'est intéressant d'ajouter de la compression, mais certains formats le sont déjà et le gain n'est alors pas énorme (par exemple, png le fait pas ligne et un coup de optipng donnera de bien meilleurs résultats qu'une compression supplémentaire). Sur des formats texte, le gain va être très intéressant, pour le rapport vitesse de décompression / taux de compression, zstd est très bon.

:whistle: j'avais utilisé la bibliothèque libbzip2 : bonne compression, bibliothèque active et pas trop grosse, code facile à faire pour juste 1 décompression (c'est la fonction BZ2_bzBuffToBuffDecompress)
30/01/2023, 08h27
adiya

Oui
Il me semblait bien qu on peut quand meme extraire les fichiers qui sont implantés dans le code source
d ailleurs, il me semble que en assembleur, les informations en question sont dans un genre de ".data", un truc dans le genre...
donc la securité des donnees n est jamais vraiment absolue...
Mais quand meme, j aime autant ne pas fournir mes .png a tout le monde...
30/01/2023, 09h35
bacelar

Donc vous pénalisez l'utilisateur légitime (performance à chier), et le hobbyiste qui veut bidouiller le bidule, pour laisser la main aux black hats, quand la start-up nation pense être "l'oméga de l'évolution".
30/01/2023, 09h52
foetus
Citation:

Envoyé par bacelar

Donc vous pénalisez l'utilisateur légitime (performance à chier)

Perte de performances :koi: :weird:
lorsque tu fais 1 IHM, beaucoup d'images se retrouvent dans l'exécutable.
D'ailleurs, étant dans l'exécutable, ce sont des accès mémoire et non disque dur/ SSD.

Après :
- Pour autre chose que des images/ sons, par exemple des .dll ou des fichiers .ini, il faudra à coup sûr les enregistrer en local. Et effectivement refaire ce que fait 1 packager est 1 peu inutile (surtout avec Windows, son architecture dossiers et ses droits)
- Si les fichiers sont protégés (ressources zippées avec mot de passe ou chiffrées avec 1 clef ou cachées dans 1 bibliothèque par exemple), là il faut voir au cas par cas.
30/01/2023, 14h11
adiya

oups...
c est quoi, un IHM ?
30/01/2023, 14h15
adiya
Citation:
Envoyé par foetus

Perte de performances :koi: :weird:
lorsque tu fais 1 IHM, beaucoup d'images se retrouvent dans l'exécutable.
D'ailleurs, étant dans l'exécutable, ce sont des accès mémoire et non disque dur/ SSD.

Après :

Pour autre chose que des images/ sons, par exemple des .dll ou des fichiers .ini, il faudra à coup sûr les enregistrer en local. Et effectivement refaire ce que fait 1 packager est 1 peu inutile (surtout avec Windows, son architecture dossiers et ses droits)
Si les fichiers sont protégés (ressources zippées avec mot de passe ou chiffrées avec 1 clef ou cachées dans 1 bibliothèque par exemple), là il faut voir au cas par cas.
Du coup, si j integre mes images a l executable, je n utilise pas .loadFromFile("")...
30/01/2023, 14h21
foetus

Citation:

Envoyé par adiya

c est quoi, un IHM ?

:mrgreen: Interface Homme-Machine, 1 application avec 1 fenêtre (contrairement à 1 application console ou 1 application Web)

Citation:

Envoyé par adiya

Du coup, si j integre mes images a l executable, je n utilise pas .loadFromFile("")...

Non :mrgreen: LoadResource, lien MSDN pour Win32/ WinAPI
Note que c'est 1 bibliothèque pour les ressources qui permet de charger, trouver, énumérer, ...
30/01/2023, 14h54
adiya

Citation:

Envoyé par bacelar

Donc vous pénalisez l'utilisateur légitime (performance à chier), et le hobbyiste qui veut bidouiller le bidule, pour laisser la main aux black hats, quand la start-up nation pense être "l'oméga de l'évolution".

Euh... avant Omega, c est la lettre Psy... faut consulter ? :mouarf:
30/01/2023, 15h03
adiya

Citation:

Envoyé par adiya

Euh... avant Omega, c est la lettre Psy... faut consulter ? :mouarf:

Autant pour moi, la lettre grecque en question, c est Psi... Tant pis pour ma blague...
30/01/2023, 15h45
bacelar

Les ressources, c'est un vieux machin du 16 bits à base handles qui servent de descripteur de segment et de tables d'indexation, sans compter que c'est dans des segments "discardable".
Un fichier, bin, on a toutes l'architecture de drivers et kernel qui optimisent les accès et le mapping mémoire.

Citation:

lorsque tu fais 1 IHM, beaucoup d'images se retrouvent dans l'exécutable.

C'est une erreur, et les Dll de localisation font bien mieux le taf.

Citation:

D'ailleurs, étant dans l'exécutable, ce sont des accès mémoire et non disque dur/ SSD.

Dans des segments non mappés en mémoire, y accéder, c'est comme aller lire sur le disque.
30/01/2023, 17h39
Bousk

C'est inutile et tu vas juste perdre du temps à essayer de mettre ça en place pour absolument aucun gain.
Au mieux les données son packagés dans des fichiers resources, et c'est uniquement dans un cadre d'optimisation des temps de chargement.
Toi tu ne fais que perdre du temps que tu ne passes pas à améliorer tes algos et compétences techniques. Sous couvert que quelqu'un pourrait copier ton paint art et le réutiliser comme il le veut dans son propre truc ? :weird:
31/01/2023, 07h31
koala01
Salut,

Citation:

Envoyé par Bousk

C'est inutile et tu vas juste perdre du temps à essayer de mettre ça en place pour absolument aucun gain.
Au mieux les données son packagés dans des fichiers resources, et c'est uniquement dans un cadre d'optimisation des temps de chargement.
Toi tu ne fais que perdre du temps que tu ne passes pas à améliorer tes algos et compétences techniques. Sous couvert que quelqu'un pourrait copier ton paint art et le réutiliser comme il le veut dans son propre truc ? :weird:

C'est d'autant plus vrai que tu dois bien te dire que, dés qu'une information finit -- d'une manière ou d'une autre -- par se retrouver en mémoire pour être utiliséee, l'utilisateur du programme est en mesure de la récupérer.
- Peu importe qu'elle soit, de base, disponible sur le disque dur ou transmise par le réseau, même si ce sera beaucoup plus facile si l'information se trouve sur un disque dur auquel l'utilisateur a accès
- Peu importe que l'information soit codée ou non
- Peu importe que l'information soit disponible "seule" ou qu'elle soit cachée parmis des milliers (millions) d'autres données dont certaines n'ont rien à voir avec la donnée elle-même
- Peu importe si le format utilisé pour représenter la donnée est standardisé (comme jpeg, json, png ou mp4) ou s'il s'agit d'un format strictement personnel et "roulé sous les aisselles".
Si l'information est utilisable par ton programme, cela implique que tous les processus utilisés pour essayer de protéger l'information devront être "inversé" pour la rendre disponible. Et cela signifie qu'il est possible d'inverser ces processus sans forcément passer spécifiquement par ton programme.

Au mieux, cela prendra "un peu plus de temps" à quelqu'un de compétant pour y arriver, mais les plus grosses boites se sont cassé les dents sur ce problème, on dépensé des millions et sans doute encore plus pour éviter que leur programme ne soit cracké et les données récupérées.

Et pourtant, aucun jeu, aucun logiciel n'a tenu plus de "quelques jours" avant que quelqu'un ne trouve le moyen de faire sauter les protections.

Crois tu vraiment faire mieux que des boites qui ont de millions de fois tes ressources?
31/01/2023, 12h30
adiya

Bref...
il y a le pour et le contre...
je ne dis pas que tout integrer dans l executable est meilleur ou que c est une securité absolue.

Si j ai bien compris, en informatique, il n y a PAS de securité totale pour les données

Il y a surement plein de reproches a faire a la methode "Tout dans l executable"...
Mais c est quand meme plus propre et plus simple, meme pour l utilisateur

C est seulement un choix personnel...
31/01/2023, 14h45
bacelar

Citation:

Mais c est quand meme plus propre et plus simple, meme pour l utilisateur

Absolument pas !!!

Vous vous leurrez, mais vous n'avez pas l'expérience ni le recul pour le voir.

A dans 2 ans, où vous serez devenu chauves parce que ça marche ici mais pas là.

Bonne chance.
01/02/2023, 00h46
deedolith

D'autant que concernant les images ... je ne compte plus les décennies qui se sont écoulées depuis que les claviers ont été équipés de l'arme absolue: La touche Print screen.
Et concernant les fichiers son, quelques secondes de recherche sur le google permettent de trouver des utilitaires capable d'enregistrer les sorties audio.

Donc ta "protection", le concept est foireux avant même d'y avoir pensé.

Quand au "plus simple pour les utilisateur", d'une part les fichiers ils s'en cognent (ce qu'ils veulent c'est une appli qui fonctionne), et d'autre part il suffit de fournir une solution de déploiement bien ficelée (installable, zip par exemple).

Conclusion:
Fait simple, tu ne t'en porteras que mieux.

Et si tu as peur qu'un utilisateur "bidouille ce qu'il ne faut pas", ca ne relève pas de ta responsabilité (pas ton problème).
01/02/2023, 18h52
koala01

Citation:

Envoyé par adiya

Bref...
il y a le pour et le contre...
je ne dis pas que tout integrer dans l executable est meilleur ou que c est une securité absolue.

Si j ai bien compris, en informatique, il n y a PAS de securité totale pour les données

Il y a surement plein de reproches a faire a la methode "Tout dans l executable"...
Mais c est quand meme plus propre et plus simple, meme pour l utilisateur

C est seulement un choix personnel...

Bien sur qu'il y a du pour et du contre... C'est comme toujours et pour tout ;)

Par contre, ce ne sera pas "plus simple" pour l'utilisateur final qui ne devra -- dans les deux cas -- que double cliquer sur l'exécutable / sur le lien placé dans le menu démarrer. Ce sera donc tout à fait pareil pour lui.

Si bien que l'on peut royalement "s'en foutre" de l'impact que cela peut avoir sur l'utilisateur final.

La vraie question est donc l'impact que peut avoir sur ... le développeur / l'équipe de développement...

Et, sur ce point, il y a vraiment à boire et à manger...

Car si on peut estimer qu'il est effectivement "plus simple" d'avoir un fichier ressource dont la structure est clairement défine pour accéder aux différentes ressources, il faut aussi se dire que cela fait un élément en plus à mettre à jour lorsque l'on veut ajouter une ressource, avec le risque de se retrouver face à une ressource indisponible si cette mise à jour n'est pas faite.

D'un autre coté, il est vrai qu'il faudra vraiment réfléchir sur la manière dont on s'assurera que l'application pourra effectivement trouver "le bon chemin d'accès" aux ressources si l'on n'utilise pas le fichier res, et, qui sait, peut-être même sur la manière de s'assurer que les mises à jours pourront rajouter ou modifier certaines de ces ressources.

Cependant, à partir du moment où l'organisation des ressources est clairement définie et où on a pu obtenir ces garanties, hé bien, il peut simplement suffire de placer une nouvelle ressource ou de modifier une ressource existante pour que tout le reste se fasse "naturellement".

C'est peut être donc effectivement "un peu plus compliqué" au départ, mais il sera "beaucoup plus facile" d'intégrer des évolutions par la suite et le "peu de temps" passé sur la réflexion permettant d'obtenir les garanties nécessaires sera amplement "remboursé" sur le long terme.

La question à se poser vraiment est donc "qu'est ce que je préfère entre me casser un peu la tête maintenant pour être tranquil plus tard ou faire ce qui me semble le plus imple maintenant et le payer au centuple par la suite :question:" Toi seul peut répondre à cette question... Et la réponse que tu donneras aujourd'hui peut être tout à fait différente à celle que tu donneras dans cinq ans ;)
01/02/2023, 19h38
adiya

Ben...
Pour l utilisateur, je vois le risque d egarer un fichier (dll, image,...)...

Evidemment, j ai bien peu d experience...

Mais rien n empeche, il me semble, de travailler sur le projet de facon "dynamique", histoire de s assurer que le logiciel tourne correctement, puis de finaliser en integrant tout dans l executable...

Je commet forcement des erreurs...
Merci de votre indulgence
01/02/2023, 19h46
adiya

Et puis je peux tout a fait produire mes logiciels sous forme "Executable avec toutes les ressources fournies dans un dossier attenant"...
je ne me l interdit pas...
et je reconnais que c est plus simple.
01/02/2023, 21h14
koala01
Citation:

Envoyé par adiya

Ben...
Pour l utilisateur, je vois le risque d egarer un fichier (dll, image,...)...

Où est le risque que l'utilisateur "égare" un fichier :question:

Nous parlons d'une ressource qui prend place sur le disque dur, pas dans un sac à mains!!! Il n'y a aucun risque que l'utilisateur "fasse tomber par médarde " un fichier du disque dur en voulant en extraire un autre !

De plus, il est totalement aberrant de vouloir intégrer une dll à un exécutable final, car cela va totalement à l'encontre du principe même d'une dll, qui est de permettre à plusieurs exécutables d'utiliser les instructions relatives aux mêmes fonctionnalités (sous linux on parle plutôt de shared libraries ou de bibliothèques partagées en français, ce n'est pas sans raison ;) )

Citation:

Evidemment, j ai bien peu d experience...

A la différence de nous qui en avons pour la plupart une belle paire d'années et souvent bien plus ;)

Tu peux nous traiter de vieux con si tu le souhaites, il n'empêche que tout ce que l'on peut dire ou écrire n'est pas forcément des conneries ;)

Citation:

Mais rien n empeche, il me semble, de travailler sur le projet de facon "dynamique", histoire de s assurer que le logiciel tourne correctement, puis de finaliser en integrant tout dans l executable...

Ca, c'est encore la pire des manières de s'y prendre, car cela signifie faire le travail deux fois :
- une fois pour faire en sorte que ton application retrouve les fichiers sur le disque dur
- une fois pour faire en sorte que ton application retrouve les fichiers dans son propre corps.
Et tout le temps que tu mettra à passer de l'un à l'autre sera du temps que tu ne pourras pas passer "à autre chose".

Citation:

Je commet forcement des erreurs...
Merci de votre indulgence

Tout le monde commet des erreurs. C'est même, quelque part, le fondement même de l'évolution.

Commettre une erreur, admettre qu'on peut l'avoir commise et en tirer les conséquences est une très grande forme de sagesse qui te permet d'évoluer.

Commettre une erreur et la reproduire parce que l'on ne s'en n'est pas rendu compte, c'est juste de la bêtise

Echouer dix ou ving fois à faire quelque chose d'une manière différente est faire preuve de volonté. Comme disait Thomas Eddisson

Citation:

Je n'ai pas échoué dix milles fois [à fabriquer une lampe], j'ai trouvé dix milles solutions qui ne fonctionnent pas

Tout cela mérite de l'indulgence.

Commettre une erreur en connaissance de cause, malgré les avertissements et les avis contraire quant à la manière de faire, c'est de l'obsination bien mal venue doublé de pure connerie.

Et ca, ca ne mérite pas la moindre indulgence !

Citation:

Envoyé par adiya

Et puis je peux tout a fait produire mes logiciels sous forme "Executable avec toutes les ressources fournies dans un dossier attenant"...
je ne me l interdit pas...

Nous non plus, nous ne te l'interdisons pas... Nous n'avons aucun moyen de le faire.

Tout ce que nous faisons, c'est te déconseiller de le faire

Citation:

et je reconnais que c est plus simple.

Mais ce n'est pas plus simple (du moins, si tu parles bien de tout mettre dans l'exécutable, comme ta phrase le laisse penser)!

Cela ne fait que déplacer un problème qui se posera forcément à un moment ou à un autre, auquel tu peux décider de réfléchir là, maintenant, "tout de suite", ou "plus tard".

La seule chose qu'il faut comprendre, c'est que si tu décides d'y réfléchir "tout de suite", tu auras beaucoup plus facile à intégrer la solution (qui pourra rester "inchangée ou presque" pour tout le projet) parce que ton projet est encore "simple", alors que si tu décide d'y réfléchir "plus tard", et que c'est quand même pour en arriver à introduire la même solution, tu auras beaucoup plus difficile à le faire parce que ton projet sera -- forcément -- devenu beaucoup plus complexe et qu'il faudra donc apporter beaucoup plus de modifications en tous genres et en toutes places pour arriver à intégrer la solution.

Ce problème s'apparente à ce que l'on appelle la "dette technique" : une décision inadaptée au départ se paye horriblement cher sur le long terme parce qu'elle occasione des problèmes qu'il faudra contourner par la suite auxquels nous n'avons pas forcément pensé au départ, et que ces contournements vont eux aussi occasionner des problèmes que l'on n'aura pas anticipés.

C'est comme les intérêts que l'on paye sur un crédit quelconque: si on ne les paye pas "rapidement", ils finissent par augmenter tellement qu'ils en viennent à dépasser le montant emprunté et par devenir simplement impossibles à payer.
02/02/2023, 11h16
adiya

Je n ai pas du tout dans l idee de vous injurier... :?

j ecoute vos conseils, je les prend en compte

Au moins, j aurais eu raison de mettre le truc sur le tapis

Ca souleve quand meme une autre question :
Il est possible (pas seulement en C++, il me semble), de creer un logiciel comportant tout ce qu il faut en 1 seul executable
Vous, vous me le deconseillez :
Alors pourquoi est ce qu il est possible de le faire ?
Et dans quelle situation est ce recommandé ?
02/02/2023, 14h12
bacelar

Citation:

Alors pourquoi est ce qu il est possible de le faire ?

Et pourquoi pas ?
On peut aussi coder en n'utilisant aucune voyelle dans le nom des variables.
Et qu'il faut le faire ?

Citation:

Et dans quelle situation est ce recommandé ?

Quand on fait un virus, car cela laisse moins de trace et plus facile de changer/crypter sa signature.
Mais sinon, je vois pas, à si, quand on fait du demo-making, mais bon la portabilité du machin, c'est plus qu'illusoire.
Je vois que des vieux trucs, à une époque où le packaging était à la ramasse.
Ça avait une utilité dans les années 80 quand Mac et Linux étaient soit confidentiel, soit inexistant.
Mais maintenant, à par les virus/vers/cheval de Troie, je vois pas.
02/02/2023, 18h19
kaitlyn

Salut,

Et bien, ça se fait quasi systématiquement pour les applications de type utilitaire. Sauf problème de licence, sont mises à disposition des versions "static (build)" (un unique EXE) et "shared link" (plusieurs fichiers). L'utilisateur final télécharge la version qu'il lui convient.
Cette notion de fichier unique se rencontre également dans les "standalone apps", "portable apps" et consorts.

Après, il faut quand même lui accorder le droit de tester et de se forger son opinion.

À cet égard, je rajoute un lien où l'on a eu une discussion sur un sujet similaire. C'est loin d'être exhaustif de tout ce qui peut se faire dans le domaine, mais ça apportera un peu d'eau au moulin.
02/02/2023, 18h37
adiya

Eh bien... Kaitlyn, merci d avoir repondu...

Je n etais pas loin de penser qu on allait voter une loi interdisant les bibliotheques statiques... :mrgreen:

Oups... Sans vouloir manquer de respect aux autres...

Donc, ca se fait encore de compiler en statique...

juste une question : "standalone apps" ?
02/02/2023, 18h58
koala01
Citation:

Envoyé par kaitlyn

Salut,

Et bien, ça se fait quasi systématiquement pour les applications de type utilitaire. Sauf problème de licence, sont mises à disposition des versions "static (build)" (un unique EXE) et "shared link" (plusieurs fichiers). L'utilisateur final télécharge la version qu'il lui convient.
Cette notion de fichier unique se rencontre également dans les "standalone apps", "portable apps" et consorts.

A ceci près que là, tu ne parle que du problème des bibliothèques qui peuvent:
1. soit être "sttatiques" : la bibliothèque contient le code "prêt à l'emploi" des fonctionnalités fournies par la bibliothèque, à charge de l'éditeur de liens prendre le code des fonctionnalités qui l'intéressent (qui sont effectivement utilisées par le programme) pour générer l'exécutable final
2. soit être "dynamiques / partagées" : la bibliothèque est "un exécutable en lui-même" qui contient -- forcément -- lui aussi le code "prêt à l'emploit" des fonctionnalités fournies par la bibliothèque, mais, contrairement aux bibliothèques statique, ici, l'éditeur de liens va mettre "toute une mécanique" qui permettra ... de charger la bibliothèque en mémoire "parce que tu en as besoin" et qui fera le liens entre l'appel d'une fonction (au niveau de l'exécutable final) et l'endroit où cette fonction se trouve dans la bibliothèque
Le résultat immédiat est que l'exécutable final lié statiquement sera très souvent "beaucoup plus gros" que l'exécutable lié dynamiquement, et que, si tu veux modifier quelque chose au niveau de la bibliothèque, c'est ... tout l'exécutable final que tu devra recréer (alors que tu peux te contenter de ne recréer que la bibliothèque dynamique pour que les changement soient "automatiquement pris en compte" dans les mêmes circonstances)

Et pour passer de l'un à l'autre, il n'y a -- a priori (du moins lorsque les choses sont correctement mises en place) -- qu'à changer une option de compilation pour générer soit une bibliothèque statique, soit une bibliothèque dynamique.

Or, la question de Adiya tourne autour de l'intégration de fichiers images et son directement au sein de l'exécutable, ce qui est "un cran plus loin" que l'intégration (ou non) des biblothèque et qui ne résoud certains problèmes ponctuels que pour permettent qu'ils lui pêtent à la figure de manière bien plus violente plus tard.

Citation:

Après, il faut quand même lui accorder le droit de tester et de se forger son opinion.

À cet égard, je rajoute un lien où l'on a eu une discussion sur un sujet similaire. C'est loin d'être exhaustif de tout ce qui peut se faire dans le domaine, mais ça apportera un peu d'eau au moulin.

Le fait est que, lorsque tu as un "programme jetable" qui intègre un ou deux fichiers de type image et / ou son, cela peut encore passer, mais il faut quand même garder en mémoire que cela implique que la taille totale de l'exécutable correspondra à la somme des fichiers ayant servis à l'utiliser, ce qui implique -- dans le cas présent -- également les fichiers d'image et / ou de son.

Et donc, cela peut marcher "pour quelques fichiers", à conditions que l'on n'ait pas besoin de les modifier trop régulièrement, mais on arrivera très rapidement à une taille d'exécutable "inacceptable" pour différentes raisons, sans même compter les problèmes inhérants à la mise à jour de ces fichiers de son et / ou d'image.

Comme toujours en informatique, il y a une différence entre "pouvoir" et "devoir" faire quelque chose: ce n'est pas forcément parce qu'il est possible de faire quelque chose qu'il faut obligatoirement le faire sans même prendre le temps de la réflexion permettant de déterminer si "c'est une bonne chose" de le faire. Et c'est surtout vrai en C++ ;)
02/02/2023, 19h20
Bousk

Citation:

Envoyé par adiya

Eh bien... Kaitlyn, merci d avoir repondu...

Je n etais pas loin de penser qu on allait voter une loi interdisant les bibliotheques statiques... :mrgreen:

Oups... Sans vouloir manquer de respect aux autres...

Donc, ca se fait encore de compiler en statique...

juste une question : "standalone apps" ?

Sauf qu'il n'a jamais été question de remettre en cause l'utilité des bibliothèques statiques.
La seule chose qu'on a reproché c'est ta lubie d'un exécutable pour les contrôler tous qui intègre les images, sons etc. Et ça, hors énorme spécificité ou challenge technique, oui c'est débile.
Et si en plus c'est spécifique Windows, ça l'est encore plus.
Quant aux standalone apps etc, elles sont souvent distribuées via... une archive à dézipper qui contient un dossier auto-suffisant. Et pas un exe intégrant toutes les données.
Et les petits utilitaires, s'utilisent en ligne de commande ou drag&drop. Encore une fois aucune donnée ici.
Bref, ça mélange des torchons et des poires.
02/02/2023, 19h25
kaitlyn

Il faut savoir raison garder, il n'a pas dit non plus qu'il allait faire un GTA 6, si ?
02/02/2023, 20h00
adiya

Eh bien, pour le moment je ne peux developper que de petits projets
Je suis un bon debutant, mais un debutant quand meme

J utilise SFML, mais pas forcement pour du jeu...

Je n ai pas encore l aptitude a travailler en equipe, ni a realiser du tres gros projet

Je precise, je suis (a peu pres ) auto-didacte... (si on met a part les tutoriels, et les livres)...
02/02/2023, 22h28
kaitlyn

C'était une rhétorique, une petite question avec une pointe d'ironie qui n'attendait pas de réponse. Tout au moins pas de ta part. En fait, c'était juste pour souligner le caractère absurde de toute cette insistance dans les messages.
03/02/2023, 11h21
adiya

Bien vu...

:roll: