magic_Nono
Messages postés1878Date d'inscriptionjeudi 16 octobre 2003StatutMembreDernière intervention16 mars 2011
-
22 août 2005 à 20:34
steve_clamage
Messages postés475Date d'inscriptiondimanche 3 octobre 2004StatutMembreDernière intervention11 août 2006
-
25 août 2005 à 08:34
J'aimerai savoir ce que vous feriez dans ce cas:
avec un gros projet
j'ai la possibilité d'accélérer considérablement sa vitesse d'exécution
mais cela entrainerai une utilisation beaucoup plus importante de la mémoire
(mémorisation de chaines de caractères au lieu de les reparcourir un nombre incalculable de fois
sachant que ce ne sont pas des parcours simples, mais traitant bcp de cas particuliers
)
feriez vous ce changement?
quitte à ce que l'utilisation mémoire soit énorme
ou pas?
merci de votre lecture & de vos avis sur la question
___________________________________________________________
Magicalement
Nono
minet03
Messages postés415Date d'inscriptionsamedi 4 janvier 2003StatutMembreDernière intervention 2 décembre 20053 22 août 2005 à 20:41
Cela dépend du projet et de son utilisation.
Il faudrais juger si la vitesse d'exécution des instructions est plus
importante que l'espace mémoire utilisé. Si la mémoire est énorme et
que c'est donc négligeable, autant rendre le prog plus rapide... !
magic_Nono
Messages postés1878Date d'inscriptionjeudi 16 octobre 2003StatutMembreDernière intervention16 mars 2011 22 août 2005 à 21:31
merci les gars d'avoir répondu présent aussi rapidement
c'est vrai qu'a y réfléchir,
tout le monde n'a pas 1Go de RAM
actuellement, je ne peux pas quantifier la place que ça prendrai
pr cet usage , ça prendra approximativement
un peu moins que le double de la taille de chaque fichié analysé
sachant que cette taille n'est pas limitée...
dc
pour les personne ayant peu de mémoire,
leur système (windows)
tamponnera
et sera ralentira le tout
ce qui est un retour à la case départ je pense
pour les autres, ils auront un rsltt plus rapide
mais le jeu en vaut il la chandelle?
pour etre plus précis sur l'utilisation mémoire, je dirais
que les fichiers sont entre qq octets et 600ko voir bcp plus
(il s'agit de fichiers sources )
ce qui fait une occupation d'1.2 Mo mini par fichier,
en RAM,
dc 2 Mo c'est négligeable
en fait
mais je me demande si ça fera que ça vu tt ce qu'il y a a coté
on verra, je pense que je v me lancer là dedans
xterminhate
Messages postés371Date d'inscriptiondimanche 4 janvier 2004StatutMembreDernière intervention23 septembre 2009 22 août 2005 à 22:09
Une suggestion en passant....
Dans les préférences de ton outil, tu peux proposer un champ indiquant
la taille mémoire maximale utilisable par l'application. Par défaut, tu
peux partir sur la mémoire physique moins environ 250Mo (mémoire
physique occupée par windows en conditions normales d'utilisation).
bien sur l'utilisateur peur vouloir réduire cette espace mémoire....
Si le fichier nécessite plus de mémoire que l'espace spécifié dans les
propriétés de l'outil, tu peux fragmenter l'analyse de ton fichier (si
possible)....
Franchement, la mémoire, c'est fait pour être utilisée !
magic_Nono
Messages postés1878Date d'inscriptionjeudi 16 octobre 2003StatutMembreDernière intervention16 mars 2011 23 août 2005 à 01:17
:) BN, si si, c'est ça, tu avais bien compris, mais en gardant certains empillages tt de mm pr ne pas tout casser.
et dis moi, pr en revenir à de l'optimisation pure
quelle différence entre
ton
unsigned short maFonctionUtilieIci();
et mon
static unsigned short BGenerale::maFonction();
il me semble que les 2 sont traduit de la mm maniere; mais je peux faire erreur...
<!--StartFragment -->sachant que
perseverare diabolicum
tu l'as vu, on es bcp a avoir changé malgré ts nos enseignements, mais on ne peux pas tt renier ainsi...brutalement.
petit à petit on intègre... ou plutot implémente,
et nous nous améliorons
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 23 août 2005 à 08:56
Une func 'static' n'est qu'une facétie du C++ qui satisfait la mode de la POO mais rien de plus, c'est bien une func ordinaire avec une adresse fixe, on enlèverait le "class::" devant qu'il n'y aurait pas un iota de changé dans le code résultant.
steve_clamage
Messages postés475Date d'inscriptiondimanche 3 octobre 2004StatutMembreDernière intervention11 août 20065 24 août 2005 à 23:19
Oui, vecchio à raison, une méthode membre peut etre vu comme une simple
fonction qui recois en parametre caché un pointeur constant (car ce
n'est pas une l-value) sur l'instance (constante ou non).
Par exemple:
class Foo
{
int _A;
public:
int getA() const { return _A; }
void setA(int A) { _A = A; }
};
on peut traduire ca en C:
typedef struct Foo
{
int _A;
};
/* ici _A est visible par l'utilisateur mais il est possible en C de
caché le contenu d'une structure au niveau de l'interface (forward
déclaration plus définition dans le source) ou d'interdire la
modification d'un champ en définissant dans l'interface une structure
dite publique dont tout les membres sont constant. */
int Foo_getA(const Foo * const this)
{
return this->_A;
}
void Foo_setA(Foo * const this, int A)
{
this->_A = A;
}
Ce qu'il faut comprendre c'est qu'il n'est pas impossible de faire de
l'OO en C (avec héritage et virtualité) mais le langage n'offre pas
directement de support. Souvent dans les gros projets on trouve des
macros chargées de "bricoler" ce support.
Il y a aussi OOPC (Object Oriented Programming
in C), une bibliothèque d'header c90 et c99 pour simuler ce support via le preprocesseur.
J'avais moi même essayé dans le but d'avoir une syntaxe plus proche du
C++. C'est formateur car ca permet vraiment de comprendre comment est
implementé un langage OO comme C++ (heritage, virtualité et
polymorphisme d'inclusion, cast dynamique...). Par contre je
déconseilles d'utiliser ca à cause de la quantité de code généré par le
preprocesseur, c'est la folie au debuggage
steve_clamage
Messages postés475Date d'inscriptiondimanche 3 octobre 2004StatutMembreDernière intervention11 août 20065 25 août 2005 à 08:34
Un exemple avec un type complexe string.
Dans le .h:
struct string; /* déclaration anticipée */
typedef struct string * string;
size_t string_size(const string this);
Dans le .c:
struct string /* définition de la structure */
{
char * data;
size_t size;
size_t capacity;
};
size_t string_size(const string this)
{
return this->size;
}
Mais le probleme c'est que en c++ on a souvent des attributs privés qui
sont néamoins accessibles en lecture par une méthode inline et le coût
est nule. C99 n'est pas encore trés bien supporté (meme gcc se plante
au niveau de l'inlining) alors la solution C90 c'est de proposer dans
l'interface une structure dont les champs sont constants, on peut meme
"cacher" le nom d'un champ pour le rendre inaccessible.
On se replace dans le contexte ou on développe une bibliothèque "string".
Dans le .h:
/* quelques macros pour cacher un nom */
#define string_concat_(A,B) A ## B
#define string_concat(A,B) string_concat_(A,B)
/* c'est pas top, on peut toujours se démerder pour rajouter un nombre magique */
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 23 août 2005 à 00:23
ah ok c'est de l'optimisation de classes, vrai qu'on a pas les mêmes mots pour les mêmes choses, je croyais que tu allais traquer les cycles.
Errare BruNewsum Est.
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 23 août 2005 à 20:49
BruNews, comment tu veux qu'un fonction n'ait pas d'adresse fixe. Les fonctions méthodes non statiques aussi ont une adresse fixe, sinon ca poserait un petit problème
Et pis pour tes commentaires sur l'optimisation, moi je trouve qu'on préfère souvent un bon algo avec une mauvaise mise en oeuvre plutot que le contraire