Pourquoi la communauté C++ s'intéresse plus à la technique et ignore la conception?

Version imprimable

Voir 40 message(s) de cette discussion en une page

01/09/2009, 17h54
Alp

Citation:

Envoyé par white_tentacle

tant que tu n'as pas appris à les lire, ils sont horribles

Tu mets le doigt sur le problème. La mode aujourd'hui pour les développeurs c'est d'avoir le beurre et l'argent du beurre... D'avoir la simplicité de développement sans se prendre la tête à apprendre des choses :aie:
01/09/2009, 17h56
Goten

Dans ce cas autant changer de métier :/
01/09/2009, 17h59
Alp

Citation:

Envoyé par Goten

Dans ce cas autant changer de métier :/

Hélas, je vois vraiment beaucoup de gens qui sont comme ça, aujourd'hui. Après on demande pas aux gens d'avoir le niveau de Abrahams & compagnie, mais un minimum quoi...
01/09/2009, 18h04
MenshaKaine

Citation:

Envoyé par loufoque

Après j'ai bien compris que sur le marché français, les templates c'est considéré comme étant une technologie expérimentale risquée. Si la France a réputation d'avoir 10 ans de retard en développement et en génie logiciel, ce n'est pas pour rien...

J'aime beaucoup ton message. Et je suis fortement d'accord avec la citation au dessus car je l'ai expérimenté lors de la majorité de mes entretiens.

Après je ne pense pas qu'on arrivera à trouver une réponse synthétique à la question de cette discussion.

De mon côté je m'intéresse autant à la technique qu'à la conception. Les deux sont pour moi très importante dans notre métier.

ps: Et pour l'histoire du public, je suis d'accord, on conçoit au cas par cas les classes. C'est juste que cette expérience m'avait choqué: on pouvait à la fin remplacer partout class par struct !
01/09/2009, 18h09
Invité

Citation:

Envoyé par loufoque

La programmation à base de copier/coller, franchement, je crois qu'on fait difficilement pire.

C'est juste un slogan, ça... Un #include, l'utilisation d'une librairie externe, un patch, une gestion de version, c'est quoi, sinon un copier-coller?

Sur les messages d'erreur, il me semble qu'on ne peut à la fois vanter le fait que le C++, grâce à la généricité, rend le code plus concis et élégant (et donc facile à maintenir), mais en même temps trouver normaux les affreux messages des templates, qui rendent la mise au point de ce code très désagréable. Mais bon, c'est l'affaire de quelques versions de compilateurs, je pense. Je me souviens d'un temps où les messages d'erreur des compilateurs C étaient presque toujours incompréhensibles...

Francois
01/09/2009, 18h16
Issam_Lahlali

Citation:

Envoyé par Matthieu Brucher

C'est bien plus vaste que ça, mais bon...
Dans ces domaines là, tu ne penses pas que la couche "métier", c'est autre chose que ce que tu dis ? Encore une fois, je fais référence à la première correction que j'ai faite sur ton terme "métier". Pour moi, le métier, c'est justement ce qui est primordial, ce qui ne va pas forcément être récupérable à l'extérieur. Dans ce cas, c'est quoi l'utilité de faire une abstraction là-dessus ? Le métier, c'est la plus value de l'application dans l'entreprise, ce n'est pas en passant de MySQL à Oracle que ton entreprise va gagner des millions d'euros, mais en passant d'un algorithme de résolution numérique à un autre, on peut gagner des millions, voire des milliards. Et là, la couche d'abstraction, on s'en fout, on n'en veut pas car on doit rester proche du matériel, tout en étant super haut-niveau.

La seule vision que tu as, c'est la vision informatique de gestion de bureau, mais tu crois sincèrement que c'est tout ce qui existe dans le monde ?

sincèrement on a le même point de vue mais je ne sais pas comment tu comprends mes messages :)

moi aussi je m'en fout de passer par MySQL ou oracle , et justement comme tu le dis il faut ce concentrer sur la vrai valeur ajoutée ce que je ne cesse de répéter tout le temps.

et je remarque qu'on passe beaucoup de temps en technique plus qu'il ne faut or c'est pas la vrai valeur ajoutée et c'est pour cela que je préconise a chaque fois de faire abstraction a toute complexité technique pour que tout les développeurs se concentre sur le métier.

prenons par exemple le cas StartWith avec std::string, on remarque qu'on l'a pas mais c'est pas ça le probléme, et on l'utilise beaucoup et dans ce cas il faut faire une abstraction a cette méthode et la coder une fois pour toute, au lieu que chacun fait sa propre version et on aura que du copier/coller qui traine.

donc finalement j'ai le même but que toi se concentrer plus sur le métier qui est la vrai valeur ajoutée et pour ça a mon avis il faut simplifier la couche technique pour éviter que tout les développeurs perdent leur temps sur un truc qui n'a pas une grande valeur ajoutée.

Citation:

Envoyé par Mac LAK

Avant de poursuivre dans cette optique, veux-tu bien aller sur cette page, ainsi que sur ce sujet, et lire les documentations de chaque librairie présentée, s'il te plait ?

prenons par exemple les sockets avec ce cours de ce site http://c.developpez.com/WalrusSock/ qui est trés bien d'ailleurs ca explique bien les sockets.

mais est ce que tu crois que je vais passer mon temps avec des trucs comme
Code:

1 2 3 WSADATA WSAData; WSAStartup(MAKEWORD(2,0), &WSAData);
ou genre
Code:

1 2 3 4 5 6 7 8 SOCKET sock; SOCKADDR_IN sin; sin.sin_addr.s_addr = inet_addr("127.0.0.1"); sin.sin_family = AF_INET; sin.sin_port = htons(4148); sock = socket(AF_INET,SOCK_STREAM,0); bind(sock, (SOCKADDR *)&sin, sizeof(sin));
la première chose que je vais faire est créer une classe très basique qui contient Open, Send , Receive et Close comme ça on cache toute la logique bas niveau et le développement avec les sockets devient un pur bonheur :)

et on peut généraliser ça sur toute fonctionnalité technique ou on répète les mêmes choses a chaque fois.

Citation:

Envoyé par Issam_Lahlali

sincèrement on a le même point de vue mais je ne sais pas comment tu comprends mes messages :)

On a peut-être le même point de vue, mais ça ne se voit pas, la preuve avec le message suivant.
Citation:
Envoyé par Issam_Lahlali
prenons par exemple les sockets avec ce cours de ce site http://c.developpez.com/WalrusSock/ qui est trés bien d'ailleurs ca exoplique bien les sockets.

mais est ce que tu crois que je vais passer mon temps avec des trucs comme
Code:

1 2 3 WSADATA WSAData; WSAStartup(MAKEWORD(2,0), &WSAData);
ou genre
Code:

1 2 3 4 5 6 7 8 SOCKET sock; SOCKADDR_IN sin; sin.sin_addr.s_addr = inet_addr("127.0.0.1"); sin.sin_family = AF_INET; sin.sin_port = htons(4148); sock = socket(AF_INET,SOCK_STREAM,0); bind(sock, (SOCKADDR *)&sin, sizeof(sin));
la première chose que je vais faire est créer une classe très basique qui contient Open, Send , Receive et Close comme ça on cache toute la logique bas niveau et le développement avec les sockets devient un pur bonheur :)

et on peut généraliser ça sur toute fonctionnalité technique ou on répète les mêmes choses a chaque fois.
Sauf que si une bibliothèque de socket permet cela, c'est qu'il y a une raison. Toi, tu n'en as pas l'utilité en informatique de gestion, mais le gars qui fait une bibliothèque de jeu en aura peut-être l'utilité.
Bref, tu occultes tout l'informatique qui ne te concerne pas et tires des conclusions à côté de la réalité.

[HS]Désolé, je suis énervé à cause d'UPS qui n'est même pas capable de téléphoner quand il y a un problème, ou plutôt si, 6 heures plus tard.[/HS]

01/09/2009, 18h45
Issam_Lahlali

Citation:

Envoyé par Matthieu Brucher

On a peut-être le même point de vue, mais ça ne se voit pas, la preuve avec le message suivant.

Sauf que si une bibliothèque de socket permet cela, c'est qu'il y a une raison.

encore une fois une incompréhension:) je ne veux pas virer la bibliothèque socket ou dire que c'est mal fait.

elle est generique et c'est normale de se taper 10 lignes pour créer une socket, mais il faut pas dire c'est normale et laisser tout les développeurs se taper les 10 lignes ou faire du copier/coller.

il faut leur simplifier la vie de ce point de vue pour ce concentrer sur le métier, et pour cette affaire d'application de gestion mon diplôme de base est en automatique et j'ai travailler sur de gros projet industriels avant de faire d'autres non industriels et en plus non orienté gestion :)
01/09/2009, 18h46
Matthieu Brucher

Alors qu'est-ce qui te pose problème dans Boost.asio ?
01/09/2009, 18h46
Mac LAK

Citation:

Envoyé par Issam_Lahlali

prenons par exemple les sockets avec ce cours de ce site http://c.developpez.com/WalrusSock/ qui est trés bien d'ailleurs ca explique bien les sockets.

Ce qui ne répond donc absolument pas à la question que j'ai posée, et montre (par exemple) que tu n'as même pas jeté un oeil sur la librairie ICE...
01/09/2009, 18h56
loufoque

Citation:

C'est juste un slogan, ça... Un #include, l'utilisation d'une librairie externe, un patch, une gestion de version, c'est quoi, sinon un copier-coller?

Un copier/coller, c'est du code dupliqué.
Justement, les macros permettent d'éviter la duplication de code plus que les templates, en faisant le copier/coller à ta place, mais il faut bien savoir décerner ce qu'il faut généraliser, sinon on tombe dans un gros bordel.

À propos de bordel, ce sujet en est un incroyable. On a atteint un nouveau record dans le nombre de pages non ?
01/09/2009, 18h56
metagoto

Citation:

Envoyé par loufoque

Après j'ai bien compris que sur le marché français, les templates c'est considéré comme étant une technologie expérimentale risquée. Si la France a réputation d'avoir 10 ans de retard en développement et en génie logiciel, ce n'est pas pour rien...

C'est vrai ça, la réputation des 10 ans de retard ?

En tant que simple observateur extérieur, au grès de mes pérégrinations sur le net depuis plusieurs années, j'ai remarqué que les "français" sont forts en maths. Là je parle du très haut niveau. J'ai aussi l'impression qu'ils sont forts en informatique théorique (encore une fois, l'aspect mathématique mais aussi dans des domaines tels que les conséquences des théories quantiques (cryptographie etc)).
Alors comment expliquer cette réputation ? (si se n'est qu'on ne trouve pas un département à la INRIA dans chaque université).
01/09/2009, 18h59
Mac LAK

Citation:

Envoyé par loufoque

Ce que tu n'as pas l'air de comprendre, c'est que C++ te permet de définir un langage spécifique à un domaine particulier.

Un "langage" ? Tu en as la grammaire ? :twisted:

Comprends bien quelque chose : oui, c'est possible. Et oui, c'est laid, quoi que tu en dises : c'est difficilement maintenable par rapport à un interpréteur Python "câblé" dans ton programme C++, ou LUA, ou JavaScript, et qui, lui, sera réellement adaptable par ton client sans devoir tout recompiler.

Il aura des fonctions métier, un "bac à sable" ne risquant donc pas de lui péter à la tête et il est totalement affranchi des contraintes techniques et/ou d'une maîtrise importante du langage C++. Je te rappelle que 99% des clients se contrefichent de savoir COMMENT tu l'as réalisé, tant que ça marche bien, que ça répond à leur besoin et qu'ils peuvent faire leur partie métier tranquillement.
Et en terme de temps de développement, je suis loin d'être persuadé que le faire en C++ soit plus rapide que de coupler un interpréteur à une "librairie métier", pour assurer les mêmes fonctionnalités au final.

Parce que quoi que tu fasses, C++ reste compilé, et des fonctions comme "eval()", courantes en langages interprétés (et franchement pratiques), restent impossibles à faire sans appeler un compilateur C++ à la volée...
Et si le but est de réécrire un langage de script à base de templates, autant câbler directement un interpréteur tout prêt : t'as largement plus de chances de ne pas déstabiliser l'utilisateur final en lui faisant apprendre un langage supplémentaire, alors qu'il maîtrise sûrement déjà quelque chose d'approchant (script Python/LUA, Grafcet, etc.).

Encore une fois : ce n'est pas parce qu'un langage permet de faire quelque chose (ou que quelque chose est réalisable avec ce langage) que c'est forcément souhaitable et/ou optimal de le faire. Et C++ n'échappe pas à la règle.
01/09/2009, 19h02
Issam_Lahlali

Citation:

Envoyé par Matthieu Brucher

Alors qu'est-ce qui te pose problème dans Boost.asio ?

Citation:

Envoyé par Mac LAK

Ce qui ne répond donc absolument pas à la question que j'ai posée, et montre (par exemple) que tu n'as même pas jeté un oeil sur la librairie ICE...

pour boost.asio voila ce qui confirme ce que je dis http://www.boost.org/doc/libs/1_40_0...ion/server.cpp

ou tu trouve 3 classes ou dans le commentaire on voit bien le mot clé Wrap pour cacher la complexité de l'utilisation et pour simplifier.

ce qui est normal puisque toutes les librairies sont en general generiqe et forcement a un moment on va se taper a chaque fois qlq lignes repetitifs pour un besoin donné et il faut avoir le reflexe d'avoir des wrappers comme dans l'exemple de boost.asio.

mais si on considère que c'est très simple sans passer par wrapper c'est un choix a respecter mais il faut assumer les dégâts du aux Copier/Coller.
01/09/2009, 19h06
loufoque

Ce retard dont je parlais c'est dans le privé, et c'est par rapport aux États-Unis (qui est un peu le leader de l'industrie de l'informatique). Le transfert technologique a aussi plus de mal à se faire qu'au Royaume-Uni à cause de la barrière de la langue.

Enfin tout de même, ça dépend vachement des entrerprises. Il y a pas mal qui ont beaucoup de retard, mais certaines en ont relativement peu.
01/09/2009, 19h15
Mac LAK

Citation:

Envoyé par Issam_Lahlali

pour boost.asio voila ce qui confirme ce que je dis http://www.boost.org/doc/libs/1_40_0...ion/server.cpp

Et tu n'as donc toujours pas regardé ce que proposait ICE...
01/09/2009, 19h17
loufoque

Citation:

Un "langage" ? Tu en as la grammaire ?

La grammaire, c'est à toi de la créer.
(Enfin il faut qu'elle soit construite au dessus de celle des expressions de C++ quand même)

Citation:

c'est difficilement maintenable par rapport à un interpréteur Python "câblé" dans ton programme C++, ou LUA, ou JavaScript, et qui, lui, sera réellement adaptable par ton client sans devoir tout recompiler.

Ce sont des besoins différents.
Un DSEL c'est en particulier utilisé pour générer du code performant, en particulier pour la vectorisation, la programmation parallèle, la génération d'un parser...
Un intérpréteur c'est fait pour embarquer un comportement dynamique flexible, c'est totalement différent.

Citation:

des fonctions comme "eval()", courantes en langages interprétés (et franchement pratiques)

Ce style de programmation est plutôt déconseillé.
01/09/2009, 19h24
Issam_Lahlali

Citation:

Envoyé par Mac LAK

Et tu n'as donc toujours pas regardé ce que proposait ICE...

je croyais que j'étais clair lorsque j'ai parler de boost.asio et pour ICE j'en ai déjà fait avant avec TAO dans le cadre de choix d'une solution pour le distribué et ICE c'est pas en doc ou en théorie que j'ai lu , je l'est pratiqué et a chaque fois on essayait de faire l'abstraction dés que possible pour laisser toujours l'utilisation très facile.

et sincerement lorsqu'on lit une doc ou on fait de la theorie c'est pas la meme chose que pratiquer, par exemple pour ICE ou toute solution pour le distribué il y a plusieurs services a prendre en compte :

naming service,event service,notification service, property service, reprise ainsi de suite, et dans ce cas va utiliser les classes de base de ICE ou n'importe quelle autre librairie et je te raconte pas la galère ou tu demandera a tout les développeurs de connaitre toutes les subtilités , par contre dans des projets ou j'ai travailler ou on bosse avec ce type de librairie avec plus que de 100 développeurs je t'assure que juste 4 développeurs qui était concerné par cette librairie et tous les autres il ne savait même pas ce qui se passe derrière, qu'on utilise ICE ou TAO ou Orbacus et c'est très bénéfique.

et encore une fois toute librairie technique est générique et c'est tout a fait normal c'est aux développeurs de créer leur boite a outil autour de ces librairies pour leur besoin pour faciliter le dev.

et autre chose pas toutes les boites ont les compétences ou les connaissances pour choisir la librairie idéale pour leur besoin, sinon cette discussion n'aura pas lieu mais le conseil quelque soit le choix qu'on fait est :
essayer de cacher au maximum toute complexité technique.
01/09/2009, 20h59
white_tentacle

Y a quand même un truc où je ne comprends plus rien à la logique de ce que tu racontes.

Tu défends les frameworks "tout faits" façon .NET/Java, qui ne présentent pas de grande difficulté technique.

Mais tu défends le fait qu'il faille wrapper toute librairie utilisée pour masquer sa complexité. Et quand on te répond que s'il faut masquer la complexité de la librairie, c'est probablement parce que la librairie est (au choix) inadaptée ou mal faite, tu t'obstines à défendre le fait qu'il faut la wrapper.

Ça ne te semble pas un peu contradictoire, tout ça ?
01/09/2009, 21h27
Issam_Lahlali

Citation:

Envoyé par white_tentacle

Y a quand même un truc où je ne comprends plus rien à la logique de ce que tu racontes.

Tu défends les frameworks "tout faits" façon .NET/Java, qui ne présentent pas de grande difficulté technique.

Mais tu défends le fait qu'il faille wrapper toute librairie utilisée pour masquer sa complexité. Et quand on te répond que s'il faut masquer la complexité de la librairie, c'est probablement parce que la librairie est (au choix) inadaptée ou mal faite, tu t'obstines à défendre le fait qu'il faut la wrapper.

Ça ne te semble pas un peu contradictoire, tout ça ?

effectivement je défends les deux et je m'explique:

je défends les frameworks genre DotNet et java c'est vrai mais l'historique en C++ fait qu'on a pas une telle librairie dans le sens qu'elle est homogène et regroupe la majorité de nos besoins techniques.

et je suis pour simplifier la couche technique quelque soit le langage, C++,C# ou java ou autre, par exemple et pour être concret pour un projet dont j'ai assister qui utilise le WCF de dotnet, des classes très simples ont était proposer aux développeurs pour leur faciliter la vie et ne pas se soucier des détails de WCF et crois moi il y en a énormément.

mais pour les développeurs dotnet ou java ils acceptent facilement cette idée de leur faciliter la vie, par contre en C++ il y a une résistance pour une telle démarche et ça se voit d'ailleurs dans ce topic :).

Citation:
Envoyé par Issam_Lahlali
prenons par exemple les sockets avec ce cours de ce site http://c.developpez.com/WalrusSock/ qui est trés bien d'ailleurs ca explique bien les sockets.

mais est ce que tu crois que je vais passer mon temps avec des trucs comme
Code:

1 2 3 WSADATA WSAData; WSAStartup(MAKEWORD(2,0), &WSAData);
ou genre
Code:

1 2 3 4 5 6 7 8 SOCKET sock; SOCKADDR_IN sin; sin.sin_addr.s_addr = inet_addr("127.0.0.1"); sin.sin_family = AF_INET; sin.sin_port = htons(4148); sock = socket(AF_INET,SOCK_STREAM,0); bind(sock, (SOCKADDR *)&sin, sizeof(sin));
la première chose que je vais faire est créer une classe très basique qui contient Open, Send , Receive et Close comme ça on cache toute la logique bas niveau et le développement avec les sockets devient un pur bonheur :)

et on peut généraliser ça sur toute fonctionnalité technique ou on répète les mêmes choses a chaque fois.
Sans être un expert, je pense que c'est l'utilisation des sockets prévue dans l'API windows en C. Si on ne veut pas descendre si bas (ce qui me semble tout à fait raisonnable et compréhensible), il existe sans doute une floppée de classes C++ permettant de faire du socket de façon plus confortable avec un joli objet gérant l'asynchrone etc...

C'est je suppose la voie qui sera préconisée dans un grand nombre de projet. Autre exemple de ce genre, créerais-tu une boîte de dialogue avec la méthode Winapi et sa boucle d'évènement, ou utiliserais-tu une surcouche tels que les MFC?

Dans un développement, je pense que nous sommes tous d'accord ici pour dire qu'il ne faut pas aller plus bas que nécessaire et se reposer, lorsque cela est possible, sur des libs de plus haut niveau éprouvées, afin de ne pas réinventer la roue.

Ce qui m'intéresserait par rapport à ce débat, même si j'ai du mal à en saisir la matière exacte, est de savoir si cette action de *wrapper* ou plutôt cacher les détails de l'implémentation se fait

1) par volonté de simplification : Tu utilises une librairie comme ce qui est proposé par boost ou QT afin de ne pas avoir les mains dans certaines API quasiment de niveau OS.
2) pour camoufler l'usage d'une librairie : Tu ne veux pas que ton code utilise directement des librairies telles que boost ou QT pour avoir la liberté de les remplacer.

Alors ? La motivation première c'est quoi?

01/09/2009, 21h44
Invité

Citation:

Envoyé par metagoto

C'est vrai ça, la réputation des 10 ans de retard ?

Probablement pas. Sur un marché ouvert, international et évolutif comme l'informatique, si les entreprises françaises avaient 10 ans de retard, elles auraient disparu il y a longtemps.

Quant à l'état de l'art, comme toujours, ça dépend des secteurs, l'informatique n'est pas un domaine homogène. Les USA investissent beaucoup plus que la France (ou l'Europe) en recherche appliquée (ici, pas mal de gens semblent considérer que la recherche *doit* être inutile), et la création d'entreprise y est favorisée (par le système économique et la taille du marché). Alors, dans les domaines de type "start up", ils sont bien plus dynamiques.

Sur des sujets plus scientifiques, d'ingéniérie, ou dans des créneaux ou l'industrie française est traditionnellement bien positionnée (télécoms), c'est l'inverse. Dans mon secteur, l'amérique et l'asie sont affreusement en retard, et l'europe occidentale domine.

Ca dépend, quoi...

Francois
01/09/2009, 21h44
Issam_Lahlali

Citation:

Envoyé par _skip

Ce qui m'intéresserait par rapport à ce débat, même si j'ai du mal à en saisir la matière exacte, est de savoir si cette action de *wrapper* ou plutôt cacher les détails de l'implémentation se fait

1) par volonté de simplification : Tu utilises une librairie comme ce qui est proposé par boost ou QT afin de ne pas avoir les mains dans certaines API quasiment de niveau OS.

2) pour camoufler l'usage d'une librairie : Tu ne veux pas que ton code utilise directement des librairies telles que boost ou QT pour avoir la liberté de les remplacer.

Alors en gros?

les deux et pour le premier point même si t'utilise boost ou Qt ou n'importe quelle librairie haut niveau , il faut penser a faire abstraction a chaque fois si c'est nécessaire, si tu vois l'exemple dont j'ai parler plus haut de boost.asio ou même dans les exemples des créateurs de boost on fait des wrappers pour simplifier l'utilisation.

et le message est simple et claire :

la majorité des librairies techniques ne peuvent pas coller a ton besoin exacte au niveau simplicité d'utilisation, et c'est normale toute librairie technique est générique puisqu'elle est censé adresser énormément de besoins, et il faut penser a créer une boite a outil pour d'une part simplifier et d'autre part protéger les changements de librairies a cause d'un changement des specs qui est monnaie courante dans notre métier.

et je ne comprends pas toute cette résistance pour une idée aussi simple que simplifier :) soit tout est simple ,soit tout le monde est expert,et je crains que ni l'une ni l'autre n'est vrai.

et comme info pendant toute mon experience en C++ il y avait toujours existante d'une équipe framework technique qui fournit des classes pour simplifier la vie aux développeurs, et le soft de ces boites marche trés trés bien et en plus c'est des éditeurs de logiciels internationals pas des SSII qui font tout et n'importe quoi.

peut être tout ce monde n'ont rien compris et ils perdent leur temps avec ce framework mais en pratique ça marche très très bien.

et sincèrement je suis quelqu'un terre a terre , je ne comprends pas trop la philosophie mais je me fie a ce que j'apprends au niveau pratique et cette démarche je l'est appris en pratique et j'ai vu ces avantages surtout pour les moyens et grands projets.
01/09/2009, 23h11
gl
Citation:

Envoyé par Issam_Lahlali

prenons par exemple les sockets avec ce cours de ce site http://c.developpez.com/WalrusSock/ qui est trés bien d'ailleurs ca explique bien les sockets.

Citation:

Envoyé par Issam_Lahlali

la première chose que je vais faire est créer une classe très basique qui contient Open, Send , Receive et Close comme ça on cache toute la logique bas niveau et le développement avec les sockets devient un pur bonheur :)

Les sockets BSD sont effectivement un élément qui s'encapsule très bien dans une couche de plus haut niveau, ils ont en effet une granularité très fine qui n'est pas nécessaire pour la plupart des applications.

Juste quelques remarques sur ta proposition :
- Une API aussi simple que celle que tu proposes à :
  - Soit de forte chance d'être propre à une application voire à certaines connexions au sein de cette application (sauf si toutes les applications en question ne sont qu'une variation sur le même thème), ce qui est contradictoire avec ton souhait initial d'une API simple et commune.
  - Soit l'API est commune à différente implémentations qui sont intrinsèquement différentes (et je ne parle pas des différences purement techniques dont on cherche à s'abstraire comme le type de connexion, mais bien de différence plus fonctionnelles comme la définition de la fin d'une trame).
  - Soit l'API dispose de peu de fonctions mais de très nombreux paramètres, ce qui ne fait que déplacer la "difficulté".
- Si tu cherches à simplifier la vie des utilisateurs de ton API, tu devrais t'intéresser au RAII qui te permettrait de ne pas avoir à appeler Open() et Close().
- Dans un projet un minimum complexe (mis à part les applications réseau ou d'autres cas où les sockets sont au cœur de l'application), l'utilisation des sockets est restreinte à certains modules qui gèrent le protocole applicatif et la problématique connexion et présentent une API axée "protocole applicatif" au reste de l'application. Au final, peu de personnes dans le projet vont avoir à utiliser les sockets.
En outre, concernant la méthode : plutôt que de re-développer une classe réseau, il faudrait regarder ce qui existe par ailleurs.
D'autant que les sockets BSD sont très répandus et devenus un standard de fait et qu'il existe de nombreuses bibliothèques de socket haut niveau très répandues et utilisées, il est donc assez facile de trouver des personnes sachant utilisées correctement ces APIs contrairement à ta classe personnelle dont les tenants et aboutissants ne sont au final connus que des quelques personnes ayant implémentées cette classe. C'est également un paramètre à prendre en compte et il faut voir si le gain apporté par l'apparente simplicité de ta classe compense cet avantage.

Citation:

Envoyé par Issam_Lahlali

et je ne comprends pas toute cette résistance pour une idée aussi simple que simplifier :) soit tout est simple ,soit tout le monde est expert,et je crains que ni l'une ni l'autre n'est vrai.

Mais encore une fois, personne n'a prétendu ici que le C++ est trivial ou que tout le monde est expert.
Ce qu'on cherche à te dire c'est, entre autre, que :
- Les autres langages ne sont pas non plus triviaux.
- La principale difficulté n'est pas forcément dans le fait d'avoir de nombreuses fonctions dans une API ou différentes APIs pour adresser le même segment technique.
- Que tu n'es pas obligé d'utiliser systématiquement tous les mécanismes/paradigmes/subtilités du langage.
- Que cette relative difficulté est le pendant de ce qui fait la puissance et un des principaux intérêts du C++.
Citation:

Envoyé par Issam_Lahlali

et comme info pendant toute mon experience en C++ il y avait toujours existante d'une équipe framework technique qui fournit des classes pour simplifier la vie aux développeurs, et le soft de ces boites marche trés trés bien et en plus c'est des éditeurs de logiciels internationals pas des SSII qui font tout et n'importe quoi.

peut être tout ce monde n'ont rien compris et ils perdent leur temps avec ce framework mais en pratique ça marche très très bien.

Mais là encore, personne n'a dit qu'il ne fallait pas faire de bibliothèque/framework haut niveau et générique. Par contre :
- Il est quasi-impossible de faire un framework haut niveau, simple d'utilisation et adressant tous les cas d'utilisation.
- Il faut étudier les conséquences, peser les avantages et inconvénients et éventuellement faire des tests/bench/maquettes avant de se précipiter sur un framework.
- Parfois ils sont inutiles voire néfastes ou inutilisables.
- Pourquoi ne pas utiliser des bibliothèques déjà répandues et donc éprouvées et debuggées (Boost, POCO, ICE, ACE, etc.) plutôt que de refaire un framework maison, peut être plus simple d'apparence mais probablement moins souple et moins robuste.
Comme l'a signalé, entre autres, Matthieu Brucher, il n'y a pas qu'un axe, qu'un paramètre à prendre en compte mais plusieurs.
Au final, le niveau d'abstraction, les bibliothèques et framework à utiliser, les critères importants, etc. sont à voir au cas par cas.
01/09/2009, 23h24
gl
Citation:

Envoyé par Matthieu Brucher

Dans le GoF, ils sont séparés en 3 grandes catégories, selon ce qu'ils font. Adapteur et façade sont proches, mais l'un travaille sur une classe, l'autre travaille sur plusieurs classes.

C'est réellement la seule différence ?

J'avais compris que la différence était plus dans l'intention :
- Le premier était à utiliser lorsque le client attendait une interface et que la classe en fournissait une autre.
- Le second permettait de masquer une ou plusieurs classes derrière une interface unifiée.
Ce qui laisse certains "cas limites" (normalisation d'interface à priori par exemple) dans une zone de flou.
Avec la différence que tu cites, il est effectivement plus de simple de cataloguer les constructions dans une catégorie ou dans l'autre, mais ça me semble assez artificielle comme différenciation.
01/09/2009, 23h29
Mac LAK

Citation:

Envoyé par Issam_Lahlali

et sincerement lorsqu'on lit une doc ou on fait de la theorie c'est pas la meme chose que pratiquer, par exemple pour ICE ou toute solution pour le distribué il y a plusieurs services a prendre en compte :

Je pratique aussi ICE, et au "maximum" ou presque : utilisation de IceGrid / IceBox pour la gestion centralisée des endpoints, génération automatique multi-langage par Slice à partir de modules ICE les plus simples possibles (à peu près ce que tu demandes comme fonctions exposées), utilisation des divers modules comme IceStorm pour les publications asynchrones, IcePatch pour la mise à jour / déploiement, etc. En gros, à part les facettes (on verra à la prochaine version de notre produit, si l'on a besoin de faire évoluer les interfaces ou pas) et les communications SSL (réseau privé, on s'en fiche donc), j'utilise TOUTE la librairie ICE...

Cela fait exactement ce que tu demandes (en lieu et place des sockets), avec un niveau d'abstraction librement décidable (c'est toi qui décide de l'interface des classes ICE), sans se fader la "technique" comme tu dis dès que tu te mets à utiliser un réseau ICE. De plus, y compris en se limitant à la boucle locale, cela permet un transfert de données entre différents langages d'une façon extrêmement simple tout en restant efficace : il n'y a guère qu'avec un wrapper comme SWIG que l'on peut avoir de meilleures performances, mais sans la notion de système déporté inhérente à ICE.

On peut légitimement se demander si tu as vraiment compris comment utiliser une telle librairie, ou si tu l'as réellement testée / évaluée... Car c'est exactement ce que tu demandes, axé réseau. Côté système, tu as POCO qui est du même ordre de généricité / abstraction, pour info.

Avec une telle librairie "réseau" et une telle librairie "système", toutes deux franchement très bien faites et très bien documentées (surtout par rapport à ACE...), génériques et découplées de la "technique", tu peux nous dire ce qu'il te manque réellement, au final ?
01/09/2009, 23h50
metagoto

Citation:

Envoyé par fcharton

Probablement pas. Sur un marché ouvert, international et évolutif comme l'informatique, si les entreprises françaises avaient 10 ans de retard, elles auraient disparu il y a longtemps.

Quant à l'état de l'art, comme toujours, ça dépend des secteurs, l'informatique n'est pas un domaine homogène. Les USA investissent beaucoup plus que la France (ou l'Europe) en recherche appliquée (ici, pas mal de gens semblent considérer que la recherche *doit* être inutile), et la création d'entreprise y est favorisée (par le système économique et la taille du marché). Alors, dans les domaines de type "start up", ils sont bien plus dynamiques.

Sur des sujets plus scientifiques, d'ingéniérie, ou dans des créneaux ou l'industrie française est traditionnellement bien positionnée (télécoms), c'est l'inverse. Dans mon secteur, l'amérique et l'asie sont affreusement en retard, et l'europe occidentale domine.

Ca dépend, quoi...

Effectivement pour les telecoms à propos du retard des US.

Et sinon pour ce qui est du génie logiciel, il me semble que c'est l'Inde qui s'accapare une majorité de contrats de nos jours. Les boîtes sont internationales mais les ingés et les devs sont indiens. Business as usual :mrgreen:

Pour ce qui est des langages de programmation, sans trop y réfléchir, j'ai l'impression que pratiquement tous les plus populaires à l'heure actuelle ont été inventés sur le territoire US... dans les années 70-90. Il faudrait que je fasse une recherche (et des beaux graphiques avec des drapeaux et tout :ccool:)
02/09/2009, 00h09
gl

Citation:

Envoyé par Mac LAK

Côté système, tu as POCO qui est du même ordre de généricité / abstraction, pour info.

Juste une petite précision, POCO ne se limite pas au côté système, elle propose également des choses intéressante côté database et XML (respectivement module Data et XML) et également réseau (module NET), même si dans ce domaine elle semble moins riche que ICE (je ne connais pas vraiment ICE, donc je ne saurais être totalement affirmatif).
En outre Applied informatics propose également différents modules (commerciaux ceux-ci) axés réseau par dessus POCO qui, d'après les échos que j'ai eu, sont de bonne qualité.
02/09/2009, 00h30
Issam_Lahlali

Citation:

Envoyé par gl

[*]Pourquoi ne pas utiliser des bibliothèques déjà répandues et donc éprouvées et debuggées (Boost, POCO, ICE, ACE, etc.) plutôt que de refaire un framework maison, peut être plus simple d'apparence mais probablement moins souple et moins robuste.

mais encore une fois le but est de ne pas tout refaire, pourquoi on me fait dire ce que je n'est jamais dit:)

le but est de simplifier ce qu'on juge compliqué et forcement il y en a plusieurs cas ou on répètent les mêmes lignes pour un besoin technique et la il faut penser a faire abstraction et éviter les copier/coller.
02/09/2009, 00h38
Issam_Lahlali

Citation:

Envoyé par Mac LAK

Je pratique aussi ICE, et au "maximum" ou presque : utilisation de IceGrid / IceBox pour la gestion centralisée des endpoints, génération automatique multi-langage par Slice à partir de modules ICE les plus simples possibles (à peu près ce que tu demandes comme fonctions exposées), utilisation des divers modules comme IceStorm pour les publications asynchrones, IcePatch pour la mise à jour / déploiement, etc. En gros, à part les facettes (on verra à la prochaine version de notre produit, si l'on a besoin de faire évoluer les interfaces ou pas) et les communications SSL (réseau privé, on s'en fiche donc), j'utilise TOUTE la librairie ICE...

juste une question est ce que tout les développeurs qui ont besoin d'utiliser le distribué dans ta boite sont censé connaitre ICE et ces subtilités?

si oui c'est un choix a respecter mais sérieusement pourquoi ajouter une complexité en plus pour tout les développeurs,tu me dira c'est trop facile mais peut être c'est facile pour toi , en général on a du mal a bien maitriser la technologie distribué et en plus pour moi tout ce qui touche au distribué n'est qu'un adaptateur , un développeur doit s'en foutre que ça soit distribué ou pas il doit y avoir une parfaite abstraction par rapport a ça et surtout un couplage très faible par rapport a cette couche.

le piège c'est qu'on fait trainer ce type de librairie dans tout le projet et si demain on veut le faire marcher dans un contexte autre que distribué on passe notre temps a isoler le métier et c'est la qu'on se rend compte que c'était mal conçu au départ.

je préfère l'autre choix ou on simplifie au maximum au developpeur métier on lui cachant toute subtilité de ce type de librairie, et c'est un choix prouvé en sur tout les projets lesquels j'avais bosser qui ont très bien marcher a l'international et on sait bien qu'en france il nya pas enormement d'editeur de logiciels qui s'impose en international en tout cas pas autant que l'angletaire, l'alemagne ou USA.

donc si je pratique une approche qui a très bien marcher , est ce que tu crois que je vais dire non c'est du n'importe quoi et il faut que je fasse autrement :)
02/09/2009, 00h57
gl
Citation:

Envoyé par Issam_Lahlali

le but est de simplifier ce qu'on juge compliqué et forcement il y en a plusieurs cas ou on répètent les mêmes lignes pour un besoin technique et la il faut penser a faire abstraction et éviter les copier/coller.

Et je vais donc répéter la question qui t'a déjà été posé plusieurs fois (et non, ce n'est pas pour être désagréable, mais pour comprendre). Qu'est ce qui est compliqué ou trop technique dans les lib citées ? Qu'est ce que tu veux encapsuler concernant les sockets de plus que ce qui existe dans ces bibliothèques.
Pour information, une connexion suivi d'un envoi/réception avec POCO s'est 4 lignes :
Code:

1 2 3 4 SocketAddress sa(IPAddress, IPPort); StreamSocket sock(sa); sock.sendBytes(SndFrame, SndLen); RcvLen = sock.receiveBytes(RcvFrame, WaitLen);
Que veux-tu simplifier ici ? Qu'y a-t-il d'aussi compliqué ?

Plutôt que de chercher à simplifier ou à encapsuler à l'infini les sockets simples, il est bien souvent plus rentable de développer un module en charge du protocole applicatif et de concentrer l'utilisation de socket à l'intérieur de celui-ci.
02/09/2009, 01h07
Issam_Lahlali
Citation:
Envoyé par gl

Et je vais donc répéter la question qui t'a déjà été posé plusieurs fois (et non, ce n'est pas pour être désagréable, mais pour comprendre). Qu'est ce qui est compliqué ou trop technique dans les lib citées ? Qu'est ce que tu veux encapsuler concernant les sockets de plus que ce qui existe dans ces bibliothèques.
Pour information, une connexion suivi d'un envoi/réception avec POCO s'est 4 lignes :

Code:

1 2 3 4 SocketAddress sa(IPAddress, IPPort); StreamSocket sock(sa); sock.sendBytes(SndFrame, SndLen); RcvLen = sock.receiveBytes(RcvFrame, WaitLen);

Que veux-tu simplifier ici ? Qu'y a-t-il d'aussi compliqué ?

Plutôt que de chercher à simplifier ou à encapsuler à l'infini les sockets simples, il est bien souvent plus rentable de développer un module en charge du protocole applicatif et de concentrer l'utilisation de socket à l'intérieur de celui-ci.
c'est la le grand desastre de C++ juste en parlant des sockets, on m'a sorti boost.asio,ICE et POCO ca veut deja tout dire.

et encore une fois on va pas faire cette démarche tout le temps, mais la ou on juge utile et c'est que je ne cesse de répéter, si POCO est facile pour les socket, ICE facile pour le distribué et Boost sur autre chose, est ce que tu crois que je vais utiliser 36 000 librairies ça sera une pure complication.

si je reviens a l'exemple de boost.asio ou on dans les exemples de Boost eux même on fait des wrappers pour simplifier.

et encore une fois le but est de faire abstraction la ou on juge utile dans un framework technique de l'entreprise et il faut éviter de me sortir a chaque fois une librairie qui soit disant facilite une partie de la couche technique, juste en quelques réponses j'ai eu droit a trois librairies et si on continue on aurai autant de posts que de librairies :)

alors pour les librairies que vous utilisez tôt ou tard il y aura des choses a simplifier et c'est pas un mal puisque les librairies sont en général générique et dans ce cas penser a les simplifier et ne pas entrer dans le piège de laisser la complexité trainer pour tous les développeurs tout au long du durée du projet c'est aussi simple que ca :)
02/09/2009, 01h07
gl

Citation:

Envoyé par Issam_Lahlali

en plus pour moi tout ce qui touche au distribué n'est qu'un adaptateur , un développeur doit s'en foutre que ça soit distribué ou pas il doit y avoir une parfaite abstraction par rapport a ça et surtout un couplage très faible par rapport a cette couche.

le piège c'est qu'on fait trainer ce type de librairie dans tout le projet et si demain on veut le faire marcher dans un contexte autre que distribué on passe notre temps a isoler le métier et c'est la qu'on se rend compte que c'était mal conçu au départ.

Si ce n'est que dans certains cas, le fait que ce soit distribué n'est pas qu'un simple détail technique dont on se moque.
Pour certains, c'est même une composante essentielle de l'architecture voire du métier.

Comme quelques uns te l'ont déjà signalé, tu devrais essayer d'élargir un peu ta vision et comprendre que l'informatique ne se réduit pas uniquement à ce que toi tu fais.
Il y a une multitudes de contextes différents, de projets différents,de contraintes différentes. Ce que l'on pratique (toi ou n'importe qui dans ce métier) n'est qu'une toute petite proportion (certes plus ou moins grande suivant le vécu des personnes, mais petite dans tous les cas) de ce qui existe.
02/09/2009, 01h13
Issam_Lahlali

Citation:

Envoyé par gl

Il y a une multitudes de contextes différents, de projets différents,de contraintes différentes. Ce que l'on pratique (toi ou n'importe qui dans ce métier) n'est qu'une toute petite proportion (certes plus ou moins grande suivant le vécu des personnes, mais petite dans tous les cas) de ce qui existe.

je pense que t'a zapper un post avant , on a ecrit le message au meme moment :)

tu remarque que j'ai mis en gras "on juge utile" et ca depend du contexte du projet, mais la vous etes contre un framework technique meme si on juge utile de faire abstraction qui dépend du contexe bien sur.

mais on est pas arriver a ce point vu que vous êtes contre avoir un framework technique et une équipe qui s'en occupe.
02/09/2009, 01h15
gl

Citation:

Envoyé par Issam_Lahlali

c'est la le grand desastre de C++ juste en parlant des sockets, on m'a sorti boost.asio,ICE et POCO ca veut deja tout dire.

Tu peux enlever C++ de ta phrase. L'existence de différente bibliothèque plus ou moins concurrente existe dans de nombreux langages.

Citation:

Envoyé par Issam_Lahlali

et encore une fois le but est de faire abstraction la ou on juge utile

Enfin.

C'est ce que tout le monde essaie de te dire depuis je ne sais combien de page.
02/09/2009, 01h18
gl

Citation:

Envoyé par Issam_Lahlali

tu remarque que j'ai mis en gras "on juge utile" et ca depend du contexte du projet, mais la vous etes contre un framework technique meme si on juge utile de faire abstraction qui dépend du contexe bien sur.

mais on est pas arriver a ce point vu que vous êtes contre avoir un framework technique et une équipe qui s'en occupe.

Non, je ne suis pas contre un framework technique. Je me cite :

Citation:

Envoyé par gl

Les sockets BSD sont effectivement un élément qui s'encapsule très bien dans une couche de plus haut niveau, ils ont en effet une granularité très fine qui n'est pas nécessaire pour la plupart des applications.

Citation:

Envoyé par gl

Mais là encore, personne n'a dit qu'il ne fallait pas faire de bibliothèque/framework haut niveau et générique.

C'est juste à voir au cas par cas. Ce que tu sembles enfin avoir compris.
02/09/2009, 01h20
Issam_Lahlali

Citation:

Envoyé par gl

Tu peux enlever C++ de ta phrase. L'existence de différente bibliothèque plus ou moins concurrente existe dans de nombreux langages.

Enfin.

C'est ce que tout le monde essaie de te dire depuis je ne sais combien de page.

maintenant je comprends cette résistance, ca m'a fait trop peur :)
et la je comprends qu'on lit pas tout le message et on veut répondre avant même de terminer la lecture de message.

a plusieurs reprises ou je dis il y a des cas ou le mieux est de faire abstraction pour éviter les copier/coller, pour être sur essaye de relire attentivement mes posts des 3 dernières pages.

mais ce qui me parait bizarre c'est le rejet catégorique d'un framework technique en entreprise avant même qu'on parle ce qu'il faut mettre dans ce framework et dans quel contexte et ce que je ne comprenais pas c'est a chaque fois on me demandais qu'il ne faut pas refaire la roue et c'est la que je comprends qu'on lit la moitié des messages :)

Citation:

Envoyé par gl

C'est juste à voir au cas par cas. Ce que tu sembles enfin avoir compris.

juste pour te montrer qu'on lit la moitié des message voici une citation récente

"la majorité des librairies techniques ne peuvent pas coller a ton besoin exacte au niveau simplicité d'utilisation, et c'est normale toute librairie technique est générique puisqu'elle est censé adresser énormément de besoins, et il faut penser a créer une boite a outil pour d'une part simplifier et d'autre part protéger les changements de librairies a cause d'un changement des specs qui est monnaie courante dans notre métier."

qui montre bien qu'il faut adapter une librairie technique a notre besoin spécifique pour simplifier la vie aux développeurs, je ne sais pas comment je peux être plus clair que ça:)
02/09/2009, 01h41
gl

Citation:

Envoyé par Issam_Lahlali

et la je comprends qu'on lit pas tout le message et on veut répondre avant même de terminer la lecture de message.

Pour ton information, sache qu'avant de répondre à un message, je le lis entièrement. Pour être plus précis avant de répondre, je lis tous les messages non lus de l'enfilade.

Citation:

Envoyé par Issam_Lahlali

a plusieurs reprises ou je dis il y a des cas ou le mieux est de faire abstraction pour éviter les copier/coller, pour être sur essaye de relire attentivement mes posts des 3 dernières pages.

Non, tu ne le dis pas, ou alors ce n'était vraiment pas clair pour moi dans tes propos.
La notion du traitement au cas par cas, je l'ai effectivement vu dans les dernières pages, mais pas dans tes messages.

Ce que je lis de toi ressemble plutôt à

Citation:

Envoyé par Issam_Lahlali

la première chose que je vais faire est créer une classe très basique qui contient Open, Send , Receive et Close comme ça on cache toute la logique bas niveau et le développement avec les sockets devient un pur bonheur :)

et on peut généraliser ça sur toute fonctionnalité technique ou on répète les mêmes choses a chaque fois.

Et je ne vois pas la moindre notion de choix en fonction du contexte.

Si depuis le début tu prônais du cas par cas, je suis désolé pour cette incompréhension, mais je ne l'ai pas compris en lisant tes messages.
02/09/2009, 01h48
Issam_Lahlali

Citation:

Envoyé par gl

Si depuis le début tu prônais du cas par cas, je suis désolé pour cette incompréhension, mais je ne l'ai pas compris en lisant tes messages.

et tu fais attention a ça dans ma citation que t'a mentionné :

"et on peut généraliser ça sur toute fonctionnalité technique ou on répète les mêmes choses a chaque fois"

est ce que tu veux laisser les répétitions de lignes autre que dans un framework technique.

et bien sur ces répétitions dépendent de ton contexte qui impose d'appeler une sequence d'une maniere repetitif dans le code.

et voici plusieurs de mes citations depuis le commencement de ce sujet cad depuis la page 39 jusqu'a 42 cad très loin de la dernière page :):

Citation:

Mais pour les moyens et grands projets ça devient primordial, au lieu que 100 développeurs perdent leur temps sur la même chose répétitif, on la donne a une équipe de 3 personnes et c'est réglé, et chacun se concentre comme il faut sur ces taches spécifiques.

Citation:

Librairie trop générique et se caracterise par un niveau trés bas de granularité au niveau methodes, cad qu'au lieu d'appeller une methode pour faire le travail on est obligé d'appeller une sequence de methodes a chaque fois, et dans ce cas le mieux est de faire l'abstraction pour eviter les copier/coller.

Citation:

c'est pour cela qu'il faut se protéger par le couplage faible si on juge utile,pour s'adapter aux changements d'une manière souple et flexible.

Citation:

prenons par exemple le cas StartWith avec std::string, on remarque qu'on l'a pas mais c'est pas ça le probléme, et on l'utilise beaucoup et dans ce cas il faut faire une abstraction a cette méthode et la coder une fois pour toute, au lieu que chacun fait sa propre version et on aura que du copier/coller qui traine.

Citation:

la majorité des librairies techniques ne peuvent pas coller a ton besoin exacte au niveau simplicité d'utilisation, et c'est normale toute librairie technique est générique puisqu'elle est censé adresser énormément de besoins, et il faut penser a créer une boite a outil pour d'une part simplifier et d'autre part protéger les changements de librairies a cause d'un changement des specs qui est monnaie courante dans notre métier.

a chaque fois je parle de mettre dans le framework technique ce qui est répétitif et ce qu'on juge utile mais il y avait dés le départ une résistance contre le framework technique , et si t'a t'est pas contre je crois que d'autres ils sont toujours contre :)

Voir 40 message(s) de cette discussion en une page

Fuseau horaire GMT +2. Il est actuellement 19h53.