Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C (je suis débutant en c) je ne vois d'instruction pour boucler

(je suis débutant en c) je ne vois d'instruction pour boucler

156 réponses
Avatar
bpascal123
Bjr,sr,
Voici une fonction tr=E8s simple qui r=E9agit comme s'il y avait une
boucle alors qu'en apparence il n'y en a pas :

#include <stdio.h>

void f2(int b);
void f1(int a);

int main(void)
{
f1(30);

return 0;
}

void f1(int a)
{
if( a )
f2( a - 1 );
printf("%d ", a);
}

void f2(int b)
{
printf(" . ");
if(b)
f1( b - 1 );
}

http://www.java2s.com/Code/C/Function/Functioncalleachother.htm

Merci,
Pascal
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
2 3 4 5 6
Avatar
-ed-
On 28 nov, 12:51, ""
wrote:
Les personnes qui ont fait java veulent que tout le monde commence à
apprendre avec java. Je ne sais pas pourquoi. Java est un langage



Euh, moi, j'ai commencé par le BASIC (meutrier) et le Pascal (zen)...

orienté objet. En plus d'apprendre la syntaxe, il faut apprendre les
objets qui composent le langage.



On peut très bien apprendre les bases de la programmation en Java sans
utiliser le paradigme objet...

Ceci-dit, de nos jours, je recommanderais plutôt un langage interprét é
simple (et puissant) comme Python ou Ruby pour apprendre la
programmation ... Une fois le terrain dégagé, c'est à dire ces
principes de base acquis

- valeur
- constante
- variable
- opérateurs
- sorties simples
- structures de code (décisions, boucles)
- tableaux
- structures de données
- procédures et fonctions
- récursion
- ... j'ai du en oublier ...

on peut attaquer un langage plus complexe et subtil comme le C.

Mais vouloir commencer de rien par le C, c'est absurde. Trop de choses
complexes et subtiles à avaler d'un coup. On se tue à le répéter .. .

J'interviens sur ce forum de manière irrégulière, pour l'instant je
concentre  mes efforts vers les algorithmes.



OK, pour ça, un langage de haut niveau suffit, comme Python, par
exemple.

Je me concentre vers le
langage assembleur. Je ne veux pas approfondir. Avant d'aller plus



Quel intérêt de se lancer dans l'assembleur ? C'est encore plus subtil
et complexe que le C et en plus, c'est pas portable...

loin dans la programmation, je veux comprendre ce qui se passe dans la
machine tant que c'est à "porter de mains".



Tu ne conduis une voiture que si tu es un expert en sciences
mécanique ? Il faut savoir faire confiance dans les comportements
décrits. Ceci dit, une connaissance limitée de l'assembleur (voir la
liste "principes de base" ci-dessus) permet d'interpréter le mode pas
à pas d'un débogeur en mode machine, mais est-ce vraiment nécessaire
pour toi ?

Ce qui se passe dans la machine, c'est plutôt simple. Il faut avoir
quelques notions basiques d'architecture logique (CPU, registres,
mémoire d'exécution, mémoire de données). Les instructions machines
sont des séquences d'octets rangées à la suite dans la mémoire
d'exécution, qui comportent une partie 'code opératoire' (opcode) et
éventuellement une partie 'données'. Ces données sont soit une valeur
immédiate (constante) soit un numéro de 'registre' (mémoire locale du
CPU) soit l'adresse d'une variable (pointeur). C'est l'opcode qui
permet de savoir exactement à quoi on a affaire...

Les codes opératoires permettent d'exécuter des opérations simples
comme :

- lire une donnée
- écrire une donnée
- faire un calcul simple (+ - * /)
- faire une comparaison (= > <)
- faire un saut direct ou conditionnel

avec ça, on fait quasiment tout ce qui est nécessaire pour exécuter
n'importe quelle application.

Le code est lu octet par octet, puis interprété par le CPU (le
processeur, quoi...).

Ce qui correspond à une instruction est exécuté avec les données
passées en paramètres

Il faut en plus connaitre le mécanisme des appels de fonctions (pile,
passage de paramètres, empilage de l'adresse de retour, instruction de
fin de fonction, mais c'est relativement simple).

Ça, c'est la théorie, et elle permet de suivre un débogueur pas à p as
en mode machine relativement facilement. Maintenant, si tu veux entrer
dans les détails propres à chaque architecture physique et à chaque
mode de fonctionnement, là, ça devient complexe et subtil. Tu y tiens
vraiment ?

En fait, je ne viens pas sur ce forum pour savoir ce qui serait bien
pour les intestins ou le foi.



Pas compris. La foi ? Le foie ? (oui, le français est aussi une langue
complexe et subtile !)
Et quel rapport avec la programmation ?

J'ai quand même du mal à imaginer que le
langage C est inutile.



Personne n'a dit qu'il était inutile. Par contre, ce n'est pas du tout
un langage d'initiation à la programmation. Encore une fois, trop de
détails spécifiques à ce langage parasitent le message (relire la
liste "principes de base" ci-dessus).

Je peux admettre que c'est difficilement



"c'est" ? Que signifie ici, pour toi, le " c' " ?

exploitable avec des langages haut niveau qui fournissent déjà les
outils pour programmer efficacement.



Langue de bois détectée (rien compris en fait ...)
Avatar
espie
In article <4b0e4cc7$0$9187$,
candide wrote:
Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien
compris à la récursivité donc te crois pas obligé de passer par ce
pensum (qui est aussi une belle tarte à la crème).



Si c'est pour donner des conseils aussi mauvais, tu peux aussi fermer
ta gueule.

Le cote "chercher la petite bete dans la norme", ca tu sais faire.

Le cote "expliquer la programmation aux gens", par contre c'est moins
au point...

Meme s'il y a des gens qui se pretendent programmeurs qui sont nuls, ca
n'est pas une raison pour inciter les nouveaux a faire pareil...
Avatar
-ed-
On 28 nov, 12:54, ""
wrote:
Par ailleurs, j'ai du mal à comprendre le "cheminement" de
l'algorithme  car au fil de la discussion, je comprends à peu près que
c'est récursif mais je vois en apparence une boucle.



Voici une bonne définition de ce qu'est la récursion :

Récursion : voir récursion.

Si tu as compris ça, tu as tout compris, notamment l'aspect répétitif
de la chose...

La question suivante devrait être "mais alors comment on sort de la
boucle ?"
Avatar
espie
In article ,
-ed- wrote:
On 28 nov, 12:54, ""
wrote:
Par ailleurs, j'ai du mal à comprendre le "cheminement" de
l'algorithme  car au fil de la discussion, je comprends à peu près que
c'est récursif mais je vois en apparence une boucle.





Voici une bonne définition de ce qu'est la récursion :



Récursion : voir récursion.



Si tu as compris ça, tu as tout compris, notamment l'aspect répétitif
de la chose...



La question suivante devrait être "mais alors comment on sort de la
boucle ?"



Personnellement, je pense toujours qu'on est deforme par des annees
d'apprentissages de la programmation structuree: il n'y a rien de
naturel dans une construction telle que
i = i + 1;
mais bon, des annees d'explications de comment ca marche, des petites
cases memoire, et tout ca, conduisent a une vision etriquee de l'informatique
et du fonctionnement des machines.

Le point de vue du MIT, de commencer par du scheme (avec _the structure and
interpretation of computer programs_) se tient parfaitement.

De toutes facons, si on veut faire des choses serieuses, tot ou tard, va
falloir s'assurer que ce qu'on fait fonctionne...

Et entre devoir ecrire explicitement mes invariants de boucle et mes
conditions d'arret, ou avoir du recursif qui se prouve "naturellement" avec
une belle equation, le recursif c'est souvent plus simple.

Juste un petit bout de point de vue.

Les variables du procedural, les boucles qui vont avec, c'est une vision
tres proche de la machine. Ca revient a prendre la route le nez dans le
guidon.

Oublier un peu tout ca, faire du fonctionnel propre, avec de la recursion,
c'est souvent une bonne facon de s'elargir les horizons.

Allez, une petite fonction recursive pour la route.

unsigned int
pgcd(unsigned int a, unsigned int b)
{
if (a < b)
return pgcd(b, a);
else if (b == 0)
return a;
else
return pgcd(b, a % b);
}
Avatar
espie
In article <4b12568a$0$978$,
Wykaaa wrote:
Erwan David a écrit :
Wykaaa écrivait :


Je ne vois pas pourquoi.
La situation a changé en 30 ans !
Les compilateurs actuels savent beaucoup mieux gérer la récursion qu'au
Moyen-Age :-)
Beaucoup transforment la récursion terminale en itération (le "pattern"
d'optimisation n'est pas très compliqué).



Heureusement, c'est quand meme une techno qui date des annees 60 !

La seule raison pour laquelle ca a mis du temps a etre utilise dans les
compilo C, c'est qu'il etait peu frequent pour les programmeurs C de
faire de la recursion, et qu'ils avaient tendance a optimiser manuellement
la recursion terminale en goto le debut de la fonction....

Toute fonction récursive peut être dérécursivée (pour les fonctions
ihéremment récursives, en passant par une pile LIFO) mais à quel prix ?
J'ai pris l'exemple de l'analyseur syntaxique des expressions
arithmétiques parce que c'est un langage "context-free" reconnaissable
par un automate à pile et donnant lieu à un algorithme LL(k) ou LR(k)
(look-ahead left ou right, k étant la profondeur du look-ahead)
, voire LALR (Look-Ahead Left Recursive employé dans Yacc et Gnu Bison)



Le seul cas d'ecole ou ca vaut le coup de faire gaffe, c'est quicksort,
ou il faut compter les elements de chaque "moitie", histoire de s'assurer
que la recursion terminale s'applique bien sur le bon morceau, sinon, ca
peut degenerer en pile de taille lineaire et pas logarithmique.

Mais je ne t'apprend rien...
Avatar
Benoit Izac
Bonjour,

le 29/11/2009 à 11:07, -ed- a écrit dans
le message
:

loin dans la programmation, je veux comprendre ce qui se passe dans la
machine tant que c'est à "porter de mains".



Tu ne conduis une voiture que si tu es un expert en sciences
mécanique ?



L'analogie est mauvaise. La programmation, c'est plutôt la fabrication
de la voiture, l'utilisation du programme étant la conduite.

Je veux fabriquer une voiture. Dans tous les cas il me faut des plans
(algorithmes) et c'est indépendant du choix que je vais faire pour sa
fabrication (langage de programmation). Ensuite, j'ai le choix :

- je veux construire moi-même toutes les pièces (assembleurs)
- je veux acheter toutes les matières premières et réaliser tous les
usinages, par contre j'utilise des vis du commerce (C)
- je veux acheter des composants existants dans le commerce comme le
moteur, la carrosserie et ne réaliser que l'assemblage (Python,
Perl, etc.)

Ça reste une analogie, la réalité est un peu plus complexe quand au
choix du langage.

Ceci dit, pour quelqu'un qui n'est pas informaticien (comme moi) et
qui ne pratique pas la programmation de manière régulière, il ne faut
pas s'attendre à pouvoir programmer en C correctement avant plusieurs
années (pratiquement dix ans dans mon cas mais je suis une
feignasse ;-) ).

Je pense qu'on apprends un langage de programmation comme une langue
étrangère : au début, on comprends rien et c'est bien normal. Il ne faut
surtout pas s'attarder sur tous les petits détails sinon on n'apprend
rien. Avec le temps, on commence à comprendre le sens des phrases même
si on ne comprend pas chaque mot. Avec la pratique, on acquière des
automatismes qui permettent de ne plus réfléchir à certaines choses et
donc de pouvoir se concentrer sur d'autre dont on ignorait l'existence.

Pour une personne qui apprend seule, parler couramment, avoir l'accent
et pouvoir faire du littéraire, c'est beaucoup, beaucoup de travail (je
veux pas décourager mais je pense même que c'est quasiment impossible).
Si l'on veux vraiment avoir une maîtrise du langage, la seule solution
c'est d'aller dans un pays où les gens parlent cette langue (milieu
professionnel ou participer au développement d'une application réelle).

Mes deux cents.
--
Benoit Izac
Avatar
Erwan David
Wykaaa écrivait :

Erwan David a écrit :
Wykaaa écrivait :

candide a écrit :

Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien
compris à la récursivité donc te crois pas obligé de passer par ce
pensum (qui est aussi une belle tarte à la crème).


La "tarte à la crème" c'est de faire croire qu'on peut se dispenser de
comprendre la récursivité quand on est programmeur. Ceci est
totalement faux.
Tout algorithme qui requiert un automate à pile est souvent beaucoup
plus facile à coder de façon récursive (exemple : la reconnaissance
syntaxique des expressions arithmétiques).
Et puis nombre d'algorithmes sur les arbres, voire les listes, sont
bien plus faciles à programmer de façon récursive.

La récursivité est un concept clé de la programmation (et de
l'informatique et des mathématiques en général).



l'étape suivante étant d'apprendre à se passer de la récursivité qand on peut...



Je ne vois pas pourquoi.
La situation a changé en 30 ans !



ça c'est mon historique de développeur embarqué qui parle...

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Avatar
espie
In article ,
Erwan David wrote:

ça c'est mon historique de développeur embarqué qui parle...



Ca veut juste dire que tu optimises la recursion terminale a la main
en presence de compilateurs deficients...
Avatar
candide
Marc Espie a écrit :
In article <4b0e4cc7$0$9187$,
candide wrote:
Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien
compris à la récursivité donc te crois pas obligé de passer par ce
pensum (qui est aussi une belle tarte à la crème).



Si c'est pour donner des conseils aussi mauvais, tu peux aussi fermer
ta gueule.



Visiblement, ça ne te fait pas plaisir que je te dise la réalité mais,
oui, un grand nombre de programmeurs n'ont pas compris la récursivité.
Comprendre la récursivité, ce n'est pas avoir compris la tarte à la
crème de la factorielle.

Une fois de plus, si on dit que l'itération est humaine et la récursion
divine, ce n'est pas pour rien : il y a vraiment une difficulté à
_vraiment_ comprendre la récursivité.



Le cote "chercher la petite bete dans la norme", ca tu sais faire.

Le cote "expliquer la programmation aux gens", par contre c'est moins
au point...



Je n'en suis pas si sûr justement. Question d'empathie.



Meme s'il y a des gens qui se pretendent programmeurs qui sont nuls, ca
n'est pas une raison pour inciter les nouveaux a faire pareil...



On n'est pas un programmeur nul si on ne maitrise pas la récursivité.
Avatar
espie
In article <4b1270bb$0$8936$,
candide wrote:
Marc Espie a écrit :
Meme s'il y a des gens qui se pretendent programmeurs qui sont nuls, ca
n'est pas une raison pour inciter les nouveaux a faire pareil...





On n'est pas un programmeur nul si on ne maitrise pas la récursivité.



Ben si.

Ou plus precisement, si on ne maitrise pas la recursivite, on est loin
d'avoir fini d'apprendre.

Ca fait partie des connaissances de base que tout programmeur raisonnablement
serieux doit connaitre. Je te l'accorde, il y a plein de guignols qui se
pretendent "programmeurs" et qui n'y ont rien compris. Ca ne change rien
au fait que c'est la honte du metier.
2 3 4 5 6