Discussion :

[Alp]

En très très très gros, ce que dit Stepanov, c'est qu'au lieu de faire :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
class StringConvertible // en gros une interface à la Java
{
  public:
  virtual std::string toString() const = 0;
};
 
class A : public StringConvertible
{
   char* ch;
   // etc
   public :
   std::string toString() const { return std::string(ch); }
};
 
void f(const StringConvertible& foo)
{
  // ...
}
 
// plus loin
A a;
// ...
f(a);

on peut faire :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class A
{
   char* ch;
   // etc
  public :
   std::string toString() const { return std::string(ch); }
};
 
template <class T>
void f(const T& foo)
{
  std::string s = foo.toString();
  // ...
}

Donc imposer une contrainte syntaxique, comme c'est prévu avec les concepts, plutôt qu'à tout prix passer par une interface, et docn tout faire à 200% en OO.

En C++, le courant tend à vouloir tirer le meilleur de la POO et de la programmation générique. C'est ça qu'il veut dire.

[Issam_Lahlali]

En C++, le courant tend à vouloir tirer le meilleur de la POO et de la programmation générique. C'est ça qu'il veut dire.

tout a fait d'accord, je ne suis pas contre les generics loin de la , je les utilisent beaucoup d'ailleurs.

C++ est multi-paradigme c'est très bien mais ça ajoute une petite complexité au langage et si on plus on ajoute la complexité de la couche technique ça peut devenir un casse tête.

donc finalement je suis pour simplifier au maximum la couche technique de C++ pour tirer profit du vrai C++ parce que a mon avis on ne fait que du faux C++ avec des bidouilles techniques dans tout les coins du projet.

la couche technique en C++ représente un frein puisqu'on lui consacre beaucoup de temps et malheureusement en dépend de la conception.

dans un monde idéal ou on a tout notre temps , je dirais C++ est un très très bon langage mais vu la concurrence et la nécessité de finir les projets le plutôt possible nous obligent a ce concentrer que sur la technique si on développe en c++.

[Matthieu Brucher]

dans un monde idéal ou on a tout notre temps , je dirais C++ est un très très bon langage mais vu la concurrence et la nécessité de finir les projets le plutôt possible nous obligent a ce concentrer que sur la technique si on développe en c++.

Non, c'est faux. En phase de conception, tu peux faire ces choix, et la vitesse de développement est identique voire avantageuse dans le cas générique. C'est un raccourci qui ne doit pas être pris.

[Issam_Lahlali]

Non, c'est faux. En phase de conception, tu peux faire ces choix, et la vitesse de développement est identique voire avantageuse dans le cas générique. C'est un raccourci qui ne doit pas être pris.

si c'était comme ça c'est l'idéal on sait que si on passe du temps en conception on gagne beaucoup de temps en dev, maintenance et évolution, finalement un dev sans conception suit un graphe logarithme ou au départ ça va vite mais vite nous sommes stagnés du a la complexité qui devient de plus en plus croissante, et avec une bonne conception c'est l'effet inverse, au départ il faut attendre pour avoir un résultat mais après ça va très vite.

mais il ne faut pas cacher et tout le temps argumenter la complexité technique de C++, le fait est la C++ est techniquement trop complexe.

par exemple pour les smarts pointers ou on parle de shared_ptr de boost, et malheureusement que dans C++0x ou on veut l'intégrer a std, pourquoi c'était pas fait depuis très longtemps et plus que ça pourquoi on a pas une syntaxe genre T# ou T ^ ou n'importe quel symbole natif du langage C++ pour représenter implicitement un shared_ptr.

et quoi dire des macros aussi ou des fois j'ai l'impression de lire un langage crypté lorsque je lis une macro.


a mon avis il n'est pas trop tard pour simplifier techniquement C++ il faut juste éviter au maximum de trouver a chaque fois des arguments aux complexités.

[Alp]

Attention, ce serait une erreur de transformer C++ en une sorte de VB, où l'on peut mettre le bordel que l'on veut et que personne ne nous en voudra. En C++, il faut se former, sinon ça casse, c'est certain. Et si cela ne tenait qu'à moi, ce serait ainsi dans tous les langages. Seulement, on voit beaucoup de "développeurs" aujourd'hui qui utilisent un langage juste pour gagner de quoi manger, sans aimer ce qu'ils font et sans être rigoureux, intelligent et motivé dans leur manière de faire. Et ça, quel que soit le langage, quelles que soient les personnes qui décident de l'évolution du langage, etc, bah tu ne peux rien y faire. Le fait est qu'en C++, c'est un peu plus prononcé.

Mais n'ais pas trop d'illusions. J'ai déjà croisé pas mal de développeurs Java qui étaient loin de maitriser les Design Patterns, alors que leur compréhension est essentielle en particulier en Java étant donné la quantité de frameworks qui se basent dessus.

Je vois des gamins de 13 ans qui sont plus motivés, déterminés et apprennent plus intelligemment que des mecs de 20, 25, 30+ , et qui au final pondront un code C++ de bien meilleure qualité. Après, je suis désolé, mais le commité peut pas non plus faire tout le boulot des développeurs. A un moment donné, quand tu te décides à faire un job, il faut que tu l'assumes. Si tu ne connais pas assez bien le langage, hé bien tu répares ça.

[Matthieu Brucher]

Un symbole pour les shared_ptr -> on a déjà dit qu'il y avait plusieurs types de pointeurs intelligents, certains plus adaptés que d'autres selon la situation
macro -> très peu utilisées en C++.

Et je suis désolé, mais un projet, qu'il soit dans n'importe quel langage, a une phase de conception, d'analyse, ... qui est longue. Et en C++, c'est aussi le cas, pourquoi ça ne le serait pas puisqu'on utilise des processus identiques ???

De ta question originale, à laquelle tout le monde a répondu que ce n'était pas vrai, tu est passé à dénigrer le C++ en le considérant comme trop complexe techniquement. Je dirai juste : ou pas. Pour moi, il n'est pas trop complexe, il y a des langages bien plus difficile à appréhender.

[Alp]

il y a des langages bien plus difficile à appréhender.

Au hasard : Haskell

[Issam_Lahlali]

Et je suis désolé, mais un projet, qu'il soit dans n'importe quel langage, a une phase de conception, d'analyse, ... qui est longue. Et en C++, c'est aussi le cas, pourquoi ça ne le serait pas puisqu'on utilise des processus identiques ???

crois moi un langage ou on passe du temps coté technique sera le dernier choisis pour un nouveau projet actuellement en entreprise,et la question n'est pas de transformer C++ en vb , le but est de laisser la puissance de c++ mais simplifier l'utilisation surtout coté librairies.

ce qui a freiner C++ est surtout cette résistance de ceux qui maitrise bien le langage et qui ne voient pas l'intérêt d'un changement.

d'ailleurs si c'est très bien comme ça pourquoi on s'embête avec c++0x , et je suis sur et certain que si par exemple les lambdas n'étaient même pas dans la nouvelle norme , la majorité vont dire que ca sert a rien d'ajouter un tel mécanisme, mais du moment ou la comité l'ajoute tout le monde commente les avantages d'un tel mécanisme.

alors le retard de standarisation du langage et des librairies techniques c'est un fait, pas mal de monde ont constater ça c'est pas une découverte et de même que C++ expert friendly c'est un fait aussi , le createur de c++ lui même parle de ça.

alors dire on ne peut rien y faire c'est comme ça, c'est a prendre ou a laisser je ne suis pas d'accord, il faut faire des évolutions pour simplifier la couche technique avant qu'il soit trop tard.

[3DArchi]

Salut,

Pour moi, il n'est pas trop complexe, il y a des langages bien plus difficile à appréhender.

Par mon expérience, j'ai vu les débutants (et parfois même des seniors) plus bloquer sur des aspects liés au framework (MFC par expl) ou liés à l'architecture du logiciel. Les développeurs peu expérimentés ou maîtrisant mal le C++ font souvent le même type d'erreur et c'est donc assez facilement prévisible et gérable. Et même si la programmation générique peut perturber au début, j'ai le sentiment que la complexité du langage est de moindre importance comparée à la complexité du logiciel. J'ai vu plus de bug ou du temps de maintenance consommé à cause d'une modification de la logique d'une fonction ou d'un échange ou d'une donnée. En fait, à un moment dans un soft, la complexité et par conséquent les coûts de maintenance ou de formation (pour un nouveau développeur fut-il expérimenté) est plus dans l'architecture logicielle que dans le langage qui la met en œuvre.

[koala01]

si c'était comme ça c'est l'idéal on sait que si on passe du temps en conception on gagne beaucoup de temps en dev, maintenance et évolution, finalement un dev sans conception suit un graphe logarithme ou au départ ça va vite mais vite nous sommes stagnés du a la complexité qui devient de plus en plus croissante, et avec une bonne conception c'est l'effet inverse, au départ il faut attendre pour avoir un résultat mais après ça va très vite.

Sur ce point, il semble que nous soyons d'accord: meilleure est l'analyse, plus court sera le temps d'implémentation et dans des proportion manifestes

mais il ne faut pas cacher et tout le temps argumenter la complexité technique de C++, le fait est la C++ est techniquement trop complexe.

Si tu veux aller cherche "la petite bête", effectivement, comme tout langage très bas niveau...

Pour le reste, justement, si prend la peine d'utiliser les possibilités réellement propres au C++ (je pense entre autres à celles fournies, tout simplement, par la STL), tu peux t'éviter dans la majeure partie des cas de te casser la tête sur les problèmes purement techniques

par exemple pour les smarts pointers ou on parle de shared_ptr de boost, et malheureusement que dans C++0x ou on veut l'intégrer a std, pourquoi c'était pas fait depuis très longtemps

Tu semble oublier que les shared_ptr ont été introduit lors de la dernière mise à jour de la norme (TR1)... Au même titre que de nombreuses autres choses.

Cette mise à jour date quand même, si je ne dis pas de bêtises, de 2003 et la principale différence entre ce que sera la nouvelle norme vis à vis des évolutions apportées par TR1 sera de déplacer les fichiers d'en-tête (du dossier tr1 ou similaire au dossier "de base"), et de sortir les fonctions/classes de l'espace de noms std::tr1 pour les placer dans l'espace de noms standard (std).

Effectivement, tr1 s'est fortement basé sur, entre autres, le travail fournit par boost... Est-ce un mal

et plus que ça pourquoi on a pas une syntaxe genre T# ou T ^ ou n'importe quel symbole natif du langage C++ pour représenter implicitement un shared_ptr.

Oulah... ne mélange pas tout, s'il te plait... T^ est une syntaxe qui n'a strictement rien à voir avec le C++, c'est une syntaxe propre à microsoft dans son point de vue C++/CLI, qui n'a rien de standard, et qu'il essaye d'imposer afin d'assurer la possibilité d'utiliser son framework .Net (à la base, son framework MFC, d'ailleurs, je crois )

Il semble que tu confonde fortement les problèmes car celui que tu épingle ici est plutôt du au fait que microsoft s'est royalement foutu des différents standards pendant des années, et qu'il continue à vouloir imposer un framework perso

et quoi dire des macros aussi ou des fois j'ai l'impression de lire un langage crypté lorsque je lis une macro.

Les macros mal faites sont la plaie, tout le monde est d'accord là dessus...

D'autres fois, les macros peuvent s'avérer utiles malgré tout.

Quoi qu'il en soit, les macros sont à classer dans la même catégorie que les goto et les fonctions récursives: la catégorie des choses à utiliser quand il est impossible de faire facilement autrement

[Matthieu Brucher]

d'ailleurs si c'est très bien comme ça pourquoi on s'embête avec c++0x , et je suis sur et certain que si par exemple les lambdas n'étaient même pas dans la nouvelle norme , la majorité vont dire que ca sert a rien d'ajouter un tel mécanisme, mais du moment ou la comité l'ajoute tout le monde commente les avantages d'un tel mécanisme.

Et crois-moi, on a des projets immenses ici et certains sont en Java, C, Fortran ou C++ et sans doute d'autres (on a du VB qui traîne). Il y a une histoire d'adéquation, on l'a déjà dit, et ça n'a rien à voir avec la question originale.
Les lambdas, c'est bien, c'est cool, mais ça ne sera utilisé dans le monde de l'entreprise que dans 4-5 ans, car il faut que tous les gros compilateurs les implémentent (c'est pas pour rien qu'on a encore très très peu de code C99, la nouvelle norme n'est pas supportée par tous les grands compilateurs du marché). D'ici là, cette nouveauté et cette complexité technique seront du passé et on ne posera même plus de question.
Et C++0x ou C++03, ça change quoi au niveau conception ? Rien !

[Issam_Lahlali]

Et C++0x ou C++03, ça change quoi au niveau conception ? Rien !

oui tout a fait d'accord, si t'a remarquer je met l'accent que sur la couche technique , pour la conception on a tout ce qu'il faut excepté peut être les concepts qui seront un bon outil pour le concepteur.

ce qui m'intéresse dans les évolutions est surtout la simplification de la couche technique, et d'ailleurs C++0x ou C++03 ne se focalise pas trop a la simplification de la couche technique.

[Issam_Lahlali]

Oulah... ne mélange pas tout, s'il te plait... T^ est une syntaxe qui n'a strictement rien à voir avec le C++, c'est une syntaxe propre à microsoft dans son point de vue C++/CLI, qui n'a rien de standard, et qu'il essaye d'imposer afin d'assurer la possibilité d'utiliser son framework .Net (à la base, son framework MFC, d'ailleurs, je crois )

je connait bien le ^ de microsoft, et si tu relis mon post j'ai dis T# ou T^ ou n'importe quel autre symbole, et rien a voir avec CLI, c'est juste un détail pour simplifier shared_ptr<MaClass>.

[Matthieu Brucher]

oui tout a fait d'accord, si t'a remarquer je met l'accent que sur la couche technique.

Donc en fait, la véritable réponse à la question, c'est plus que c'est toi qui t'intéresse plus à la technique que la communauté
Sérieusement, je ne comprend pas l'objectif que tu poursuis depuis quelques messages qui consistent à dénigrer le C++.

[Goten]

Oui sauf que y'a pas que shared_ptr<>. Il en existe bien d'autres ( weak_ptr<> , scoped_ptr etc) et chacun ont des cas d'utilisation bien définies... Un symbole pour chaque? ça deviendrait vite ingérable.

edit : Comme Matthieu Brucher, je trouve que les derniers messages tournent plus au _je descend C++_ qu'autre chose. Sans parler du fait que le topic tourne un peu en rond. (même arguments qui reviennent sans cesse et pas que de ta part)

[Issam_Lahlali]

Donc en fait, la véritable réponse à la question, c'est plus que c'est toi qui t'intéresse plus à la technique que la communauté
Sérieusement, je ne comprend pas l'objectif que tu poursuis depuis quelques messages qui consistent à dénigrer le C++.

je parle de la couche technique pour critiquer le temps qu'on passe dessus.

et pour le dénigrement de C++ je réponds juste au fait qu'a chaque fois on explique la complexité technique.

je suis plus contre l'explication a chaque fois des complexités techniques que du fait que C++ est techniquement complexe, comme mentionné d'autres langages sont plus compliqués que C++ mais est ce que c'est un argument pour dire que tout va bien et C++ est techniquement très facile.

il faut être objective: C++ est compliqué techniquement mais il apporte des mécanismes très puissants pour bien développer les projets.

mais est ce qu'il n y a pas moyen de le rendre facile techniquement?

[Alp]

Tu aurais un exemple pour illustrer ? Un exemple intelligent.

[Issam_Lahlali]

Tu aurais un exemple pour illustrer ? Un exemple intelligent.

tu utilisera quoi comme librairies si t'a a développer une application distribuée qui a un accès des bases de données et en plus a besoin du MOM?

[Alp]

tu utilisera quoi comme librairies si t'a a développer une application distribuée qui a un accès des bases de données et en plus a besoin du MOM?

Le rapport avec 1/ la conception 2/ la complexité technique ?

Pour ta question, sinon, j'ai participé au développement d'une bibliothèque (pas librairie, bibliothèque) qui comporte une composante distribuée & MOM. Il n'y aurait plus qu'à brancher l'accès à la base de données dans l'aspect distribution, ce qui se fera sans soucis grâce à la généricité que j'ai introduit dans la bibliothèque.

PS : non, la bibliothèque n'est pas publique.

[Issam_Lahlali]

Le rapport avec 1/ la conception 2/ la complexité technique ?

Pour ta question, sinon, j'ai participé au développement d'une bibliothèque (pas librairie, bibliothèque) qui comporte une composante distribuée & MOM. Il n'y aurait plus qu'à brancher l'accès à la base de données dans l'aspect distribution, ce qui se fera sans soucis grâce à la généricité que j'ai introduit dans la bibliothèque.

PS : non, la bibliothèque n'est pas publique.

la relation c'est que tous ces aspects concerne la couche technique (database, distribué et MOM)

prenons l'exemple du MOM ou on trouve JMS en java par exemple , l'intérêt est que je suis decouplé des librairies techniques et a tout moment je peux changer la librairie technique sans autant tout changer.

on peut faire MOM sans JMS mais il y un coup si on veut changer de librairie, même si on fait notre propre abstraction pour switcher rapidement il y a un cout en plus au niveau dev.

finalement on voit que d'autres langages bénéficient de l'expérience et de l'historique du langage pour faciliter le dev pour les problèmes techniques répétitifs.

en c++ chacun fait ce qu'il veut avec aucune volonté de standariser ce qu'on fait depuis 20 ans,pour en faciliter l'utilisation.

donc en gros C++ n'assiste ni le concepteur ni le developpeur, c'est a eux de se débrouiller comme des grands pour choisir une librairie dans la jungle des librairies.

d'autres langages ont choisis la démarche d'assister les développeurs et concepteurs dans leur démarche surtout concernant la couche technique.