Segmentation fault.
J'ai tout d'abord eu du mal à identifier le problème, mais j'ai réussi
grâce à des supers pouvoirs hérités de Goldorak.
En fait, à la fin de la fonction foisDeux(), la variable temporaire
temp est détruite. Logique. En même temps, la fonction renvoie une
copie de l'objet, qui possède donc dans ses attributs un pointeur sur
une zone mémoire inaccessible (action du delete[]). Problème donc à la
destruction de ce dernier.
En fait, je ne sais pas trop comment arranger ce problème. Je ne
voudrais pas modifier *directement* les attributs de v1 dans la
fonction foisDeux(), pour garder ce vecteur en stock.
| Gabriel Dos Reis wrote: | > Olivier Azeau writes: | > [...] | > | Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une | > | bonne dose de fonctionnel le C++ n'est plus le 1er choix : pour des | > | raisons de sécurité (manque de contrôle sur les possibilités du | > | binaire généré), pour des raisons d'évolutivité (compilation, | > | dépendances binaires), ... | > Par « fonctionnel » tu veux dire quoi exactement ? | > | | Grosso modo, tout ce qui nécessite un importante connaissance métier | par opposition à ce qui nécessite un savoir faire beaucoup plus | informatique.
comme les gens (e.g. physicien ou matheux appliqués) qui font du calcul scientifique par exemple ?
Je ne connais pas bien ces métiers-là mais j'imagine que dans la mesure du possible ils vont utiliser des trucs genre MatLab (probablement écrit lui-même en C ou en C++ ?) en priorité ? Ce qui peut être différent sur ce genre de domaine c'est que la complexité algorithmique inhérente au métier ne permette pas une séparation trop importante entre l'ensemble de la réalisation logicielle et la connaissance fonctionnelle d'où une utilisation justifiée du C++ pour des gens dont le métier premier n'est pas de faire du logiciel.
Cependant (et cela rejoint un thread en cours sur fr.comp.objet) les aspects algorithmiques ne représentent qu'une petite portion de l'activité de réalisation de logiciels d'aujourd'hui.
Gabriel Dos Reis wrote:
Olivier Azeau <john@doe.com> writes:
| Gabriel Dos Reis wrote:
| > Olivier Azeau <john@doe.com> writes:
| > [...]
| > | Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une
| > | bonne dose de fonctionnel le C++ n'est plus le 1er choix : pour des
| > | raisons de sécurité (manque de contrôle sur les possibilités du
| > | binaire généré), pour des raisons d'évolutivité (compilation,
| > | dépendances binaires), ...
| > Par « fonctionnel » tu veux dire quoi exactement ?
| >
|
| Grosso modo, tout ce qui nécessite un importante connaissance métier
| par opposition à ce qui nécessite un savoir faire beaucoup plus
| informatique.
comme les gens (e.g. physicien ou matheux appliqués) qui font du
calcul scientifique par exemple ?
Je ne connais pas bien ces métiers-là mais j'imagine que dans la mesure
du possible ils vont utiliser des trucs genre MatLab (probablement écrit
lui-même en C ou en C++ ?) en priorité ?
Ce qui peut être différent sur ce genre de domaine c'est que la
complexité algorithmique inhérente au métier ne permette pas une
séparation trop importante entre l'ensemble de la réalisation logicielle
et la connaissance fonctionnelle d'où une utilisation justifiée du C++
pour des gens dont le métier premier n'est pas de faire du logiciel.
Cependant (et cela rejoint un thread en cours sur fr.comp.objet) les
aspects algorithmiques ne représentent qu'une petite portion de
l'activité de réalisation de logiciels d'aujourd'hui.
| Gabriel Dos Reis wrote: | > Olivier Azeau writes: | > [...] | > | Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une | > | bonne dose de fonctionnel le C++ n'est plus le 1er choix : pour des | > | raisons de sécurité (manque de contrôle sur les possibilités du | > | binaire généré), pour des raisons d'évolutivité (compilation, | > | dépendances binaires), ... | > Par « fonctionnel » tu veux dire quoi exactement ? | > | | Grosso modo, tout ce qui nécessite un importante connaissance métier | par opposition à ce qui nécessite un savoir faire beaucoup plus | informatique.
comme les gens (e.g. physicien ou matheux appliqués) qui font du calcul scientifique par exemple ?
Je ne connais pas bien ces métiers-là mais j'imagine que dans la mesure du possible ils vont utiliser des trucs genre MatLab (probablement écrit lui-même en C ou en C++ ?) en priorité ? Ce qui peut être différent sur ce genre de domaine c'est que la complexité algorithmique inhérente au métier ne permette pas une séparation trop importante entre l'ensemble de la réalisation logicielle et la connaissance fonctionnelle d'où une utilisation justifiée du C++ pour des gens dont le métier premier n'est pas de faire du logiciel.
Cependant (et cela rejoint un thread en cours sur fr.comp.objet) les aspects algorithmiques ne représentent qu'une petite portion de l'activité de réalisation de logiciels d'aujourd'hui.
Olivier Azeau
wrote:
Olivier Azeau wrote:
wrote:
Marc Boyer wrote:
In article <BE0wd.4482$, Olivier Azeau
wrote:
wrote:
[...]
Dans la pratique, je crois pouvoir dire que mon choix de langages est assez limité : C, C++, et peut-être Java et Ada. Parmi ces langages-là, pour efficacité du programmeur dans mon domaine d'application (serveurs importants, avec des clients dédiés), on peut écarter immédiatement le C, et assez vite le Java. L'Ada, c'est peut-être un alternatif intéressant, mais il manque de l'infrastruture et les outils de développement par rapport au C++.
J'ai eu l'occasion de travailler sur des serveurs de calcul qui devaient traiter de gros volumes de flux de données en "temps-réel" - ce qui signifiait en l'occurrence que le débit du flux de sortie ne doit pas être inférieur à celui d'entrée - et, effectivement, le C++ était probablement le meilleur choix *car* il y avait un grand souci de rapidité et de gestion de l'occupation mémoire.
Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une bonne dose de fonctionnel le C++ n'est plus le 1er choix : pour des raisons de sécurité (manque de contrôle sur les possibilités du binaire généré), pour des raisons d'évolutivité (compilation, dépendances binaires), ... Je ne compte plus les projets où l'on réserve le C++ aux parties pointues et où l'on introduit des langages plus légers et aux contours mieux limités, javascript par exemple, pour le fonctionnel ou l'intégration.
Et quel est le premier choix ? L'Ada, peut-être, mais les outils de développement ne sont pas toujours ce qu'on aimerait. Et c'est bigrement difficile à trouver des gens expérimentés en Ada 95.
VBA ? VB.NET ? C# ? Javascript ? PHP ? Python ?
Le serveur que je mentionnais plus haut fournissait un framework C++ pour séparer les aspects techniques des aspects métiers mais ce que la plupart des gens demandaient c'était d'avoir un framework leur permettant d'écrire la partie métier en "script".
Dans la pratique, quand il s'agit de sécurité, malgré ses défauts théorique, le C++ en sort plutôt bien. Quoiqu'on dise, c'est bien possible, et même assez facile, à écrire du mauvais code en n'importe quel langage. Quand la sécurité entre en jeu, il n'est pas question de se passer d'un bon processus de développement.
Or, si le C++ a souvent les choix par défaut qui ne conviennent pas, il permet toujours à passer outre, et je n'ai pas encore rencontré une situation où il m'a empéché de faire ultra-robuste. Chose que je ne peux pas dire pour certains autres langages modernes qui se vantent de leur fiabilité.
Je n'ai jamais dit qu'on ne peut pas faire du robuste en C++ : je dis juste que cela demande un bien plus grande maîtrise qu'avec d'autres langages et qu'il vaut mieux ne pas confier le C++ à n'importe qui.
[snip]
Pour ce qui est de la disponibilité des outils, C++ est peut-être
en
tête mais on constate tout de même que c'est loin d'être un choix systématique. cf par exemple les statistiques SourceForge sur http://c2.com/cgi/wiki?ProgrammingLanguagePopularity : C++ est en tête mais représente moins de 20% de l'ensemble.
Je ne prendrais pas un échantionnage des projets pris d'une façon aléatoire comme mésure de la qualité. Qu'il soit open source ou privé, la grande majorité des logiciels ne sont pas d'une qualité qui m'impressionne.
Oui, mais, s'ils répondent correctement à un besoin, cela ne suffit-il pas à justifier leur existence ?
[snip]
On peut lire aussi sur http://c2.com/cgi/wiki?ProgrammingLanguageUsageStatistics :
"According
to IDC, out of 13 million developer seats worldwide in 1999, Visual Basic had 7.2 million vs. 3.6 million for C/C++ seats and 1.3 million Java seats. By 2003, Visual basic should still be ahead with 7.4 million, but the race will be closer with 5.2 million C/C++ developer seats, and 4.4 million Java seats." Sans compter que dans le lot C++, on compte bien évidemment les "dialectes" comme COM/C++ qui est très présent et qui n'est qu'un lointain cousin d'un C++ qui se voudrait proche de Ada.
Mais quel rapport ? Si tu enseignes des techniciens qui vont écrire des applications client vite fait, c'est probablement le VB qu'il faut enseigner, plutôt que le C++. J'avoue être un peu élitiste, mais je n'appelle pas ça la programmation:-). (Même is je sais que ce l'est, et que dans son contexte, c'est aussi valable que ce que je fais.)
Ce que tu décris, c'est la réalité mais c'est aussi un peu de la caricature. Quand je vois, par exemple, ce qu'on arrive à faire en utilisant uniquement de la programmation déclarative mixant HTML/XSLT/XML/SQL, je me dis que mon C++ adoré a quelquefois plusieurs trains de retard.
kanze@gabi-soft.fr wrote:
Olivier Azeau wrote:
kanze@gabi-soft.fr wrote:
Marc Boyer wrote:
In article <BE0wd.4482$Of5.3019@nntpserver.swip.net>, Olivier Azeau
wrote:
kanze@gabi-soft.fr wrote:
[...]
Dans la pratique, je crois pouvoir dire que mon choix de
langages est assez limité : C, C++, et peut-être Java et
Ada. Parmi ces langages-là, pour efficacité du programmeur dans
mon domaine d'application (serveurs importants, avec des clients
dédiés), on peut écarter immédiatement le C, et assez vite le
Java. L'Ada, c'est peut-être un alternatif intéressant, mais il
manque de l'infrastruture et les outils de développement par
rapport au C++.
J'ai eu l'occasion de travailler sur des serveurs de calcul
qui devaient traiter de gros volumes de flux de données en
"temps-réel" - ce qui signifiait en l'occurrence que le débit
du flux de sortie ne doit pas être inférieur à celui d'entrée
- et, effectivement, le C++ était probablement le meilleur
choix *car* il y avait un grand souci de rapidité et de
gestion de l'occupation mémoire.
Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler
une bonne dose de fonctionnel le C++ n'est plus le 1er choix :
pour des raisons de sécurité (manque de contrôle sur les
possibilités du binaire généré), pour des raisons
d'évolutivité (compilation, dépendances binaires), ... Je ne
compte plus les projets où l'on réserve le C++ aux parties
pointues et où l'on introduit des langages plus légers et aux
contours mieux limités, javascript par exemple, pour le
fonctionnel ou l'intégration.
Et quel est le premier choix ? L'Ada, peut-être, mais les outils
de développement ne sont pas toujours ce qu'on aimerait. Et
c'est bigrement difficile à trouver des gens expérimentés en Ada
95.
VBA ? VB.NET ? C# ? Javascript ? PHP ? Python ?
Le serveur que je mentionnais plus haut fournissait un framework C++
pour séparer les aspects techniques des aspects métiers mais ce que la
plupart des gens demandaient c'était d'avoir un framework leur
permettant d'écrire la partie métier en "script".
Dans la pratique, quand il s'agit de sécurité, malgré ses
défauts théorique, le C++ en sort plutôt bien. Quoiqu'on dise,
c'est bien possible, et même assez facile, à écrire du mauvais
code en n'importe quel langage. Quand la sécurité entre en jeu,
il n'est pas question de se passer d'un bon processus de
développement.
Or, si le C++ a souvent les choix par défaut qui ne conviennent
pas, il permet toujours à passer outre, et je n'ai pas encore
rencontré une situation où il m'a empéché de faire
ultra-robuste. Chose que je ne peux pas dire pour certains
autres langages modernes qui se vantent de leur fiabilité.
Je n'ai jamais dit qu'on ne peut pas faire du robuste en C++ : je dis
juste que cela demande un bien plus grande maîtrise qu'avec d'autres
langages et qu'il vaut mieux ne pas confier le C++ à n'importe qui.
[snip]
Pour ce qui est de la disponibilité des outils, C++ est peut-être
en
tête mais on constate tout de même que c'est loin d'être un choix
systématique. cf par exemple les statistiques SourceForge sur
http://c2.com/cgi/wiki?ProgrammingLanguagePopularity : C++ est en
tête mais représente moins de 20% de l'ensemble.
Je ne prendrais pas un échantionnage des projets pris d'une
façon aléatoire comme mésure de la qualité. Qu'il soit open
source ou privé, la grande majorité des logiciels ne sont pas
d'une qualité qui m'impressionne.
Oui, mais, s'ils répondent correctement à un besoin, cela ne suffit-il
pas à justifier leur existence ?
[snip]
On peut lire aussi sur
http://c2.com/cgi/wiki?ProgrammingLanguageUsageStatistics :
"According
to IDC, out of 13 million developer seats worldwide in 1999, Visual
Basic had 7.2 million vs. 3.6 million for C/C++ seats and 1.3 million
Java seats. By 2003, Visual basic should still be ahead with 7.4
million, but the race will be closer with 5.2 million C/C++ developer
seats, and 4.4 million Java seats."
Sans compter que dans le lot C++, on compte bien évidemment les
"dialectes" comme COM/C++ qui est très présent et qui n'est qu'un
lointain cousin d'un C++ qui se voudrait proche de Ada.
Mais quel rapport ? Si tu enseignes des techniciens qui vont
écrire des applications client vite fait, c'est probablement le
VB qu'il faut enseigner, plutôt que le C++. J'avoue être un peu
élitiste, mais je n'appelle pas ça la programmation:-). (Même is
je sais que ce l'est, et que dans son contexte, c'est aussi
valable que ce que je fais.)
Ce que tu décris, c'est la réalité mais c'est aussi un peu de la caricature.
Quand je vois, par exemple, ce qu'on arrive à faire en utilisant
uniquement de la programmation déclarative mixant HTML/XSLT/XML/SQL, je
me dis que mon C++ adoré a quelquefois plusieurs trains de retard.
Dans la pratique, je crois pouvoir dire que mon choix de langages est assez limité : C, C++, et peut-être Java et Ada. Parmi ces langages-là, pour efficacité du programmeur dans mon domaine d'application (serveurs importants, avec des clients dédiés), on peut écarter immédiatement le C, et assez vite le Java. L'Ada, c'est peut-être un alternatif intéressant, mais il manque de l'infrastruture et les outils de développement par rapport au C++.
J'ai eu l'occasion de travailler sur des serveurs de calcul qui devaient traiter de gros volumes de flux de données en "temps-réel" - ce qui signifiait en l'occurrence que le débit du flux de sortie ne doit pas être inférieur à celui d'entrée - et, effectivement, le C++ était probablement le meilleur choix *car* il y avait un grand souci de rapidité et de gestion de l'occupation mémoire.
Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une bonne dose de fonctionnel le C++ n'est plus le 1er choix : pour des raisons de sécurité (manque de contrôle sur les possibilités du binaire généré), pour des raisons d'évolutivité (compilation, dépendances binaires), ... Je ne compte plus les projets où l'on réserve le C++ aux parties pointues et où l'on introduit des langages plus légers et aux contours mieux limités, javascript par exemple, pour le fonctionnel ou l'intégration.
Et quel est le premier choix ? L'Ada, peut-être, mais les outils de développement ne sont pas toujours ce qu'on aimerait. Et c'est bigrement difficile à trouver des gens expérimentés en Ada 95.
VBA ? VB.NET ? C# ? Javascript ? PHP ? Python ?
Le serveur que je mentionnais plus haut fournissait un framework C++ pour séparer les aspects techniques des aspects métiers mais ce que la plupart des gens demandaient c'était d'avoir un framework leur permettant d'écrire la partie métier en "script".
Dans la pratique, quand il s'agit de sécurité, malgré ses défauts théorique, le C++ en sort plutôt bien. Quoiqu'on dise, c'est bien possible, et même assez facile, à écrire du mauvais code en n'importe quel langage. Quand la sécurité entre en jeu, il n'est pas question de se passer d'un bon processus de développement.
Or, si le C++ a souvent les choix par défaut qui ne conviennent pas, il permet toujours à passer outre, et je n'ai pas encore rencontré une situation où il m'a empéché de faire ultra-robuste. Chose que je ne peux pas dire pour certains autres langages modernes qui se vantent de leur fiabilité.
Je n'ai jamais dit qu'on ne peut pas faire du robuste en C++ : je dis juste que cela demande un bien plus grande maîtrise qu'avec d'autres langages et qu'il vaut mieux ne pas confier le C++ à n'importe qui.
[snip]
Pour ce qui est de la disponibilité des outils, C++ est peut-être
en
tête mais on constate tout de même que c'est loin d'être un choix systématique. cf par exemple les statistiques SourceForge sur http://c2.com/cgi/wiki?ProgrammingLanguagePopularity : C++ est en tête mais représente moins de 20% de l'ensemble.
Je ne prendrais pas un échantionnage des projets pris d'une façon aléatoire comme mésure de la qualité. Qu'il soit open source ou privé, la grande majorité des logiciels ne sont pas d'une qualité qui m'impressionne.
Oui, mais, s'ils répondent correctement à un besoin, cela ne suffit-il pas à justifier leur existence ?
[snip]
On peut lire aussi sur http://c2.com/cgi/wiki?ProgrammingLanguageUsageStatistics :
"According
to IDC, out of 13 million developer seats worldwide in 1999, Visual Basic had 7.2 million vs. 3.6 million for C/C++ seats and 1.3 million Java seats. By 2003, Visual basic should still be ahead with 7.4 million, but the race will be closer with 5.2 million C/C++ developer seats, and 4.4 million Java seats." Sans compter que dans le lot C++, on compte bien évidemment les "dialectes" comme COM/C++ qui est très présent et qui n'est qu'un lointain cousin d'un C++ qui se voudrait proche de Ada.
Mais quel rapport ? Si tu enseignes des techniciens qui vont écrire des applications client vite fait, c'est probablement le VB qu'il faut enseigner, plutôt que le C++. J'avoue être un peu élitiste, mais je n'appelle pas ça la programmation:-). (Même is je sais que ce l'est, et que dans son contexte, c'est aussi valable que ce que je fais.)
Ce que tu décris, c'est la réalité mais c'est aussi un peu de la caricature. Quand je vois, par exemple, ce qu'on arrive à faire en utilisant uniquement de la programmation déclarative mixant HTML/XSLT/XML/SQL, je me dis que mon C++ adoré a quelquefois plusieurs trains de retard.
Christophe Lephay
"Olivier Azeau" a écrit dans le message de news: cRxwd.4874$
wrote:
Or, si le C++ a souvent les choix par défaut qui ne conviennent pas, il permet toujours à passer outre, et je n'ai pas encore rencontré une situation où il m'a empéché de faire ultra-robuste. Chose que je ne peux pas dire pour certains autres langages modernes qui se vantent de leur fiabilité.
Je n'ai jamais dit qu'on ne peut pas faire du robuste en C++ : je dis juste que cela demande un bien plus grande maîtrise qu'avec d'autres langages et qu'il vaut mieux ne pas confier le C++ à n'importe qui.
Mais ce que James dit, c'est qu'il est difficile de faire aussi robuste avec les alternatives, pas que ça requiert plus, ou moins, de compétences qu'avec tel ou tel autre langage.
Chris
"Olivier Azeau" <john@doe.com> a écrit dans le message de news:
cRxwd.4874$Of5.3529@nntpserver.swip.net...
kanze@gabi-soft.fr wrote:
Or, si le C++ a souvent les choix par défaut qui ne conviennent
pas, il permet toujours à passer outre, et je n'ai pas encore
rencontré une situation où il m'a empéché de faire
ultra-robuste. Chose que je ne peux pas dire pour certains
autres langages modernes qui se vantent de leur fiabilité.
Je n'ai jamais dit qu'on ne peut pas faire du robuste en C++ : je dis
juste que cela demande un bien plus grande maîtrise qu'avec d'autres
langages et qu'il vaut mieux ne pas confier le C++ à n'importe qui.
Mais ce que James dit, c'est qu'il est difficile de faire aussi robuste avec
les alternatives, pas que ça requiert plus, ou moins, de compétences qu'avec
tel ou tel autre langage.
"Olivier Azeau" a écrit dans le message de news: cRxwd.4874$
wrote:
Or, si le C++ a souvent les choix par défaut qui ne conviennent pas, il permet toujours à passer outre, et je n'ai pas encore rencontré une situation où il m'a empéché de faire ultra-robuste. Chose que je ne peux pas dire pour certains autres langages modernes qui se vantent de leur fiabilité.
Je n'ai jamais dit qu'on ne peut pas faire du robuste en C++ : je dis juste que cela demande un bien plus grande maîtrise qu'avec d'autres langages et qu'il vaut mieux ne pas confier le C++ à n'importe qui.
Mais ce que James dit, c'est qu'il est difficile de faire aussi robuste avec les alternatives, pas que ça requiert plus, ou moins, de compétences qu'avec tel ou tel autre langage.
Chris
Gabriel Dos Reis
Olivier Azeau writes:
| Gabriel Dos Reis wrote: | > Olivier Azeau writes: | > | Gabriel Dos Reis wrote: | > | > Olivier Azeau writes: | > | > [...] | > | > | Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une | > | > | bonne dose de fonctionnel le C++ n'est plus le 1er choix : pour des | > | > | raisons de sécurité (manque de contrôle sur les possibilités du | > | > | binaire généré), pour des raisons d'évolutivité (compilation, | > | > | dépendances binaires), ... | > | > Par « fonctionnel » tu veux dire quoi exactement ? | > | > | > | | Grosso modo, tout ce qui nécessite un importante connaissance | > métier | > | par opposition à ce qui nécessite un savoir faire beaucoup plus | > | informatique. | > comme les gens (e.g. physicien ou matheux appliqués) qui font du | > calcul scientifique par exemple ? | > | | Je ne connais pas bien ces métiers-là mais j'imagine que dans la | mesure du possible ils vont utiliser des trucs genre MatLab | (probablement écrit lui-même en C ou en C++ ?) en priorité ?
Matlab pour les cours, très certainement, pour les petites expériences, oui. Mais pour de vrais applications qui tournent, non. Ces gens là utilisaient Fortran, ils ont tenté une migration vers le C -- ce qui explique la nature de C99. Mais la considération de C++ ne va qu'en croissant, depuis 94. Ces gens là ne veulent pas devenir informaticiens, ils sont contents de leur métiers ; mais ils veulent utiliser C++ pour maîstriser la complexité des applications. J'ai observé cela en Europe, c'est encore plus criaard ici. Le projet ASCI -- fondé par les (US) National Labs -- dépensent des sommes astronomiques dans la mise en place d'outils de développement et une très bonne partie va à Fortran et C++.
| Ce qui peut être différent sur ce genre de domaine c'est que la | complexité algorithmique inhérente au métier ne permette pas une | séparation trop importante entre l'ensemble de la réalisation
C'est une idée générale, tellement générale que quand on regarde de près, on se rend compte que l'un des aspects lus plus importants, c'est la complexité logicielle -- et non seulement algorithmique -- qui tend à dominer le développement. Les structures de données ne sont plus de simples tableaux. La variété d'algorithmes, chacun avec ses propres avantages et inconvérient, tend souvent privilégier une approche orienté objet au haut niveau, et une approche moins abstraite dans les couches intermédiaires et de bas niveau. Laurent Deniau pourra vous en dire plus. Mais ces gens ne veulent pas devenir informaticiens.
| logicielle et la connaissance fonctionnelle d'où une utilisation | justifiée du C++ pour des gens dont le métier premier n'est pas de | faire du logiciel. | | Cependant (et cela rejoint un thread en cours sur fr.comp.objet) les | aspects algorithmiques ne représentent qu'une petite portion de | l'activité de réalisation de logiciels d'aujourd'hui. | | |
-- Gabriel Dos Reis
Olivier Azeau <john@doe.com> writes:
| Gabriel Dos Reis wrote:
| > Olivier Azeau <john@doe.com> writes:
| > | Gabriel Dos Reis wrote:
| > | > Olivier Azeau <john@doe.com> writes:
| > | > [...]
| > | > | Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une
| > | > | bonne dose de fonctionnel le C++ n'est plus le 1er choix : pour des
| > | > | raisons de sécurité (manque de contrôle sur les possibilités du
| > | > | binaire généré), pour des raisons d'évolutivité (compilation,
| > | > | dépendances binaires), ...
| > | > Par « fonctionnel » tu veux dire quoi exactement ?
| > | >
| > | | Grosso modo, tout ce qui nécessite un importante connaissance
| > métier
| > | par opposition à ce qui nécessite un savoir faire beaucoup plus
| > | informatique.
| > comme les gens (e.g. physicien ou matheux appliqués) qui font du
| > calcul scientifique par exemple ?
| >
|
| Je ne connais pas bien ces métiers-là mais j'imagine que dans la
| mesure du possible ils vont utiliser des trucs genre MatLab
| (probablement écrit lui-même en C ou en C++ ?) en priorité ?
Matlab pour les cours, très certainement, pour les petites
expériences, oui.
Mais pour de vrais applications qui tournent, non. Ces gens là
utilisaient Fortran, ils ont tenté une migration vers le C -- ce qui
explique la nature de C99. Mais la considération de C++ ne va qu'en
croissant, depuis 94. Ces gens là ne veulent pas devenir
informaticiens, ils sont contents de leur métiers ; mais ils veulent
utiliser C++ pour maîstriser la complexité des applications. J'ai
observé cela en Europe, c'est encore plus criaard ici.
Le projet ASCI -- fondé par les (US) National Labs -- dépensent des
sommes astronomiques dans la mise en place d'outils de développement
et une très bonne partie va à Fortran et C++.
| Ce qui peut être différent sur ce genre de domaine c'est que la
| complexité algorithmique inhérente au métier ne permette pas une
| séparation trop importante entre l'ensemble de la réalisation
C'est une idée générale, tellement générale que quand on regarde de
près, on se rend compte que l'un des aspects lus plus importants,
c'est la complexité logicielle -- et non seulement algorithmique --
qui tend à dominer le développement. Les structures de données ne sont
plus de simples tableaux. La variété d'algorithmes, chacun avec ses
propres avantages et inconvérient, tend souvent privilégier une
approche orienté objet au haut niveau, et une approche moins abstraite
dans les couches intermédiaires et de bas niveau. Laurent Deniau
pourra vous en dire plus. Mais ces gens ne veulent pas devenir
informaticiens.
| logicielle et la connaissance fonctionnelle d'où une utilisation
| justifiée du C++ pour des gens dont le métier premier n'est pas de
| faire du logiciel.
|
| Cependant (et cela rejoint un thread en cours sur fr.comp.objet) les
| aspects algorithmiques ne représentent qu'une petite portion de
| l'activité de réalisation de logiciels d'aujourd'hui.
|
|
|
| Gabriel Dos Reis wrote: | > Olivier Azeau writes: | > | Gabriel Dos Reis wrote: | > | > Olivier Azeau writes: | > | > [...] | > | > | Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une | > | > | bonne dose de fonctionnel le C++ n'est plus le 1er choix : pour des | > | > | raisons de sécurité (manque de contrôle sur les possibilités du | > | > | binaire généré), pour des raisons d'évolutivité (compilation, | > | > | dépendances binaires), ... | > | > Par « fonctionnel » tu veux dire quoi exactement ? | > | > | > | | Grosso modo, tout ce qui nécessite un importante connaissance | > métier | > | par opposition à ce qui nécessite un savoir faire beaucoup plus | > | informatique. | > comme les gens (e.g. physicien ou matheux appliqués) qui font du | > calcul scientifique par exemple ? | > | | Je ne connais pas bien ces métiers-là mais j'imagine que dans la | mesure du possible ils vont utiliser des trucs genre MatLab | (probablement écrit lui-même en C ou en C++ ?) en priorité ?
Matlab pour les cours, très certainement, pour les petites expériences, oui. Mais pour de vrais applications qui tournent, non. Ces gens là utilisaient Fortran, ils ont tenté une migration vers le C -- ce qui explique la nature de C99. Mais la considération de C++ ne va qu'en croissant, depuis 94. Ces gens là ne veulent pas devenir informaticiens, ils sont contents de leur métiers ; mais ils veulent utiliser C++ pour maîstriser la complexité des applications. J'ai observé cela en Europe, c'est encore plus criaard ici. Le projet ASCI -- fondé par les (US) National Labs -- dépensent des sommes astronomiques dans la mise en place d'outils de développement et une très bonne partie va à Fortran et C++.
| Ce qui peut être différent sur ce genre de domaine c'est que la | complexité algorithmique inhérente au métier ne permette pas une | séparation trop importante entre l'ensemble de la réalisation
C'est une idée générale, tellement générale que quand on regarde de près, on se rend compte que l'un des aspects lus plus importants, c'est la complexité logicielle -- et non seulement algorithmique -- qui tend à dominer le développement. Les structures de données ne sont plus de simples tableaux. La variété d'algorithmes, chacun avec ses propres avantages et inconvérient, tend souvent privilégier une approche orienté objet au haut niveau, et une approche moins abstraite dans les couches intermédiaires et de bas niveau. Laurent Deniau pourra vous en dire plus. Mais ces gens ne veulent pas devenir informaticiens.
| logicielle et la connaissance fonctionnelle d'où une utilisation | justifiée du C++ pour des gens dont le métier premier n'est pas de | faire du logiciel. | | Cependant (et cela rejoint un thread en cours sur fr.comp.objet) les | aspects algorithmiques ne représentent qu'une petite portion de | l'activité de réalisation de logiciels d'aujourd'hui. | | |
-- Gabriel Dos Reis
Gabriel Dos Reis
writes:
[...]
| Et quel est le premier choix ? L'Ada, peut-être, mais les outils | de développement ne sont pas toujours ce qu'on aimerait. Et | c'est bigrement difficile à trouver des gens expérimentés en Ada | 95. | | Dans la pratique, quand il s'agit de sécurité, malgré ses | défauts théorique, le C++ en sort plutôt bien. Quoiqu'on dise,
Yep. Le truc, c'est qu'il faut comprendre que C++ fournit des soutils pour écrire des codes sécures, même si certains aspects hérités de C ou pour la programmation système inciteraient quelqu'un à énoncer un théorème général de non-sécurité. La vérité c'est que quand on écrit un programme en C++, en général on écrit dans un sous-ensemble -- on n'est pas obligé d'utiliser tout le langage. Il y a des gens à JPL qui utilisent C++ pour des missions critiques -- savais-tu que le robot sur Mars tournent un OS écrit en C++ et est commandé sur terre par des logiciels écrits en C++ ? Des logiciels de transaction, à l'échelle européenne, tournant 24h sur 24, 4 jours sur 7 écrits en C++.
-- Gaby
kanze@gabi-soft.fr writes:
[...]
| Et quel est le premier choix ? L'Ada, peut-être, mais les outils
| de développement ne sont pas toujours ce qu'on aimerait. Et
| c'est bigrement difficile à trouver des gens expérimentés en Ada
| 95.
|
| Dans la pratique, quand il s'agit de sécurité, malgré ses
| défauts théorique, le C++ en sort plutôt bien. Quoiqu'on dise,
Yep. Le truc, c'est qu'il faut comprendre que C++ fournit des soutils
pour écrire des codes sécures, même si certains aspects hérités de C ou
pour la programmation système inciteraient quelqu'un à énoncer un
théorème général de non-sécurité. La vérité c'est que quand on écrit
un programme en C++, en général on écrit dans un sous-ensemble -- on
n'est pas obligé d'utiliser tout le langage. Il y a des gens à JPL qui
utilisent C++ pour des missions critiques -- savais-tu que le robot
sur Mars tournent un OS écrit en C++ et est commandé sur terre par des
logiciels écrits en C++ ?
Des logiciels de transaction, à l'échelle européenne, tournant 24h sur
24, 4 jours sur 7 écrits en C++.
| Et quel est le premier choix ? L'Ada, peut-être, mais les outils | de développement ne sont pas toujours ce qu'on aimerait. Et | c'est bigrement difficile à trouver des gens expérimentés en Ada | 95. | | Dans la pratique, quand il s'agit de sécurité, malgré ses | défauts théorique, le C++ en sort plutôt bien. Quoiqu'on dise,
Yep. Le truc, c'est qu'il faut comprendre que C++ fournit des soutils pour écrire des codes sécures, même si certains aspects hérités de C ou pour la programmation système inciteraient quelqu'un à énoncer un théorème général de non-sécurité. La vérité c'est que quand on écrit un programme en C++, en général on écrit dans un sous-ensemble -- on n'est pas obligé d'utiliser tout le langage. Il y a des gens à JPL qui utilisent C++ pour des missions critiques -- savais-tu que le robot sur Mars tournent un OS écrit en C++ et est commandé sur terre par des logiciels écrits en C++ ? Des logiciels de transaction, à l'échelle européenne, tournant 24h sur 24, 4 jours sur 7 écrits en C++.
-- Gaby
Gabriel Dos Reis
Olivier Azeau writes:
[...]
| Je n'ai jamais dit qu'on ne peut pas faire du robuste en C++ : je dis | juste que cela demande un bien plus grande maîtrise qu'avec d'autres | langages et qu'il vaut mieux ne pas confier le C++ à n'importe qui.
Je demanderais pas à notre assistante de faire les « paper work » avec C++. C'est sûr.
-- Gaby
http://www.research.att.com/~bs/applications.html
Olivier Azeau <john@doe.com> writes:
[...]
| Je n'ai jamais dit qu'on ne peut pas faire du robuste en C++ : je dis
| juste que cela demande un bien plus grande maîtrise qu'avec d'autres
| langages et qu'il vaut mieux ne pas confier le C++ à n'importe qui.
Je demanderais pas à notre assistante de faire les « paper work » avec
C++. C'est sûr.
| Je n'ai jamais dit qu'on ne peut pas faire du robuste en C++ : je dis | juste que cela demande un bien plus grande maîtrise qu'avec d'autres | langages et qu'il vaut mieux ne pas confier le C++ à n'importe qui.
Je demanderais pas à notre assistante de faire les « paper work » avec C++. C'est sûr.
-- Gaby
http://www.research.att.com/~bs/applications.html
drkm
Gabriel Dos Reis writes:
Des logiciels de transaction, à l'échelle européenne, tournant 24h sur 24, 4 jours sur 7 écrits en C++.
Avec 3 jours de maintenance sur 7 ?-)
--drkm
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
Des logiciels de transaction, à l'échelle européenne, tournant 24h sur
24, 4 jours sur 7 écrits en C++.
Des logiciels de transaction, à l'échelle européenne, tournant 24h sur 24, 4 jours sur 7 écrits en C++.
Avec 3 jours de maintenance sur 7 ?-)
--drkm
Gabriel Dos Reis
drkm writes:
| Gabriel Dos Reis writes: | | > Des logiciels de transaction, à l'échelle européenne, tournant 24h sur | > 24, 4 jours sur 7 écrits en C++. | | Avec 3 jours de maintenance sur 7 ?-)
Way. Comme tu l'as deviné, je voulais écrire 7 jours sur 7. Je ne sais pas d'où vient le 4 :-(
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > Des logiciels de transaction, à l'échelle européenne, tournant 24h sur
| > 24, 4 jours sur 7 écrits en C++.
|
| Avec 3 jours de maintenance sur 7 ?-)
Way. Comme tu l'as deviné, je voulais écrire 7 jours sur 7.
Je ne sais pas d'où vient le 4 :-(
| Gabriel Dos Reis writes: | | > Des logiciels de transaction, à l'échelle européenne, tournant 24h sur | > 24, 4 jours sur 7 écrits en C++. | | Avec 3 jours de maintenance sur 7 ?-)
Way. Comme tu l'as deviné, je voulais écrire 7 jours sur 7. Je ne sais pas d'où vient le 4 :-(
-- Gaby
drkm
Gabriel Dos Reis writes:
Je ne sais pas d'où vient le 4 :-(
Juste au-dessous du 7 sur le pavé numérique ?
--drkm
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
