Version imprimable
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:
Salut,
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.Citation:
Envoyé par Bousk
- 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?
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...
Absolument pas !!!Citation:
Mais c est quand meme plus propre et plus simple, meme pour l utilisateur
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.
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).
Bien sur qu'il y a du pour et du contre... C'est comme toujours et pour tout ;)Citation:
Envoyé par adiya
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 ;)
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
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.
Où est le risque que l'utilisateur "égare" un fichier :question:Citation:
Envoyé par adiya
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 ;) )
A la différence de nous qui en avons pour la plupart une belle paire d'années et souvent bien plus ;)Citation:
Evidemment, j ai bien peu d experience...
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 ;)
Ca, c'est encore la pire des manières de s'y prendre, car cela signifie faire le travail deux fois :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...
- 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".
Tout le monde commet des erreurs. C'est même, quelque part, le fondement même de l'évolution.Citation:
Je commet forcement des erreurs...
Merci de votre indulgence
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
Tout cela mérite de l'indulgence.Citation:
Je n'ai pas échoué dix milles fois [à fabriquer une lampe], j'ai trouvé dix milles solutions qui ne fonctionnent pas
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 !
Nous non plus, nous ne te l'interdisons pas... Nous n'avons aucun moyen de le faire.Citation:
Envoyé par adiya
Tout ce que nous faisons, c'est te déconseiller de le faire
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)!Citation:
et je reconnais que c est plus simple.
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.
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é ?
Et pourquoi pas ?Citation:
Alors pourquoi est ce qu il est possible de le faire ?
On peut aussi coder en n'utilisant aucune voyelle dans le nom des variables.
Et qu'il faut le faire ?
Quand on fait un virus, car cela laisse moins de trace et plus facile de changer/crypter sa signature.Citation:
Et dans quelle situation est ce recommandé ?
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.
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.
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" ?
A ceci près que là, tu ne parle que du problème des bibliothèques qui peuvent:Citation:
Envoyé par kaitlyn
- 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
- 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.
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.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.
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++ ;)
Sauf qu'il n'a jamais été question de remettre en cause l'utilité des bibliothèques statiques.Citation:
Envoyé par adiya
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.
Il faut savoir raison garder, il n'a pas dit non plus qu'il allait faire un GTA 6, si ?
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)...
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.
Bien vu...
:roll: