Salut tout le monde, je ne suis qu'un débutant (en cours d’apprentissage du c++) et il y a une notion qui reste tres abstraite pour moi, c'est par rapport aux fonctions.
je n'arrive pas a comprendre l'utilité et le fonctionnement des différents types (int, string, double, bool, etc...)
qui sont utilisés pour déclarer une fonction.
je ne sais pas quelle est leur utilité précise dans ce cas et quand on doit les utiliser    
Merci d'avance

up  

 
Ta question n'est pas très claire pour moi et je ne sais pas non plus quel est ton background. Je vais essayer de t'expliquer cela sous une forme plus mathématique (ou il existe aussi une notion de types similaire à celle de l'informatique).
e:
 
Si tu as fait un peu de trigonométrie, tu connais sans doute la fonction "sinus" . Cette fonction prend un argument de type réel (l'angle dont on veut calculer le sinus) et retourne une valeur de type réelle elle aussi. Les mathématiciens disent que cette fonction est définie de R dans R.
 
Dans les langages de la génération de C++ on definit cela de la manière suivant

 
Le type double est le "nom des réels en C++" (pas taper je sais bien que c'est une grossière  approximation). Donc là on donne tout d'abord le type de retour (le premier "double" ) et ensuite le nom de la fonction. Entre parenthèse on indique que la fonction prends un paramètre (appellé l'angle) de type aussi réel c'est-à-dire double.
 
Donc chaque fois que tu as besoin de définir une fonction tu dois te poser la question de savoir "quel est le type des paramètres dont j'ai besoin" et "quel type de valeur la fonction doit retourner".    Le type doit être définit de la manière la plus précise possible.  Par exemple dans l'exemple de la fonction sinus ci-dessus, quand on demande à un débutant quel est le type de l'angle on obtient souvent la réponse "l'angle est un nombre". Mais pour la programmation il faut être plus précis que cela. Est-ce que c'est un nombre entier ? un nombre réel ? Un petit ou un grand nombre ? Si tu peux répondre à ces questions alors tu auras une indication du type de données que tu dois spécifier.

super, merci tu m'as bien aidé.  

leonhard a très bien expliqué l'aspect fonctionnel du typage (opérations qu'on peut réaliser sur un type de donnée). Mais il y a un autre aspect tout aussi important : c'est l'allocation de l'espace mémoire, c'est-à-dire la quantité de mémoire que le CPU doit réserver pour stocker chaque variable de ton programme. L'idée est d'être le plus économe possible. Si tu dois stocker un entier compris entre 0 et 255, un octet suffira (ex, un UNSIGNED CHAR) : pas la peine de réserver un double, bien plus gourmand en espace mémoire.
Le type influe aussi sur les performances du programme. Parfois, il vaut mieux rester en entiers plutôt que de passer en float ou double.

 
 
Ah oui mais non ... Tu as parfaitement raison bien entendu, mais je pense que pour un débutant, aujourd'hui (juillet 2018) cet aspect n'est pas fondamental dans un premier temps. Si tu as un programme qui va utiliser quelques centaines de kB avec des byte et 8 fois quelques centaines de kB avec des long int, ça ne change pas vraiment les choses. Quand j'ai commencé la programmation (au millénaire passé) il fallait essayer d'économiser chaque bit possible (je suis certain que tu te rappelle des packed array of boolean de pascal). Mais maintenant, toujours pour un débutant, on s'en fout. C'est comme les questions d'optimisation d'algorithme, c'est un problème de programmeur avancé comme toi développant des applis complexes, pas un problème de débutant.  
 
Petite citation : Premature optimisation of code is the root of all evil (Knuth).

"Premature optimisation of code is the root of all evil (Knuth)"
--> entièrement d'accord. Mais savoir dimensionner la taille de ses variables est une habitude à prendre dès le départ je trouve. Après, on se retrouve avec des programmes obèses qui font 30 Mo juste pour afficher une fenêtre et un petit message.
Même chose pour les librairies : savoir inclure que celles dont on a besoin. Je vois des sites web qui mettent 1 Mo de JQuery juste pour pouvoir écrire $(ID) alors qu'ils seraient plus rapides à charger en enlevant cette lib et faire du document.getElementById().
 
Les développeurs ont tellement pris l'habitude de coder avec des couches d'abstractions (ou libs) qui leur simplifient la vie et accélèrent le dév qu'ils en oublient de vérifier s'ils en ont vraiment besoin et si ça ne ralentit pas l'exécution du programme...
 
D'où pourquoi aujourd'hui, on a des machines super puissantes et pourtant, on n'arrive pas à faire tourner certains programmes de manière fluide parce qu'ils ont été codés comme des porcs.

Entièrement d'accord avec rufo.  
Nous vivons à l'époque du bloatware.

 
Au risque de me répéter vous avez tous les 2 mille fois raison. Mais ce que je voulais dire, c'est que demander à quelqu'un qui ne voit pas la différence entre int et un float de savoir s'il faut un int, un short, un long (ou éventuellement un unsigned int) n'est pas une bonne méthode d'explication. Tous les exemples que vous montrez sont des exemples complexes programmés par des informaticiens qu'on pourrait espérer expérimentés. Il y a exactement le même problème avec la "scalabilité" des algos employés, cependant parler de la complexité (classe grand O et toutes ces choses de complexité asymptotique) à un débutant c'est un moyen assez sûr pour le perdre en route.

Pour moi, le typage des variables fait parti des bases de la programmation qu'un débutant doit apprendre. En effet, comme lorsqu'on apprend à faire des maths, on apprend à ne pas mélanger les patates et les carottes, il en est de même dans la programmation. On ne mélange pas un string et un int, on ne mélange pas un double et un int. Tout cela a des conséquences qui vont au delà de l'optimisation.  

 
Oui enfin bon, déclarer un unsigned short plutôt qu'un int, ça va pas transformer un char en fusée, par contre ça va bien t'emmerder quand t'auras déclaré un int quelque part et que tu vas devoir caster pour appeler ta fonction.
 
On parle pas de librairies ici, juste d'apprendre ce qu'est la programmation.

C'est un tout. Programmer, c'est utiliser des libraires et savoir inclure uniquement celles dont on a réellement besoin. On voit souvent des dév en C/C++ ou en Java inclure tout un tas de libs "par habitude" sans trop savoir réellement à quoi elle servent ou si c'est vraiment utile dans ce programme là de toutes les inclure parce que dans tous leurs autres programmes, ils les ont toujours incluses
 
A mon sens, savoir programmer, c'est maîtriser parfaitement chaque pièce du puzzle (le programme) qu'on a assemblée : on a mis ces pièces là : y'en a aucune à mettre en plus, aucune à mettre en moins. Ca peut paraît un peu excessif comme point de vue, mais je pense que c'est vers ça que doit tendre chaque développeur : l'économie des ressources matérielles et des instructions.
Edi : oui, je suis un peu nostalgique de l'époque des démo makers qui codaient des animations de malade sur une disquette de 800 Ko

Les animations de malade c était moins de 30k