Librairie dynamique - Page 12

aze (./330) :
sinon non, le ++ est exécuté avant le calcul de l'expression, c'est juste que GC a présenté le déroulement déjà optimisé par le compilosans optimisation, ça donne a1 = a; a = a + 1; ret = a1 + 1; return ret; et c'est ce comportement qui doit être conservé

Euh non, ce n'est pas ça la définition de la postincrémentation en C! En Java peut-être (où des trucs comme a++ + a++ sont valides), mais en C, tout ce qui se trouve entre 2 "sequence points" (ce qui est en général l'expression entière) est exécuté en une seule fois et ensuite les postincrémentations sont effectués. Et une variable donnée ne peut être {pré,post}{in,dé}crémentée qu'une seule fois entre 2 sequence points, sinon le comportement n'est pas défini (ce qui implique que la définition style Java que tu as donnée est une implémentation valide, mais ce n'est pas la définition ni la seule implémentation possible).

ah d'accord. mais est ce que ça ne revient pas fonctionnellement au même ? (en dehors des cas a++ + a++)
pour le java, je n'en sais rien je n'y connais rien

Ça doit également faire une différence pour a++ + a ^^
(Mais pas pour a + a++)

aze (./332) :
ah d'accord. mais est ce que ça ne revient pas fonctionnellement au même ? (en dehors des cas a++ + a++)

C'est bien ce que je dis.

pour le java, je n'en sais rien je n'y connais rien

Il me semble que la définition en Java correspond à celle que tu as donnée, avec une évaluation gauche à droite, donc a++ + a++ revient à a+a+1 suivi de a+=2. Mais en C, a++ + a++ est incorrect tout simplement (et donc le compilateur peut générer ce qu'il veut, même du code qui efface toutes tes données ).

GoldenCrystal (./333) :
Ça doit également faire une différence pour a++ + a ^^(Mais pas pour a + a++)

Ces expressions sont également incorrectes en C.

C'est intelligent un langage qui t'autorise des expressions incorrectes dis moi
J'ai jamais écrit de code comme ça en C (en C# oui par contre) mais en fait, c'est vraiment con comme truc.
Comment on peut normaliser des "comportements indéterminés" ?

Ça permet d'optimiser beaucoup plus et d'exploiter mieux le comportement spécifique à la machine qu'un langage où tout est déterminé.

Par exemple, sur le 68k (et le x86 aussi, d'ailleurs, du moins en la convention d'appel C (appelée cdecl sous W32/W64)), les arguments sont poussés sur la pile de droite à gauche, du coup dans:
f(g(),h())
le compilateur a intérêt à exécuter d'abord h, puis g, puis f, alors que sur une machine ou convention d'appel qui pousse les paramètres de gauche à droite, l'ordre g, h, f sera plus efficace. Donc le C ne définit pas d'ordre pour les appels de g et h. (En revanche, le compilateur n'a pas le droit d'exécuter g et h en même temps en 2 threads sauf s'il peut prouver qu'il n'y a pas d'interaction.)

Argh
Tu veux dire qu'on peut écrire du code non portable sans même avoir un warning ?
Quelle horreur, je suis bien content de ne plus trop toucher au C
(Et bon j'avoue, j'ai jamais lu la norme du C, je déteste lire les trucs illisibles)
Par contre le coup de passer les arguments de gauche à droite me semble fumeux… Comment tu gères "..." du coup ?

Martial> Pour en revenir à ton problème, mon avis est qu’en C (ou dans n’importe quel autre langage que l’ASM), ça ne vaut pas le coup de chercher à réduire le nombre de lignes de code. En assembleur une ligne égale une instruction, mais pas en langage de haut niveau où on peut du coup se permettre d’étendre son code sur plusieurs lignes, pour en améliorer la lisibilité, sans pour autant diminuer la qualité du code produit par le compilateur.

Ouais c'est pour ça que le java poutre quand même vachement plus. Tout est fait de sorte qu'on "ait l'impression que c'est évalué de gauche à droite". Après derrière le compilo peut prendre les raccourcis qu'il veut, si tu fais des trucs qui ont des effets de bord ce sera un poil plus lent mais au moins ça marchera comme il faut, même dans plusieurs années.

GoldenCrystal (./338) :
u veux dire qu'on peut écrire du code non portable sans même avoir un warning ?

Oui, parce que le compilateur n'a aucun moyen de savoir que ton code n'est pas portable. Une fonction sans effets de bord globaux ne posera pas de problème pour ce genre d'usage. Si l'ordre des appels importe, c'est à toi d'écrire des instructions séparées pour tes appels de fonction. (Le point-virgule est évidemment un sequence point, de même que l'opérateur virgule, mais pas la virgule des appels de fonction.)

Par contre le coup de passer les arguments de gauche à droite me semble fumeux… Comment tu gères "..." du coup ?

Les conventions d'appel qui font ça (genre la convention __pascal sous W16) ne gèrent en général pas les varargs.

Sasume (./339) :
Martial> Pour en revenir à ton problème, mon avis est qu’en C (ou dans n’importe quel autre langage que l’ASM), ça ne vaut pas le coup de chercher à réduire le nombre de lignes de code. En assembleur une ligne égale une instruction, mais pas en langage de haut niveau où on peut du coup se permettre d’étendre son code sur plusieurs lignes, pour en améliorer la lisibilité, sans pour autant diminuer la qualité du code produit par le compilateur.

J'approuve, et j'ai laissé mon écriture en deux lignes, que je préfère à celle de aze en ./330

Tu veux dire qu'on peut écrire du code non portable sans même avoir un warning ?

On peut écrire du code fortement non portable (entre architectures et entre compilos) sans même avoir un warning

Bon bah, vous venez d'augmenter très fortement mon affection pour le C#

Hmm, je sais pas si le C# est spécifié de sorte à n'avoir aucun comportement indéfini (dont des programmes pourraient dépendre, mais qui pourrait être implémenté différemment par exemple par Mono), hein

Comme je l'ai dit, c'est en tous cas le but du Java donc c'est probablement vrai en C# aussi. Et ça fait du bien de pas avoir à réfléchir quand tu écris une expression - juste à savoir ce que tu fais. Exemple bête, on veut écrire ça:

FILE *f;
[...]
if (f = fopen("truc", "r")) {
    [...]
}

Ben à éviter, parce que ça fout un warning sous GCC, du coup si mon code était recompilé un jour sous GCC je passerais pour un type qui code comme un porc (ce qui est bien évidemment parfaitement faux )

./345 > Bah disons que tu as l'endianness qui *pourrait* poser problème en cas d'utilisation de code unsafe (=> pointeurs), et l'initialisation statique des classes non déterministe, qui par définition, est « indéfinie ».
Le C# ne garantit aucun endianness particulier, mais en revanche il spécifie précisément les cas où l'initialisation statique sera déterministe ou non
Enfin globalement le langage ne laisse pas grand chose au hasard. Ce qui peut varier c'est au niveau du runtime (ce sont normalement des modifications sans impact, à part sur les performances) et de la bibliothèque de classes utilisée, mais ça s'arrête là
Pour le reste, en dehors des types pointeurs/entiers natifs (incluant IntPtr et UIntPtr), tous les types sont comme en Java, parfaitement définis et ont une taille fixe.
Par exemple, sizeof(int) == 4 sera toujours vrai quel que soit le compilateur ou le runtime employé.
C'est bien plus simple que le langage C hein ?

Folco (./342) :
J'approuve, et j'ai laissé mon écriture en deux lignes, que je préfère à celle de aze en ./330

Bah, moi je n'aime pas les écritures qui ajoutent 1 puis le retirent ou l'inverse, l'écriture compacte est plus efficace en principe (même si l'optimisation règle ce problème normalement).

Brunni (./346) :
Comme je l'ai dit, c'est en tous cas le but du Java donc c'est probablement vrai en C# aussi.

Sauf que la pratique est très différente comme l'a montré GCJ. La seule raison pour laquelle OpenJDK est tellement compatible est que c'est carrément l'implémentation qui a été libérée, la spec toute seule ne suffisait pas.

tu la connais bien on dirait la spec du java.

c'est surtout que gcj est une merde qui fait les choses à sa façon. Blamer la spec au lieu des devs, je connais.

./346> C'est correct mais quand même goret comme code ça

M'étonne que tu ne savais pas que la portabilité du C était du genre à se briser en morceaux si on souffle dessus, GoldenCrystal
Ça doit faire trop longtemps que tu ne fais que du C#.

Le code de Brunni ne me choque pas, moi. Si tu fais un machin = fopen(...) puis if (!machin), un jour tu feras un copier/coller et tu oublieras de changer la variable dans l'une des deux lignes.
Pour ce qui est du warning, suffit de rajouter une paire de parenthèses pour que GCC se taise, ou alors de faire if ((machin = fopen(...)) != NULL)
(que je trouve plus expressif bien qu'un peu plus verbeux)

(et avant que Ximoon ne râle : ouais, si vous bossez dans l'embarqué critique, écrire ce genre de trucs n'est probablement pas accepté )

Zerosquare (./350) :
M'étonne que tu ne savais pas que la portabilité du C était du genre à se briser en morceaux si on souffle dessus, GoldenCrystal

Bah, je savais pour la taille des types variables entre 1 bit et ∞, pour l'endianness indéterminé, les atroces cast d'entiers en pointeurs et de pointeurs en entiers (bon ok, le C# peut aussi dans une certaine mesure), mais bon les abominations qu'a balancé Kevin, non, je connaissais pas

(Sinon le code de Brunni ne me pose aucun problème non plus )

Les casts de pointeurs peuvent aussi rapidement entraîner du comportement indéterminé (mais GCC te donne des warnings en général, d'ailleurs même un truc indéterminé du genre i = i++ donne un warning sous GCC), cf. strict aliasing.

Y a-t-il une fonction de la libc qui permette de réaliser une insertion dans un fichier, à un emplacement déterminé ? Donc redimensionnement du fichier et déplacement du bloc de données après les données à écrire ?

Hmm pas à ma connaissance… Mais les insertions de données dans un fichier c'est le mal !
Tu imagines si tu ajoutes plein d'octets (un par un bien sur !) au début d'un gros fichier de 1 Go ? C'est la catastrophe sur les performances

sur un système bien fait on aurait un chainage de blocs

Ben ça marcherait bien que si tu insères à un emplacement qui est un multiple de la taille des blocs ^^

Enfin c'est possible aussi sans recopie même dans le cas général, mais là ça demande de changer beaucoup de choses dans l'approche du système de fichiers. Peut-être que ça existe déjà ? (y'a beaucoup d'approches "inhabituelles" qui ont été implémentées dans des systèmes de fichiers "spéciaux")

En tout cas la fonction "insertion" est pas implémentée dans la libc, c'est sûr

Ok, c'est bien ce que j'avais cru comprendre à la sortie de ma lecture de l'après-midi, mais je voulais en être sûr.

le mieux qui me vient à l'esprit, c'est
-open()
-mmap()
-memmove()
-maj de l'endroit à insérer
-close()

Je pense que des fread/fwrite par blocs de 4096 octets seraient plus efficaces. (Si le fichier est gros, éventuellement une puissance de 2 plus élevée pour être sûr pour l'avenir, déjà les programmes qui utilisent des blocs de 512 (ou 1024 ou 2048) octets se tapent une pénalité de performances sur les disques dur les plus récents.) memmove n'est pas optimisée pour les espaces mmap.

Le problème dans tout ça c que si jamais quelque chose (coupure de courant, programme qui plante, os qui plante, …) foire au milieu de la modification du fichier, y'a un fort risque qu'une partie (au moins) des données soit perdue.
Bon, y'a quand même un moyen pas trop tordu ni compliqué pour sécuriser ça mais il faut y penser