La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Logiciels => Discussion démarrée par: BadMax le 05 mars 2015 à 11:37:30
-
Edit Vivien : Hors sujet extrait du post Droit de "Bloquer un sujet" (https://lafibre.info/evolution/droit-de-bloquer-un-sujet/)
Ah oui, et où ça?
Est-ce que la seule allusion au NAT est polémique, comme le fait de parler de GOTO dans certains cercles? (j'ai cessé de parler plusieurs années à quelqu'un de ma famille à cause de sa phobie du GOTO)
Le GOTO c'est le maaaaaaal
-
Beuh, le goto est la base de toute programmation (ou presque) : faire des sauts.
goto == if == while == for == function : c'est un jmp
-
Moi on m'a appris à faire des boucles et à bien structurer mes conditions :) #profAyatollah
Je parle du goto des langages évolués, pas le jmp en assembleur qui lui est incontournable :)
-
Tu parles d'un langage évolué type C ?
Dans ce type de langage, le goto est exactement comme un if(true) : un saut.
-
Le GOTO c'est mal surtout parce que le code devient illisible (faut retrouver le label correspondant toussa toussa, ...) et qu'au final on fait la même chose avec des instructions conditionnelles ou de boucle qui ont des délimiteurs qui permettent de faciliter la lecture.
Donc oui au concept mais non à l'utilisation de cette instruction satanique (sauf si on n'a pas le choix... genre en batch...)
Bon on est encore en train de bordéliser un topic là ;)
-
Le GOTO c'est mal surtout parce que le code devient illisible (faut retrouver le label correspondant toussa toussa, ...) et qu'au final on fait la même chose avec des instructions conditionnelles ou de boucle qui ont des délimiteurs qui permettent de faciliter la lecture.
Donc oui au concept mais non à l'utilisation de cette instruction satanique (sauf si on n'a pas le choix... genre en batch...)
Bon on est encore en train de bordéliser un topic là ;)
Ben vois-tu, je ne suis pas (du tout) d'accord avec toi.
Je pense que, comme beaucoup, tu es dans le matraquage des universitaires qui n'ont jamais codé, et qui considère que "on peut faire quelque chose de mauvais avec, donc c'est mauvais".
Les mêmes personnes haissent le C, parcque "tu peux faire de l'allocation mémoire manuelle, et donc des segfault / overflow, et donc c'est mauvais".
Une petite citation pour la route:
UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things.
L'utilisation du goto peut-être très pratique, en particulier dans la gestion des erreurs, par exemple:
..
ret = fstatat(dirfd, name, &st, 0);
if (ret)
goto out;
..
if (S_ISDIR(st.st_mode))
goto out;
..
out:
fprintf(stderr, "Haha!");
return -1;
C'est nettement mieux que les autres possibilitées :
- dupliquer le code gestion d'erreur
- créer une fonction à chaque fois
-
Inquisitionnnnnnnnnnnnn !!!!!!!!!!!!!!
En C, je fais :
- une fonction pour gérer mes erreurs qui nécessite un simple appel
- une fonction qui catch les SIGILL ou autre pour indiquer où j'en étais au moment du core dump (avec une simple chaine globale qu'il suffit de mettre à jour suivant la fonction appelée)
-
L'utilisation du goto peut-être très pratique, en particulier dans la gestion des erreurs.
Ca date un peu ton argument, on a inventer try/throw/catch/finally depuis et meme en C: https://code.google.com/p/exceptions4c :P
#include "e4c.h"
try {
ret = fstatat(dirfd, name, &st, 0);
if (ret)
throw (RuntimeException,'le stat a foiré !');
..
if (S_ISDIR(st.st_mode))
throw (RuntimeException,'booo un répertoire !');
..
}
catch {
const e4c_exception * exception = e4c_get_exception();
fprintf(stderr, "Haha! a cause de %s", exception->message);
return -1;
}
c'est quand meme plus propre et on peut passer la cause plus facilement qu'avec un goto ;) et libérer des ressources avec un finally sans se faire zapper pas un return interne.
et c'est mis en oeuvre par des goto ;)
-
Bouahaha, trop facile ;D
En C, je fais :
- une fonction pour gérer mes erreurs qui nécessite un simple appel
- une fonction qui catch les SIGILL ou autre pour indiquer où j'en étais au moment du core dump (avec une simple chaine globale qu'il suffit de mettre à jour suivant la fonction appelée)
Prenons un exemple réel.
J'ai une fonction, qui, dans l'ordre:
- ouvrir un fichier
- alloue de la mémoire
- crée un pool de thread et fait d'autres trucs
Chaque truc est nécessaire pour faire les suivants:
- j'ai besoin de mon fichier avant de threader le truc
- j'ai besoin de la mémoire allouée avant de threader le truc
Donc, je ne peux que swap les deux premières instructions (mais au final, cela ne change rien).
J'ai donc plusieurs cas d'erreur :
- si l'ouverture échoue : return
- si l'allocation échoue : je dois clore le fichier
- si le threading échoue : je dois clore le fichier, et libérer la mémoire
En swappant les deux premières instructions:
- si l'alloc échoue: return
- si l'ouverture échoue: free
- si le threading échoue : clore le fichier, et libérer la mémoire
Dans tout les cas, après exécution des trois opérations, je dois clore le fichier, libérer la mémoire, libérer le pool de thread.
Donc, en faisant une fonction, il faut que je lui donne :
- le fd
- le pointeur sur ma mémoire
- le pointeur sur mon pool
Si je clos le fichier alors qu'il n'est pas ouvert : zut.
Si je libère ma mémoire alors qu'elle n'est pas allouée : zut !
Si je libère le pool alors que la création dudit pool a échouée, humpf
Donc, dans ma fonction, je dois aussi lui donner un moyen de savoir quoi faire des 3 paramètres suscités.
N'est-ce pas un peu compliqué ? 8)
[quote="kergsen"
Ca date un peu ton argument, on a inventer try/throw/catch/finally depuis et meme en C: https://code.google.com/p/exceptions4c :P
[/quote]
Pour reprendre mon exemple ci-dessus, cela signifie que je dois mettre des try/catch imbriqués, c'est à dire augmenter d'autant la profondeur du code, c'est à dire diminuer d'autant la lisibilité dudit code.
Je trouve que c'est beaucoup faire pour remplacer une solution qui n'a qu'une idéologie contre elle, non ?
Au passage, concernant exceptions4c, je note que le truc utilise des signaux : ce n'est donc pas utilisable sur des programmes multi-threadé (https://code.google.com/p/exceptions4c/wiki/threads); Rien que pour cela, non merci, goto still rulz :D
Amicalement,
-
Je ne pense pas que ce soit par idéologie mais plus pour de la clarté, réutilisation/partage du code, optimisation (pas mal d'optimisations de haut-niveau ne marchent plus quand il y a des goto), portage/transpilation (https://fr.wikipedia.org/wiki/Compilateur_source_%C3%A0_source)vers d'autre langage, etc
Apres moi, je ne suis pas dogmatique, il m'est arrivé souvent d'utiliser des goto, du moins au début de ma carrière ou sur des très petits projets. Mais j'évite autant que faire ce peut quand même.
Pour ton exemple, t'as pas besoin d'imbriqué les try/catch, un seul suffit. En général on init les variables de ressource a 'null' et dans le finally on libere (dans l'autre sens) celles qui ne sont pas a null.
fichier = NULL;
memoire = NULL;
pool = NULL;
...
try {
if (! (fichier = open(...))) throw(RuntimeException,"erreur ouverture fichier");
if (! (memoire = malloc(...)) throw(RuntimeException,"plus de memoire");
if (! (pool = ...)) throw(RuntimeException,"pas de pool!");
...
catch {
... gestion de l'erreur (affichage, log, etc)
}
finally
{
if (pool) ... // tue les threads, libere le pool;
if (memoire) free(memoire);
if (fichier) close(fichier);
}
-
Si je clos le fichier alors qu'il n'est pas ouvert : zut.
Si je libère ma mémoire alors qu'elle n'est pas allouée : zut !
Si je libère le pool alors que la création dudit pool a échouée, humpf
sortie(code,fd, mem, pool)
{
if (fd!=0){close(fd);}
if (mem!=NULL){free(mem);}
if (pool!=NULL){truckinettoie(pool);}
exit(code);
}
Des questions ? :)
-
Oui : en quoi est mieux que :
goto out;
out:
if (fd!=0)
close(fd);
if (mem!=NULL)
free(mem);
if (pool!=NULL)
truckinettoie(pool);
-
La portée de ton goto se limitera à ton .c alors qu'une fonction pourra etre rangée au propre et appelée depuis n'importe autre source, bref un vrai code modulaire.
-
Si goto est le mal, alors qu'est-ce qu'on doit dire de setjmp() et longjmp() ?
-
+1 avec BadMax...
Bon allez c'est trolldi donc je me lâche... Si en même temps vous utilisez des langages du moyen-âge... Bizarrement en C# j'ai jamais ressenti le besoin d'utiliser de GOTO d'aucune sorte.
Ben vois-tu, je ne suis pas (du tout) d'accord avec toi.
Je pense que, comme beaucoup, tu es dans le matraquage des universitaires qui n'ont jamais codé, et qui considère que "on peut faire quelque chose de mauvais avec, donc c'est mauvais".
Les mêmes personnes haissent le C, parcque "tu peux faire de l'allocation mémoire manuelle, et donc des segfault / overflow, et donc c'est mauvais".
Alors pour info je n'ai pas de formation universitaire en informatique (ni même école d'ingénieur d'ailleurs) je suis totalement autodidacte (et je suis loin de me considérer comme un cador...). Ma formation informatique s'est limité à du Pascal, du C et du Java en application à du calcul numérique (donc essentiellement des algorithmes mathématiques qu'on finissait par implèmenter). Autant te dire, que nos profs étaient plus matheux qu'informaticiens (à part un mais il était alcoolique et officier de sécurité) et que du coup ce genre de considération leur passait au dessus de la tête.
Mon avis sur le GOTO s'est forgé avec "l'expérience"... Mais effectivement je suis plutôt d'accord avec le fait que ce n'est pas intrinsèquement mauvais, c'est juste que dans 90% des cas, c'est très mal utilisé. Après mon expérience est relativement limitée vu le nombre de projets sur lesquels j'ai bossé. Peut-être que dans quelques années, je ferai l'apologie du GOTO qui sait (mais j'y crois pas en le disant ;))
-
Si en même temps vous utilisez des langages du moyen-âge... Bizarrement en C# j'ai jamais ressenti le besoin d'utiliser de GOTO d'aucune sorte.
Inquisitionnnnnnnnnnnnn !!!!!!!!!!!!!!
;D ;D
-
En Java il n'y a pas d'instruction goto, à ma connaissance. :)
En C++ et C#, c'est vrai que le système d'exceptions fournit une alternative plus adaptée à la plupart des cas d'usages du goto. Mais en C, son usage reste courant...
Bien entendu, on peut rendre du code illisible avec. Mais on n'a pas non plus besoin de l'instruction goto pour atteindre ce but: un peu d'arithmétique incompréhensible sur les pointeurs ou une surcharge d'opérateurs infâme permettra de rendre un code imbitable à coup sûr.
Et cet argument peut marcher dans les deux sens... comme l'a montré jack, il existe des cas où un goto est beaucoup plus clair que de multiples niveaux d'imbrication.
En tout cas, il faut quand même savoir que l'usage du goto en C est loin d'être rare en pratique. Le noyau Linux en est d'ailleurs truffé.
-
Bizarrement en C# j'ai jamais ressenti le besoin d'utiliser de GOTO d'aucune sorte.
encore heureux ;) C# et les autres langages de plus haut niveau que C permettent dans la plus part des cas d'éviter l'emploi de goto.
Le C est un peu a part. On fait des trucs très bas niveau avec et souvent utiliser un goto peut-être très pratique et concis (pour sortir d'une imbrication de "if" notamment ).
Il ne faut pas généraliser un langage ou des techniques de programmation a toutes sortes de cas et de types de projets.
Quand on écrit un driver bas niveau ou un soft embarqué pour du temps réel ou un gros logiciel de gestion on n'a pas du tout les mêmes contraintes et on n'utilise pas les mêmes techniques.
Le contexte est donc primordial et devrait passer avant le fait d'être dogmatique sur l'emploi ou non du goto.
-
C'est rigolo, quand j'avais suivi une pseudo formation AFPA en 2006/2007, le formateur insistait lourdement sur le fait qu'il ne fallait jamais utiliser de GOTO.
Après, vu qu'il était très mauvais, bloqué dans un modèle des années 80, et qu'il passait la moitié de sa journée à tenir un camion à pizza pour arrondir sa paie au lieu de nous former, je n'ai jamais su s'il fallait tenir compte de la seule chose qu'il a essayé de nous apprendre.
-
c'est une question de rigueur.
comme certains pro-java, pro-C# disant que le PHP c'est crade. Parce que eux meme sont des crados...
il y a des programmeurs qui ne savent pas coder correctement car ils ne savent pas utiliser une rigueur assidue qui leur ai propre, ils sont obligés d’être contraint par la rigueur même du langage.
-
J'aime bien cette approche donnée en exemple en Ada, langage utilisé en aéronautique et spatial sur de nombreux systèmes embarqués. Ada est normalement considéré comme exemplaire en terme de "propreté" à l'écriture et l'exécution (avec les débordements qu'on connait).
http://en.wikibooks.org/wiki/Ada_Programming/Control#Isn.27t_goto_evil.3F
procedure Use_Return is
begin
Do_Something;
if Test then
return;
end if;
Do_Something_Else;
return;
end Use_Return;
procedure Use_Goto is
begin
Do_Something;
if Test then
goto Exit_Use_Goto;
end if;
Do_Something_Else;
<<Exit_Use_Goto>>
return;
end Use_Goto;
Because the use of a goto needs the declaration of a label, the goto is in fact twice as readable than the use of return. So if readability is your concern and not a strict "don't use goto" programming rule then you should rather use goto than multiple returns. Best, of course, is the structured
approach where neither goto nor multiple returns are needed:
-
procedure Use_Goto is
begin
Do_Something;
if Test then
goto Exit_Use_Goto;
end if;
if Test2 then
goto Exit_Use_Goto;
end if;
Do_Something_Else;
<<Exit_Use_Goto>>
Do_Something
return;
end Use_Goto;
Et d'un coup, c'est nettement plus lisible, propre etc etc (pour de l'ada #trolldi)!
-
De toutes façons, l'avenir est au Windev :
// Exécution d'un thread avec passage de paramètres
sDate est une chaîne
sDate = DateSys()
// Exécution du thread
ThreadExécute("THREADNAME", threadNormal, "pExecReq", sDate)
// Détail de la procédure "pExecReq" qui attend une date en paramètre d'une requête
PROCEDURE pExecReq(sDate)
SI HExécuteRequête(Sup_Date, hRequêteDéfaut, sDate) = Faux ALORS
Erreur(HErreurInfo())
SINON
HLitPremier(Sup_Date)
FIN
Traduction des instructions en français littéral, autorisation des accents dans les variables, le rêve de tout développeur !
</trolldi>
-
Caractères non ascii dans les variables, je vois pas le soucis, tout le monde n'a pas en langue natale un truc à base de ASCII :D
Bon après le reste...
Windev a un gros avantage malgré tout en pratique : offre d'embauche avec Windev écrit dedans ? => tu passes à la suivante
-
Windev a un gros avantage malgré tout en pratique : offre d'embauche avec Windev écrit dedans ? => tu passes à la suivante
Et des pubs à accrocher sur la porte des toilettes des hommes.
GOTO: sortie
-
encore heureux ;) C# et les autres langages de plus haut niveau que C permettent dans la plus part des cas d'éviter l'emploi de goto.
Le C est un peu a part. On fait des trucs très bas niveau avec et souvent utiliser un goto peut-être très pratique et concis (pour sortir d'une imbrication de "if" notamment ).
Qu'est-ce que tu appelles "bas niveau"?
-
Il entend bas niveau dans le sens abstraction :
- gestion manuelle de la mémoire du tas vs les garbage collector du C# ou du Java,
- l'accès à des primitives systèmes dans un code machine vs l'utilisation d'un code binaire intermédiaire qui sera interprété par une machine virtuelle,
- le fait que le C et le C++ sont davantage utilisés dans de la recherche de performance (jeux...) ou des pilotes vs une facilité de l'environnement de programmation pour le développeur, etc.
-
- le fait que le C et le C++ sont davantage utilisés dans de la recherche de performance (jeux...) ou des pilotes vs une facilité de l'environnement de programmation pour le développeur, etc.
Pas d'accord du tout!
Il y a beaucoup de choses pas du tout orienté performance en C, à commencer par les chaines terminées par NUL, les E/S, etc.
Le C n'est pas du tout un vrai bon langage de bas niveau. Ada est beaucoup plus orienté bas niveau.
-
J'aime bien cette approche donnée en exemple en Ada, langage utilisé en aéronautique et spatial sur de nombreux systèmes embarqués. Ada est normalement considéré comme exemplaire en terme de "propreté" à l'écriture et l'exécution (avec les débordements qu'on connait).
Comme Ariane qui fait boum?
-
Qu'est ce que ça à avoir avec la performance le fait que les chaînes soient terminées par NULL ? C'est du fait seul que le type string n'existe pas en en C ANSI. A la place on fait appel à la logique des pointeurs.
Pour les E/S il y a plusieurs façons de faire, soit en passant par les bibliothèques C, soit en passant directement par les primitives systèmes... Et quoi qu'il en soit, à moins de programmer au niveau même du noyau j'imagine, il y aura toujours un problème de performances vu qu'il s'agit d'interruptions système.
Il n'y avait nulle référence à ADA dans son post. La comparaison était par rapport aux langages plus haut niveau qu'on a cité tous deux.
Il y a évidemment plus bas niveau que le C... Tout ce qui est programmation en assembleur par exemple. Mais çà n'occulte pas qu'on est en dessous du C# ou Java.
En tout cas, dans un contexte de très faible mémoire ou de temps réel j'ai pas souvenir d'avoir vu ces derniers privilégiés au C.
-
Qu'est ce que ça à avoir avec la performance le fait que les chaînes soient terminées par NULL ? C'est du fait seul que le type string n'existe pas en en C ANSI.
Si, il y a plusieurs types string : char[n] et char* (et les mêmes en const).
A la place on fait appel à la logique des pointeurs.
Pour les E/S il y a plusieurs façons de faire, soit en passant par les bibliothèques C, soit en passant directement par les primitives systèmes... Et quoi qu'il en soit, à moins de programmer au niveau même du noyau j'imagine, il y aura toujours un problème de performances vu qu'il s'agit d'interruptions système.
Je parles de printf et co.
Il n'y avait nulle référence à ADA dans son post.
Et alors?
La comparaison était par rapport aux langages plus haut niveau qu'on a cité tous deux.
Il y a évidemment plus bas niveau que le C... Tout ce qui est programmation en assembleur par exemple. Mais çà n'occulte pas qu'on est en dessous du C# ou Java.
C'est quoi ça être en dessous?
En tout cas, dans un contexte de très faible mémoire ou de temps réel j'ai pas souvenir d'avoir vu ces derniers privilégiés au C.
Justement, il y a un dialecte de Java conçu spécifiquement pour un contexte de mémoire très très faible avec des contraintes temps réel.
-
Ariane 501 qui fait boum, c'est plus un échec des procédures de validation qu'autre chose...
Que ce bug ait existé, c'est une chose... qu'il n'ait pas été détecté avant le vol du premier FM, c'est là où ça craint.
-
Comme Ariane qui fait boum?
Par exemple :)
-
Ariane 501 qui fait boum, c'est plus un échec des procédures de validation qu'autre chose...
Que ce bug ait existé, c'est une chose... qu'il n'ait pas été détecté avant le vol du premier FM, c'est là où ça craint.
C'est une exception Ada "castée" (réinterprétée) à la C en valeur numérique.
C'est une cascade de fautes, de bugs, d'imbécillités.
C'est aussi un code absolument abject.
-
On parle de 'bas niveau' pour désigner un langage qui est "proche" du cpu, c'est a dire proche de l'assembleur. Par 'proche' on entend la complexité qu'il faut pour le compiler et le traduire en assembleur et le faible niveau d'abstraction qu'il offre.
A l'inverse on parle de 'haut niveau' pour les langages qui sont 'loin' du cpu, qui ont un haut niveau d'abstraction et sont souvent interprétés au lieu d'être compilés et dont la compilation, quand elle a lieu, est souvent complexe. D'ailleurs en pratique on compile souvent un langage de haut niveau vers un langage de bas niveau qu'on compile ensuite en assembleur pour générer du code exécutable. Cela permet de simplifier la portabilité et les optimisations: en générant du C on peut après le compiler et l'optimiser avec les outils propres a chaque OS et au passage, on profite des décennies de progrès faites sur la compilation du C.
Il fréquent d'ailleurs dans le code C généré par les compilateurs (et les "transpileurs") de haut niveau de générer énormèment de goto.
-
C'est une exception Ada "castée" (réinterprétée) à la C en valeur numérique.
C'est une cascade de fautes, de bugs, d'imbécillités.
C'est aussi un code absolument abject.
C'est surtout un bug qui aurait été détecté si les SRI (systèmes de référence inertiels) avaient été validés avec la trajectoire simulée d'Ariane 5.
Ou si les SRI avaient été testés en boucle fermée.
-
kgersen laisse tomber... Nous sommes en train de nourrir un troll...
Ça beau être habituel avec corrector, ça me déprime quand même.
Autre chose à faire de mes soirées que de partir dans un débat stérile où un mot aléatoire est retenu dans une phrase et les arguments intéressants ignorés.
Les vrais curieux iront se documenter...
-
C'est surtout un bug qui aurait été détecté si les SRI (systèmes de référence inertiels) avaient été validés avec la trajectoire simulée d'Ariane 5.
Ou si les SRI avaient été testés en boucle fermée.
Disons que les bugs existent, qu'est-ce qui justifiait que ce bug provoque cette conséquence?
Rien!
-
On parle de 'bas niveau' pour désigner un langage qui est "proche" du cpu, c'est a dire proche de l'assembleur. Par 'proche' on entend la complexité qu'il faut pour le compiler et le traduire en assembleur et le faible niveau d'abstraction qu'il offre.
A l'inverse on parle de 'haut niveau' pour les langages qui sont 'loin' du cpu, qui ont un haut niveau d'abstraction et sont souvent interprétés au lieu d'être compilés et dont la compilation, quand elle a lieu, est souvent complexe. D'ailleurs en pratique on compile souvent un langage de haut niveau vers un langage de bas niveau qu'on compile ensuite en assembleur pour générer du code exécutable. Cela permet de simplifier la portabilité et les optimisations: en générant du C on peut après le compiler et l'optimiser avec les outils propres a chaque OS et au passage, on profite des décennies de progrès faites sur la compilation du C.
Il fréquent d'ailleurs dans le code C généré par les compilateurs (et les "transpileurs") de haut niveau de générer énormèment de goto.
Qu'est-ce que tu appelles "complexe"?
-
C'est surtout un bug qui aurait été détecté si les SRI (systèmes de référence inertiels) avaient été validés avec la trajectoire simulée d'Ariane 5.
Ou si les SRI avaient été testés en boucle fermée.
Suffisait de relire le cahier des charges pour se rendre compte qu'aucun des systèmes inertiels n'était prévu pour la poussée d'Ariane 5.
-
Suffisait de relire le cahier des charges pour se rendre compte qu'aucun des systèmes inertiels n'était prévu pour la poussée d'Ariane 5.
Pourquoi le composant était toujours actif?
-
Quel composant ?
-
Qu'est-ce que tu appelles "complexe"?
l'antonyme de simple
-
l'antonyme de simple
On est bien avancé...
-
On est bien avancé...
C'est pourtant simple ou pas complexe.
-
GCC C est "simple", oui oui oui...
-
kgersen laisse tomber... Nous sommes en train de nourrir un troll...
Ça beau être habituel avec corrector, ça me déprime quand même.
Autre chose à faire de mes soirées que de partir dans un débat stérile où un mot aléatoire est retenu dans une phrase et les arguments intéressants ignorés.
Pardon, mais les arguments que j'ai vu était pas vraiment intéressants, et même plutôt à coté de la plaque pour être gentil.
C n'est pas du tout un langage adapté ni pour être proche du matériel (voir le merdier du C dans les parties proche du matériel de linux) ni pour être efficace. D'ailleurs être efficace et être de bas niveau sont des objectifs incompatibles pour un langage de programmation primaire comme le C.
A contrario : Ada
-
On parle de 'bas niveau' pour désigner un langage qui est "proche" du cpu, c'est a dire proche de l'assembleur. Par 'proche' on entend la complexité qu'il faut pour le compiler et le traduire en assembleur et le faible niveau d'abstraction qu'il offre.
A l'inverse on parle de 'haut niveau' pour les langages qui sont 'loin' du cpu, qui ont un haut niveau d'abstraction et sont souvent interprétés au lieu d'être compilés et dont la compilation, quand elle a lieu, est souvent complexe. D'ailleurs en pratique on compile souvent un langage de haut niveau vers un langage de bas niveau qu'on compile ensuite en assembleur pour générer du code exécutable.
Ce serait sympa de donner des exemples.
Cela permet de simplifier la portabilité et les optimisations: en générant du C on peut après le compiler et l'optimiser avec les outils propres a chaque OS et au passage, on profite des décennies de progrès faites sur la compilation du C.
Le C est très difficilement optimisable. Il n'a pas été conçu pour être optimisable. Et quand un compilateur décide de s'amuser à vraiment optimiser il casse énormèment de code, voir linux par exemple. La "sémantique" est un vrai merdier.
Il fréquent d'ailleurs dans le code C généré par les compilateurs (et les "transpileurs") de haut niveau de générer énormèment de goto.
Oui parce que goto est l'opération élèmentaire qui défini les "structures" de la soi-disant programmation structurée.
-
Qu'est ce que ça à avoir avec la performance le fait que les chaînes soient terminées par NULL ?
Là on voit que tu n'y connais vraiment rien.
Une structure de donnée terminée par un symbole spécial doit être parcourue en entier juste pour déterminer sa taille.
C'est du fait seul que le type string n'existe pas en en C ANSI.
Non, c'est du fait que c'est plus simple pour le programmeur! Sinon il faudrait se balader avec deux pointeurs! Ou un pointeur et un entier! Comme memxxxx! Et oui! Réveille-toi!
A la place on fait appel à la logique des pointeurs.
Pour les E/S il y a plusieurs façons de faire, soit en passant par les bibliothèques C, soit en passant directement par les primitives systèmes... Et quoi qu'il en soit, à moins de programmer au niveau même du noyau j'imagine, il y aura toujours un problème de performances vu qu'il s'agit d'interruptions système.
Absolument n'importe quoi, ça aucun rapport avec les interruptions. Quels interruptions en fait?
Il n'y avait nulle référence à ADA dans son post. La comparaison était par rapport aux langages plus haut niveau qu'on a cité tous deux.
Je fais des comparaisons.
Tu n'es pas assez compétent pour voir un rapport. Trop "complexe" pour toi, laisse tomber!
Il y a évidemment plus bas niveau que le C... Tout ce qui est programmation en assembleur par exemple. Mais çà n'occulte pas qu'on est en dessous du C# ou Java.
Java est basé sur le C?
En tout cas, dans un contexte de très faible mémoire ou de temps réel j'ai pas souvenir d'avoir vu ces derniers privilégiés au C.
Tu n'as pas vu grand chose dans ta vie.
-
Beuh, le goto est la base de toute programmation (ou presque) : faire des sauts.
goto == if == while == for == function : c'est un jmp
Je sais pas de quel goto tu parles, mais en C le goto c'est à l'intérieur d'une fonction!
-
+1 avec BadMax...
Bon allez c'est trolldi donc je me lâche... Si en même temps vous utilisez des langages du moyen-âge... Bizarrement en C# j'ai jamais ressenti le besoin d'utiliser de GOTO d'aucune sorte.
Tu peux me montrer comment tu fais une simple recherche d'une valeur négative dans un tableau, avec retour de l'index de la première valeur?
-
Si goto est le mal, alors qu'est-ce qu'on doit dire de setjmp() et longjmp() ?
L'antéchrist?
-
C'est rigolo, quand j'avais suivi une pseudo formation AFPA en 2006/2007, le formateur insistait lourdement sur le fait qu'il ne fallait jamais utiliser de GOTO.
Donner des conseils négatifs, on fait difficilement plus crétin.
Dommage que tu n'ai pas demandé ce qu'il fallait utiliser.
-
C n'est pas du tout un langage adapté ni pour être proche du matériel (voir le merdier du C dans les parties proche du matériel de linux) ni pour être efficace. D'ailleurs être efficace et être de bas niveau sont des objectifs incompatibles pour un langage de programmation primaire comme le C.
Il peut intégrer de l'assembleur et dispose d'un accès rapide aux zones mémoires, il est donc plus proche que la majorité des merdes^Wlangages "qui rosk"
Le C est très difficilement optimisable. Il n'a pas été conçu pour être optimisable. Et quand un compilateur décide de s'amuser à vraiment optimiser il casse énormèment de code, voir linux par exemple. La "sémantique" est un vrai merdier.
Exemple ?
Oui parce que goto est l'opération élèmentaire qui défini les "structures" de la soi-disant programmation structurée.
Exactement !
(pourquoi "soi-disant" ? tu peux développer ?)
Là on voit que tu n'y connais vraiment rien.
Une structure de donnée terminée par un symbole spécial doit être parcourue en entier juste pour déterminer sa taille.
Boarf, pas la peine d'être méchant hein ?
char* n'est pas une chaine, c'est un tableau de caractère. Si le dernier caractère est \0, alors ce tableau peut-être analysé comme un chaine par les fonctions standards de manipulation desdites chaines. Sinon, overflow en cas d'essai;
Si tu veux manipuler un tableau comme un chaine, de facto, le NULL final n'est pas efficace, tu devrais donc faire une structure pour ajouter le nombre de caractère de la chaine;
Absolument n'importe quoi, ça aucun rapport avec les interruptions. Quels interruptions en fait?
Oui, c'est n'importe quoi (parcque les IO font toujours appels à des syscall, quel que soit le langage utilisé, en userspace).
En revanche, cela a tout à voir avec les interruptions.
Rappel de "comment faire un syscall":
- remplir les registres avec les paramètres, valeur de retour, type etc du syscall
- utiliser l'assembleur "int"
C'est "coûteux" du fait d'un changement de contexte, mais pas scandaleux et surtout nécessaire;
Je sais pas de quel goto tu parles, mais en C le goto c'est à l'intérieur d'une fonction!
Ouais, ce n'est pas le même mot clé (longjmp ou un truc du genre pour les goto "globaux"), cela ne change en rien la nature de la chose;
-
Il peut intégrer de l'assembleur et dispose d'un accès rapide aux zones mémoires, il est donc plus proche que la majorité des merdes^Wlangages "qui rosk"
N'importe quel langage peut proposer un accès aux zones mémoires, même BASIC (peek).
Boarf, pas la peine d'être méchant hein ?
Si, quand on m'agresse ça vaut la peine!
Oui, c'est n'importe quoi (parcque les IO font toujours appels à des syscall, quel que soit le langage utilisé, en userspace).
En revanche, cela a tout à voir avec les interruptions.
Rappel de "comment faire un syscall":
- remplir les registres avec les paramètres, valeur de retour, type etc du syscall
- utiliser l'assembleur "int"
Tu décris juste une implèmentation possible sur un CPU donné. Un cas particulier donc.
C'est "coûteux" du fait d'un changement de contexte, mais pas scandaleux et surtout nécessaire;
Pas forcèment. Il y a aussi le mappage mémoire.
-
Oui parce que goto est l'opération élèmentaire qui défini les "structures" de la soi-disant programmation structurée.
(pourquoi "soi-disant" ? tu peux développer ?)
De quelle "structuration" on parle?
La sémantique d'un bloc d'instruction c'est exécution la première instruction, déplacer le pointeur d'instruction et continuer avec le reste. Et de temps en temps, déplacer le pointeur d'instruction.
La programmation impérative est fondamentalement une manipulation du pointeur d'instruction. On peut essayer de maquiller ça un peu mais c'est du flan, on en revient toujours à ça.
L'absence de goto est un goto implicite à l'instruction suivante.
Quand on décrit la sémantique d'un langage, on a le vrai truc sans fard, sans artifices.
-
C'est "coûteux" du fait d'un changement de contexte, mais pas scandaleux et surtout nécessaire;
Pardon mais tu racontes n'importe quoi!
C'est nécessaire uniquement quand tu as besoin immédiatement d'une information (cette information peut être "void" ou "unit" : une information vide qui indique qu'une opération est terminée).
Pour les write de toute façon le fait que write retourne une valeur indique juste que de la place a été trouvée dans un tampon ou un cache pour écrire les données. Elles n'ont encore été envoyées nul part (sauf cas particulier).
Donc un "changement de contexte" (ou changement de quoi que ce soit) n'est pas du tout nécessaire.
-
Ouais, ce n'est pas le même mot clé (longjmp ou un truc du genre pour les goto "globaux"), cela ne change en rien la nature de la chose;
Absolument n'importe quoi!
longjmp n'a vraiment rien à voir avec goto.
Je ne sais pas si ça vaut le coup d'expliquer tellement c'est évident quand on a la moindre idée de ce que fait longjmp : aller au point mémorisé par setjmp dans une fonction active en sautant les fonctions intermédiaires, et restaurer peut être la valeur des variables locales ou peut être pas.
Donc tout est différent de goto!
Mélanger les deux n'a rigoureusement aucun sens!
-
N'importe quel langage peut proposer un accès aux zones mémoires, même BASIC (peek).
Tu peux m'apprendre comment faire avec un langage de script, genre php ou Python ? Ou javascript ? ;D
Non pas que je doute de ce que tu avances, juste que je suis curieux de savoir !
Donc j'aimerais bien que tu peux donne du code qui, pour un offset donné, me donne ce qui est écrit à cet endroit;
Tu décris juste une implèmentation possible sur un CPU donné. Un cas particulier donc.
Mon man 2 syscall me dit que mon cas particulier est massivement général :
Every architecture has its own way of invoking and passing arguments to
the kernel. The details for various architectures are listed in the
two tables below.
The first table lists the instruction used to transition to kernel
mode, (which might not be the fastest or best way to transition to the
kernel, so you might have to refer to vdso(7)), the register used to
indicate the system call number, and the register used to return the
system call result.
arch/ABI instruction syscall # retval Notes
───────────────────────────────────────────────────────────────────
arm/OABI swi NR - a1 NR is syscall #
arm/EABI swi 0x0 r7 r0
blackfin excpt 0x0 P0 R0
i386 int $0x80 eax eax
ia64 break 0x100000 r15 r10/r8 bool error/
errno value
parisc ble 0x100(%sr2, %r0) r20 r28
s390 svc 0 r1 r2 See below
s390x svc 0 r1 r2 See below
sparc/32 t 0x10 g1 o0
sparc/64 t 0x6d g1 o0
x86_64 syscall rax rax
Dans tout les cas, il y a utilisation d'une instruction assembleur dédié (mais cette liste n'est pas exhaustive vas-tu répondre, certes)
Pas forcèment. Il y a aussi le mappage mémoire.
Pardon mais tu racontes n'importe quoi!
C'est nécessaire uniquement quand tu as besoin immédiatement d'une information (cette information peut être "void" ou "unit" : une information vide qui indique qu'une opération est terminée).
Pour les write de toute façon le fait que write retourne une valeur indique juste que de la place a été trouvée dans un tampon ou un cache pour écrire les données. Elles n'ont encore été envoyées nul part (sauf cas particulier).
Donc le changement de contexte n'est pas du tout nécessaire.
Erreur : dans tout les cas, il y a entrée dans le contexte noyau, execution de code en kernelspace, retour en espace utilisateur : context switch;
Ce que tu essayes de rajouter, c'est qu'il existe des switchs plus "conservateur" que d'autres, c'est tout à fait vrai; Ça reste un switch;
longjmp n'a vraiment rien à voir avec goto.
Hey, t'as raison, les deux mots clefs ne sont pas rigoureusement identiques !
Comme c'est toi, je vais faire un peu de mauvaise foi pour la route : ça reste un goto, au sens sémantique du terme 8)
-
Tu peux m'apprendre comment faire avec un langage de script, genre php ou Python ? Ou javascript ? ;D
Tu rajoutes une API dans le navigateur qui fait juste ça.
Si quelqu'un te dit que c'est une énorme faille, tu le traites d'ignare, tu dévies la discussion sur le NAT et tu discutes des semaines sans corriger la faille. :D
Il faut bien insister que le bugtracker n'est pas un forum ou autre débilité du même style.
QUELS CONNARDS CES DEV CHROMIUM!!!!!
-
Mon man 2 syscall me dit que mon cas particulier est massivement général :
Dans tout les cas, il y a utilisation d'une instruction assembleur dédié (mais cette liste n'est pas exhaustive vas-tu répondre, certes)
Ben oui, il y a une instruction qui permet un appel système. Ce qui n'a absolument aucun rapport avec le concept d'interruption dont il était question. Une interruption c'est quand un périphérique veut interrompre le CPU, donc c'est asynchrone. L'instruction int n'interrompt rien, elle est synchrone.
-
Hey, t'as raison, les deux mots clefs ne sont pas rigoureusement identiques !
Comme c'est toi, je vais faire un peu de mauvaise foi pour la route : ça reste un goto, au sens sémantique du terme 8)
Vas-y, donne moi le sens sémantique!
-
Mon man 2 syscall me dit que mon cas particulier est massivement général :
Il ne dit rien de tel. Il ne parle même pas d'interruption!
Erreur : dans tout les cas, il y a entrée dans le contexte noyau, execution de code en kernelspace, retour en espace utilisateur : context switch;
Dans quels tous les cas?
Ce que tu essayes de rajouter, c'est qu'il existe des switchs plus "conservateur" que d'autres,
Ah bon, tu peux donner un exemple?
-
Exemple ?
Par exemple l'ordre en mémoire des membres d'une structure est imposé, le compilateur ne peut pas réorganiser pour gagner de la place, sauf à démontrer que ça n'a aucun impact, par analyse globale (passablement difficile, il faudrait suivre tous les pointeurs, je pense qu'aucun compilateur au monde ne s'amuse à ça).
Le C ne permet pas de dire : là je veux la représentation précisèment comme ça, là je m'en fou. (Ada le permet, mais l'autre taré va encore dire que je m'éloigne du sujet.)
Par exemple si une fonction reçoit deux pointeurs a et b, alors a[p] et b[q] peuvent désigner la même chose, même si a!=b. (En Java ce n'est pas le cas puisqu'il n'y a pas de pointeurs d'éléments mais des "références" (ce qui est façon politiquement correcte et hypocrite(*) de dire : des pointeurs) sur des tableaux.)
Fortran considère que a et b ne peuvent pas désigner la même chose, ce qui est une clé de la performance.
(*) Java est à la base un langage de bouffons hypocrites neuneu
Par exemple si le compilateur optimise les opérations portant sur des int en utilisant les lois de l'arithmétique (comme a*x/a est remplacé par x), il peut casser du code qui utilise le comportement habituel des int qui est le comportement modulaire fournis par le CPU - donc le C n'est pas du tout un langage de bas niveau puisqu'il ne permet pas d'utiliser les opérations arithmétiques du CPU (bon, on peut jouer sur volatile mais ça casse la performance vu qu'un compilateur ne veut pas en général mettre un volatile en registre même si rien ne s'y oppose).
Linus n'est donc pas content que le compilateur se mette à optimiser les opérations arithmétiques, et il n'est pas le seul. Les gens se sentent floués parce qu'ils pensaient que le C était proche du CPU, ce qui n'était pas le cas (enfin personne n'a promis ça).
Bon, je vais passer sur des subtilités dont j'ai parlé dans un autre topic sur les connards de chez GNU C et le libre de merde, topic qui est parti en vrille à cause d'un taré. Sauf si ça intéresse quelqu'un...
Bref C est un outil de merde.
-
Tu peux m'apprendre comment faire avec un langage de script, genre php ou Python ?
http://lmgtfy.com/?q=Python+raw+memory+access
http://stackoverflow.com/questions/15347985/raw-memory-access-java-python
-
Erreur : dans tout les cas, il y a entrée dans le contexte noyau, execution de code en kernelspace, retour en espace utilisateur : context switch;
Ah, je vois que j'ai oublié de relever cette autre absurdité :
Un appel système ne provoque certainement pas un changement de contexte. (Sauf bien sûr quand l'appel est bloquant et donc donne la main à un autre thread.)
C'est bien moins coûteux qu'un changement de contexte parce que l'adressage ne change pas : une même adresse correspond toujours à une même donnée. Donc le cache n'est pas invalidé.
On est à un niveau de confusion conceptuelle vraiment important, là.
-
char* n'est pas une chaine, c'est un tableau de caractère.
char* n'est pas non plus un tableau de caractère.
Déjà si on veut être précis char* est un type, pas une valeur. Un type pointeur.
Une valeur de type char* peut pointer sur un ou plusieurs objets de type char, ou pas.
Un objet de type char* peut contenir une valeur de type char*, ou pas.
-
Et quoi qu'il en soit, à moins de programmer au niveau même du noyau j'imagine, il y aura toujours un problème de performances vu qu'il s'agit d'interruptions système.
Qu'est-ce que vous appelez "interruptions système"?
-
Pouah, tu me déçois ..
Tu ne me donnes pas de code !
Tu me dit que, pour faire de l'accès mémoire en JS, il faut coder un accès mémoire en C !
Bientôt, tu vas me dire que tu fais un programme en JS, il te suffit de le faire en C et d'utiliser exec ..
Trop facile, trop facile..
EDIT: haaa, ben si, voici un super exemple (http://stackoverflow.com/questions/15347985/raw-memory-access-java-python).
L'idée est d'utiliser la mémoire du processus courant via procfs.
Je te propose donc d'utiliser directement /proc/kcore : tant qu'à utiliser un truc pratique et à ne surtout pas être de mauvaise fois, autant y aller jusqu'au bout !
Ben oui, il y a une instruction qui permet un appel système. Ce qui n'a absolument aucun rapport avec le concept d'interruption dont il était question. Une interruption c'est quand un périphérique veut interrompre le CPU, donc c'est asynchrone. L'instruction int n'interrompt rien, elle est synchrone.
Rhoo !
Et elle fait quoi, l'instruction ?
Je te laisse chercher ?
Indice: chercher la différence entre interruption synchrone et asynchrone.
Vas-y, donne moi le sens sémantique!
Qui porte du sens;
On peut donc dire que tout est sémantique : pour tout groupe d'élèment aléatoire, tu peux trouver une suite logique donnant un sens à l'ensemble.
En revanche, dire que cela n'a pas de sens ne met qu'en lumière ton incapacité (ou ta non-volonté ?) à le trouver :)
Il ne dit rien de tel. Il ne parle même pas d'interruption!
Mais si, mais si, c'est la deuxième colonne du tableau que j'ai copié : l'instruction à utiliser.
Dans quels tous les cas?
Dans tout les cas qui sont répertoriés dans mon manuel.
Mais bon, même en restant théorique : comment peut-on faire pour qu'un programme se coupe volontairement afin d'obtenir des choses du noyau ?
Hormis les syscall à base d'instruction spécifique et d'interruption, comment un processus peut-il "ne rien faire" ? Il a un temps processeur alloué.
La seule solution qui me vient à l'esprit consisterai à mettre à disposition les infos pour le syscall, et à perdre du temps en instruction inutile.
Débile comme solution, non ?
Ah bon, tu peux donner un exemple?
Tu l'as très bien fait tout seul !
En fonction de ce que tu as besoin, tu peux utiliser l'un des deux types de switch: soft ou hard, et donc ne sauvegarder qu'une partie des trucs à sauvegarder (c'est à dire, pas la totalité).
Et dans ce cas, on peut donc dire que le switch est plus "conservateur" (= économe, si tu préfères)
Par exemple l'ordre en mémoire des membres d'une structure est imposé, le compilateur ne peut pas réorganiser pour gagner de la place, sauf à démontrer que ça n'a aucun impact, par analyse globale (passablement difficile, il faudrait suivre tous les pointeurs, je pense qu'aucun compilateur au monde ne s'amuse à ça).
Le C ne permet pas de dire : là je veux la représentation précisèment comme ça, là je m'en fou. (Ada le permet, mais l'autre taré va encore dire que je m'éloigne du sujet.)
Par exemple si une fonction reçoit deux pointeurs a et b, alors a[p] et b[q] peuvent désigner la même chose, même si a!=b. (En Java ce n'est pas le cas puisqu'il n'y a pas de pointeurs d'éléments mais des "références" (ce qui est façon politiquement correcte et hypocrite(*) de dire : des pointeurs) sur des tableaux.)
Fortran considère que a et b ne peuvent pas désigner la même chose, ce qui est une clé de la performance.
(*) Java est à la base un langage de bouffons hypocrites neuneu
Par exemple si le compilateur optimise les opérations portant sur des int en utilisant les lois de l'arithmétique (comme a*x/a est remplacé par x), il peut casser du code qui utilise le comportement habituel des int qui est le comportement modulaire fournis par le CPU - donc le C n'est pas du tout un langage de bas niveau puisqu'il ne permet pas d'utiliser les opérations arithmétiques du CPU (bon, on peut jouer sur volatile mais ça casse la performance vu qu'un compilateur ne veut pas en général mettre un volatile en registre même si rien ne s'y oppose).
Linus n'est donc pas content que le compilateur se mette à optimiser les opérations arithmétiques, et il n'est pas le seul. Les gens se sentent floués parce qu'ils pensaient que le C était proche du CPU, ce qui n'était pas le cas (enfin personne n'a promis ça).
Bon, je vais passer sur des subtilités dont j'ai parlé dans un autre topic sur les connards de chez GNU C et le libre de merde, topic qui est parti en vrille à cause d'un taré. Sauf si ça intéresse quelqu'un...
Bref C est un outil de merde.
Hum hum;
En gros, tu critiques le concept de tableau : un tableau contient un autre tableau.
char* n'est pas non plus un tableau de caractère.
Déjà si on veut être précis char* est un type, pas une valeur. Un type pointeur.
Une valeur de type char* peut pointer sur un ou plusieurs objets de type char, ou pas.
Un objet de type char* peut contenir une valeur de type char*, ou pas.
Tu peux aussi dire : char* est un entier.
Qu'est-ce que vous appelez "interruptions système"?
Si tu parles d'une interruption, c'est un message beep;
-
Rhoo !
Et elle fait quoi, l'instruction ?
Elle fait un appel système. Elle contribue donc à la progression du thread en cours d'exécution.
Mais si, mais si, c'est la deuxième colonne du tableau que j'ai copié : l'instruction à utiliser.
Et? Qu'est-ce que ça fait de savoir ça?
Mais bon, même en restant théorique : comment peut-on faire pour qu'un programme se coupe volontairement afin d'obtenir des choses du noyau ?
Un appel système évidemment. Je n'ai aucune idée de ce que tu essayes de dire.
Tu l'as très bien fait tout seul !
En fonction de ce que tu as besoin, tu peux utiliser l'un des deux types de switch: soft ou hard, et donc ne sauvegarder qu'une partie des trucs à sauvegarder (c'est à dire, pas la totalité).
Et dans ce cas, on peut donc dire que le switch est plus "conservateur" (= économe, si tu préfères)
On dit surtout "mode switch".
-
En gros, tu critiques le concept de tableau
Non
: un tableau contient un autre tableau.
Pardon?
Tu peux aussi dire : char* est un entier.
Non
-
Résumons :
- une interruption est une interruption
- un appel système est un appel système
- changement de contexte est un changement de contexte
- changement de mode est un changement de mode
- un appel système sert à demander au noyau de commencer à faire quelque chose ou bien à récupérer une information (qui peut être vide) ou bien les deux
- une interruption sert à signaler au CPU un changement d'état qui pourrait mériter son attention
- un appel système provoque un changement de mode
- un changement de mode ne change pas le sens des adresses mémoires manipulées par le code
Quand on me dit "interruption" je comprends interruption, pas appel système.
Ayant éclairci ces points préliminaires, je pense qu'on peut reprendre la discussion à partir de là.
-
Oui, c'est n'importe quoi (parcque les IO font toujours appels à des syscall, quel que soit le langage utilisé, en userspace).
Il faudrait que tu précises ce que tu entends par IO.
(J'aurais certainement mieux fait de commencer par ça, mais bon...)
-
Comme c'est toi, je vais faire un peu de mauvaise foi pour la route : ça reste un goto, au sens sémantique du terme 8)
Qu'est-ce que "goto (au sens sémantique)"?
-
Oui, c'est n'importe quoi (parcque les IO font toujours appels à des syscall, quel que soit le langage utilisé, en userspace).
En revanche, cela a tout à voir avec les interruptions.
Tu peux définir ce que tu appelles "interruption" dans ce contexte?
Est-ce que tu cherches juste à dire que la fonction appelant cesse d'être exécutée pendant l'exécution de l'appel système?
-
Traduction des instructions en français littéral, autorisation des accents dans les variables, le rêve de tout développeur !
</trolldi>
Le C autorise tous les caractères accentués.
-
C'est nécessaire uniquement quand tu as besoin immédiatement d'une information (cette information peut être "void" ou "unit" : une information vide qui indique qu'une opération est terminée).
Pour les write de toute façon le fait que write retourne une valeur indique juste que de la place a été trouvée dans un tampon ou un cache pour écrire les données. Elles n'ont encore été envoyées nul part (sauf cas particulier).
EXPLICATION
Sauf cas particulier, après un appel à write vous n'avez pas la garantie que des données ont été physiquement écrites, juste qu'une zone mémoire a été copiée ailleurs et que l'écriture physique ou ce qui doit être fait va se produire sous peu.
Donc on pourrait tout à fait avoir une fonction write qui ne fait aucun appel système dans certains cas.
-
Autre exemple montrant que C n'est pas langage de bas niveau :
Vous avez une carte graphique qui affiche une image si vous copiez l'image à une adresse précise et qu'ensuite vous mettez une valeur magique dans une autre adresse.
Comment faire ça en C?
-
Rien qu'a lire ces 2 choses on voit clairement que tu as une connaissance plus que superficiel sur ses sujets...
Le C est très difficilement optimisable. Il n'a pas été conçu pour être optimisable. Et quand un compilateur décide de s'amuser à vraiment optimiser il casse énormèment de code, voir linux par exemple. La "sémantique" est un vrai merdier.
C difficilement optimisable, pas concu pour être optimisable?! soit tu confond avec optimisation au niveau du source (source-level optimisation) et encore C est aussi tres optimisable a ce niveau, soit t'as carrèment aucune idée de comment un compilateur fonctionne.
Oui parce que goto est l'opération élèmentaire qui défini les "structures" de la soi-disant programmation structurée.
Mais non c'est parce que 'goto' est ce qui se compile directement en un branchement de code en langage machine , quasi la seule instruction disponible pour faire ca. Tu raisonnes de haut en bas alors qu'il faut raisonner dans l'autre sens. On a concu les langages de programmation de bas en haut: au fil des années on a abstrait de plus de plus pour faciliter la productivité, la qualité , la concision, ...
Ne réduit pas ton raisonnement sur ce sujet a ce que tu connais: Linux et x86. C'est plus vaste que cela. Le C n'a pas été concu pour Linux (c'est l'inverse) et pour être compiler en x86 ... Ne pas confondre le langage (la syntaxe, 'if','while','for',etc) et les librairies (open(),printf(),...). Par abus de langage on confond souvent les 2.
Je sais pas même pourquoi je me fatigue a répondre, enfin ça servira a d'autres, j’espère. De toute façon le sujet est, encore une fois, déjà torpillé.
-
Rien qu'a lire ces 2 choses on voit clairement que tu as une connaissance plus que superficiel sur ses sujets...
kgersen, le poly-incompétent, a un avis. Sur tout. Il a presque toujours tout faux, mais c'est distrayant.
Mais non c'est parce que 'goto' est ce qui se compile directement en un branchement de code en langage machine , quasi la seule instruction disponible pour faire ca.
N'importe quoi!
Tu raisonnes de haut en bas alors qu'il faut raisonner dans l'autre sens. On a concu les langages de programmation de bas en haut: au fil des années on a abstrait de plus de plus pour faciliter la productivité, la qualité , la concision, ...
N'importe quoi!
Ne réduit pas ton raisonnement sur ce sujet a ce que tu connais: Linux et x86.
Tu confonds moi et les autres. Normal. C'est le bordel dans tête!
C'est plus vaste que cela. Le C n'a pas été concu pour Linux (c'est l'inverse)
N'importe quoi!
et pour être compiler en x86 ... Ne pas confondre le langage (la syntaxe, 'if','while','for',etc) et les librairies (open(),printf(),...). Par abus de langage on confond souvent les 2.
La bibliothèque standard fait parti du langage!
Il n'y a pas un truc qui ait un sens dans ton message.
Si tu savais à qui tu t'adresses... lol
-
En Java il n'y a pas d'instruction goto, à ma connaissance. :)
Il y a juste return (utilisable n'importe où), continue, break (survitaminé).
Bref, les puristes de la programmation structurée repasseront.
-
Bon je vous ressers des cahuètes mais faudrait consommer messieurs.
-
encore heureux ;) C# et les autres langages de plus haut niveau que C permettent dans la plus part des cas d'éviter l'emploi de goto.
Le C est un peu a part. On fait des trucs très bas niveau avec et souvent utiliser un goto peut-être très pratique et concis (pour sortir d'une imbrication de "if" notamment ).
Il ne faut pas généraliser un langage ou des techniques de programmation a toutes sortes de cas et de types de projets.
Quand on écrit un driver bas niveau ou un soft embarqué pour du temps réel ou un gros logiciel de gestion on n'a pas du tout les mêmes contraintes et on n'utilise pas les mêmes techniques.
Si, on utilise les mêmes techniques pour parvenir au même résultat : un programme qui marche, le plus efficace, lisible, vérifiable possible...
linux utilise goto absolument partout, et une grande partie de l'arborescence du source (en nombre de répertoires) n'est pas du tout de bas niveau.
Une bonne partie du code de linux ressemble à n'importe quel code C, sauf que les bibliothèques utilisées sont limitées. linux est vraiment conçu à un haut niveau. Même les drivers sont souvent multi-plateformes.
-
c'est une question de rigueur.
comme certains pro-java, pro-C# disant que le PHP c'est crade.
PHP est sans discussion possible une monstruosité, une abjection absolue.
Les mecs qui l'ont pondu doivent avoir l'ESB, un truc comme ça.
-
Il entend bas niveau dans le sens abstraction :
- gestion manuelle de la mémoire du tas vs les garbage collector du C# ou du Java,
Tu peux utiliser un GC en C. Beaucoup de gens le font.
Tu peux faire des désallocations explicites en Java. Beaucoup de gens le font, surtout au début parce que le GC était monstrueusement inefficace.
Les autres ressources que la mémoire doivent bien être gérée manuellement!
-
Bon je vous ressers des cahuètes mais faudrait consommer messieurs.
;D
ben soit on insiste juste qu'a ce qu'il pète les plombs comme d'hab et le sujet va être fermer
soit on n'insiste pas et il va se lasser et trouver un autre sujet a polluer.
Le tout est donc de bien doser la provoc pour l'occuper ici le plus longtemps possible comme ca il ne viendra pas polluer les sujets intéressants.
C'est tout un art de manipuler le Corrector :D
-
kgersen laisse tomber... Nous sommes en train de nourrir un troll...
Ça beau être habituel avec corrector, ça me déprime quand même.
Je comprends. Si tu ne veux pas que je te mouche, ben va ailleurs.
-
;D
ben soit on insiste juste qu'a ce qu'il pète les plombs comme d'hab et le sujet va être fermer
soit on n'insiste pas et il va se lasser et trouver un autre sujet a polluer.
Le tout est donc de bien doser la provoc pour l'occuper ici le plus longtemps possible comme ca il ne viendra pas polluer les sujets intéressants.
C'est tout un art de manipuler le Corrector :D
Tu argumentes ou tu t'écrases.
-
On parle de 'bas niveau' pour désigner un langage qui est "proche" du cpu, c'est a dire proche de l'assembleur. Par 'proche' on entend la complexité qu'il faut pour le compiler et le traduire en assembleur et le faible niveau d'abstraction qu'il offre.
N'importe quoi. Tu es la seule personne au monde à utiliser cette définition.
A l'inverse on parle de 'haut niveau' pour les langages qui sont 'loin' du cpu, qui ont un haut niveau d'abstraction et sont souvent interprétés au lieu d'être compilés et dont la compilation, quand elle a lieu, est souvent complexe.
Donc C et C++ sont de haut niveau : la compilation de C est souvent complexe! (Pour C++ on peut enlever le souvent.)
D'ailleurs en pratique on compile souvent un langage de haut niveau vers un langage de bas niveau qu'on compile ensuite en assembleur pour générer du code exécutable.
Non. On ne compile presque jamais vers un langage qui est utilisé par des humains.
Cela permet de simplifier la portabilité et les optimisations: en générant du C on peut après le compiler et l'optimiser avec les outils propres a chaque OS et au passage, on profite des décennies de progrès faites sur la compilation du C.
Il faut une très très grande prudence pour écrire du code portable en C, il y a énormèment de pièges, énormèment de différences entre les compilateurs et les environnements.
Enfin même en Java ce n'est pas évident d'écrire du code portable...
Il fréquent d'ailleurs dans le code C généré par les compilateurs (et les "transpileurs")
Je n'ai jamais vu ce terme!
-
N'importe quoi. Tu es la seule personne au monde à utiliser cette définition.
Non on doit etre deux. Je ne compte pas les gens qui m'ont appris cela.
D'ailleurs en pratique on compile souvent un langage de haut niveau vers un langage de bas niveau qu'on compile ensuite en assembleur pour générer du code exécutable.
Non. On ne compile presque jamais vers un langage qui est utilisé par des humains.
C'est ce que fait GCC avec ses extensions Ada.
Il faut une très très grande prudence pour écrire du code portable en C, il y a énormèment de pièges, énormèment de différences entre les compilateurs et les environnements.
En pratique, les problèmes viennent des compilateurs, pas du langage.
Je n'ai jamais vu ce terme!
Demande à GCC.
-
En pratique, les problèmes viennent des compilateurs, pas du langage.
Trop. Drôle.
Il croit que les compilateur n'ont aucun rapport avec le langage.
Je crois qu'on a touché quelque chose.
-
De toute façon le sujet est, encore une fois, déjà torpillé.
Désolé :-[
#include <stdio.h>
int main(){
char toto[]= "azertyuiop";
printf("toto[5]: %c\n", toto[5]);
char *tata = toto + 4;
printf("tata[1] : %c\n", tata[1]);
printf("toto = %i, tata = %i\n", toto, tata);
printf("toto[5] = %i, tata[1] = %i\n", &toto[5], &tata[1]);
return 0;
}
4% [jack:/tmp]gcc -o main test.c
5% [alex:/tmp]./main
toto[5]: y
tata[1] : y
toto = -1391393456, tata = -1391393452
toto[5] = -1391393451, tata[1] = -1391393451
Est-ce que toto = tata ? Non.
Est-ce que toto[p] = tata[q] ? Oui.
On appelle cela des tableaux.
C'est un simple exemple. Un langage qui n'autorise pas cela, qui interdit donc, plus globalement, deux pointeurs de pointer sur la même chose, est un langage défaillant (java ?).
Tu peux aussi dire : char* est un entier.
Sisi, char* est un entier (plus ou moins gros en fonction de ton espace mémoire). Le reste n'est que sémantique propre au langage (taille de la zone pointée, ce que je devrais pouvoir faire avec etc).
lle fait un appel système. Elle contribue donc à la progression du thread en cours d'exécution.
Pour x86:
INT is an assembly language instruction for x86 processors that generates a software interrupt.
IO : Input/Output : entrée/sortie : lecture/écriture sur un périphérique; Fait par le noyau (sauf si ce dernier exporte ledit périphérique en userspace, ce qui est rare, si je ne m'abuse, mais faisable, si je ne m'abuse guère plus).
Qu'est-ce que "goto (au sens sémantique)"?
Go to bed corrector!
EXPLICATION
Sauf cas particulier, après un appel à write vous n'avez pas la garantie que des données ont été physiquement écrites, juste qu'une zone mémoire a été copiée ailleurs et que l'écriture physique ou ce qui doit être fait va se produire sous peu.
Donc on pourrait tout à fait avoir une fonction write qui ne fait aucun appel système dans certains cas.
Vraiment ?
Comment ton kernel va savoir qu'il doit copier cette zone mémoire pour l'envoyer sur le dev ?
Il faut une très très grande prudence pour écrire du code portable en C, il y a énormèment de pièges, énormèment de différences entre les compilateurs et les environnements.
La première règle: programmer en C :D
C'est déjà pas mal, t'as fait le gros du boulot avec ça.
Si tu savais à qui tu t'adresses... lol
Vas-y, raconte moi ?
-
Je m'explique: il y a longtemps, lorsque j'étais étudiant, je programmais sur Solaris avec le compilo de Sun des programmes avec des appels à la Xlib. Ca fonctionnait sans problème.
Un peu plus tard, j'ai re-compilé ces programmes sur Linux m68k (mon Amiga) : avec gcc, aucun problème.
J'arrive sous Linux x86 : je re-compile et ... ça core dump.
Le code était on ne peut plus "normal" sans manipulations complexes, juste avec des tableaux et des variables typées.
Le problème venait du mécanisme d'allocation de gcc 2.95 (Red Hat 5 en 2000) sur la pile: suivant les options d'optimisations, on faisait planter le code à différents endroits sans raison. J'ai longtemps cherché la cause : en fait, à un endroit, j'avais un indice qui débordait d'un tableau.
J'ai reproduit le phénomène avec un simple TP: mon code plantait systématiquement sur Linux x86 et gcc 2.95 et fonctionnait à merveille sous Linux m68k avec une version de gcc plus ancienne. Je l'avais aussi re-compilé sous SAS/C sur AmigaOS: aucun problème non plus (meme pas un warning).
-
-ffast-math
Sets the options -fno-math-errno, -funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and -fcx-limited-range.
This option causes the preprocessor macro __FAST_MATH__ to be defined.
This option is not turned on by any -O option besides -Ofast since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications.
-fno-math-errno
Do not set errno after calling math functions that are executed with a single instruction, e.g., sqrt. A program that relies on IEEE exceptions for math error handling may want to use this flag for speed while maintaining IEEE arithmetic compatibility.
This option is not turned on by any -O option since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications.
The default is -fmath-errno.
On Darwin systems, the math library never sets errno. There is therefore no reason for the compiler to consider the possibility that it might, and -fno-math-errno is the default.
-funsafe-math-optimizations
Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid and (b) may violate IEEE or ANSI standards. When used at link-time, it may include libraries or startup files that change the default FPU control word or other similar optimizations.
This option is not turned on by any -O option since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications. Enables -fno-signed-zeros, -fno-trapping-math, -fassociative-math and -freciprocal-math.
The default is -fno-unsafe-math-optimizations.
-fassociative-math
Allow re-association of operands in series of floating-point operations. This violates the ISO C and C++ language standard by possibly changing computation result. NOTE: re-ordering may change the sign of zero as well as ignore NaNs and inhibit or create underflow or overflow (and thus cannot be used on code that relies on rounding behavior like (x + 2**52) - 2**52. May also reorder floating-point comparisons and thus may not be used when ordered comparisons are required. This option requires that both -fno-signed-zeros and -fno-trapping-math be in effect. Moreover, it doesn't make much sense with -frounding-math. For Fortran the option is automatically enabled when both -fno-signed-zeros and -fno-trapping-math are in effect.
The default is -fno-associative-math.
-freciprocal-math
Allow the reciprocal of a value to be used instead of dividing by the value if this enables optimizations. For example x / y can be replaced with x * (1/y), which is useful if (1/y) is subject to common subexpression elimination. Note that this loses precision and increases the number of flops operating on the value.
The default is -fno-reciprocal-math.
-ffinite-math-only
Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs.
This option is not turned on by any -O option since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications.
The default is -fno-finite-math-only.
-fno-signed-zeros
Allow optimizations for floating-point arithmetic that ignore the signedness of zero. IEEE arithmetic specifies the behavior of distinct +0.0 and −0.0 values, which then prohibits simplification of expressions such as x+0.0 or 0.0*x (even with -ffinite-math-only). This option implies that the sign of a zero result isn't significant.
The default is -fsigned-zeros.
-fno-trapping-math
Compile code assuming that floating-point operations cannot generate user-visible traps. These traps include division by zero, overflow, underflow, inexact result and invalid operation. This option requires that -fno-signaling-nans be in effect. Setting this option may allow faster code if one relies on “non-stop” IEEE arithmetic, for example.
This option should never be turned on by any -O option since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions.
The default is -ftrapping-math.
Source : https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Bon, vous arrivez à voir que les optimisations sont plus ou moins possibles selon la sémantique plus ou moins précise du dialecte compilé?
-
On appelle cela des tableaux.
Super.
C'est un simple exemple. Un langage qui n'autorise pas cela, qui interdit donc, plus globalement, deux pointeurs de pointer sur la même chose, est un langage défaillant (java ?).
N'importe quoi.
Sisi, char* est un entier
Hein? Tu parles de quoi? Du langage C? D'un compilateur particulier?
C'est quoi être un entier? Est-ce qu'un flottant est un entier?
Tu as la moindre notion de ce dont il est question?
En C un pointeur n'est pas un entier. Point final.
(plus ou moins gros en fonction de ton espace mémoire). Le reste n'est que sémantique propre au langage (taille de la zone pointée, ce que je devrais pouvoir faire avec etc).
Hein? Tout est de la sémantique.
Pour x86:
IO : Input/Output : entrée/sortie : lecture/écriture sur un périphérique; Fait par le noyau (sauf si ce dernier exporte ledit périphérique en userspace, ce qui est rare, si je ne m'abuse, mais faisable, si je ne m'abuse guère plus).
Tu veux dire sur une mémoire de masse?
-
Vas-y, raconte moi ?
Disons que s'il y a un sujet où il n'est pas avisé d'essayer de me piéger, c'est la définition de certains langages dont le C.
Il y a très peu de chance que quelqu'un pris en hasard maîtrise mieux le sujet que moi.
(Après, je ne peux pas empêcher les forumeurs de passer pour des andouilles.)
-
Kernighan, c'est toi ?
Ou Ritchie ?
-
Mince, j'avais survolé ton code sans faire attention :
#include <stdio.h>
int main(){
char toto[]= "azertyuiop";
printf("toto[5]: %c\n", toto[5]);
char *tata = toto + 4;
printf("tata[1] : %c\n", tata[1]);
printf("toto = %i, tata = %i\n", toto, tata);
tata et toto ne sont pas des entiers, tu ne peux pas utiliser %i.
Tu es sûr de comprendre le C?
-
Kernighan, c'est toi ?
Ou Ritchie ?
Non.
Mais j'ai un tout petit peu contribué à la normalisation.
-
"blablablablablabla"
L'assembleur que j'ai sous les yeux me donne raison;
Je te présente mes condoléances.
-
Mince, j'avais survolé ton code sans faire attention :
tata et toto ne sont pas des entiers, tu ne peux pas utiliser %i.
Tu es sûr de comprendre le C?
Ben justement: il peut parfaitement utiliser %i.
Il ne devrait pas, ce n'est pas pareil :)
Ada l'interdirait mais C s'en tape. Les types c'est pour les peureux.
-
BadMax, tu peux m'instruire sur "pourquoi je ne devrais pas" ? Merci !
-
Non on doit etre deux. Je ne compte pas les gens qui m'ont appris cela.
C'est ce que fait GCC avec ses extensions Ada.
Demande à GCC.
Raconte-moi ce que fait "GCC avec ses extensions Ada"!
-
Ben justement: il peut parfaitement utiliser %i.
Il ne devrait pas, ce n'est pas pareil :)
Ada l'interdirait mais C s'en tape. Les types c'est pour les peureux.
Ben tu fais ce que tu veux mon grand.
Mais le comportement de printf n'est pas défini, et le compilateur peut très bien décider d'imprimer "BadMax ne sait pas programmer" à la place de la valeur voulue.
Déjà, rien ne dit que la taille d'un pointeur soit la bonne.
Ensuite, la représentation d'un pointeur pourrait être incompatible, etc.
Bref, tu racontes absolument n'importe quoi.
-
BadMax, tu peux m'instruire sur "pourquoi je ne devrais pas" ? Merci !
Parce qu'un pointeur n'est PAS un entier!
Comme je l'ai dit!
-
On appelle cela des tableaux.
Cela s'appelle surtout de l'arithmétique de pointeurs et de l'aliasing.
C'est un simple exemple. Un langage qui n'autorise pas cela, qui interdit donc, plus globalement, deux pointeurs de pointer sur la même chose, est un langage défaillant (java ?).
Java autorise deux "références" (= pointeurs) sur la même chose, bien sûr!
Tu es au courant que Java n'a rien de tel que l'arithmétique de pointeurs?
Sisi, char* est un entier (plus ou moins gros en fonction de ton espace mémoire).
Toute suite de bits peut être (conceptuellement) vue comme entier. Les flottants peuvent être vus comme des entiers. Simplement cette vue n'a aucun intérêt. Aucun opération arithmétique ne correspondra.
Tu ne peux pas écrire un char* dans une zone mémoire et relire un type entier dans la même zone et exiger un résultat bien défini. C'est un comportement indéfini. En C les types comptent.
-
"blablablablablabla"
L'assembleur que j'ai sous les yeux me donne raison;
Je te présente mes condoléances.
Hein? Quoi? Comment?
-
corrector, tu confonds le langage C avec les méthodes de programmation.
Le C est justement un langage considéré comme bas-niveau car il permet de faire n'importe quoi, surtout des trucs qui, algorithmiquement parlant, sont particulièrement cradingue. Mais parfois les contraintes machines sont ce qu'elles sont, et justement C permet d'y répondre mais, certes, salement. Le but est parfois que ça marche, vite et bien.
Si tu veux que le programmeur ne code pas comme un porc, tu l'obliges à utiliser un langage contraignant comme Ada qui est "haut-niveau" car ne permettant pas de faire n'importe quoi en manipulant des pointeurs en entiers ou l'inverse. Cela dit, Ada n'est pas utilisable directement sans API système basée sur du C car la plupart des OS actuels sont tous développés sur des bibliothèques en C.
Si tout était programmé en Ada, on n'aurait peut-etre meme pas de faille de sécurité basée sur des largesses d'appréciation du développeur.
@Jack: un pointeur est un pointeur, pas en entier. Mais C s'en tape, la preuve:
char *tata = toto + 4;Ca marche car le compilateur s'en moque bien et sait comment s'y retrouver.
-
"INT is an assembly language instruction for x86 processors that generates a software interrupt"
Oui .... c'est l'idée. Bien évidemment!
Je n'ai pas la moindre idée de ce que tu essaies de me démontrer.
-
corrector, tu confonds le langage C avec les méthodes de programmation.
Hein?
Le C est justement un langage considéré comme bas-niveau
J'ai montré précédemment que c'est un très mauvais langage de bas niveau.
car il permet de faire n'importe quoi, surtout des trucs qui, algorithmiquement parlant, sont particulièrement cradingue.
Comme quoi?
Mais parfois les contraintes machines sont ce qu'elles sont, et justement C permet d'y répondre mais, certes, salement. Le but est parfois que ça marche, vite et bien.
Le but de la plupart des "programmeurs" est de torcher un code qui a vaguement l'air de marcher.
Si tu veux que le programmeur ne code pas comme un porc, tu l'obliges à utiliser un langage contraignant comme Ada qui est "haut-niveau" car ne permettant pas de faire n'importe quoi en manipulant des pointeurs en entiers ou l'inverse.
Tu peux faire des conversions forcées et des opérations dangereuses en Ada comme en C.
Si tout était programmé en Ada, on n'aurait peut-etre meme pas de faille de sécurité basée sur des largesses d'appréciation du développeur.
Un langage qui élimine les failles de sécurité?
Qu'est-ce qu'on se marre!
@Jack: un pointeur est un pointeur, pas en entier. Mais C s'en tape, la preuve:
char *tata = toto + 4;Ca marche car le compilateur s'en moque bien et sait comment s'y retrouver.
Non, C ne s'en tape pas. Au contraire tout dépend du type.
Tu ne comprends juste rien au C.
-
4 c'est un entier non ?
donc toto + 4 est une opération entre entiers, juste ?
et pourtant on stocke le résultat dans un type pointeur de char.
Formidable ! Le compilateur a retrouvé ses petits avec le type char et a su de combien gérer l'incrèment du pointeur.
Demo
void main(void)
{
char *toto="hello";
int *popo="hello";
char *tata=toto+4;
int *pipi=popo+1;
printf("%s %s", tata, (char *)pipi);
}
Les deux affichent "o".
Bref, c'est là où C c'est du n'importe quoi. Mais c'est fait exprès.
-
4 c'est un entier non ?
donc toto + 4 est une opération entre entiers, juste ?
Hein? Quoi?
et pourtant on stocke le résultat dans un type pointeur de char.
C'est un pointeur! Il n'y a pas de "pourtant".
Formidable ! Le compilateur a retrouvé ses petits avec le type char et a su de combien gérer l'incrèment du pointeur.
Il n'a pas "su gérer", il a implèmenté une opération du langage C.
Bref, c'est là où C c'est du n'importe quoi. Mais c'est fait exprès.
Ce que tu as écrit n'est pas du C, c'est du n'importe quoi.
MAINTENANT CA SUFFIT, HEIN.
ON NE VA PASSER LA JOURNÉE.
TU NE CONNAIS RIEN AU C. TU RACONTES N'IMPORTE QUOI. OU BIEN TU APPRENDS LE C, OU BIEN TU CULTIVES TON IGNORANCE.
-
Sisi, c'est du C !
-
Qu'est-ce que tu essayes de prouver?
Qu'avec l'arithmétique des POINTEURS (qui ne sont pas des entiers) on peut faire des trucs tordus ou écrire du code de bas niveau?
Bien sûr qu'on peut. L'allocateur mémoire est écrit en C. Le GC de Java est écrit en C. Etc.
-
Pour la postérité: je viens de supprimer un message erroné de ma part, ayant lu de travers un des exemples postés. Parfois mieux vaut s'abstenir. :P
-
Pas grave ça ne s'était pas vu :)
-
Tu peux me montrer comment tu fais une simple recherche d'une valeur négative dans un tableau, avec retour de l'index de la première valeur?
Allez pour te faire plaisir :
int[] monTableau = { 1, 10, -5, 3, 4, -8, 2};
int iIndexOfFirstNegativeValue = Array.FindIndex(monTableau, i => i < 0); //retourne 2
Autre chose ?
Je peux te le faire d'autres façons si tu veux.
-
Allez pour te faire plaisir :
int[] monTableau = { 1, 10, -5, 3, 4, -8, 2};
int iIndexOfFirstNegativeValue = Array.FindIndex(monTableau, i => i < 0); //retourne 2
effectivement ca marche: http://goo.gl/xo86vb (cliquez sur 'compile' puis 'execute').
la meme en C 'crado': http://goo.gl/bvXasd :o
-
Allez pour te faire plaisir :
int[] monTableau = { 1, 10, -5, 3, 4, -8, 2};
int iIndexOfFirstNegativeValue = Array.FindIndex(monTableau, i => i < 0); //retourne 2
Autre chose ?
Comment tu écris FindIndex?
-
Comment tu écris FindIndex?
Comme ça se prononce... F.i.n.d.I.n.d.e.x
Si la vraie question est celle de son implèmentation, à vrai dire je ne sais pas vu que c'est une méthode de .NET !
-
Comment TOI tu ferais ça?
-
Avec un clavier.
-
C'est avec le cerveau qu'il faut réfléchir tonton!
Normal que tu n'arrives à rien si tu penses avec le clavier!
-
Avec un clavier.
Exactement ! Je ne réinvente pas la roue quand d'autres l'ont fait avant moi et souvent d'une meilleure façon que je ne l'aurais fait moi-même !
Je ne vois pas en quoi mon implèmentation changerait quoi que ce soit si ce n'est de risquer d'être moins performant ! Et sinon au passage une bête boucle for sur le tableau avec un If pour tester et un break pour stopper les itérations une fois un élèment trouvé marcherait très bien (ce qui ne doit pas être tres éloigné de l'implementation réelle de la chose et qui doit être de mémoire ce que kgersen a proposé en C)
-
Avec un break, on retombe sur le problème du goto!
-
Quel problème ?
-
(http://image.noelshack.com/fichiers/2013/30/1374518815-35734259.jpg)
C'est sale car tu sors de la boucle avant la condition de fin.
En gros, tu devrais faire un while et intégrer ton test dans la condition.
-
Effectivement d'ou le 'crado' (j'ai mis le 'break' pour faire de la provoc:))
for (idx = 0 ; idx < size; idx++ )
{
if (monTableau[idx] < 0)
{
trouve = true;
break;
}
}
alors que, dogmatiquement on ferais:
idx = 0;
while((idx <size) && (monTableau[idx] >= 0)) idx++;
// si idx == size on a pas trouvé de negatif
ce qui est plus propre (ca "se lit" presqu'en francais et il n'y a pas le booléen) et plus optimisable (certains optimiseur n'essaient même pas quand ils rencontrent un break ou un goto).
-
Quel problème ?
Ce n'est pas SESE (Single Entry Single Exit).
Ce n'est pas "structuré".
-
Et sortir d'un for comme un malpropre casse le prédicteur de boucle : https://fr.wikipedia.org/wiki/Pr%C3%A9diction_de_branchement#Pr.C3.A9dicteur_de_boucle
-
Effectivement d'ou le 'crado' (j'ai mis le 'break' pour faire de la provoc:))
for (idx = 0 ; idx < size; idx++ )
{
if (monTableau[idx] < 0)
{
trouve = true;
break;
}
}
alors que, dogmatiquement on ferais:
idx = 0;
while((idx <size) && (monTableau[idx] >= 0)) idx++;
// si idx == size on a pas trouvé de negatif
ce qui est plus propre (ca "se lit" presqu'en francais et il n'y a pas le booléen) et plus optimisable (certains optimiseur n'essaient même pas quand ils rencontrent un break ou un goto).
Quelles optimisations deviennent impossibles avec un break ou un goto?
-
Ah oui le while ne m'est pas venu a l'esprit tout de suite... C'est bien pour ça que j'utilise ce qui existe déjà plutot que de faire des trucs moches ;)
-
A l'inverse on parle de 'haut niveau' pour les langages qui sont 'loin' du cpu, qui ont un haut niveau d'abstraction et sont souvent interprétés au lieu d'être compilés et dont la compilation, quand elle a lieu, est souvent complexe.
Tu as des exemples de ce qui est complexe à compiler?
-
Hey, t'as raison, les deux mots clefs ne sont pas rigoureusement identiques !
longjmp n'est pas un mot clef!
Comme c'est toi, je vais faire un peu de mauvaise foi pour la route : ça reste un goto, au sens sémantique du terme 8)
Ben déjà commence par expliquer comment on utilise setjmp/longjmp.
-
L'idée est d'utiliser la mémoire du processus courant via procfs.
Une solution linux-only n'est pas une solution.
Je te propose donc d'utiliser directement /proc/kcore : tant qu'à utiliser un truc pratique et à ne surtout pas être de mauvaise fois, autant y aller jusqu'au bout !
N'importe quoi!
Mais bon, même en restant théorique : comment peut-on faire pour qu'un programme se coupe volontairement afin d'obtenir des choses du noyau ?
Couper quoi?
Tu veux dire attendre un évènement? Lequel?
-
"blablablablablabla"
L'assembleur que j'ai sous les yeux me donne raison;
Je te présente mes condoléances.
Dans ta splendide incompétence, je pense que tu essaies de dire que ça marche dans un cas particulier donc que ton code est correct donc que tu as raison.
No comment...
-
4 c'est un entier non ?
donc toto + 4 est une opération entre entiers, juste ?
4 c'est un entier non ?
Donc (en PHP je crois, ou dans un de ses frères) 4*"hello" est une opération entre entiers, juste ?
-
Et sortir d'un for comme un malpropre casse le prédicteur de boucle : https://fr.wikipedia.org/wiki/Pr%C3%A9diction_de_branchement#Pr.C3.A9dicteur_de_boucle
Je ne comprends pas.
Qu'est-ce que tu suggères?
-
(http://image.noelshack.com/fichiers/2013/30/1374518815-35734259.jpg)
C'est sale car tu sors de la boucle avant la condition de fin.
En gros, tu devrais faire un while et intégrer ton test dans la condition.
Tu pourrais mais je ne vois pas l'intérêt. C'est une vraie boucle for standard (avec une variable de contrôle initialisée, testée et modifiée uniquement dans le "for( ; ; )") avec parfois une sortie anticipée.
Bien sûr ce n'est plus "SESE" et donc il ne faut pas mettre du code de nettoyage en fin de bloc, mais si on peut respecter cette condition, quel est le souci?
-
Je m'explique: il y a longtemps, lorsque j'étais étudiant, je programmais sur Solaris avec le compilo de Sun des programmes avec des appels à la Xlib. Ca fonctionnait sans problème.
Un peu plus tard, j'ai re-compilé ces programmes sur Linux m68k (mon Amiga) : avec gcc, aucun problème.
J'arrive sous Linux x86 : je re-compile et ... ça core dump.
Le code était on ne peut plus "normal" sans manipulations complexes, juste avec des tableaux et des variables typées.
Le problème venait du mécanisme d'allocation de gcc 2.95 (Red Hat 5 en 2000) sur la pile: suivant les options d'optimisations, on faisait planter le code à différents endroits sans raison. J'ai longtemps cherché la cause : en fait, à un endroit, j'avais un indice qui débordait d'un tableau.
J'ai reproduit le phénomène avec un simple TP: mon code plantait systématiquement sur Linux x86 et gcc 2.95 et fonctionnait à merveille sous Linux m68k avec une version de gcc plus ancienne. Je l'avais aussi re-compilé sous SAS/C sur AmigaOS: aucun problème non plus (meme pas un warning).
Et ça n'a rien à voir avec le fait que le langage dit qu'un accès hors d'un tableau a un comportement indéfini et n'oblige pas le compilateur à au moins proposer un mode de test avec vérification de ces accès?
-
C'est ce que fait GCC avec ses extensions Ada.
Tu peux expliciter ce que fait GCC?
-
@Jack: un pointeur est un pointeur, pas en entier. Mais C s'en tape, la preuve:
char *tata = toto + 4;Ca marche car le compilateur s'en moque bien et sait comment s'y retrouver.
Le compilateur ne fait pas d'ironie et applique la sémantique du langage.
La langage C définit l'addition sur un pointeur en fonction du tableau dans lequel pointe ce pointeur.
Un pointeur n'est pas considéré comme un entier en C.
-
Ben justement: il peut parfaitement utiliser %i.
Tu veux dire, s'il ne veut aucune garantie que son programme fonctionne, il peut faire n'importe quoi?
Ada l'interdirait mais C s'en tape. Les types c'est pour les peureux.
Ton savoir concernant le C vient de quel prof maboul?
-
Rien qu'a lire ces 2 choses on voit clairement que tu as une connaissance plus que superficiel sur ses sujets...
C difficilement optimisable, pas concu pour être optimisable?! soit tu confond avec optimisation au niveau du source (source-level optimisation) et encore C est aussi tres optimisable a ce niveau, soit t'as carrèment aucune idée de comment un compilateur fonctionne.
Explique-nous "comment un compilateur fonctionne."
A défaut d'être intelligent ça sera amusant.
-
Demo
void main(void)
{
char *toto="hello";
int *popo="hello";
char *tata=toto+4;
int *pipi=popo+1;
printf("%s %s", tata, (char *)pipi);
}
Les deux affichent "o".
Tu as essayé?
-
if (fd!=0)
close(fd);
Attention 0 est une valeur valide et tout à fait normale pour un fdnum.
-
Si goto est le mal, alors qu'est-ce qu'on doit dire de setjmp() et longjmp() ?
On doit dire :
- qu'il n'y a pas de raison solide et rationnelle d'éviter de façon générale le goto à chaque fois qu'il semble nécessaire pour éviter d'autres choses qu'on aime éviter (redondance du code, ajout de variable, complexification des flux de données...)
- qu'il faut de façon générale absolument éviter longjmp() pour des raisons évidentes et non idéologiques, même s'il est concevable que certains cas fassent exception
-
Pour la postérité: je viens de supprimer un message erroné de ma part, ayant lu de travers un des exemples postés. Parfois mieux vaut s'abstenir. :P
Si tout le monde faisait comme toi, il y aurait beaucoup moins de messages dans ce topic.
-
idx = 0;
while((idx <size) && (monTableau[idx] >= 0)) idx++;
// si idx == size on a pas trouvé de negatif
Moche. Relativement très moche.
Il faut donc re-tester la condition de sortie après, et donc la condition de sortie est écrite plusieurs fois. Avec le risque de bug en cas de modification du code...
Mais à part ça, c'est le goto qui rend le code moins maintenable, il suffit de le répéter mille fois pour que ça devienne vrai.
-
IO : Input/Output : entrée/sortie : lecture/écriture sur un périphérique; Fait par le noyau (sauf si ce dernier exporte ledit périphérique en userspace, ce qui est rare, si je ne m'abuse, mais faisable, si je ne m'abuse guère plus).
Go to bed corrector!
Vraiment ?
Comment ton kernel va savoir qu'il doit copier cette zone mémoire pour l'envoyer sur le dev ?
Ben tu lui communique l'information d'une façon quelconque. Genre tu l'écris à une adresse où il va chercher l'information. Tu sais, comme une convention d'appel. Mais sans appel. Juste tu postes une requête dans une sorte de socket.
Tu manques vraiment d'imagination.
-
#include <stdio.h>
int main(){
char toto[]= "azertyuiop";
printf("toto[5]: %c\n", toto[5]);
char *tata = toto + 4;
printf("tata[1] : %c\n", tata[1]);
printf("toto = %i, tata = %i\n", toto, tata);
printf("toto[5] = %i, tata[1] = %i\n", &toto[5], &tata[1]);
return 0;
}
Sur les architectures où un pointeur fait la taille de deux int, tu penses que ça va donner quoi?
-
Une solution linux-only n'est pas une solution.
C'est intrinséquement une solution (mais pas pour tout le monde).
N'importe quoi!
Dixit le type qui me dit, pour manipuler la mémoire d'un process, d'utiliser /proc/self/mem ?
Dans ta splendide incompétence, je pense que tu essaies de dire que ça marche dans un cas particulier donc que ton code est correct donc que tu as raison.
Non, ce que j'essaie de te dire, c'est que ta négation ne devrait pas être aussi catégorique qu'elle ne l'est.
Et ça n'a rien à voir avec le fait que le langage dit qu'un accès hors d'un tableau a un comportement indéfini et n'oblige pas le compilateur à au moins proposer un mode de test avec vérification de ces accès?
Ben tu vois, je pense que tu as raison: dans ce cas précis, le fait que cela fonctionne n'est qu'un hasard;
Il y a débordement, mais ce dernier est bénin dans le premier cas, fatal dans le deuxième;
Attention 0 est une valeur valide et tout à fait normale pour un fdnum.
Mea culpa
On doit dire :
- qu'il n'y a pas de raison solide et rationnelle d'éviter de façon générale le goto à chaque fois qu'il semble nécessaire pour éviter d'autres choses qu'on aime éviter (redondance du code, ajout de variable, complexification des flux de données...)
Je partage ce point de vue
Ben tu lui communique l'information d'une façon quelconque. Genre tu l'écris à une adresse où il va chercher l'information. Tu sais, comme une convention d'appel. Mais sans appel. Juste tu postes une requête dans une sorte de socket.
Tu manques vraiment d'imagination.
Mon processus a 1 sec de temps processeur.
À la 0.5sec, il a besoin de faire un IO.
Il écrit les données à un quelconque endroit en mémoire.
Il a besoin du résultat pour la suite de son exécution: que fait-il pendant les 0.5sec restantes ?
J'me demande s'il existe un moyen pour un processus de dire "bof, noyau, tu m'as donné du temps CPU, mais en fait j'nen veux pas"
PS: 2 pages, tu abuses.
Au fait, tu ne m'as pas dit comment je devrais coder mon machin, tu peux y passer 2min à me prodiguer ton savoir ? Merci !
-
Dixit le type qui me dit, pour manipuler la mémoire d'un process, d'utiliser /proc/self/mem ?
Ah bon, je dis ça?
Mon processus a 1 sec de temps processeur.
À la 0.5sec, il a besoin de faire un IO.
Il écrit les données à un quelconque endroit en mémoire.
Il a besoin du résultat pour la suite de son exécution: que fait-il pendant les 0.5sec restantes ?
Ben il fait un appel système, évidemment. Je ne vois pas le problème.
J'me demande s'il existe un moyen pour un processus de dire "bof, noyau, tu m'as donné du temps CPU, mais en fait j'nen veux pas"
Par exemple pthread_yield
PS: 2 pages, tu abuses.
Un thème, un message.
C'est hygiénique. Et pratique pour le modérateur s'il y a des déplacements à faire.
Au fait, tu ne m'as pas dit comment je devrais coder mon machin, tu peux y passer 2min à me prodiguer ton savoir ? Merci !
Comme tu veux, c'est une question de gout.
-
Pour ceux qui ne connaissent pas Dart (mon langage de travail en ce moment, après des années de C, C++ et C# c'est très "reposant" et la syntaxe est proche).
void main() {
List<int> tableau = [1, 10, -5, 3, 4, -8, 2];
int idx = tableau.takeWhile((i)=>i>0).length;
if (idx==tableau.length) idx = -1;
print("index = $idx");
}
https://dartpad.dartlang.org/4a65a1f1b1fcdf7b39e9
ou facon comme l'exemple en C#:
void main() {
List<int> tableau = [1, 10, -5, 3, 4, -8, 2];
int idx;
try
{
idx = tableau.indexOf(tableau.firstWhere((i)=>i<0));
}
catch (e)
{
idx = -1;
}
print("index = $idx");
}https://dartpad.dartlang.org/b5dcc2dd4351c0015402