Discussion :

[Luc Hermitte]

a- Es tu bien certain qu'il s'agisse de bad_alloc???
b- Et dans des cas d'allocation de tableaux de types natifs??? En général, une forte utilisation de mémoire (sur les systèmes modernes, la mémoire n'est presque jamais épuisée) a tendance à faire apparaitre tous les bugs d'un programme...

c- Là je suis bien d'accord, mais note que la STL n'est pas du tout immunisée contre ce genre de malheur : l'index sur ton vector renvoyé n'est pas le bon, tant pis pour toi... Ou alors il faut ajouter des tests pour chaque conteneur, ce qui ne donne un code ni élégant, ni efficace...

Il me semble que c'est typiquement là qu'une boucle try/catch est utile... Encore que, personnellement, je préfère un test.

d- Il me semble que si tu es dans une situation ou une allocation de tableau de types natifs (de taille raisonnable) peut échouer, espérer un fonctionnement correct du programme est espérer beaucoup. Mais cela tient sans doute au fait que je n'ai jamais vu de bad_alloc... En fait, la première fois que j'en verrai un, cela méritera non seulement d'arrêter le programme, mais aussi d'envoyer à l'utilisateur un message de félicitations, et peut etre un avoir sur ses achats futurs...

e- J'essaie juste de comprendre en quoi les "new" sont dangereux... Et je dois dire que l'explication par les exceptions ne me parait pas satisfaisante

(pff le système de citations de dvpz est vraiment mauvais ... encore pire qu'avec les autres forums phpbb (perte des citations précédente) )
a- Quand on se prend une pop-up plus de mémoire virtuelle, ou qu'une autre application (xsltproc IIRC) affiche une out-of-memory quelques minutes après que FF et chrome aient disparu, oui, le bad_alloc ou du moins l'échec d'allocation, j'y crois à fond. Ils y a des signes qui ne trompent pas.

b- Sur mon serveur je recevais de temps en temps (à cause d'un bug d'un de mes pairs) un message sur une socket qui me donnait une taille négative (ou excessivement grande si tu préfères signed/unsigned n'est qu'une question de point de vu) pour le message qui suivait. A vouloir allouer avec cette taille aberrante (avec un vector<unsigned char>::resize()), je me prenais une bad_alloc sur de l'allocation d'octet (sur solaris...).
Et re-cf a- pour les systèmes "modernes" (OK, c'était XP) qui ne peuvent pas suivre

c- C'est pour cela que l'on a des STL checkées. Mais le problème n'était pas là. Le problème venait d'une entrée corrompue et de l'impossibilité de savoir qu'elle est corrompue avant d'avoir pu la charger en entier pour appliquer un checksum...
Un accès hors bornes s'assimilerait à une erreur de programmation dans mon cas. C'est un tout autre problème qui appelle une toute autre solution.

d- Espérer un fonctionnement correct n'est pas espérer beaucoup quand on désire être robuste aux E/S aberrantes.
Quand un serveur critique doit tenir 6 mois sans tomber, on ne va pas l'arrêter parce qu'un de ses nombreux interlocuteurs lui envoie n'importe quoi.

e- Le problème n'est pas new. Les problèmes sont :
- d'être responsable de plus de deux ressources brutes à la fois dans une même portée,
- et new[] qui souvent est remplaçable par un container RAII comme std::vector par défaut
new est nécessaire pour allouer des objets avant qu'une structure RAII puisse en assumer la responsabilité.

f- Je ne comprend pas... Dans tous les OS actuels, chaque processus gère son espace d'adressage propre, non... Donc, une fuite mémoire ne concerne que ce processus, non?

f- Et bien non. Re-cf mon expérience personnelle avec xsltproc/fop+antivirus qui épuisaient la RAM que le PC était capable de fournir aux processus. Si tous les processus sont trop gourmands (qu'ils fuient ou non), il arrive un moment où l'OS ne peut plus fournir de la RAM. Et s'ils fuient, le problème sera exacerbé : on atteindra plus vite le point où l'OS ne pourra plus suivre tant que les processus fautifs n'auront pas été redémarrés.

[JolyLoic]

En gros, on parle beaucoup de portabilité (concept crucial à l'époque où il y avait presque autant d'OS que d'ordinateurs) au moment ou il n'y a presque plus qu'un OS vivant, on parle beaucoup de manque de mémoire à l'époque où on n'en manque plus, etc...

C'est amusant, car autant il y a 15 ans, la portabilité, c'était pour les entreprises uniquement, les particuliers n'utilisant que 2 OS assez semblables, autant aujourd'hui la portabilité me semble bien plus importante pour le grand public, entre les 3 OS classiques (*2 entre 32 et 64 bits), les 5 consoles de jeu, les N téléphones portable, les X PDA...

[Matthieu Brucher]

En fait, c'est une question assez générale en informatique. J'ai parfois l'impression qu'on passe beaucoup de temps à "refaire la dernière guerre". En gros, on parle beaucoup de portabilité (concept crucial à l'époque où il y avait presque autant d'OS que d'ordinateurs) au moment ou il n'y a presque plus qu'un OS vivant, on parle beaucoup de manque de mémoire à l'époque où on n'en manque plus, etc...

Tu ne dois pas vivre dans le même monde que nous
Je fonctionne au travail sur deux plateformes, Windows et Linux, et selon les clusters, j'ai accès à différents distributions, donc différents compilateurs, en-têtes, ... La mémoire, je n'en ai jamais assez. Même avec des bécanes qui ont 16Go pour 4 coeurs, c'est juste, je ne parle même pas de l'actualité en Allemagne.

Ce qui est vrai pour certains ne l'est jamais pour d'autres.

[Invité]

Tu ne dois pas vivre dans le même monde que nous
Je fonctionne au travail sur deux plateformes, Windows et Linux, et selon les clusters, j'ai accès à différents distributions, donc différents compilateurs, en-têtes, ... La mémoire, je n'en ai jamais assez. Même avec des bécanes qui ont 16Go pour 4 coeurs,

Ce qui est vrai pour certains ne l'est jamais pour d'autres.

Allons... Comme tout le monde il y a un peu de Windows et de Linux chez moi, mais mes applications ne tournent que sous windows. Pourquoi? Parce que je n'ai pas un client qui utilise Linux pour autre chose que ses serveurs...

J'ai des clients sous Mac (des agences de pub), mais en général ils font tourner leurs application "métier" (ce que j'écris) sur des PC (quitte à s'acheter une machine dédiée, c'est pas cher). La raison, c'est que presque tout le monde utilise des outils Windows pour communiquer (à commencer par Office). Avec le temps, j'ai l'impression que cette suprématie de Windows se renforce. Il y a dix ans, dire "on n'est que windows" pouvait te couter un client par ci par là... Aujourd'hui, même pas peur !

Quant à l'idée de faire tourner ca sur des PDA ou des téléphones, oui c'est super cool, mais ca ne sert à rien dans le contexte d'une application comme la mienne...

A l'intérieur de Windows, je n'ai jamais ressenti de problèmes de portabilité... En général, d'une version à l'autre, tout passe, sauf un petit coin de lien office ici... Il faut juste se garder d'utiliser trop vite les nouveautés. D'autant plus que la plupart des entreprises migrent très lentement. (seule exception : Office, là on a des pb plus complexe de portabilité, et des versions variées parfois au sein d'une même entreprise, heureusement, c'est généralement assez simple)

Je connais moins Linux, en fait, ma principale expérience c'est que la multiplicité des distributions, et la tendance à tout configurer sont d'excellentes raisons d'éviter Linux pour des applications devant tourner chez de nombreux clients. Le temps nécessaire au test de ces différentes distributions (même si le code est portable, il faudra le tester, c'est comme ça) sera généralement prohibitif.

Ce que je veux dire, c'est que les cas où la portabilité est cruciale sont très peu nombreux. Une fois de plus, je pense que l'on se focalise sur un problème secondaire (là où il y a toutes sortes de choses plus importantes).

Quant à la mémoire, je suis d'accord avec ta remarque : on n'en a jamais assez, et les utilisateurs surtout. Du coup, c'est le facteur sur lequel il faut se concentrer quand on développe (plus, à mon avis que la portabilité, les exceptions, ou l'utilisation judicieuse, mais hypothétique, des 84 coeurs des machines d'après demain). En général, il est possible de faire tourner beaucoup de programmes avec de faibles volumes de mémoire, mais il faut penser ses algorithmes pour cela.

Personnellement, j'ai tendance à développer sur des machines d'avant hier, de façon à ne pas trop préjuger des machines de mes clients. Par ailleurs, il me semble qu'il est raisonnable de partir du principe qu'une application client ne devrait pas utiliser plus de 15 ou 20% de la mémoire dispo, (quitte à utiliser pas mal de processeur, c'est le charme des multcoeurs), avec des "machines standard" à 2Go, ca veut dire 300-400 Mo de mémoire, et ca me semble suffisant pour toutes les applications que je veux utiliser (même si les données au départ représentent pas mal de Gigaoctets).

Francois

[Invité]

C'est amusant, car autant il y a 15 ans, la portabilité, c'était pour les entreprises uniquement, les particuliers n'utilisant que 2 OS assez semblables, autant aujourd'hui la portabilité me semble bien plus importante pour le grand public, entre les 3 OS classiques (*2 entre 32 et 64 bits), les 5 consoles de jeu, les N téléphones portable, les X PDA...

Je ne suis pas tout à fait d'accord... Ce qui me semble nécessaire, aujourd'hui, avec le grand public, c'est de l'interopérabilité : le fait que tous ces OS puissent communiquer entre eux. C'est avant tout une question de standards.

La portabilité, le fait que l'on *doive* developper des applications qui marchent sur toutes les plate formes ne me parait pas si cruciale. En gros, on a de plus en plus des applis mac et des applis PC différentes, le fait qu'un jeu existe sur une console et pas sur une autre choque de moins en moins...

Mais c'est bien sur dans le monde professionnel que c'est le plus sensible, avec la disparition des gros systèmes, et l'uniformisation de la micro informatique autour de windows.

Francois

[Luc Hermitte]

Ma foi, nous le gros serveur reste sous Solaris et les postes clients passent de Windows à Linux. Est-ce que je généralise que c'est la fin de Windows ?
Bon maintenant le client n'est pas un utilisateur lambda qui utilisera les postes clients pour faire du word. Il aura d'autres machines pour cela.

[JolyLoic]

Quand tu développes des bibliothèques, et non des applications finales, tu n'as déjà pas les mêmes critères de portabilité. Et même pour notre application 100% typique d'application d'entreprise/gestion, orientée windows, on nous a déjà demandé des portages sur PDA et téléphones portables...

[Invité]

Quand tu développes des bibliothèques, et non des applications finales, tu n'as déjà pas les mêmes critères de portabilité. Et même pour notre application 100% typique d'application d'entreprise/gestion, orientée windows, on nous a déjà demandé des portages sur PDA et téléphones portables...

Dans le cas des PDA et telephones, tu veux dire que tu as la même application qui tourne sur les deux? Ou juste un client spécifique, programme d'accès à l'application dédié aux PDA ou aux téléphones?

Ce qu'on entend, me semble-t-il par "portabilité", c'est la possibilité de transférer l'ensemble d'une application (avec ses données, et toutes ses fonctions) vers un autre système. Et là, j'ai l'impression que c'est un problème qui se pose de moins en moins (en partie parce que les machines coutent assez peu cher, en partie parce que les OS suivent le progrès des machines, ce qui n'était pas le cas autrefois).

En revanche, l'interopérabilité, c'est à dire le fait de pouvoir accéder, via des clients spécialisés, à un même système, depuis toutes sortes de terminaux, me semble un problème très commun, mais là, on est dans un problème très différent: en général les clients seront des programmes distinct, et pas le "portage" d'une application vers un autre système.

Francois

[Matthieu Brucher]

Ce qu'on entend, me semble-t-il par "portabilité", c'est la possibilité de transférer l'ensemble d'une application (avec ses données, et toutes ses fonctions) vers un autre système. Et là, j'ai l'impression que c'est un problème qui se pose de moins en moins (en partie parce que les machines coutent assez peu cher, en partie parce que les OS suivent le progrès des machines, ce qui n'était pas le cas autrefois).

Non, tu es sans doute dans un domaine qui est particulier et qui n'a pas ce problème. La portabilité est quelque chose qui est de plus en plus demandée (OS X gagne des parts de marché, tout comme Linux, par exemple, et ça ne se limite pas aux OS).

Bon, on a tout de même un peu trop dérivé, là...

[JolyLoic]

Dans le cas des PDA et telephones, tu veux dire que tu as la même application qui tourne sur les deux? Ou juste un client spécifique, programme d'accès à l'application dédié aux PDA ou aux téléphones?

On nous l'a demandé, mais on ne l'a pas fait (et on perd peut-être de l'argent) car justement l'application n'avait pas été prévue pour être portable. L'idée aurait été d'avoir un pan de notre application (pas tout, bien évidemment) sous ces environnements.

Et pour certains des prochains modules sur lesquels on travaille, on garde cette idée de portabilité en tête (certains utilisateurs potentiels, des visiteurs médicaux ne possèdent pas d'ordinateur portable, par exemple, surtout dans certains pays). Peut-être que ce ne sera pas exactement le même code qui tournera sous ces environnements, mais on n'a pas les moyens de maintenir 2 codes trop différents.