Dans le cadre du développement d'un projet sous Windows avec Visual Studio
ou CodeGear C++ , est il possible d'intégrer directement des fichiers
multimédia (JPG, PNG, AVI, AAC et Flash) dans une DLL lors de sa création ?
Le but est de pouvoir réutiliser ces fichiers depuis un executable via des
fonctions tout en empêchant ou rendant difficile leur utilisation en dehors
du cadre de l'aplpli (pour les droits d'auteurs), en particulier pour la
vidéo.
> On Jul 30, 12:27 am, Falk Tannhäuser >> // Find global character statistics and key length >> std::map<unsigned char, unsigned> stat;
> Seulement curiosité, mais est-ce qu'il y a une raison pour > std::map, plutôt que : > std::vector< unsigned > stat( UCHAR_MAX + 1 ) : > (ce que j'aurais fait). En fin de compte, ton « indice », > c'est bien un petit entier non-négatif, ce qui correspond à > l'utilisation classique de vector (voire même un tableau de > type C
Non, pas de raison particulière, sauf que je n'avais pas envie de me prendre le choux :-) La version avec std::vector ou tableau doit bien être plus performant (moins d'allocations dynamiques, temps d'accès O(1) contrairement à O(log N) pour std::map) et prendre moins de mémoire, mais vu la faible quantité de données à traiter la différence reste imperceptible.
Je ne pensais pas particulièrement à la performance. C'est juste qu'en mon esprit, la collection par défaut, c'est std::vector. Je ne m'en écarte que s'il y une raison : le fait que l'indice ne soit pas un type entier, par exemple, ou que les indices potentielles sont telles que ça risque de dépasser une utilisation raisonable de la mémoire (p.e. des numéros de sécurité sociale, traités comme des entiers).
Mais c'est peut-être simplement une vieille habitude de ma part. Dans le cas qui nous intéresse, les indices sont des caractères, qui conceptuellement ne sont pas des entiers. Seulement, j'ai tellement travaillé dans l'informatique de bas niveau que je n'arrive pas toujours à en faire l'abstraction ; je n'oublie jamais que les caractères sont des entiers.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 30, 10:09 pm, Falk Tannhäuser <tannhauser86549s...@free.fr>
wrote:
James Kanze schrieb:
> On Jul 30, 12:27 am, Falk Tannhäuser <tannhauser86549s...@free.fr>
>> // Find global character statistics and key length
>> std::map<unsigned char, unsigned> stat;
> Seulement curiosité, mais est-ce qu'il y a une raison pour
> std::map, plutôt que :
> std::vector< unsigned > stat( UCHAR_MAX + 1 ) :
> (ce que j'aurais fait). En fin de compte, ton « indice »,
> c'est bien un petit entier non-négatif, ce qui correspond à
> l'utilisation classique de vector (voire même un tableau de
> type C
Non, pas de raison particulière, sauf que je n'avais pas envie
de me prendre le choux :-) La version avec std::vector ou
tableau doit bien être plus performant (moins d'allocations
dynamiques, temps d'accès O(1) contrairement à O(log N) pour
std::map) et prendre moins de mémoire, mais vu la faible
quantité de données à traiter la différence reste
imperceptible.
Je ne pensais pas particulièrement à la performance. C'est juste
qu'en mon esprit, la collection par défaut, c'est std::vector.
Je ne m'en écarte que s'il y une raison : le fait que l'indice
ne soit pas un type entier, par exemple, ou que les indices
potentielles sont telles que ça risque de dépasser une
utilisation raisonable de la mémoire (p.e. des numéros de
sécurité sociale, traités comme des entiers).
Mais c'est peut-être simplement une vieille habitude de ma
part. Dans le cas qui nous intéresse, les indices sont des
caractères, qui conceptuellement ne sont pas des entiers.
Seulement, j'ai tellement travaillé dans l'informatique de bas
niveau que je n'arrive pas toujours à en faire l'abstraction ;
je n'oublie jamais que les caractères sont des entiers.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
> On Jul 30, 12:27 am, Falk Tannhäuser >> // Find global character statistics and key length >> std::map<unsigned char, unsigned> stat;
> Seulement curiosité, mais est-ce qu'il y a une raison pour > std::map, plutôt que : > std::vector< unsigned > stat( UCHAR_MAX + 1 ) : > (ce que j'aurais fait). En fin de compte, ton « indice », > c'est bien un petit entier non-négatif, ce qui correspond à > l'utilisation classique de vector (voire même un tableau de > type C
Non, pas de raison particulière, sauf que je n'avais pas envie de me prendre le choux :-) La version avec std::vector ou tableau doit bien être plus performant (moins d'allocations dynamiques, temps d'accès O(1) contrairement à O(log N) pour std::map) et prendre moins de mémoire, mais vu la faible quantité de données à traiter la différence reste imperceptible.
Je ne pensais pas particulièrement à la performance. C'est juste qu'en mon esprit, la collection par défaut, c'est std::vector. Je ne m'en écarte que s'il y une raison : le fait que l'indice ne soit pas un type entier, par exemple, ou que les indices potentielles sont telles que ça risque de dépasser une utilisation raisonable de la mémoire (p.e. des numéros de sécurité sociale, traités comme des entiers).
Mais c'est peut-être simplement une vieille habitude de ma part. Dans le cas qui nous intéresse, les indices sont des caractères, qui conceptuellement ne sont pas des entiers. Seulement, j'ai tellement travaillé dans l'informatique de bas niveau que je n'arrive pas toujours à en faire l'abstraction ; je n'oublie jamais que les caractères sont des entiers.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Vincent Burel
"Falk Tannhäuser" wrote in message news:4a71fdfd$0$27785$
James Kanze schrieb: > On Jul 30, 12:27 am, Falk Tannhäuser >> // Find global character statistics and key length >> std::map<unsigned char, unsigned> stat; > > Seulement curiosité, mais est-ce qu'il y a une raison pour > std::map, plutôt que : > std::vector< unsigned > stat( UCHAR_MAX + 1 ) : > (ce que j'aurais fait). En fin de compte, ton « indice », c'est > bien un petit entier non-négatif, ce qui correspond à > l'utilisation classique de vector (voire même un tableau de type C
Non, pas de raison particulière, sauf que je n'avais pas envie de me prendre le choux :-) La version avec std::vector ou tableau doit bien être plus performant (moins d'allocations dynamiques, temps d'accès O(1) contrairement à O(log N) pour std::map) et prendre moins de mémoire, mais vu la faible quantité de données à traiter la différence reste imperceptible.
Donc il suffisait de jouer à Motus pendant quelques heures pour décoder le fichier txt. (il faut quand même etre un peu programmeur).
Si mon générateur de bruit avait marché correctement , ca aurait donné un fichier genre celui-ci : http://vincent.burel.free.fr/misc/SimpleAsciiText2.bin (c'est toujours un text ASCII classique - différent mais toujours encodé par une clef symétrique char(n) = char(n) XOR f(n)) - vous y trouverez les mots mathématique, hasard et ordinateur).
Ca devrait etre beaucoup plus dur ! enfin j'espère ! :-)
VB
"Falk Tannhäuser" <tannhauser86549spam@free.fr> wrote in message
news:4a71fdfd$0$27785$426a74cc@news.free.fr...
James Kanze schrieb:
> On Jul 30, 12:27 am, Falk Tannhäuser <tannhauser86549s...@free.fr>
>> // Find global character statistics and key length
>> std::map<unsigned char, unsigned> stat;
>
> Seulement curiosité, mais est-ce qu'il y a une raison pour
> std::map, plutôt que :
> std::vector< unsigned > stat( UCHAR_MAX + 1 ) :
> (ce que j'aurais fait). En fin de compte, ton « indice », c'est
> bien un petit entier non-négatif, ce qui correspond à
> l'utilisation classique de vector (voire même un tableau de type C
Non, pas de raison particulière, sauf que je n'avais pas envie de me
prendre le choux :-) La version avec std::vector ou tableau doit bien
être plus performant (moins d'allocations dynamiques, temps d'accès O(1)
contrairement à O(log N) pour std::map) et prendre moins de mémoire, mais
vu la faible quantité de données à traiter la différence reste
imperceptible.
Donc il suffisait de jouer à Motus pendant quelques heures pour décoder le
fichier txt.
(il faut quand même etre un peu programmeur).
Si mon générateur de bruit avait marché correctement , ca aurait donné un
fichier genre celui-ci :
http://vincent.burel.free.fr/misc/SimpleAsciiText2.bin
(c'est toujours un text ASCII classique - différent mais toujours encodé par
une clef symétrique char(n) = char(n) XOR f(n)) - vous y trouverez les mots
mathématique, hasard et ordinateur).
Ca devrait etre beaucoup plus dur !
enfin j'espère ! :-)
"Falk Tannhäuser" wrote in message news:4a71fdfd$0$27785$
James Kanze schrieb: > On Jul 30, 12:27 am, Falk Tannhäuser >> // Find global character statistics and key length >> std::map<unsigned char, unsigned> stat; > > Seulement curiosité, mais est-ce qu'il y a une raison pour > std::map, plutôt que : > std::vector< unsigned > stat( UCHAR_MAX + 1 ) : > (ce que j'aurais fait). En fin de compte, ton « indice », c'est > bien un petit entier non-négatif, ce qui correspond à > l'utilisation classique de vector (voire même un tableau de type C
Non, pas de raison particulière, sauf que je n'avais pas envie de me prendre le choux :-) La version avec std::vector ou tableau doit bien être plus performant (moins d'allocations dynamiques, temps d'accès O(1) contrairement à O(log N) pour std::map) et prendre moins de mémoire, mais vu la faible quantité de données à traiter la différence reste imperceptible.
Donc il suffisait de jouer à Motus pendant quelques heures pour décoder le fichier txt. (il faut quand même etre un peu programmeur).
Si mon générateur de bruit avait marché correctement , ca aurait donné un fichier genre celui-ci : http://vincent.burel.free.fr/misc/SimpleAsciiText2.bin (c'est toujours un text ASCII classique - différent mais toujours encodé par une clef symétrique char(n) = char(n) XOR f(n)) - vous y trouverez les mots mathématique, hasard et ordinateur).
Ca devrait etre beaucoup plus dur ! enfin j'espère ! :-)
