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

Citation:

---

Envoyé par Luc Hermitte

Pas d'alloc dynamique ? (comment ça j'attendais que tu le confirmes ? ;)) Il ne reste que la 0-initialisation qui peut couter plus cher que nécessaire sur un vecteur.

---

Attention : l'initialisation d'un code critique n'est PAS critique... Le code critique, c'est celui qui tourne en boucle, hors initialisation et finalisation. Oui, je sais, c'est vicieux. :mouarf:
Donc, t'as le droit à un new/malloc à l'init, mais pas pendant le fonctionnement (à fortiori, encore moins le droit aux resize/realloc bien sûr).

Citation:

---

Envoyé par Luc Hermitte

Qu'est-ce qui me fait dire que je n'étais pas le seul ? Des codes que j'ai croisé et qui abusent de mutex -- car abus d'états partagés. Avec une réflexion dès la conception pour voir qu'il n'y avait un gros sac de noeud en place d'une hiérarchie, les choses auraient été différentes.

---

T'inquiètes pas, j'en ai vu aussi : non, tu n'es pas fou, ni maudit, ni persécuté par les serial-mutexeurs... ;)
Comme toujours, il y a des gens qui les utilisent sans savoir le faire réellement. Mais il y a aussi des gens qui savent les utiliser, et surtout QUAND les utiliser, simplement ils ne sont pas légion.

Citation:

---

Envoyé par Luc Hermitte

Pour les lock-free, j'ai l'impression que c'est récent comme approche (du moins, c'est moins confidentiel qu'avant), mais les implémentations qui marchent me semblent brevetées...

---

Brevetés, je ne sais pas, mais confidentiels et en code fermé, ça je peux te le garantir par contre... Mettre 50% de perfs dans les dents à la concurrence, ça vaut son pesant d'or et tu tiens donc le "comment" secret.

Pour cette histoire de code critique il y a des techniques qui demandent surtout un code fait maison, par exemple Pool d'allocation et le Cache c'est deux la peuvent affecter les performances d'une manière très significative et en général leurs implémentations reste spécifique a ce qu'on veut faire.

par exemple pour doxygen, ou il y a utilisation d'un cache fait maison pour accélérer le traitement, j'ai fait l'expérience de virer le cache et le temps a tout simplement doublé pour le traitement de certains projets.


Pour l'abstraction et la simplification de la couche technique qui était l'origine d'une grande querelle:), j'ai tomber par hasard sur un post du créateur de boost.asio qui dit:

Code:

---

1 2 3 4 5 6 7 8

A design goal of asio is to provide a basis for further levels of abstraction. One of the ways to develop abstractions on top of asio is to create what I like to call composed operations. These are simply operations that are made up of calls to other lower-level operations. Asio already includes some composed operations to address common network programming problems: async_read and async_write to deal with short reads and writes; and async_read_until to perform delimited reads.

---

a un moment j'ai insister qu'on peut faire une abstraction pour une librairie existante pour notre besoin spécifique et j'avais pris comme exemple boost.asio justement , vu que les librairies en général propose des fonctionnalités génériques, mais il y avait une grande résistance:)

le but la n'est pas de relancer le sujet, parce que je pense que ça ne se terminera jamais mais le but est de montrer que c'est un point de vu que beaucoup le partage, et chacun a sa manière de structurer et concevoir, il n y a pas de manière unique.

Le vrai vrai de vrai, vraiment réél probleme de C++, c'est qu'en tant que développeur en dotNet, avec un framework qui possede un très grand nombre de librairies, ou tu peux ajouter enterprise library, entity framework ou nhibernate ou une tonne d'utilitaires très pratique facile, c'est difficile de se retrouver dans un monde C++ ou tout est disparate et non standard, t'as le choix de plein de librairies, pas toujours facile à trouver, pas toujours facile à inclure dans un projets et ca rend la complexité tellement grande que c'est difficile de monter un environnement de developpement en C++ pour faire quelques applications que ce soit....

certains trouvent que c'est un problème, d'autres que c'est mieux comme ca.
Si C# et C++ etaient similaire, quel interêt d'avoir les deux?

Pour ma part, je dirais que c'est parfois un problème, parfois un avantage.
Mais j'avoue que c'est parfois assez énervant. Du coup, j'ai de plus en plus tendance à programmer en java ou en c# lorsque je dois faire des applis simple, standar (dans le sens: qui n'ont pas besoin de faire des choses vraiment spécifiques) et avec peu de contraintes (rapidité et portabilité principalement).
Mais parfois, le C++, voire le C, sont tout simplement indispensables. Et au final, avec un peu d'expérience, on fini par s'habituer à la "constellation" de bibliothèques et a apprendre à les utiliser sans trop se prendre la tête.