Discussion :

[JulienDuSud]

Je ne peux que rejoindre koala sur ce point.

L'algorithmique matheux, c'est bien, mais c'est souvent impossible à implémenter dans un logiciel informatique où tout espace et vitesse est restreint, toujours finit.

Souvent, l'algorithmie matheux parvient à trouver une solution programmables à des problèmes bien précis qui ne sont qu'un modèle restreint du problème réel, et ceux qui essaient de trouver une solution à partir d'un modèle complet se cassent la gueule à cause des restrictions environementales propres à la programmation. Et c'est là que le génie de l'analyste / architecte entre en jeux afin de pouvoir effectivement implémenter l'algorithme. Et ça, c'est souvent pas un matheux qui pourra le faire.

Il suffit d'aller voir projecteuler.net pour se faire une idée. Tous les problèmes ont une solution mathématique qu'il suffit de googler pour trouver.
Il est dit que toutes les solutions du site peuvent être calculées en moins d'une minute sur une machine moyenne. Trouver le bon compromis entre l'algorithme mathématique et l'implémentation informatique est un véritable challenge.

[koala01]

Je ne peux que rejoindre koala sur ce point.

L'algorithmique matheux, c'est bien, mais c'est souvent impossible à implémenter dans un logiciel informatique où tout espace et vitesse est restreint, toujours finit.

Souvent, l'algorithmie matheux parvient à trouver une solution programmables à des problèmes bien précis qui ne sont qu'un modèle restreint du problème réel, et ceux qui essaient de trouver une solution à partir d'un modèle complet se cassent la gueule à cause des restrictions environementales propres à la programmation. Et c'est là que le génie de l'analyste / architecte entre en jeux afin de pouvoir effectivement implémenter l'algorithme. Et ça, c'est souvent pas un matheux qui pourra le faire.

Il suffit d'aller voir projecteuler.net pour se faire une idée. Tous les problèmes ont une solution mathématique qu'il suffit de googler pour trouver.
Il est dit que toutes les solutions du site peuvent être calculées en moins d'une minute sur une machine moyenne. Trouver le bon compromis entre l'algorithme mathématique et l'implémentation informatique est un véritable challenge.

Mon intervention portait plutôt sur le fait que l'algorithmique n'a parfois simplement rien de mathématique...

Toute la partie UML qui a trait aux diagrammes de séquences, d'états ou de communication entre tout à fait dans ce que l'on peut appeler de manière vaste et générique "l'algorithmique"...

Ce sera cet algorithme qu'il faudra réellement implémenter (c'est d'ailleurs pourquoi j'aime autant quitter UML à ce niveau et partir sur un "bon vieux" nassi-sheiderman , mais ce n'est qu'un avis perso, d'autant plus que je connais les réticences de certains vis à vis de cette représentation algorithmique )

[Mac LAK]

Il me manquait ces détails.. de taille!

Autant pour moi/nous : c'était tellement "évident" que je n'ai pas pensé à le dire de prime abord... Ce sont des questions qui m'ont fait penser que tu n'avais pas ces éléments en main (car si tu les avais eus, tu n'aurais jamais eu cette réaction).

Je résonnais plus en terme de règles omniscientes, pré-établies et applicable de facto à tous projets d'une même société (modulo des exceptions éparses -bien entendu).

Cela arrive, mais presque exclusivement dans des sociétés qui sont dans des niches ultra-restreintes, avec donc un seul "type" de projet ou presque. Et cela reste un cas rare malgré tout.

Vous allez me dire que c'est d'une évidence affligeante. D'accord, mais comme par ailleurs on peut lire ci et là que certains bannissent des pans entiers du langage C++ quel qu'en soit le projet, ça pouvait corroborer l'illusion dans laquelle je me suis fourvoyé

C'est comme tout, connaître l'interlocuteur aide aussi à remettre les choses dans leur contexte. Sans précisions particulières, pour ma part, je parle en général de code temps réel bas niveau, par exemple.

Alors ça me rassure sur le devenir de l'espèce humaine!

Et puis surtout, tu le verras par toi-même, ce sont les développeurs eux-mêmes qui font les règles de codage en général. Les qualiticiens ne font que vérifier que leurs règles concordent avec les règles Qualité générales (ISO 9001 le plus souvent), et/ou les normes client (DO178, EN50155, etc.). Si ça remplit toutes les cases, ils valident, sinon ils te disent les points à revoir.

Après, si t'as une équipe de dévs "mous" ou une équipe "dynamique", ça change plus ou moins vite. Comme d'hab, il te faudra des chiffres pour étayer et rendre ta proposition financièrement intéressante, mais ça, ça vient en prenant de l'expérience et/ou en travaillant sur ces règles avec un "ancien" qui t'aidera à formaliser tes idées.

Le plus important, c'est de comprendre que ces règles sont là pour accélérer le développement, le rendre plus fiable et rendre la prise en main d'un nouveau projet plus simple. Si tu n'y vois que des contraintes, il y a deux solutions : soit tu n'as pas compris un point très important (et il te faut alors t'y mettre rapidement), soit la boite est en train de couler pour incompétence chronique...

[loufoque]

Tous les problèmes ont une solution mathématique qu'il suffit de googler pour trouver.

Tu sers à quoi alors si les solutions aux problèmes qu'on t'a engagé pour résoudre existent déjà sur Internet ?

Si tu as un problème de ce type, tu embauches un matheux

Sauf que l'algorithmique, c'est de l'informatique, pas des maths...

C'est en ce sens que je dis que c'est facile. Du point de vue de l'entreprise, c'est déterministe et prévisible. Le reste du développement (architecture, interface, maintenance, évolution) c'est une autre paire de manches...

Ben c'est pareil. S'il te faut un informaticien théorique qui cherche des solutions à ton problème, c'est pas du tout déterministe non plus.

mais en entreprise, c'est rarement ça qui pose problème.

Dans la plupart des entrerpises, on fait essentiellement du code "métier" qui n'est en fait que de la glue et de l'organisation entre les divers composants, donc le problème ne se pose pas.

[Issam_Lahlali]

il y a une phrase avec laquelle j'étais dans la majorité des cas contre il s'agit de "C'est pareil pour tous les langages", mais pour ce cas précis d'algorithmique je crois que c'est pareil pour la majorité des langages et C++ ne présente pas de difficulté ni de complexité par rapport a d'autres langages et ça veut pas dire que c'est pas compliqué du tout, je veux dire que si un algorithmique est difficile en C++ ça doit l'être autant ou plus pour d'autres langages , je dirais même plus facile dans le cas de calcul mathématique vu la nature d'utilisation de C++ dans des domaines de calcul et on a une boite a outil très intéressante en C++pour ça.

et pour le cas d'algorithme dans le sens de diagramme de séquence mentionné par Koala, donc qui concerne les contrôleurs qui déroule une séquence ça ne présente aussi aucune difficulté particulière en C++ par rapport a d'autres, quoi que d'autres technologies essaye d'isoler ce type de comportement dans des diagrammes graphiques pour plus de lisibilité comme le cas de WF de dotnet.

[JulienDuSud]

Tu sers à quoi alors si les solutions aux problèmes qu'on t'a engagé pour résoudre existent déjà sur Internet ?

Je parlais des problèmes de projecteuler.net, où ce sont des problèmes de calcul où le temps et la place sont restreintes. Bien sûr que pour ce genre de problèmes c'est le programmeur qui doit se débrouiller, je n'ai jamais dit le contraire.

Je voulais juste appuyer le fait que résoudre un problème mathématiquement ne veut pas dire le résoudre informatiquement.

[Invité]

mais pour ce cas précis d'algorithmique je crois que c'est pareil pour la majorité des langages

Je ne suis que partiellement d'accord...

Souvent, les algorithmes existent dans des livres avant d'exister comme du code. Les langages qui sont utilisés dans les livres (le Fortran autrefois, le C ensuite) ont un petit avantage sur les autres, car les auteurs des algorithmes, qui ont testé leurs idées dans ces langages, auront parfois utilisé certaines de leurs caractéristiques.

Egalement, il y a des langages très orientés algos. Je vais citer l'APL, une fois de plus... Mais le C et le Fortran seraient probablement en bonne position. Je pense que le C++ s'en tire "pas mal" du fait de son origine C, et de son caractère bas niveau...

je dirais même plus facile dans le cas de calcul mathématique vu la nature d'utilisation de C++ dans des domaines de calcul et on a une boite a outil très intéressante en C++pour ça.

Là je ne suis pas trop d'accord. Le C++ (et le C avant lui) pêchent notoirement en matière de calcul mathématique. Regarde la STL, la seule classe dédiée aux calculs numériques (valarray) est à moitié finie, pas de matrices, une librairie mathématique ultra-light ... Il manque plein de choses. Boost corrige un certain nombre de choses, mais on est encore très loin du compte.

Dans ce domaine le C et le C++ s'imposent parce qu'ils permettent d'aller vite, et sont (ou peuvent être) procéduraux (les algos sont généralement publiés dans un style très procédural), mais pas grâce à leur librairie mathématique...

Francois

[Invité]

Je parlais des problèmes de projecteuler.net, où ce sont des problèmes de calcul où le temps et la place sont restreintes. Bien sûr que pour ce genre de problèmes c'est le programmeur qui doit se débrouiller, je n'ai jamais dit le contraire.

Tu crois que c'est spécifique à l'informatique et absent des maths?

Un grand nombre d'algorithmes utilisés aujourd'hui ont été inventés, bien avant l'ordinateur, par des gens comme Gauss, ou Euler, qui devaient trouver des "trucs" pour réduire temps et espace, parce qu'ils faisaient leurs calculs à la main (essaie un jour de calculer à la main 10 décimales de pi, tu verras...)

J'ai regardé les premiers problèmes de Project Euler, pour un certain nombre je n'ai vu que des maths. En fait, sur les 10 premiers, je pense que les 1, 2, 5, 6, 8 et 9 doivent se résoudre en papier crayon, sans l'aide d'un ordi... (je vais d'ailleurs essayer, j'éditerai mes commentaires ici, mais je crois que l'idée générale des challenge, c'est qu'en commençant par poser les maths, on peut tenir la contrainte d'une minute...)

EDIT : et à la fin de la page de présentation, ils disent ca...

"Project Euler exists to encourage, challenge, and develop the skills and enjoyment of anyone with an interest in the fascinating world of mathematics."

Francois

[Goten]

Oh oui même au delà des 10 y'en a pas mal qui peuvent être fait au papier + crayon. Après y'en a qui font plus mal et qui nécessite la puissance de calcul de l'ordi forcément.

[Invité]

En fait, sur les premiers, l'ordi apparait souvent comme une "tentation". Prends l'exemple du 2... Il y a une solution papier crayon (et un coup de calculette ou d'excel), mais la tentation de programmer la somme est énorme.

Le 4 est encore pire, il y a (certainement) une solution élégante (en fait je suis certain d'avoir lu un truc là dessus, chez Knuth, je crois), sans elle, ce n'est pas faisable à la main... En revanche, pour un ordi, il y a 400 000 produits à tester, ca ne coute rien...

EDIT : le problème no4 est effectivement un excellent exemple de l'influence des maths sur l'algorithmique... Le but est de trouver le plus grand palindrome (nombre qui se lit pareil dans les deux sens, comme 123321) produit de deux nombres de 3 chiffres...

Sans réfléchir et bestialement, il suffit de tester tout les produits de 100*100 à 999*999 (en sens inverse, plutôt...), et on va trouver la solution.

Maintenant, on peut aussi refléchir sur les propriétés de ces nombres "palindromiques" (divisibilité et tout ca). Leur symétrie d'écriture se traduit forcément en propriétés mathématiques. Du coup, on va pouvoir réduire la recherche, et dans ce cas précis, résoudre le problème à la main (ici, on se ramène finalement à une quinzaine de multiplications...)

Maintenant, là ou les matheux gagnent toujours (en informatique) c'est quand la question est posée pour de plus grandes valeurs : par exemple, trouver le plus grand palindrome produit de deux nombres de 8 chiffres...

ReEdit : le problème de la semaine (no 254) est un excellent exemple de ce que j'essaie d'expliquer... Le calcul qu'on demande de faire n'est pas compliqué. Il s'agit de sommer une série, qui se calcule sommant deux fois les chiffres d'un nombre. En fait, la vérification de l'exemple qu'ils fournissent (valeur du 20eme terme de la série) est quasi immédiate quand on la programme. Oui mais, la somme des chiffres d'un nombre s'apparente à un logarithme, on le fait ici deux fois, ce qui signifie qu'une solution "force brute" s'apparente à une double exponentielle. Aucune astuce informatique ne pourra régler le problème, il faut impérativement faire ses maths avant de programmer.

Francois

[Issam_Lahlali]

Souvent, les algorithmes existent dans des livres avant d'exister comme du code. Les langages qui sont utilisés dans les livres (le Fortran autrefois, le C ensuite) ont un petit avantage sur les autres, car les auteurs des algorithmes, qui ont testé leurs idées dans ces langages, auront parfois utilisé certaines de leurs caractéristiques.

effectivement le C est peut être plus adapté vu l'existant , mais pour les algo je trouve que la grande difficulté est de trouver le bon algo pour une problématique donné que son implémentation,et pour cet avantage de C on peut faire de même en C++ aussi en bénéficiant de son caractère multi-paradigme.

et comme t'a bien mentionné le C++ s'en sort très bien pour les algo, nettement mieux que la majorité des nouveaux langages et c'est pas ce point qui joue en défaveur de C++ mais plus en défaveur des autres nouveaux langages.

En gros pour les algos le grand risque est dans la phase ou on utilise crayon et papier, des fois on conçoit un algo mal adapté a la problématique et on entre dans le piège de la démarche empirique ou a chaque fois on le réadapte par rapport aux bugs remontés et la on passe notre temps a faire de la maintenance.

et concrètement et quelque soit le langage d'ailleurs on zappe cette phase de crayon-papier et on commence par coder directement l'algo et au fur et a mesure on l'adapte par rapport aux cas mal traités ou par rapport aux performances et la on fait de l'empirique , et l'empirique en général engendre une usine a gaz puisqu'on fait patch sur patch.

[white_tentacle]

Et réussir à faire de l'optimal pour chaque cas particulier à partir d'un système générique, tu n'as pas l'impression qu'il y a comme un problème de conception à la base ?

En fait, il me semble que la C++ et la STL prévoient justement ça. La possibilité de spécialiser des templates, de spécifier l'allocateur est justement là pour ça. Autrement dit, tu peux faire du spécifique par dessus la couche générique, de manière totalement transparente.

Je suis aussi un peu étonné de l'exemple que tu as donné (vérification des débordements de tableau) puisque la STL ne le fait pas (sauf si tu lui demandes explicitement, par exemple, en utilisant at() plutôt que [] ).

[Matthieu Brucher]

Je suis aussi un peu étonné de l'exemple que tu as donné (vérification des débordements de tableau) puisque la STL ne le fait pas (sauf si tu lui demandes explicitement, par exemple, en utilisant at() plutôt que [] ).

En fait, rien n'indique dans la STL qu'il ne faut pas tester avec []. Dans la version sécurisée de la STL proposée par Visual Studio, il y a les mêmes vérifications avec [] qu'avec at().

[Alp]

En fait, rien n'indique dans la STL qu'il ne faut pas tester avec []. Dans la version sécurisée de la STL proposée par Visual Studio, il y a les mêmes vérifications avec [] qu'avec at().

Et quand ça rate, le debugger t'envoie dans CRT_Debug() ou je ne sais quoi, oui

[Mac LAK]

En fait, il me semble que la C++ et la STL prévoient justement ça. La possibilité de spécialiser des templates, de spécifier l'allocateur est justement là pour ça. Autrement dit, tu peux faire du spécifique par dessus la couche générique, de manière totalement transparente.

Mais on ne peut pas hériter d'une classe de la STL, et commencer à jouer avec les allocateurs me semble être franchement plus l'usine à gaz que quoi que ce soit d'autre...
De plus, cela ne supprimera pas le code générique des templates, or c'est surtout là-dessus qu'un algo maison "en dur" battra les algos génériques.

[koala01]

Mais on ne peut pas hériter d'une classe de la STL,

Tu ne peux pas hériter publiquement d'une classe de la STL..

et commencer à jouer avec les allocateurs me semble être franchement plus l'usine à gaz que quoi que ce soit d'autre...

Tu as une telle granularité dans politiques des conteneurs template qu'il t'est réellement possible de ne changer que le trait qui ne te convient pas

Il est vrai que, de manière classique, on ne travaille qu'avec le permier, mais c'est oublier un peu vite qu'il en existe trois autres derrière

De plus, cela ne supprimera pas le code générique des templates, or c'est surtout là-dessus qu'un algo maison "en dur" battra les algos génériques.

Définis le comportement de ton trait "maion" correctement et utilise le dans la déclaration de ton conteneur, ce ne sera plus le code générique qui sera utilisé, mais celui de ton trait maison

[Invité]

En fait, il me semble que la C++ et la STL prévoient justement ça. La possibilité de spécialiser des templates, de spécifier l'allocateur est justement là pour ça. Autrement dit, tu peux faire du spécifique par dessus la couche générique, de manière totalement transparente.

Pour les conteneurs seulement, et seulement si l'amélioration maison porte sur le stockage et l'allocation... Si tu as besoin d'une version particulière d'un algo (un tri adapté à un cas particulier, pour citer un exemple banal), ou d'une modification de structure d'un conteneur qui impacte également ses "fonctions de base" (toutes modifications des maps ou des sets, je pense). T'es un rien coincé.

D'ailleurs, la STL ne prétend pas le contraire, tous ses auteurs expliquent qu'elle fournit "de bonnes implémentations de méthodes standard", mais pas "les meilleures méthodes".

Francois

[white_tentacle]

En fait, rien n'indique dans la STL qu'il ne faut pas tester avec []. Dans la version sécurisée de la STL proposée par Visual Studio, il y a les mêmes vérifications avec [] qu'avec at().

Son contrat te dit que c'est interdit d'appeler [] hors bornes. Ça laisse fortement présager que ça ne doit pas être testé par l'appelé, mais par l'appelant, d'autant plus qu'il y a une méthode at() qui elle, teste dans l'appelé.

Pour les conteneurs seulement, et seulement si l'amélioration maison porte sur le stockage et l'allocation... Si tu as besoin d'une version particulière d'un algo (un tri adapté à un cas particulier, pour citer un exemple banal), ou d'une modification de structure d'un conteneur qui impacte également ses "fonctions de base" (toutes modifications des maps ou des sets, je pense). T'es un rien coincé.

si tu spécialises std::map<MonType>, tu fais bien ce que tu veux, non ? (ça revient effectivement à tout refaire en spécifique, j'en conviens, mais ça a l'avantage de pouvoir être fait de manière transparente, sans revoir tout le code, et après coup, une fois que tu as identifié par profilage où il faut optimiser).

[Mac LAK]

Tu ne peux pas hériter publiquement d'une classe de la STL..

Ils ont rajouté le "virtual" qui va bien devant le destructeur, pour l'héritage ?
Jusqu'à présent, une classe de STL, soit j'en hérite en rajoutant de nouvelles méthodes, soit je l'encapsule, mais l'héritage "tel quel" est plus que déconseillé, si je me souviens bien, rapport au destructeur non virtuel...

Tu as une telle granularité dans politiques des conteneurs template qu'il t'est réellement possible de ne changer que le trait qui ne te convient pas

Je ne sais pas si j'ai été bien clair, mais le problème d'optimisation n'est pas dans les arguments du template, mais dans le CODE des MÉTHODES du template... Pas réellement dans le "T.push_back()" appelé, si tu préfères, mais dans le fait que l'on aie auparavant un truc du genre "if (T.full()) throw ....".

Si l'on en vient à devoir surcharger et/ou réécrire quasiment chaque méthode du template, et/ou construire un trait ultra-spécifique et dépendant de l'implémentation de la STL, tu n'as pas l'impression que c'est nettement moins maintenable qu'un code maison ?

[3DArchi]

Ils ont rajouté le "virtual" qui va bien devant le destructeur, pour l'héritage ?

Si tu fais un héritage privé, alors tu ne pourras pas le manipuler comme la classe de base. Donc le destructeur peut ne pas être virtuel :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
struct A
{};
struct B : private A
{
};
 
int main()
{
   A *pa = new B;//erreur
}

error: 'A' is an inaccessible base of 'B'

'cast de type'*: la conversion de 'B *' en 'A *' existe, mais n'est pas accessible