as de bol d'avoir parlé du C vu que justement c'est le language que j'utilise dans les deux cas et qu'il est la source d'un argument supplémentaire dans le deuxième cas...
Pour l'algo sur les CRF je dois utiliser des tableaux à deux dimensions et plus dont la taille n'est pas connue à la compilation. Une des nouveautée cool du C99 est la tableau dynamiques qui me permmettent de faire :
int x = /* calcul de la taille X */;
int y = /* calcul de la taille Y */;
double tbl[x][y];
Le problème c'est que ce tableau ne peut pas se trouver dans une structure car la taille de la structure doit être connue à la compilation... De même, le passage de ce tableau en paramètre d'une fonction est embetant, soit je passe la taille des dimenssion en paramètre :
void mafonction(int x, int y, double tbl[x][y])
Ce qui devient vite les bordel si on a plusieurs tableau en paramètres. Soit ma fonction est capable de retrouver toute seule les dimension et donc je peut passer le tableau sous forme unidimentionelle, mais dans ce cas l'indicage devien chiant à mourir.
On est ici dans le cas ou une limitation du langage rajoute encore une couche au fait que le programme est bien plus lisible. La version splité en plusieurs fonctions se retrouve avoir des trucs du genre :
mdl->tbl[x * mdl->dimenx + y] = val;
ce qui est bien moins lible que juste
tbl[x][y] = val;
Mais si l'indicage est lié au langage, le fait de devoir aller chercher le tableaux dans une structure est lié à la décomposition. Pourquoi aller chercher un tableaux qui est juste une étape temporaire dans l'algo à l'interieur du structure qui donne l'impréssion d'avoir étée allouée quelque part ailleur ?
Bien sur, il est toujour possible d'avoir une structure "state" qui devient un fourtout pour toutes les variables à passer d'une fonction à l'autre. Mais dans ce cas pourquoi ce faire chier avec ce genre de truc :
void etape1(state *st) {...}
void etape2(state *st) {...}
void etape3(state *st) {...}
void etape4(state *st) {...}
void algo(void) {
state st;
etape1(&st);
etape2(&st);
etape3(&st);
etape4(&st);
}
alors que
void algo(void) {
/* etape1 */
...
/* etape2 */
...
/* etape3 */
...
/* etape4 */
...
}
est tout aussi clair, indique bien que les trois étape sont séquentielles, et n'oblige pas de faire une gymnastique avec une structure batarde ?
Et il ne faut pas oublier que ça simplifie le travail du compilateur. La sémantique et la portée des données et explicite et permet souvent des optimisations plus agréssive.
Perso, je pense toujours qu'il ne faut faire confiance ni aux dévelopeurs, ni au compilateur... donc je fais le code le plus simple, le plus lisible et le plus explicite possible, même si ça doit violer les style de codage.
Le compilo ne produira pas forcement du code plus rapide, mais dans tous les cas, il y a peut de chance qu'il soit plus lent.
Les autres dévellopeurs comprennent plus facilement mon code et on moins de chances de faire des conneries quand ils le modifient ou le maintiennent.
[^] # Re: Langage idéal...
Posté par beagf . En réponse au journal Nimrod, ça se rapproche du langage idéal. Évalué à 5.
Pour l'algo sur les CRF je dois utiliser des tableaux à deux dimensions et plus dont la taille n'est pas connue à la compilation. Une des nouveautée cool du C99 est la tableau dynamiques qui me permmettent de faire :
int x = /* calcul de la taille X */;
int y = /* calcul de la taille Y */;
double tbl[x][y];
Le problème c'est que ce tableau ne peut pas se trouver dans une structure car la taille de la structure doit être connue à la compilation... De même, le passage de ce tableau en paramètre d'une fonction est embetant, soit je passe la taille des dimenssion en paramètre :
void mafonction(int x, int y, double tbl[x][y])
Ce qui devient vite les bordel si on a plusieurs tableau en paramètres. Soit ma fonction est capable de retrouver toute seule les dimension et donc je peut passer le tableau sous forme unidimentionelle, mais dans ce cas l'indicage devien chiant à mourir.
On est ici dans le cas ou une limitation du langage rajoute encore une couche au fait que le programme est bien plus lisible. La version splité en plusieurs fonctions se retrouve avoir des trucs du genre :
mdl->tbl[x * mdl->dimenx + y] = val;
ce qui est bien moins lible que juste
tbl[x][y] = val;
Mais si l'indicage est lié au langage, le fait de devoir aller chercher le tableaux dans une structure est lié à la décomposition. Pourquoi aller chercher un tableaux qui est juste une étape temporaire dans l'algo à l'interieur du structure qui donne l'impréssion d'avoir étée allouée quelque part ailleur ?
Bien sur, il est toujour possible d'avoir une structure "state" qui devient un fourtout pour toutes les variables à passer d'une fonction à l'autre. Mais dans ce cas pourquoi ce faire chier avec ce genre de truc :
void etape1(state *st) {...}
void etape2(state *st) {...}
void etape3(state *st) {...}
void etape4(state *st) {...}
void algo(void) {
state st;
etape1(&st);
etape2(&st);
etape3(&st);
etape4(&st);
}
alors que
void algo(void) {
/* etape1 */
...
/* etape2 */
...
/* etape3 */
...
/* etape4 */
...
}
est tout aussi clair, indique bien que les trois étape sont séquentielles, et n'oblige pas de faire une gymnastique avec une structure batarde ?
Et il ne faut pas oublier que ça simplifie le travail du compilateur. La sémantique et la portée des données et explicite et permet souvent des optimisations plus agréssive.
Perso, je pense toujours qu'il ne faut faire confiance ni aux dévelopeurs, ni au compilateur... donc je fais le code le plus simple, le plus lisible et le plus explicite possible, même si ça doit violer les style de codage.
Le compilo ne produira pas forcement du code plus rapide, mais dans tous les cas, il y a peut de chance qu'il soit plus lent.
Les autres dévellopeurs comprennent plus facilement mon code et on moins de chances de faire des conneries quand ils le modifient ou le maintiennent.