Discussion :

[koala01]

Cette discussion issue de Apprendre le C & C++, un bon choix ?


Salut,

Si je pouvais te donner un conseil, ce serait d'apprendre en priorité les "base communes", les "principes généraux" que l'on retrouve dans strictement tous les langages: les principes de l'algorithmique et de la programmation structurée d'une part, les principes de la programmation orientée objet d'autre part(même si ces derniers ne s'appliquent pas à tous les langages).

Il ne faut, en effet, pas donner plus de pouvoir aux langages qu'ils n'en ont réellement: ce ne sont que des outils qui permettent d'indiquer à "quelque chose d'aussi bête qu'un ordinateur" ce que l'on attend d'eux.

Seulement, avant de vouloir essayer de faire comprendre à un ordinateur ce que l'on attend de lui, il faut... savoir exactement ce que l'on attend qu'il fasse et dans quel ordre.

Ce n'est qu'une fois que l'on sait clairement et précisément (ou du moins "de manière aussi précise que possible") ce que l'on attend de l'ordinateur qu'il faut faire intervenir un langage de programmation pour le lui indiquer, et le travail se limite alors souvent à un "long et fastidieux travail de dactylographie" (bon, d'accord, j'exagère un peu sur ce point )

Lorsque l'on respecte cet ordre d'apprentissage et de développement avant l'écriture du code, on se donne l'occasion de rendre sa vraie place aux langages de programmation, ils semblent directement beaucoup moins complexes, et l'on passe beaucoup moins longtemps à s'arracher les cheveux en se demandant "pourquoi il ne fait pas ce que je veux".

Ceci dit, je confirme ce qui a déjà été dit par ailleurs: C et C++ sont effectivement des langages fort proches, et s'il est possible que tu sois, à cause de la quantité de code existant, confronté à des situation dans lesquelles ton rencontrera peut être du code C dans du code C++, il est bon et préférable d'apprendre ces langages séparément.

A l'extrême limite, j'en arriverais volontiers à conseiller d'apprendre C++ avant C, histoire de ne pas prendre des "mauvaises habitudes" qui passent pourtant en C pour "des règles de bonnes pratiques" lors de l'apprentissage de C.

Je ne crois personnellement pas qu'il ne vaille pas la peine d'apprendre C, car c'est un langage qui est à l'heure actuelle encore largement utilisé, même si c'est peut être dans des secteurs "de niche".

Par contre, je suis catégorique sur le fait que la connaissance de C n'est nullement un prérequis à l'apprentissage de C++

[NoIdea]

Moi je te conseillerais plutôt, si tu as le temps et que pour l'instant tu n'as pas encore étudié d'autres langages de programmation :

-Apprend le C : les types, les pointeurs, l'algorithmie, les étapes de compilation, les headers...
-fixe toi des projets : créer une librairie (par ex liste chainée ou doublement chainée pour un type donné), Améliore une librairie existante, créer un jeu (avec la SDL par exemple), ... (tout cela est largement possible en C)
Normalement, le paradigme procédural est étudié.
-Apprends le C++ without classes : la surcharge de fonction, la surdéfinition d'opérateur, les templates, les namespaces, les références...
Normalement, le paradigme générique est étudié.
-utilise ce nouveau language : recréé une liste chainée pour n'importe quel type.
-Apprend la notion de classe et surtout le RAII
-Facilite les choses avec la STL
-Normalement la notion d'objet est étudiée bien qu'il y a pas beaucoup de différence entre une class (c++) et une struct (C) mis a part quelques différences de syntaxe.
-Apprend le véritable intérêt des classes : le polymorphisme.
-Facilite encore plus grâce a boost et Qt.
-intéresse toi aux design patterns.

Par contre, je suis catégorique sur le fait que la connaissance de C n'est nullement un prérequis à l'apprentissage de C++

Que tu passes directement au c++ ou que tu fasses c puis c++, les même connaissance seront obtenues. Cependant, commencer par le c++ ne donne pas une idée de ce qu'il se passe dernière :
par exemple, souvent si l'on commence par le c++, un des premiers programme sera
int nb=10;
cout<<nb;
alors que en C on aura
int nb=10;
printf("%i",&nb);

Quelqu'un de débutant pensera longtemps(ou pas), ne pensera jamais qu'on ne puisse pas afficher quelque chose dans cout. De plus, la syntaxe de "fonction" est cachée par l'opérateur <<
Alors que dans le deuxième cas, un débutant verra tout de suite que pour chaque chose, il y a une manière différente de les afficher. De plus, printf ressemble réellement à une fonction.

histoire de ne pas prendre des "mauvaises habitudes" qui passent pourtant en C pour "des règles de bonnes pratiques" lors de l'apprentissage de C.

koala, a tu de nombreux exemples de mauvaises habitudes autres que les #define utilisés en permanence et l'absence de RAII ?

[koala01]

-Apprend le C : les types, les pointeurs, l'algorithmie...

Pourquoi vouloir faire apprendre l'algorithmie et les bases de la programmation en passant par un langage, quel qu'il soit

Les bases de la programmation, algorithmie en tête, sont totalement indépendantes de n'importe quel langage et s'appliquent strictement à tous.

C'est, à mon sens, justement parce que les approches "traditionnelles" essayent d'inculquer les bases de la programmation en même temps qu'un langage particulier que tous les langages semblent si complexes et rebutants aux récipiendaires.

De même pour la programmation orientée objets: C++ a l'énorme avantage de permettre certaines chose que d'autres langages refusent (l'exemple classique étant l'héritage multiple ), mais tous les langages OO incitent le développeur / le programmeur à respecter les mêmes règles, principes et loi de manière plus ou moins stricte selon leur propre philosophie.

Si tu commences par apprendre les "bonnes pratiques" qui te permettent de développer un projet qui "tient la route", si tu y adjoint des méthodes de développement qui te permettent d'avoir une vue d'ensemble cohérente de l'adaptation de ton projet au besoins exprimés (je penses, entre autres, à UML), l'apprentissage d'un langage OO devient particulièrement aisé, parce qu'il te devient possible de faire le rapprochement entre ce que tu as envisagé "de manière abstraite" (en mettant ta méthode de développement en oeuvre) et ce que le langage permet "concrètement".

Tu n'a donc "plus qu'à"... adapter ta connaissance des principes généraux aux restrictions et au permissivités du langage que tu apprend

Encore une fois, cette méthode d'apprentissage permet de "démystifier" le langage que tu apprend

[white_tentacle]

koala, a tu de nombreux exemples de mauvaises habitudes autres que les #define utilisés en permanence et l'absence de RAII ?

Le nommage différent parce qu'il n'y a pas de namespace ni de surcharge, les passages de paramètres par pointeurs parce qu'il n'y a pas de références, les single return (absence de raii), les déclarations de variable en début de fonction, etc. Je suis sûr qu'on en trouve rapidement plein d'autres.

[koala01]

Le nommage différent parce qu'il n'y a pas de namespace ni de surcharge, les passages de paramètres par pointeurs parce qu'il n'y a pas de références, les single return (absence de raii), les déclarations de variable en début de fonction, etc. Je suis sûr qu'on en trouve rapidement plein d'autres.

Ouppss... je n'avais pas vu la question

Comme tu y a répondu, je pourrais aussi citer la gestions manuelle de la mémoire systématique, le recours aux tableaux de caractères pour représenter des... chaines de caractères, l'utilisation même de fonctions issues du C en C++, le transtypage vers void pour transmettre un paramètre dont le type n'est pas connu à une fonction, et il y en a encore d'autres

Je crois que, si tout le monde s'y met, nous devrions sans doute arriver à dresser une liste presque exhaustive contenant pas loin d'une centaine de pratiques conseillées en C et déconseillées en C++

[NoIdea]

Les bases de la programmation, algorithmie en tête, sont totalement indépendantes de n'importe quel langage et s'appliquent strictement à tous.

Tout à fait d'accord, mais, pour regarder les conséquences de son algorithme (lenteur, et autres défauts), il faut à un moment écrire dans un langage cet algorithme. Or je ne pense pas qu'apprendre un troisième langage soit une bonne idée.

De même pour l'OO.

[NoIdea]

Quant au mauvaises pratiques, si vous voulez dire que les bibliothèques C que l'on inclut ont des problèmes, d'accord (namespace, nom des fonctions...). Toutefois, il existe souvent des wrapper.
Cependant, dans le cas où les programmeurs et eux même ont des mauvaises habitude, je suis moins d'accord :

qu'il n'y a pas de namespace ni de surcharge, les passages de paramètres par pointeurs parce qu'il n'y a pas de références, les single return (absence de raii), les déclarations de variable en début de fonction

namespace=touche finale + utile que dans les gros projets.
surcharge= problème corrigé dans la partie 2 : le C++ without classes.
absence de raii=vrai problème mais peut être corrigé.

la gestions manuelle de la mémoire systématique, le recours aux tableaux de caractères pour représenter des... chaines de caractères, l'utilisation même de fonctions issues du C en C++, le transtypage vers void pour transmettre un paramètre dont le type n'est pas connu à une fonction, et il y en a encore d'autres

Personnellement, je pense qu'il existe peu de personne qui apprécie de gérer la mémoire systématiquement ainsi que les chaines de caractère. Avec la découverte de la STL, ces habitudes devraient se perdre rapidement :
on ne parle pas de quelqu'un qui va programmer en C pendant 10 ans puis qui va se mettre au c++.
Utilisé des fonctions issue du C plutôt que du c++ ne pose de problème qu'en cas de mélange des 2.
Quant-aux transcryptage vers void, il est souvent remplaçable par des templates qui sont découverte dans mon chapitre 2. De plus, gérer des void* plutot que des template est beaucoup plus dur.

Je pense donc, qu'il y a de faible chance pour que quelqu'un puisse s'imprégner de mauvaises habitudes qui ne seront pas changées rapidement par la venue du c++ et quelques mois de C.

que les approches "traditionnelles"

Il me semblait qu'une approche traditionnelle était plutot :

-C
-C with classes
-c++

et non

-C
-C++ without classes
-C++

[koala01]

Tout à fait d'accord, mais, pour regarder les conséquences de son algorithme (lenteur, et autres défauts), il faut à un moment écrire dans un langage cet algorithme. Or je ne pense pas qu'apprendre un troisième langage soit une bonne idée.

Pas forcément...

Si tu apprend à te mettre à la place de l'ordinateur qui reçois les instructions une à une, tu peux déjà très rapidement arriver à déterminer où pêche l'algorithme.

Et cela peut occasionner quelques franches moment de rigolade, si tu le fais sérieusement sans te prendre au sérieux

Il s'agit d'un exercice dans lequel je me lance très régulièrement, et je peux t'assurer que grâce à cela, la première compilation réussie me donne généralement... exactement le résultat que je souhaitais.

Il te permet aussi bien de tester la logique générale que de trouver les instructions qui sont répétées de manière indues, et, si tu effectue suffisamment (comprend: tant que tu remarque quelque chose d'illogique) d'itération écriture / modification de l'algorithme -->test mental, tu arrives très rapidement à un algorithme "optimal"

Cette manière de faire peut, aussi, te permettre de déterminer qu'une structure de données particulière ne semble, par exemple, pas forcément adaptée ( l'exemple typique serait l'utilisation d'un tableau ou d'une liste quand un arbre binaire s'avèrerait plus efficace pour la recherche).

N'oublie pas que l'ordinateur est quelque chose de, finalement, totalement idiot qui ne sait (même si j'exagère un peu) que compter de 0 à un et qu'appliquer un nombre très restreint d'opération de base.

Tu ne pourra donc lui donner que "l'intelligence" que tu veux bien / peux lui inculquer, et c'est pour cela que tout le travail intellectuel que tu aura fourni avant d'écrire ta première ligne de code sera particulièrement valorisé par la suite

[Invité]

@Koala

Seulement, avant de vouloir essayer de faire comprendre à un ordinateur ce que l'on attend de lui, il faut... savoir exactement ce que l'on attend qu'il fasse et dans quel ordre.

Ce n'est qu'une fois que l'on sait clairement et précisément (ou du moins "de manière aussi précise que possible") ce que l'on attend de l'ordinateur qu'il faut faire intervenir un langage de programmation pour le lui indiquer, et le travail se limite alors souvent à un "long et fastidieux travail de dactylographie" (bon, d'accord, j'exagère un peu sur ce point )

Là je suis complètement d'accord. Autrefois, quand on développait, on décrivait la logique, on dessinait l'organigramme etc, et on avait deux ou trois passages par jour. On allait lire son petit (ou gros suivant le cas) paquet de cartes à trois bâtiments de là, on allait chercher son listing une heure plus tard, dans le même bâtiment. Là je vous assure que c'était du développement et l'étape programmation était accessoire. Si le programme concernait le dessin, on allait chercher la bande dans la salle machine, et il fallait attendre que la table soit libre pour avoir le résultat.
Mais maintenant, il semble que l'on mette la programmation en avant.

Par contre, je ne suis pas vraiment d'accord avec votre dernier post.

De la même façon qu'on ne peut pas apprendre à parler anglais dans des livres, on ne peut pas apprendre les échanges avec une machine (un langage) sans discuter effectivement avec elle.
Si j'avais à conseiller un débutant, je lui dirais de commencer avec un truc très simple, comme le BASIC. Autrement dit, à choisir pour commencer entre le C et le C++, c'est sans hésiter le C. Je ne sais pas quelle mauvaise habitude on risque de prendre, mais ça me parait complètement secondaire par rapport à l'avantage de "savoir ce qui se passe".
La lecture de chaque post de ces forums me confirme cela.
Je sais bien, c'est un sujet maintes fois évoqué, autant j'admets que le C n'est pas un prérequis nécessaire au C++, autant je suis sur que pour comprendre la programmation, il faut commencer pas du bas-niveau (au sens où on l'utilise dans ce domaine).

Pour mémoire, il y a eu un échange de post très intéressant sur le forum concurrent (je parle du forum C naturellement).

PS Vous écrivez plus vite que moi, j'ai 2 post de retard

[NoIdea]

tu arrives très rapidement à un algorithme "optimal"

Pas forcément, il existe des problèmes ou il n'y a pas de "bon" algorithmes :
On utilise donc des heuristiques, pour ce rendre compte de la lenteur d'un algorithme par rapport à une heuristique sans le tester, dur-dur parfois...
De plus, je ne pense pas qu'un débutant veuille pouvoir au début exécuter un algorithme uniquement dans sa tête (à un moment, il faut qu'il le "voit").

[koala01]

Quant au mauvaises pratiques, si vous voulez dire que les bibliothèques C que l'on inclut ont des problèmes, d'accord (namespace, nom des fonctions...). Toutefois, il existe souvent des wrapper.
Cependant, dans le cas où les programmeurs et eux même ont des mauvaises habitude, je suis moins d'accord :

Demande à quelqu'un qui a l'habitude de coder en C d'écrire un code en C++... Tu risques d'avoir pas mal de surprises

namespace=touche finale + utile que dans les gros projets.

Loin de là...

namespace : un espace de noms dédié pour chaque projet, dés le début du projet, même s'il n'est pas subdivisé, et même si le projet reste limité.

Cela permettra justement de ne pas "tout laisser trainer" dans l'espace de noms global

surcharge= problème corrigé dans la partie 2 : le C++ without classes.
absence de raii=vrai problème mais peut être corrigé.

A condition d'y penser...

Personnellement, je pense qu'il existe peu de personne qui apprécie de gérer la mémoire systématiquement ainsi que les chaines de caractère. Avec la découverte de la STL, ces habitudes devraient se perdre rapidement :
on ne parle pas de quelqu'un qui va programmer en C pendant 10 ans puis qui va se mettre au c++.
Utilisé des fonctions issue du C plutôt que du c++ ne pose de problème qu'en cas de mélange des 2.

Les mauvaises habitudes, surtout si on les a surinées comme "bonnes" pour un autre langage sont malheureusement les plus difficiles à perdre...

Le forum fourmille d'exemples de ce genre

Quant-aux transcryptage vers void, il est souvent remplaçable par des templates qui sont découverte dans mon chapitre 2. De plus, gérer des void* plutot que des template est beaucoup plus dur.

Je pense donc, qu'il y a de faible chance pour que quelqu'un puisse s'imprégner de mauvaises habitudes qui ne seront pas changées rapidement par la venue du c++ et quelques mois de C.

Hum...

J'ai l'impression que l'on ne participe pas vraiment sur les mêmes forums...

De mon expérience personnelle, je peux t'assurer qu'il est parfois très difficile d'inciter quelqu'un à abandonner son précieux char* au profit de std::string ou d'abandonner son Type* au profit de std::vector

Il me semblait qu'une approche traditionnelle était plutot :
-C
-C with classes
-c++

et non

-C
-C++ without classes
-C++

Ce que j'appelle "approche traditionnelle" regroupe toute approche tentant d'inculquer des "principes de base" (adaptés au paradigme mis en avant) au travers d'un langage particulier.

As tu déjà remarqué la tête de javaistes lorsque tu leur lance le terme "LSP"

Certains ne savent même pas ce que c'est, simplement parce que tout hérite implicitement de Object, et qu'ils en arrivent à ne même pas se poser la question de l'opportunité d'un héritage.

Le problème, c'est que si tu base l'étude des "principes fondamentaux" sur un langage donné, tu en biaise l'apprentissage du seul fait des restrictions ou permissivités du langage en question.

Les "bonnes pratiques" qui découlent alors du langage passent pour être "la règle générale", alors qu'elles devraient être considérée comme... l'exception propre au langage

[NoIdea]

Par contre, je ne suis pas vraiment d'accord avec votre dernier post.

De la même façon qu'on ne peut pas apprendre à parler anglais dans des livres, on ne peut pas apprendre les échanges avec une machine (un langage) sans discuter effectivement avec elle.
Si j'avais à conseiller un débutant, je lui dirais de commencer avec un truc très simple, comme le BASIC. Autrement dit, à choisir pour commencer entre le C et le C++, c'est sans hésiter le C. Je ne sais pas quelle mauvaise habitude on risque de prendre, mais ça me parait complètement secondaire par rapport à l'avantage de "savoir ce qui se passe".
La lecture de chaque post de ces forums me confirme cela.
Je sais bien, c'est un sujet maintes fois évoqué, autant j'admets que le C n'est pas un prérequis nécessaire au C++, autant je suis sur que pour comprendre la programmation, il faut commencer pas du bas-niveau (au sens où on l'utilise dans ce domaine).

Merci, c'est exactement ce que je voulais dire...

[koala01]

Pas forcément, il existe des problèmes ou il n'y a pas de "bon" algorithmes :

j'aurais peut-être du parler d'algorithme "le moins mauvais possible", mais c'est jouer sur les termes ,
On utilise donc des heuristiques, pour ce rendre compte de la lenteur d'un algorithme par rapport à une heuristique sans le tester, dur-dur parfois...
De plus, je ne pense pas qu'un débutant veuille pouvoir au début exécuter un algorithme uniquement dans sa tête (à un moment, il faut qu'il le "voit").[/QUOTE]J'ai "eu la chance" d'avoir des cours d'algorithmie et de conception orienté objet sans aucune référence à un langage donné, dans lesquels on ne touchait pour ainsi dire jamais à un ordinateur (tout se faisait sur des feuilles, et l'évaluation de la qualité de l'algorithme se faisait sur le tableau noir).

Cette chance était, il est vrai, couplée avec celle d'avoir un prof très sérieux qui ne se prenait pas au sérieux

Mais je peux t'assurer que, quand les conditions sont présentes, cela ne te manque absolument pas de ne pas voir ce que l'ordinateur fait effectivement, simplement, parce que tu le vois d'une autre manière (dans mon cas : un prof qui "fait le pitre" devant le tableau).

Si, lorsque tu analyse un algorithme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
variable A =0
tant que A différent de 10
    machin
    chose
    A = A + 1
fin tant

tu as quelqu'un qui en arrive à un discours proche de

A vaut 0
est-ce que A est différent de 10
OUI, on vient de dire qu'elle vaut 0
on fait machin
on fait chose
A vaut 0 + 1 : A vaut maitenant 1
on retoune au début.
A est il différent de 10
OUI, on vient de dire qu'il vaut 1
...

je peux t'assurer que le fait de ne pas le voir à l'écran ne te manque absolument pas

[NoIdea]

Oui mais peut tu me dire (sans tester) si un A* est mieux que dijkstra dans telle ou dans telle condition? De combien cela va changer ?
Bien sur, il est possible d'avoir un ordre de grandeur, mais le temps passé à le calculer n'est-il pas parfois plus long que d'écrire les 2 ?

Personnellement koala, ta réflexion ressemble à la mienne quand...
j'essaye de débugger un programme.

[koala01]

@Koala

Là je suis complètement d'accord. Autrefois, quand on développait, on décrivait la logique, on dessinait l'organigramme etc, et on avait deux ou trois passages par jour. On allait lire son petit (ou gros suivant le cas) paquet de cartes à trois bâtiments de là, on allait chercher son listing une heure plus tard, dans le même bâtiment. Là je vous assure que c'était du développement et l'étape programmation était accessoire. Si le programme concernait le dessin, on allait chercher la bande dans la salle machine, et il fallait attendre que la table soit libre pour avoir le résultat.
Mais maintenant, il semble que l'on mette la programmation en avant.

Et c'est un très grand tord...

La programmation est et doit rester "l'étape finale" d'un processus de développement.

On se comprend ici sur les termes: je veux dire par là que la programmation vient "une fois que l'on a la (quasi) certitude que l'ensemble tient la route", quitte, si cette étape montre des lacunes dans ce qui a été fait avant, à ce que l'on reparte dans un processus de développement afin de les supprimer

Par contre, je ne suis pas vraiment d'accord avec votre dernier post.

De la même façon qu'on ne peut pas apprendre à parler anglais dans des livres, on ne peut pas apprendre les échanges avec une machine (un langage) sans discuter effectivement avec elle.

Pour l'accent et la prononciation, je suis d'accord, rien ne vaut l'oral.

Par contre, en ce qui concerne le vocabulaire et la grammaire, il est presque plus facile de les acquérir grâce... aux lectures.

Je lis particulièrement bien l'anglais, et je l'écrit finalement pas si mal, mais je dois avouer que je le parle quand même avec "l'accent d'une vache espagnole", principalement parce que j'ai effectivement peu d'occasions de le pratiquer

Si j'avais à conseiller un débutant, je lui dirais de commencer avec un truc très simple, comme le BASIC. Autrement dit, à choisir pour commencer entre le C et le C++, c'est sans hésiter le C. Je ne sais pas quelle mauvaise habitude on risque de prendre, mais ça me parait complètement secondaire par rapport à l'avantage de "savoir ce qui se passe".

Je serais plutôt de l'avis contraire...

La priorité devrait être que... cela fonctionne correctement avant de fonctionner vite.

Un programme qui mène vite à une erreur est, pour moi, bien moins intéressant qu'un programme qui fait ce qu'on attend de lui, même s'il le fait un peu plus lentement.

Je ne veux absolument pas dire par là que la notion de performances doit être oubliée, mais, c'est à mon sens quelque chose qui doit être évalué une fois que l'on a... un résultat exploitable.

En cela, savoir comment se comportera le processeur (après l'étape de compilation) ou le compilateur devient finalement bien moins important que d'avoir une logique... logique et clairement la" moins mauvaise possible"

[NoIdea]

De plus, ton algorithme peut etre très rapidement écrit en C sans aucune contrainte de langage. (et l'algorithme que tu montre se rapproche énormément de ce que l'on fait au début).

[NoIdea]

Et c'est un très grand tord...

La programmation est et doit rester "l'étape finale" d'un processus de développement.

On se comprend ici sur les termes: je veux dire par là que la programmation vient "une fois que l'on a la (quasi) certitude que l'ensemble tient la route", quitte, si cette étape montre des lacunes dans ce qui a été fait avant, à ce que l'on reparte dans un processus de développement afin de les supprimer

Je suis d'accord avec toi que dans le cas ou une personne maitrise la programmation c'est un tord. Cependant, il faut avoir une idée de comment écrire le code pour savoir si ce que l'on fait "tient la route". C'est pour cela, que les débutants échappent à cette règle.
De plus, avec de l'expérience, cette personne verra qu'il vaut souvent mieux passer le double en réflexion car cela permet d'éviter de tout recommencer à 0. J'espère donc qu'une fois qu'il a compris le langage, la personne arrêtera de programmer avant de réfléchir.

[koala01]

Oui mais peut tu me dire (sans tester) si un A* est mieux que dijkstra dans telle ou dans telle condition? De combien cela va changer ?
Bien sur, il est possible d'avoir un ordre de grandeur, mais le temps passé à le calculer n'est-il pas parfois plus long que d'écrire les 2 ?

Je ne crois personnellement pas...

Comme sans doute tout le monde ici, je réfléchis et je parle beaucoup plus vite que je n'écris, même si j'écris (relativement) vite et si le processeur exécute sans doutes plus d'instructions que moi en une seconde.

De plus, l'écriture n'est peut être pas grand chose par rapport au temps nécessaire pour arriver à... ce que le code compile (il faut déjà arriver à décrypter les messages du compilateur), et, une fois que le code compile, encore faut-il qu'il s'exécute... sans erreur

Personnellement koala, ta réflexion ressemble à la mienne quand...
j'essaye de débugger un programme.

C'est, justement, à l'étape de débuggage que l'on perd le plus de temps.

La raison première étant sans doute qu'il faut commencer par retrouver la valeur de l'ensemble des variables dans le binaire

Si tu joue toi même au débuggeur AVANT d'écrire ton code, tu de donnes la possibilité de repérer les erreurs beaucoup plus tôt, alors que ta variable A s'appelle encore effectivement A, et que tu peux voir quelle sera l'ensemble des étapes suivantes.

Au final, si tu t'y prend bien, tu peux te dire que la première compilation réussie (une fois corrigées les erreurs de syntaxe) te permettra d'obtenir un exécutable qui... fonctionnera exactement comme il est sensé le faire.

Cela ne devra pas t'empêcher d'effectuer des tests unitaires, et il est toujours possible malgré tout que tu te sois gouré au moment où tu jouais au débuggeur, mais, dans l'ensemble, je peux t'assurer que tu gagnera énormément de temps en développement

C'est bien simple, le plus souvent, lorsque l'on me soumet un problème à résoudre, je commence par... boire un café ou fumer une cigarette pour prendre le temps d'y réfléchir sereinement...

Tu devrais essayer (bois un soft drink si tu préfères et que tu n'es pas fumeur ), cette méthode fait réellement des miracles

[Invité]

De mon expérience personnelle, je peux t'assurer qu'il est parfois très difficile d'inciter quelqu'un à abandonner son précieux char* au profit de std::string ou d'abandonner son Type* au profit de std::vector

Je n'ai pas abandonné mon char*, mais ça ne m'empêche pas d'utiliser AnsiString. De la même façon, j'utilise des TList et aussi des listes chainées maison (j'utilise Borland).
Par contre, il ne semble pas que cela gène un développeur C++ d'utiliser la même classe pour des points et des vecteurs. Je n'imagine pas qu'un développeur en C fasse la même erreur.

C'est bien simple, le plus souvent, lorsque l'on me soumet un problème à résoudre, je commence par... boire un café ou fumer une cigarette pour prendre le temps d'y réfléchir sereinement...

Là 128% (voire 256%) d'accord. Mon truc, c'est pas le café mais le crayon, quant au tabac, c'est plutôt dans la pipe.

[koala01]

Je suis d'accord avec toi que dans le cas ou une personne maitrise la programmation c'est un tord. Cependant, il faut avoir une idée de comment écrire le code pour savoir si ce que l'on fait "tient la route". C'est pour cela, que les débutants échappent à cette règle.

Parce que tout les y incite, essentiellement...

Entre autres le fait qu'on ne leur explique pas que l'ordinateur n'est jamais qu'un "brave petit soldat" qui "fait ce qu'on lui dit" sans se poser la question de savoir si une instruction donnée est opportune à un endroit donné dans le code.

De plus, avec de l'expérience, cette personne verra qu'il vaut souvent mieux passer le double en réflexion car cela permet d'éviter de tout recommencer à 0. J'espère donc qu'une fois qu'il a compris le langage, la personne arrêtera de programmer avant de réfléchir.

Justement, ce que je conseille, c'est d'apprendre comment déterminer la "moins mauvaise" logique possible avant même d'écrire le code, en sachant que l'ordinateur ne se posera jamais la question de savoir s'il est effectivement intéressant d'incrémenter A à tel moment précis du code ou s'il n'est pas préférable de le faire deux instructions plus tôt ou plus tard.

Si on arrive à convaincre dés le départ le débutant de ce fait, c'est l'ensemble de son évolution qui s'en trouvera facilitée, et l'ensemble de ses développements de test qui... gagnera en qualité