Discussion :

[3DArchi]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
initialisation de l'intervalle
saisie de la valeur
si valeur est dans l'intervalle 
    faire
        valeur_courante = (debut_intervalle + fin_intervalle) / 2
        si (valeur < valeur_courante)
            fin_intervalle = valeur_courante
        sinon
            debut_intervalle = valeur_courante
    tant que valeur_courante != valuer
    La valeur est valeur_courante

Ce qui serait intéressant, c'est de remplacer cet algo assez procédural par une approche objet (j'ai pas encore réfléchi à ce que ça pourrait être). Après tout, on est dans un forum C++ (donc, j'imagine que le cours est du C++) et pas de C.

[HanLee]

Ce qui serait intéressant, c'est de remplacer cet algo assez procédural par une approche objet (j'ai pas encore réfléchi à ce que ça pourrait être). Après tout, on est dans un forum C++ (donc, j'imagine que le cours est du C++) et pas de C.

Ah non, pas d'approche objet pour les algorithmes. D'ailleurs, ça veut dire quoi ?

La POO, c'est une manière de structurer ses programmes, problème orthogonal à un problème algorithmique.

Et le C++ n'implique pas de faire de l'objet, on peut rester en procédural. Tous les algorithmes de la STL sont des fonctions libres. C'est très bien comme ça.

On est pas dans le dogme comme en Java.

[Frifron]

Oui l'approche objet est inexistante dans l'algo mais bon je ne vois ni comment ni pourquoi mettre de l'objet ici.

La ou l'OO sera interessant, c'est si on va un peu plus loin est qu'on met en place un algorithme de recherche dichotomique sur un conteneur d'objets triés (et puis comparer les résultats avec le classique find)

[3DArchi]

Ah non, pas d'approche objet pour les algorithmes. D'ailleurs, ça veut dire quoi ?

La POO, c'est une manière de structurer ses programmes, problème orthogonal à un problème algorithmique.

Et le C++ n'implique pas de faire de l'objet, on peut rester en procédural. Tous les algorithmes de la STL sont des fonctions libres. C'est très bien comme ça.

On est pas dans le dogme comme en Java.

Pour continuer sur le troll avec HanLee et Frifron, je maintiens: ça serait intéressant de l'aborder sur le paradigme purement objet, car tant qu'à programmer avec un langage objet autant raisonner en objet.
"La POO, c'est une manière de structurer ses programmes, problème orthogonal à un problème algorithmique." Oui mais la pratique montre qu'on finit par programmer comme on a pensé l'algo surtout en C++ où on finit par implémenter du C maquillé en C++ et on ne s'oblige pas à transcrire un algo dans une approche OO.

[HanLee]

Pour continuer sur le troll avec HanLee et Frifron, je maintiens: ça serait intéressant de l'aborder sur le paradigme purement objet, car tant qu'à programmer avec un langage objet autant raisonner en objet.
"La POO, c'est une manière de structurer ses programmes, problème orthogonal à un problème algorithmique." Oui mais la pratique montre qu'on finit par programmer comme on a pensé l'algo surtout en C++ où on finit par implémenter du C maquillé en C++ et on ne s'oblige pas à transcrire un algo dans une approche OO.

Non, le C++ n'est pas un langage exclusivement objet, il est pragmatique (bien que très orienté impératif).
En C++, on est libre de nos styles de programmation. On est pas en Java/C# (bien qu'ils commencent à intégrer beaucoup de choses des langages fonctionnels, et ça c'est bien).

Enfin, j'ai pas compris si le but c'était de structurer le programme dont l'intérêt est de rejouer un algorithme, et ceci dans une optique POO, ou bien de structurer notre fonction libre, en l'adaptant sous forme POO-esque.

- Dans le premier cas, OK, tu peux ignorer tout ce qui suit (1er cas = mettre sous l'approche POO, toute la partie mélange de l'algorithme avec l'input).
Ce serait très limité quand même, vu la taille du problème.

C'est comme tout domaine scientifique, chaque approche a ses domaines de prédilection, et les problèmes minuscules comme ceux-ci bah ne donnent pas un avantage flagrant. D'ailleurs, la POO n'est pas encore la panacée...

- Dans le deuxieme cas (= formuler l'algorithme de dichotomie uniquement, c'est-à-dire non couplé avec l'input, sous forme POO) :

Ca veut dire que tu voudrais transformer std::lower_bound en mode POO ?
Autre question, std::sin, std::cos, std::log et consort. devraient être dans une classe donc ? Ca en deviendrait ridicule.

POO ou pas, la seule différence, ce sera le type de données que tu manipules, et qui manipule quoi.
Typiquement, tu n'auras que des objets, et des méthodes...
En général, on s'autorise des types primitifs quand même.

Un algorithme comme ça, c'est du pur calcul.

Et au final, tu te retrouveras avec une méthode statique, et donc tu auras créé une classe de manière "hypocrite".
Preuve que cette classe n'a pas vraiment lieu d'exister...

[Hyperyon]

Je vous signale que le premier message de ce topic était de demander simplement un peu d'aide, et là... ça part un peu en troll

Le programme marche nickel

Et merci encore les gens

[3DArchi]

Non, le C++ n'est pas un langage exclusivement objet, il est pragmatique (bien que très orienté impératif).
En C++, on est libre de nos styles de programmation. On est pas en Java/C# (bien qu'ils commencent à intégrer beaucoup de choses des langages fonctionnels, et ça c'est bien).

Oui, mais dans le cadre d'un cours/TD sur C++, on peut se contraindre à l'aborder uniquement en approche OO. Ca reste un exercice de style.

Enfin, j'ai pas compris si le but c'était de structurer le programme dont l'intérêt est de rejouer un algorithme, et ceci dans une optique POO, ou bien de structurer notre fonction libre, en l'adaptant sous forme POO-esque.

L'idée n'est plus de raisonnée en disant 'je cherche un algo pour trouver un nombre à partir d'une saisie' mais de le reformuler avec le vocabulaire OO.

C'est comme tout domaine scientifique, chaque approche a ses domaines de prédilection, et les problèmes minuscules comme ceux-ci bah ne donnent pas un avantage flagrant. D'ailleurs, la POO n'est pas encore la panacée...

Je répète, l'intérêt est alors pour l'exercice de style.

- Dans le deuxieme cas (= formuler l'algorithme de dichotomie uniquement, c'est-à-dire non couplé avec l'input, sous forme POO) :

Ca veut dire que tu voudrais transformer std::lower_bound en mode POO ?
Autre question, std::sin, std::cos, std::log et consort. devraient être dans une classe donc ? Ca en deviendrait ridicule.

Réecriture des fonctions mathématiques

Et au final, tu te retrouveras avec une méthode statique, et donc tu auras créé une classe de manière "hypocrite".
Preuve que cette classe n'a pas vraiment lieu d'exister...

Dans ce cas, effectivement, tu auras transcrit une solution 'C' en 'C++'.

[Médinoc]

Réecriture des fonctions mathématiques

Euh... Il me semble que métaprogrammation et POO sont deux choses différentes...

De plus, c'est bon pour du compile-time, mais pas pour des données dépendant de l'exécution...

[3DArchi]

Euh... Il me semble que métaprogrammation et POO sont deux choses différentes...

C'était pour illustrer qu'il n'est pas toujours ridicule de réécrire certaine fonction de base.

[Luc Hermitte]

Il y a une erreur de compréhension que je vois de plus en plus souvent (effet troupeau ?) et qui est revenue ici.

OO et impératif ne sont pas deux choses qui s'opposent. C'est au contraire parfaitement orthogonal. Le modèle OO du C++ EST impératif. D'autres langages vont mixer OO et fonctionnel.

Ce n'est pas parce que la recherche dichotomique va travailler sur un TAD, qui effet de bord du C++ sera une classe, que son algo sera OO pour autant.

PS: je vous invite à consulter la livre d'algorithmie qui est maintenu par A.Stepanov (il est disponible en ligne sur son site)