Vu d'un néophyte (pas débutant, mais pas très bon), quelles
différences y a-t-il entre Java et C++, mis à part quelques petites
particularités syntaxiques (syntaxe de création d'un tableau,
l'utilisation de destructeur d'objet, l'initialisation par défaut des
champs) ? Est-ce que l'héritage multiple change vraiment quelque chose
?
Où puis-je trouver un document clair (français ou anglais) qui me
permette de faire la transition (j'ai lu un article disant que C/C++
était plus rapide que Java et nécessitait moins de lignes) ?
Merci d'avance.
Tu en es sûr. Pour avoir les perfs qu'ils veulent, il suffit d'acheter une machine plus puissante.
Encore faut-il qu'elle existe... Les problemes dans ce que tu dis : - Un logiciel mono-thread doit etre completement revu pour gerer plusieurs CPU - Un CPU a une frequence max, que meme a n'importe quel prix un fournisseur de matos ne peux fournir - Les licences sont vendues par machine, donc rajouter une machine pour gerer les perfs (faisable dans mon exemple perso) coute cher. (pb du non gratuit... :), et de grosses entreprises ayant des grilles qu'elles n'adaptent pas)
Ou sinon, ce n'est pas les différences de performance d'un langage à l'autre qui vont faire l'affaire. Or, la prix d'une machine plus performant, c'est combien : 2000 Euros ? 10000 ? Tandis que le prix d'un mois de plus de développement ?
Quand elle existe, je susi bien d'accord : ca vaut le coup! A conduition que la licence suive, et qu'elle ne soit pas dependante du nombre de machine, comme c'est très souvent le cas
Je me facture à 500 Euros le jours, bas prix -- c'est environ 10000 Euros par mois, sans compter les frais annex.
Euh... Ca paye pas beaucoup les experts C++ :(
Mais qu'est-ce qui te fait dire que le Java n'est pas compilé. La compilation a lieu bien évidemment lors du chargement, chaque fois qu'on démarre l'appli.
Ca m'apprendra a pas me renseigner, et ne pas etre logique. J'y avait pas pensé comme ca. Donc OK, je me suis bien planté :)
James Kanze wrote:
Tu en es sûr. Pour avoir les perfs qu'ils veulent, il suffit
d'acheter une machine plus puissante.
Encore faut-il qu'elle existe...
Les problemes dans ce que tu dis :
- Un logiciel mono-thread doit etre completement revu pour gerer
plusieurs CPU
- Un CPU a une frequence max, que meme a n'importe quel prix un
fournisseur de matos ne peux fournir
- Les licences sont vendues par machine, donc rajouter une machine pour
gerer les perfs (faisable dans mon exemple perso) coute cher. (pb du non
gratuit... :), et de grosses entreprises ayant des grilles qu'elles
n'adaptent pas)
Ou sinon, ce n'est pas les
différences de performance d'un langage à l'autre qui vont faire
l'affaire. Or, la prix d'une machine plus performant, c'est combien :
2000 Euros ? 10000 ? Tandis que le prix d'un mois de plus de
développement ?
Quand elle existe, je susi bien d'accord : ca vaut le coup!
A conduition que la licence suive, et qu'elle ne soit pas
dependante du nombre de machine, comme c'est très souvent le cas
Je me facture à 500 Euros le jours, bas prix --
c'est environ 10000 Euros par mois, sans compter les frais annex.
Euh... Ca paye pas beaucoup les experts C++ :(
Mais qu'est-ce qui te fait dire que le Java n'est pas compilé. La
compilation a lieu bien évidemment lors du chargement, chaque fois
qu'on démarre l'appli.
Ca m'apprendra a pas me renseigner, et ne pas etre logique.
J'y avait pas pensé comme ca.
Donc OK, je me suis bien planté :)
Tu en es sûr. Pour avoir les perfs qu'ils veulent, il suffit d'acheter une machine plus puissante.
Encore faut-il qu'elle existe... Les problemes dans ce que tu dis : - Un logiciel mono-thread doit etre completement revu pour gerer plusieurs CPU - Un CPU a une frequence max, que meme a n'importe quel prix un fournisseur de matos ne peux fournir - Les licences sont vendues par machine, donc rajouter une machine pour gerer les perfs (faisable dans mon exemple perso) coute cher. (pb du non gratuit... :), et de grosses entreprises ayant des grilles qu'elles n'adaptent pas)
Ou sinon, ce n'est pas les différences de performance d'un langage à l'autre qui vont faire l'affaire. Or, la prix d'une machine plus performant, c'est combien : 2000 Euros ? 10000 ? Tandis que le prix d'un mois de plus de développement ?
Quand elle existe, je susi bien d'accord : ca vaut le coup! A conduition que la licence suive, et qu'elle ne soit pas dependante du nombre de machine, comme c'est très souvent le cas
Je me facture à 500 Euros le jours, bas prix -- c'est environ 10000 Euros par mois, sans compter les frais annex.
Euh... Ca paye pas beaucoup les experts C++ :(
Mais qu'est-ce qui te fait dire que le Java n'est pas compilé. La compilation a lieu bien évidemment lors du chargement, chaque fois qu'on démarre l'appli.
Ca m'apprendra a pas me renseigner, et ne pas etre logique. J'y avait pas pensé comme ca. Donc OK, je me suis bien planté :)
Christophe Lephay
"Vincent" a écrit dans le message de news:
total = prixHorsTaxe.applyTaxe(tva); Est tout à fait acceptable et applyTaxe n'est guère plus long à écrire que la surcharge de l'opérateur. Même si l'opérateur peut être employé ailleurs...
Alors, il faut que tu introduit une classe supplémentaire Pour surcharger l'opérateur plus il te faut bien aussi une classe Prix
ou un truc dans ce goût là, non?
Non. tu peux avoir juste une classe prix qui gère ces opérations. Avec ton exemple, tu risque de multiplier et les classes (pour les prix hors taxes, les prix ttc, les prix auxquels la tva ne s'appliquent pas).
-- une valeur décimale qui connaît la TVA française. Dans l'exemple C++ comme Java la TVA est dans l'appel, mais ça n'est
pas forcément une bonne idée...
Mais ce n'était qu'un exemple simple. Que faire dans les programmes du marché, par exemple, où les formules qu'on manipule sont vraiment compliqués, et qu'ils changent assez souvent. Je ne vois pas l'avantage d'un opérateur par rapport à une fonction
pour l'évolutivité.
Je suis assez d'accord...
Très clairement soit c'est simple ou très peu usagé et utiliser add() ou mult() est un peu plus pénible, mais pas bloquant. Sois c'est compliqué et il y a intérêt à encapsuler dans une fonction, ne serait-ce que pour l'évolutivité du code... Je ne crois pas que le fait que la surcharge d'opérateur permette d'écrire des formules complexe et volatile en dehors d'une encapsulation soit un atout...
L'intéret des opérateurs sur les fonctions devient évident lorsque les formules deviennent complexes. Par exemple comprendre un calcul d'amortissement dégressif ou de coefficient de corrélation sera plus facile avec des opérateurs surchargés qu'avec des fonctions...
Chris
"Vincent" <vclassine@elan.fr> a écrit dans le message de
news:9e49e584.0307300124.553dbdc3@posting.google.com...
total = prixHorsTaxe.applyTaxe(tva);
Est tout à fait acceptable et applyTaxe n'est guère plus long à écrire
que la surcharge de l'opérateur. Même si l'opérateur peut être employé
ailleurs...
Alors, il faut que tu introduit une classe supplémentaire
Pour surcharger l'opérateur plus il te faut bien aussi une classe Prix
ou un truc dans ce goût là, non?
Non. tu peux avoir juste une classe prix qui gère ces opérations. Avec ton
exemple, tu risque de multiplier et les classes (pour les prix hors taxes,
les prix ttc, les prix auxquels la tva ne s'appliquent pas).
-- une valeur
décimale qui connaît la TVA française.
Dans l'exemple C++ comme Java la TVA est dans l'appel, mais ça n'est
pas forcément une bonne idée...
Mais ce n'était qu'un exemple simple. Que faire dans les programmes du
marché, par exemple, où les formules qu'on manipule sont vraiment
compliqués, et qu'ils changent assez souvent.
Je ne vois pas l'avantage d'un opérateur par rapport à une fonction
pour l'évolutivité.
Je suis assez d'accord...
Très clairement soit c'est simple ou très peu
usagé et utiliser add() ou mult() est un peu plus pénible, mais pas
bloquant. Sois c'est compliqué et il y a intérêt à encapsuler dans une
fonction, ne serait-ce que pour l'évolutivité du code... Je ne crois
pas que le fait que la surcharge d'opérateur permette d'écrire des
formules complexe et volatile en dehors d'une encapsulation soit un
atout...
L'intéret des opérateurs sur les fonctions devient évident lorsque les
formules deviennent complexes. Par exemple comprendre un calcul
d'amortissement dégressif ou de coefficient de corrélation sera plus facile
avec des opérateurs surchargés qu'avec des fonctions...
total = prixHorsTaxe.applyTaxe(tva); Est tout à fait acceptable et applyTaxe n'est guère plus long à écrire que la surcharge de l'opérateur. Même si l'opérateur peut être employé ailleurs...
Alors, il faut que tu introduit une classe supplémentaire Pour surcharger l'opérateur plus il te faut bien aussi une classe Prix
ou un truc dans ce goût là, non?
Non. tu peux avoir juste une classe prix qui gère ces opérations. Avec ton exemple, tu risque de multiplier et les classes (pour les prix hors taxes, les prix ttc, les prix auxquels la tva ne s'appliquent pas).
-- une valeur décimale qui connaît la TVA française. Dans l'exemple C++ comme Java la TVA est dans l'appel, mais ça n'est
pas forcément une bonne idée...
Mais ce n'était qu'un exemple simple. Que faire dans les programmes du marché, par exemple, où les formules qu'on manipule sont vraiment compliqués, et qu'ils changent assez souvent. Je ne vois pas l'avantage d'un opérateur par rapport à une fonction
pour l'évolutivité.
Je suis assez d'accord...
Très clairement soit c'est simple ou très peu usagé et utiliser add() ou mult() est un peu plus pénible, mais pas bloquant. Sois c'est compliqué et il y a intérêt à encapsuler dans une fonction, ne serait-ce que pour l'évolutivité du code... Je ne crois pas que le fait que la surcharge d'opérateur permette d'écrire des formules complexe et volatile en dehors d'une encapsulation soit un atout...
L'intéret des opérateurs sur les fonctions devient évident lorsque les formules deviennent complexes. Par exemple comprendre un calcul d'amortissement dégressif ou de coefficient de corrélation sera plus facile avec des opérateurs surchargés qu'avec des fonctions...
Chris
Christophe Lephay
"Jean-Marc Bourguet" a écrit dans le message de news:
writes:
Non. C'est David Vandervoorde. (Dans les groupes anglophones, il écrit son nom Daveed, pour qu'on le prononce correctement. Il est belge, et malgré son nom de famille, belge francophone.)
Pourquoi "malgré" ?
Parce que Vandervoorde fait plus flamand que wallon...
Chris
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de
news:pxbfzkoz1wa.fsf@news.bourguet.org...
kanze@gabi-soft.fr writes:
Non. C'est David Vandervoorde. (Dans les groupes anglophones, il écrit
son nom Daveed, pour qu'on le prononce correctement. Il est belge, et
malgré son nom de famille, belge francophone.)
Pourquoi "malgré" ?
Parce que Vandervoorde fait plus flamand que wallon...
"Jean-Marc Bourguet" a écrit dans le message de news:
writes:
Non. C'est David Vandervoorde. (Dans les groupes anglophones, il écrit son nom Daveed, pour qu'on le prononce correctement. Il est belge, et malgré son nom de famille, belge francophone.)
Pourquoi "malgré" ?
Parce que Vandervoorde fait plus flamand que wallon...
Chris
Gabriel Dos Reis
"Christophe Lephay" writes:
| "Jean-Marc Bourguet" a écrit dans le message de | news: | > writes: | > | > > Non. C'est David Vandervoorde. (Dans les groupes anglophones, il écrit | > > son nom Daveed, pour qu'on le prononce correctement. Il est belge, et | > > malgré son nom de famille, belge francophone.) | > | > Pourquoi "malgré" ? | | Parce que Vandervoorde fait plus flamand que wallon...
Il s'appelle pas Vandervoorde. Il n'y a pas de r après le e.
| "Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de
| news:pxbfzkoz1wa.fsf@news.bourguet.org...
| > kanze@gabi-soft.fr writes:
| >
| > > Non. C'est David Vandervoorde. (Dans les groupes anglophones, il écrit
| > > son nom Daveed, pour qu'on le prononce correctement. Il est belge, et
| > > malgré son nom de famille, belge francophone.)
| >
| > Pourquoi "malgré" ?
|
| Parce que Vandervoorde fait plus flamand que wallon...
Il s'appelle pas Vandervoorde. Il n'y a pas de r après le e.
| "Jean-Marc Bourguet" a écrit dans le message de | news: | > writes: | > | > > Non. C'est David Vandervoorde. (Dans les groupes anglophones, il écrit | > > son nom Daveed, pour qu'on le prononce correctement. Il est belge, et | > > malgré son nom de famille, belge francophone.) | > | > Pourquoi "malgré" ? | | Parce que Vandervoorde fait plus flamand que wallon...
Il s'appelle pas Vandervoorde. Il n'y a pas de r après le e.
-- gaby
Gabriel Dos Reis
Jean-Marc Bourguet writes:
| > Parce que Vandervoorde fait plus flamand que wallon... | | L'origine, oui. Mais il faut ne pas avoir vecu longtemps en Belgique | pour faire des hypotheses sur la langue maternelle de quelqu'un en se | basant sur le nom.
Est-ce que je suis portugais, moi ? :-) (Je suis même incapable de lire/parler/comprendre le portugais).
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
| > Parce que Vandervoorde fait plus flamand que wallon...
|
| L'origine, oui. Mais il faut ne pas avoir vecu longtemps en Belgique
| pour faire des hypotheses sur la langue maternelle de quelqu'un en se
| basant sur le nom.
Est-ce que je suis portugais, moi ? :-)
(Je suis même incapable de lire/parler/comprendre le portugais).
| > Parce que Vandervoorde fait plus flamand que wallon... | | L'origine, oui. Mais il faut ne pas avoir vecu longtemps en Belgique | pour faire des hypotheses sur la langue maternelle de quelqu'un en se | basant sur le nom.
Est-ce que je suis portugais, moi ? :-) (Je suis même incapable de lire/parler/comprendre le portugais).
-- Gaby
Christophe Lephay
"Martinez Jerome" a écrit dans le message de news:bg8haf$
James Kanze wrote:
Tu en es sûr. Pour avoir les perfs qu'ils veulent, il suffit d'acheter une machine plus puissante.
Encore faut-il qu'elle existe... Les problemes dans ce que tu dis : - Un logiciel mono-thread doit etre completement revu pour gerer plusieurs CPU - Un CPU a une frequence max, que meme a n'importe quel prix un fournisseur de matos ne peux fournir - Les licences sont vendues par machine, donc rajouter une machine pour gerer les perfs (faisable dans mon exemple perso) coute cher. (pb du non gratuit... :), et de grosses entreprises ayant des grilles qu'elles n'adaptent pas)
Mais bon, tu conviendras quand même qu'il s'agit de cas suffisemment particuliers pour qu'on en tire pas une méthode générale de programmation. Notemment, les besoins les plus importants au niveau des performances se trouvent *en général* sur des serveurs gérant beaucoup de transactions. Dans ces cas, le nombre de CPUs a plus d'impact sur les bonnes performances du système que leur fréquence. Par ailleurs, même dans le cas des applications mono-utilisateur les plus gourmandes, les performances de la machine cible font partie des spécifications (par exemple personne ne se plaint quand le dernier jeu à la mode est trop lent sur une machine qui date d'il y a à peine cinq ans).
Celà ne veut pas dire que le besoin d'une optimisation vraiment poussée n'existe jamais, mais juste que celà ne concerne plus que des cas extrement particuliers.
Chris
"Martinez Jerome" <jerome.martinez@aenlever-orangefrance.com> a écrit dans
le message de news:bg8haf$a5c2@news.rd.francetelecom.fr...
James Kanze wrote:
Tu en es sûr. Pour avoir les perfs qu'ils veulent, il suffit
d'acheter une machine plus puissante.
Encore faut-il qu'elle existe...
Les problemes dans ce que tu dis :
- Un logiciel mono-thread doit etre completement revu pour gerer
plusieurs CPU
- Un CPU a une frequence max, que meme a n'importe quel prix un
fournisseur de matos ne peux fournir
- Les licences sont vendues par machine, donc rajouter une machine pour
gerer les perfs (faisable dans mon exemple perso) coute cher. (pb du non
gratuit... :), et de grosses entreprises ayant des grilles qu'elles
n'adaptent pas)
Mais bon, tu conviendras quand même qu'il s'agit de cas suffisemment
particuliers pour qu'on en tire pas une méthode générale de programmation.
Notemment, les besoins les plus importants au niveau des performances se
trouvent *en général* sur des serveurs gérant beaucoup de transactions. Dans
ces cas, le nombre de CPUs a plus d'impact sur les bonnes performances du
système que leur fréquence. Par ailleurs, même dans le cas des applications
mono-utilisateur les plus gourmandes, les performances de la machine cible
font partie des spécifications (par exemple personne ne se plaint quand le
dernier jeu à la mode est trop lent sur une machine qui date d'il y a à
peine cinq ans).
Celà ne veut pas dire que le besoin d'une optimisation vraiment poussée
n'existe jamais, mais juste que celà ne concerne plus que des cas extrement
particuliers.
"Martinez Jerome" a écrit dans le message de news:bg8haf$
James Kanze wrote:
Tu en es sûr. Pour avoir les perfs qu'ils veulent, il suffit d'acheter une machine plus puissante.
Encore faut-il qu'elle existe... Les problemes dans ce que tu dis : - Un logiciel mono-thread doit etre completement revu pour gerer plusieurs CPU - Un CPU a une frequence max, que meme a n'importe quel prix un fournisseur de matos ne peux fournir - Les licences sont vendues par machine, donc rajouter une machine pour gerer les perfs (faisable dans mon exemple perso) coute cher. (pb du non gratuit... :), et de grosses entreprises ayant des grilles qu'elles n'adaptent pas)
Mais bon, tu conviendras quand même qu'il s'agit de cas suffisemment particuliers pour qu'on en tire pas une méthode générale de programmation. Notemment, les besoins les plus importants au niveau des performances se trouvent *en général* sur des serveurs gérant beaucoup de transactions. Dans ces cas, le nombre de CPUs a plus d'impact sur les bonnes performances du système que leur fréquence. Par ailleurs, même dans le cas des applications mono-utilisateur les plus gourmandes, les performances de la machine cible font partie des spécifications (par exemple personne ne se plaint quand le dernier jeu à la mode est trop lent sur une machine qui date d'il y a à peine cinq ans).
Celà ne veut pas dire que le besoin d'une optimisation vraiment poussée n'existe jamais, mais juste que celà ne concerne plus que des cas extrement particuliers.
Chris
Gabriel Dos Reis
writes:
| > Peut être qu'il y a moins de formalités pour le reprendre. Mais un bon | > produit commercial, avec une base de clients, c'est bien rare qu'il ne | > soit pas repris. | | Ça dépend. Dans un des cas, le produit (les composants Booch) a été | acheté par un concurrent, avec le but évident d'éliminer un concurrent | supérieur techniquement.
Dans une certaine mesure, on peut nommer aussi KAI.
-- Gaby
kanze@gabi-soft.fr writes:
| > Peut être qu'il y a moins de formalités pour le reprendre. Mais un bon
| > produit commercial, avec une base de clients, c'est bien rare qu'il ne
| > soit pas repris.
|
| Ça dépend. Dans un des cas, le produit (les composants Booch) a été
| acheté par un concurrent, avec le but évident d'éliminer un concurrent
| supérieur techniquement.
Dans une certaine mesure, on peut nommer aussi KAI.
| > Peut être qu'il y a moins de formalités pour le reprendre. Mais un bon | > produit commercial, avec une base de clients, c'est bien rare qu'il ne | > soit pas repris. | | Ça dépend. Dans un des cas, le produit (les composants Booch) a été | acheté par un concurrent, avec le but évident d'éliminer un concurrent | supérieur techniquement.
Dans une certaine mesure, on peut nommer aussi KAI.
| Gabriel Dos Reis wrote in | news:: | | >| Ça dépend. Dans un des cas, le produit (les composants Booch) a été | >| acheté par un concurrent, avec le but évident d'éliminer un conc urrent | >| supérieur techniquement. | > | > Dans une certaine mesure, on peut nommer aussi KAI. | > | | Oui. D'ailleurs, c'est devenu quoi ? Intel (?) a intégré la technolog ie | de KAI,
Je ne crois. Pour le moment, le fonctionnement observable est de l'équipe est int main() { } -- même si une personne de KAI est effectivement intégrée à l'équipe de développement du compilo Intel.
| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in
| news:m3ispjyktq.fsf@uniton.integrable-solutions.net:
|
| >| Ça dépend. Dans un des cas, le produit (les composants Booch) a été
| >| acheté par un concurrent, avec le but évident d'éliminer un conc urrent
| >| supérieur techniquement.
| >
| > Dans une certaine mesure, on peut nommer aussi KAI.
| >
|
| Oui. D'ailleurs, c'est devenu quoi ? Intel (?) a intégré la technolog ie
| de KAI,
Je ne crois. Pour le moment, le fonctionnement observable est de
l'équipe est int main() { } -- même si une personne de KAI est
effectivement intégrée à l'équipe de développement du compilo Intel.
| Gabriel Dos Reis wrote in | news:: | | >| Ça dépend. Dans un des cas, le produit (les composants Booch) a été | >| acheté par un concurrent, avec le but évident d'éliminer un conc urrent | >| supérieur techniquement. | > | > Dans une certaine mesure, on peut nommer aussi KAI. | > | | Oui. D'ailleurs, c'est devenu quoi ? Intel (?) a intégré la technolog ie | de KAI,
Je ne crois. Pour le moment, le fonctionnement observable est de l'équipe est int main() { } -- même si une personne de KAI est effectivement intégrée à l'équipe de développement du compilo Intel.
-- Gaby
--=-=-=--
Fabien LE LEZ
On 29 Jul 2003 09:58:01 -0700, (Vincent) wrote:
Pour moi un template c'est un peu comme une expréssion régulière, non? ça n'apporte pas de fonctionnalité que tu ne puisse pas écrire directement (même si c'est lourd), non?
Ton raisonnement, c'est que le C++ ne sert à rien, puisqu'on peut tout programmer en assembleur...
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
On 29 Jul 2003 09:58:01 -0700, vclassine@elan.fr (Vincent) wrote:
Pour moi un template c'est un peu comme une expréssion régulière, non?
ça n'apporte pas de fonctionnalité que tu ne puisse pas écrire
directement (même si c'est lourd), non?
Ton raisonnement, c'est que le C++ ne sert à rien, puisqu'on peut tout
programmer en assembleur...
--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
Pour moi un template c'est un peu comme une expréssion régulière, non? ça n'apporte pas de fonctionnalité que tu ne puisse pas écrire directement (même si c'est lourd), non?
Ton raisonnement, c'est que le C++ ne sert à rien, puisqu'on peut tout programmer en assembleur...
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
Fabien LE LEZ
On Tue, 29 Jul 2003 20:14:22 +0200, "Christophe Lephay" wrote:
Dans le même ordre d'idée, on pourrait dire que le paradigme OO n'est pas indispensable quoique utile.
C'est aussi vrai pour l'informatique en général ;-)
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
Dans le même ordre d'idée, on pourrait dire
que le paradigme OO n'est pas indispensable quoique utile.
C'est aussi vrai pour l'informatique en général ;-)
--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
On Tue, 29 Jul 2003 20:14:22 +0200, "Christophe Lephay" wrote:
Dans le même ordre d'idée, on pourrait dire que le paradigme OO n'est pas indispensable quoique utile.
C'est aussi vrai pour l'informatique en général ;-)
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
