JKB a écrit :
Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Lorsque tu prends la norme C ou Fortranquelque chose, tu _sais_ à quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Et au passage, lorsque tu as une
merde quelconque, tu ne sais plus si le bug est dans ton code, dans
l'OS ou dans ce qui est entre les deux, la JVM.et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les programmes
mais que l'on installe des exécutables, ne me dit pas que tu ne t'es
jamais retrouvé avec un binaire qui tourne sous une distribution et pas
sur une autre à cause d'une sordide histoire de linker
Jamais, pour la simple raison que lorsque je suis contraint à
diffuser des binaires, j'écris un makefile aux petits oignons avec
une édition des liens statique et juste les symboles nécessaires.
L'exécutable est un peu plus gros et parfaitement portable puisqu'il
n'est dynamiquement lié qu'à la libc et deux ou trois trucs
dépendants du système. Lorsque je diffuse des sources, autoconf fait
le boulot à ma place et rajoute ce qu'il faut.
cela ne change rien au fait que l'on installe un binaire et pas un code
source
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, même à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du graphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associer à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la structure
Avec du temps, tu vas y arriver. Mais si tu avais unfichier d'en-tête avec la définition du type 'graphe' et les deux ou
trois routines associées à la gestion de ce graphe, ce serait
beaucoup plus simple (sans compter que ce serait plus efficace,
parce que le graphe de boost est un graphe bien plus général que
celui nécessaire à un A* et sa création prend un temps dingue pour
rien).
je ne connais pas ton A* ni d'un point de vue mathématique ni d'un
point de vue algorithmique
Et non, mais c'est toi qui vois. Ce n'est pas parce que tu ne sais
pas programmer en C qu'il est permissif. En C, c'est à toi de
t'enquérir des erreurs. Si tu ne le fais pas, c'est ton problème,
pas celui du langage.
bien sur que si
c'est le problème du langage parce que comme tu le dis, tout le monde ne
sait pas programmer en c ou que tout le monde a sa propre vision du
traitement de l'erreur ou exception, ou croit qu'il le fait dans les
règles
et ton saut ou règle de saut dans ton anneau il correspond à quoi ?
Aux sauts d'une tâche à une autre. Quelle question ?! Tu implantes
un buffer circulant sous la forme d'un anneau chaîner, ce qui éviter
la gestion de fifo pour le coup parfaitement inefficaces.
et comment tu fais pour faire le distingo entre les différentes
priorités,
franchement si c'était juste pour dire que tu connaissais les buffeurs
circulaires c'était pas la peine
Tu es vraiment irrécupérable. Je viens de te dire comment éviter les
'buffer overflows' et tu me parles de rustine... Le fait d'avoir une
chaîne terminée par un 0 ou des fonctions de bas niveau capables de
déborder est la cause de l'immense majorité des failles. Il faut
donc changer de paradigme.
c'est pas ce que tu proposes "un changement de paradigne" tu
proposes un changement de structures, en gros introduire la taille dans
la chaine ou buffeur
c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la définition du
langage ou de la librairie de manière à éviter tous les contrôles
dynamiques qui existent dans un os
un exemple histoire d'être plus clair un driver
public MyDriver :: Driver
{
}
ben cette simple notation me donne accès aux espaces d'adressages qui
correspondent au hard et m'imposent un canal de communication pour les
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à péta
ouchnouke je protège de manière structurelle mon hard et je ne fais pas
de test inutile
Bon, il vaut mieux lire ça qu'être aveugle... Réfléchis à ce que tu
viens d'écrire et tu verras à quel point c'est absurde.
huùmmmmmmmmmmmmmmmm
toujours pas trouvé, tu peux m'éclairer
si les threads sont bien pensés l'on pourra utiliser tous les coeurs
d'une machine avec un seul thread maintenant on est d'accord ce n'est
pas du scalaire dans sa définition exacte du terme si cela peut te faire
plaisir
Cen'est pas ce que tu écrivais puisque tu opposais parallèle et
scalaire.
copier /coller
en plus si les threads sont bien pensés on peut faire du scalaire ou
du vrai parallélisme
quand pensez vous ?
Que tes produits sont vachement efficaces.
je suppose inefficace :-)
Non, ton dealer t'en a filé de la bonne.
pas vraiment, mais je pense que ce qui ne passe pas avec l'obj
c'est que l'obj impose une réflexion avant de coder contrairement au c
où l'on peut très souvent s'arranger disons que le degré de liberté est
moindre et encore j'ai un doute, j'ai déjà codé à l'arraché comme un
goret
tiens exemple mon algo de compression franchement je plains
l'inconscient qui veut lire le code :-)
Tiens, il y avait longtemps.
Parce que l'inconscient, il essayera de comprendre
l'incompréhensible. Je t'aide, lorsque tu code dans un langage
impératif, tu commences _toujours_ par faire une analyse, que tu la
nommes fonctionnelle ou non. Il n'y a aucune raison que
l'utilisation d'un langage impératif génère un code ignoble (pas
plus que l'utilisation d'un langage objet génère un code propre).
laisse un bout de code entre plusieurs mains et reviens voir le
résultat
J'ai des tas d'exemples de codes écrits en C de plusieurs dizaines
de milliers de lignes quasiment sans commentaire et qui sont
_limpides_ alors que j'ai des trucs beaucoup plus courts en C++
et imbitables.
Maintenant, l'utilisation d'un truc comme Java fait du code
généralement compréhensible par le seul concepteur dès que le
programme dépasse une taille critique parce qu'on ne sait plus
réellement à l'échelle du programme (je ne parle pas de la fonction)
comment tout ce beau monde interagit.
l'obj est indissociable des design patent donc parfaitement
compréhensible et cela quel que soit la taille du dit programme.
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
JKB a écrit :
Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Lorsque tu prends la norme C ou Fortran
quelque chose, tu _sais_ à quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Et au passage, lorsque tu as une
merde quelconque, tu ne sais plus si le bug est dans ton code, dans
l'OS ou dans ce qui est entre les deux, la JVM.
et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les programmes
mais que l'on installe des exécutables, ne me dit pas que tu ne t'es
jamais retrouvé avec un binaire qui tourne sous une distribution et pas
sur une autre à cause d'une sordide histoire de linker
Jamais, pour la simple raison que lorsque je suis contraint à
diffuser des binaires, j'écris un makefile aux petits oignons avec
une édition des liens statique et juste les symboles nécessaires.
L'exécutable est un peu plus gros et parfaitement portable puisqu'il
n'est dynamiquement lié qu'à la libc et deux ou trois trucs
dépendants du système. Lorsque je diffuse des sources, autoconf fait
le boulot à ma place et rajoute ce qu'il faut.
cela ne change rien au fait que l'on installe un binaire et pas un code
source
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, même à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.
l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du graphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associer à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la structure
Avec du temps, tu vas y arriver. Mais si tu avais un
fichier d'en-tête avec la définition du type 'graphe' et les deux ou
trois routines associées à la gestion de ce graphe, ce serait
beaucoup plus simple (sans compter que ce serait plus efficace,
parce que le graphe de boost est un graphe bien plus général que
celui nécessaire à un A* et sa création prend un temps dingue pour
rien).
je ne connais pas ton A* ni d'un point de vue mathématique ni d'un
point de vue algorithmique
Et non, mais c'est toi qui vois. Ce n'est pas parce que tu ne sais
pas programmer en C qu'il est permissif. En C, c'est à toi de
t'enquérir des erreurs. Si tu ne le fais pas, c'est ton problème,
pas celui du langage.
bien sur que si
c'est le problème du langage parce que comme tu le dis, tout le monde ne
sait pas programmer en c ou que tout le monde a sa propre vision du
traitement de l'erreur ou exception, ou croit qu'il le fait dans les
règles
et ton saut ou règle de saut dans ton anneau il correspond à quoi ?
Aux sauts d'une tâche à une autre. Quelle question ?! Tu implantes
un buffer circulant sous la forme d'un anneau chaîner, ce qui éviter
la gestion de fifo pour le coup parfaitement inefficaces.
et comment tu fais pour faire le distingo entre les différentes
priorités,
franchement si c'était juste pour dire que tu connaissais les buffeurs
circulaires c'était pas la peine
Tu es vraiment irrécupérable. Je viens de te dire comment éviter les
'buffer overflows' et tu me parles de rustine... Le fait d'avoir une
chaîne terminée par un 0 ou des fonctions de bas niveau capables de
déborder est la cause de l'immense majorité des failles. Il faut
donc changer de paradigme.
c'est pas ce que tu proposes "un changement de paradigne" tu
proposes un changement de structures, en gros introduire la taille dans
la chaine ou buffeur
c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la définition du
langage ou de la librairie de manière à éviter tous les contrôles
dynamiques qui existent dans un os
un exemple histoire d'être plus clair un driver
public MyDriver :: Driver
{
}
ben cette simple notation me donne accès aux espaces d'adressages qui
correspondent au hard et m'imposent un canal de communication pour les
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à péta
ouchnouke je protège de manière structurelle mon hard et je ne fais pas
de test inutile
Bon, il vaut mieux lire ça qu'être aveugle... Réfléchis à ce que tu
viens d'écrire et tu verras à quel point c'est absurde.
huùmmmmmmmmmmmmmmmm
toujours pas trouvé, tu peux m'éclairer
si les threads sont bien pensés l'on pourra utiliser tous les coeurs
d'une machine avec un seul thread maintenant on est d'accord ce n'est
pas du scalaire dans sa définition exacte du terme si cela peut te faire
plaisir
Cen'est pas ce que tu écrivais puisque tu opposais parallèle et
scalaire.
copier /coller
en plus si les threads sont bien pensés on peut faire du scalaire ou
du vrai parallélisme
quand pensez vous ?
Que tes produits sont vachement efficaces.
je suppose inefficace :-)
Non, ton dealer t'en a filé de la bonne.
pas vraiment, mais je pense que ce qui ne passe pas avec l'obj
c'est que l'obj impose une réflexion avant de coder contrairement au c
où l'on peut très souvent s'arranger disons que le degré de liberté est
moindre et encore j'ai un doute, j'ai déjà codé à l'arraché comme un
goret
tiens exemple mon algo de compression franchement je plains
l'inconscient qui veut lire le code :-)
Tiens, il y avait longtemps.
Parce que l'inconscient, il essayera de comprendre
l'incompréhensible. Je t'aide, lorsque tu code dans un langage
impératif, tu commences _toujours_ par faire une analyse, que tu la
nommes fonctionnelle ou non. Il n'y a aucune raison que
l'utilisation d'un langage impératif génère un code ignoble (pas
plus que l'utilisation d'un langage objet génère un code propre).
laisse un bout de code entre plusieurs mains et reviens voir le
résultat
J'ai des tas d'exemples de codes écrits en C de plusieurs dizaines
de milliers de lignes quasiment sans commentaire et qui sont
_limpides_ alors que j'ai des trucs beaucoup plus courts en C++
et imbitables.
Maintenant, l'utilisation d'un truc comme Java fait du code
généralement compréhensible par le seul concepteur dès que le
programme dépasse une taille critique parce qu'on ne sait plus
réellement à l'échelle du programme (je ne parle pas de la fonction)
comment tout ce beau monde interagit.
l'obj est indissociable des design patent donc parfaitement
compréhensible et cela quel que soit la taille du dit programme.
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
JKB a écrit :
Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Lorsque tu prends la norme C ou Fortranquelque chose, tu _sais_ à quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Et au passage, lorsque tu as une
merde quelconque, tu ne sais plus si le bug est dans ton code, dans
l'OS ou dans ce qui est entre les deux, la JVM.et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les programmes
mais que l'on installe des exécutables, ne me dit pas que tu ne t'es
jamais retrouvé avec un binaire qui tourne sous une distribution et pas
sur une autre à cause d'une sordide histoire de linker
Jamais, pour la simple raison que lorsque je suis contraint à
diffuser des binaires, j'écris un makefile aux petits oignons avec
une édition des liens statique et juste les symboles nécessaires.
L'exécutable est un peu plus gros et parfaitement portable puisqu'il
n'est dynamiquement lié qu'à la libc et deux ou trois trucs
dépendants du système. Lorsque je diffuse des sources, autoconf fait
le boulot à ma place et rajoute ce qu'il faut.
cela ne change rien au fait que l'on installe un binaire et pas un code
source
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, même à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du graphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associer à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la structure
Avec du temps, tu vas y arriver. Mais si tu avais unfichier d'en-tête avec la définition du type 'graphe' et les deux ou
trois routines associées à la gestion de ce graphe, ce serait
beaucoup plus simple (sans compter que ce serait plus efficace,
parce que le graphe de boost est un graphe bien plus général que
celui nécessaire à un A* et sa création prend un temps dingue pour
rien).
je ne connais pas ton A* ni d'un point de vue mathématique ni d'un
point de vue algorithmique
Et non, mais c'est toi qui vois. Ce n'est pas parce que tu ne sais
pas programmer en C qu'il est permissif. En C, c'est à toi de
t'enquérir des erreurs. Si tu ne le fais pas, c'est ton problème,
pas celui du langage.
bien sur que si
c'est le problème du langage parce que comme tu le dis, tout le monde ne
sait pas programmer en c ou que tout le monde a sa propre vision du
traitement de l'erreur ou exception, ou croit qu'il le fait dans les
règles
et ton saut ou règle de saut dans ton anneau il correspond à quoi ?
Aux sauts d'une tâche à une autre. Quelle question ?! Tu implantes
un buffer circulant sous la forme d'un anneau chaîner, ce qui éviter
la gestion de fifo pour le coup parfaitement inefficaces.
et comment tu fais pour faire le distingo entre les différentes
priorités,
franchement si c'était juste pour dire que tu connaissais les buffeurs
circulaires c'était pas la peine
Tu es vraiment irrécupérable. Je viens de te dire comment éviter les
'buffer overflows' et tu me parles de rustine... Le fait d'avoir une
chaîne terminée par un 0 ou des fonctions de bas niveau capables de
déborder est la cause de l'immense majorité des failles. Il faut
donc changer de paradigme.
c'est pas ce que tu proposes "un changement de paradigne" tu
proposes un changement de structures, en gros introduire la taille dans
la chaine ou buffeur
c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la définition du
langage ou de la librairie de manière à éviter tous les contrôles
dynamiques qui existent dans un os
un exemple histoire d'être plus clair un driver
public MyDriver :: Driver
{
}
ben cette simple notation me donne accès aux espaces d'adressages qui
correspondent au hard et m'imposent un canal de communication pour les
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à péta
ouchnouke je protège de manière structurelle mon hard et je ne fais pas
de test inutile
Bon, il vaut mieux lire ça qu'être aveugle... Réfléchis à ce que tu
viens d'écrire et tu verras à quel point c'est absurde.
huùmmmmmmmmmmmmmmmm
toujours pas trouvé, tu peux m'éclairer
si les threads sont bien pensés l'on pourra utiliser tous les coeurs
d'une machine avec un seul thread maintenant on est d'accord ce n'est
pas du scalaire dans sa définition exacte du terme si cela peut te faire
plaisir
Cen'est pas ce que tu écrivais puisque tu opposais parallèle et
scalaire.
copier /coller
en plus si les threads sont bien pensés on peut faire du scalaire ou
du vrai parallélisme
quand pensez vous ?
Que tes produits sont vachement efficaces.
je suppose inefficace :-)
Non, ton dealer t'en a filé de la bonne.
pas vraiment, mais je pense que ce qui ne passe pas avec l'obj
c'est que l'obj impose une réflexion avant de coder contrairement au c
où l'on peut très souvent s'arranger disons que le degré de liberté est
moindre et encore j'ai un doute, j'ai déjà codé à l'arraché comme un
goret
tiens exemple mon algo de compression franchement je plains
l'inconscient qui veut lire le code :-)
Tiens, il y avait longtemps.
Parce que l'inconscient, il essayera de comprendre
l'incompréhensible. Je t'aide, lorsque tu code dans un langage
impératif, tu commences _toujours_ par faire une analyse, que tu la
nommes fonctionnelle ou non. Il n'y a aucune raison que
l'utilisation d'un langage impératif génère un code ignoble (pas
plus que l'utilisation d'un langage objet génère un code propre).
laisse un bout de code entre plusieurs mains et reviens voir le
résultat
J'ai des tas d'exemples de codes écrits en C de plusieurs dizaines
de milliers de lignes quasiment sans commentaire et qui sont
_limpides_ alors que j'ai des trucs beaucoup plus courts en C++
et imbitables.
Maintenant, l'utilisation d'un truc comme Java fait du code
généralement compréhensible par le seul concepteur dès que le
programme dépasse une taille critique parce qu'on ne sait plus
réellement à l'échelle du programme (je ne parle pas de la fonction)
comment tout ce beau monde interagit.
l'obj est indissociable des design patent donc parfaitement
compréhensible et cela quel que soit la taille du dit programme.
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n 'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques ligne s,
surtout lorsque ce sont de sombres histoires de synchronisation
(cherche un peu race condition sur ton moteur de recherche favori).Lorsque tu prends la norme C ou Fortranquelque chose, tu _sais_ Ã quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnem ent
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la gue ule
des codes que tu as déjà soumis ici et dans fsm, ça ne m'étonne pas
trop) que ces problèmes n'existent pas.
Et au passage, lorsque tu as une
merde quelconque, tu ne sais plus si le bug est dans ton code, dans
l'OS ou dans ce qui est entre les deux, la JVM.et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les prog rammes
mais que l'on installe des exécutables, ne me dit pas que tu ne t'es
jamais retrouvé avec un binaire qui tourne sous une distributio n et pas
sur une autre à cause d'une sordide histoire de linker
Jamais, pour la simple raison que lorsque je suis contraint Ã
diffuser des binaires, j'écris un makefile aux petits oignons a vec
une édition des liens statique et juste les symboles néces saires.
L'exécutable est un peu plus gros et parfaitement portable puis qu'il
n'est dynamiquement lié qu'à la libc et deux ou trois truc s
dépendants du système. Lorsque je diffuse des sources, aut oconf fait
le boulot à ma place et rajoute ce qu'il faut.
cela ne change rien au fait que l'on installe un binaire et pas un cod e
source
Je ne vois pas en quoi ta réponse répond à mon argument . Enfin,
c'est du rémy tout craché.
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, mê me à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, j uste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du grap he
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associ er à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la stru cture
Et c'est justement ce qui est idiot.
à force de vouloir tout coller
dans des structures génériques pour que les petits doigts du
programmeur ou de l'analyste ne souffrent pas, tu as des tas de
choses complètement inutile pour ton besoin. Sauf que ta
bibliothèque C++ ne le sait pas et le gère pour toi. D'où le côté
parfaitement sous-optimal.
Avec du temps, tu vas y arriver. Mais si tu avais unfichier d'en-tête avec la définition du type 'graphe' et l es deux ou
trois routines associées à la gestion de ce graphe, ce ser ait
beaucoup plus simple (sans compter que ce serait plus efficace,
parce que le graphe de boost est un graphe bien plus génér al que
celui nécessaire à un A* et sa création prend un temp s dingue pour
rien).
je ne connais pas ton A* ni d'un point de vue mathématique ni d' un
point de vue algorithmique
C'est le b-a-ba de l'algorithmie.
Et non, mais c'est toi qui vois. Ce n'est pas parce que tu ne sais
pas programmer en C qu'il est permissif. En C, c'est à toi de
t'enquérir des erreurs. Si tu ne le fais pas, c'est ton problà ¨me,
pas celui du langage.
bien sur que si
c'est le problème du langage parce que comme tu le dis, tout le m onde ne
sait pas programmer en c ou que tout le monde a sa propre vision du
traitement de l'erreur ou exception, ou croit qu'il le fait dans les
règles
Ne me fais pas croire qu'on peut sérieusement programmer en C++ s ans
savoir programmer proprement en C. Les seuls types que j'ai vu
prétendre ça génèrent du code tout juste bon à jeter à la poubelle.
Si tu veux programmer sérieusement en C++, il faut une certaine
rigueur.
Si tu as une certaine rigueur, rien ne t'empêche de
programmer correctement en C.et ton saut ou règle de saut dans ton anneau il correspond à quoi ?
Aux sauts d'une tâche à une autre. Quelle question ?! Tu i mplantes
un buffer circulant sous la forme d'un anneau chaîner, ce qui à ©viter
la gestion de fifo pour le coup parfaitement inefficaces.
et comment tu fais pour faire le distingo entre les différentes
priorités,
franchement si c'était juste pour dire que tu connaissais les buf feurs
circulaires c'était pas la peine
Tu n'as rien à m'apprendre en programmation système. La gest ion des
tâches, je la fais par un séquenceur qui va choisir la tâ che Ã
exécuter sur le buffer circulaire en question, en sautant les tà ¢ches
les moins prioritaires selon une certaine règle. Ce truc te perme t
même de faire du temps réel.
Tu es vraiment irrécupérable. Je viens de te dire comment éviter les
'buffer overflows' et tu me parles de rustine... Le fait d'avoir une
chaîne terminée par un 0 ou des fonctions de bas niveau ca pables de
déborder est la cause de l'immense majorité des failles. I l faut
donc changer de paradigme.
c'est pas ce que tu proposes "un changement de paradigne" tu
proposes un changement de structures, en gros introduire la taille dan s
la chaine ou buffeur
Il n'y a aucune notion de structure lorsqu'on parle de buffer ou de
chaîne de caractère en C. Et je te conseille aussi d'ouvrir un
dictionnaire, je pense que tu en a besoin pour comprendre certains
mots.c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la dà ©finition du
langage ou de la librairie de manière à éviter tous l es contrôles
dynamiques qui existent dans un os
un exemple histoire d'être plus clair un driver
public MyDriver :: Driver
{
}
ben cette simple notation me donne accès aux espaces d'adressag es qui
correspondent au hard et m'imposent un canal de communication pour l es
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à péta
ouchnouke je protège de manière structurelle mon hard et j e ne fais pas
de test inutile
Bon, il vaut mieux lire ça qu'être aveugle... Réflà ©chis à ce que tu
viens d'écrire et tu verras à quel point c'est absurde.
huùmmmmmmmmmmmmmmmm
toujours pas trouvé, tu peux m'éclairer
Non. Ãa me prendrait beaucoup trop de temps.
si les threads sont bien pensés l'on pourra utiliser tous les c oeurs
d'une machine avec un seul thread maintenant on est d'accord ce n'e st
pas du scalaire dans sa définition exacte du terme si cela peut te faire
plaisir
Cen'est pas ce que tu écrivais puisque tu opposais parallè le et
scalaire.
copier /coller
en plus si les threads sont bien pensés on peut faire du scalaire ou
du vrai parallélisme
Ce qui veut dire que tu sous-entends que le scalaire est le
contraire du parallélisme, ce qui est _faux_.
l'obj est indissociable des design patent donc parfaitement
compréhensible et cela quel que soit la taille du dit programme.
Non. Le fait de manipuler des objets graphiques ne présuppose en
rien la façon dont ils sont implantés. Ce n'est pas parce qu e tu
utilises Motif avec des variables de type 'Widget' que tu dois
utiliser un langage objet. Il n'y a aucune raison à celà .
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
JKB
Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n 'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques ligne s,
surtout lorsque ce sont de sombres histoires de synchronisation
(cherche un peu race condition sur ton moteur de recherche favori).
Lorsque tu prends la norme C ou Fortran
quelque chose, tu _sais_ Ã quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnem ent
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la gue ule
des codes que tu as déjà soumis ici et dans fsm, ça ne m'étonne pas
trop) que ces problèmes n'existent pas.
Et au passage, lorsque tu as une
merde quelconque, tu ne sais plus si le bug est dans ton code, dans
l'OS ou dans ce qui est entre les deux, la JVM.
et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les prog rammes
mais que l'on installe des exécutables, ne me dit pas que tu ne t'es
jamais retrouvé avec un binaire qui tourne sous une distributio n et pas
sur une autre à cause d'une sordide histoire de linker
Jamais, pour la simple raison que lorsque je suis contraint Ã
diffuser des binaires, j'écris un makefile aux petits oignons a vec
une édition des liens statique et juste les symboles néces saires.
L'exécutable est un peu plus gros et parfaitement portable puis qu'il
n'est dynamiquement lié qu'à la libc et deux ou trois truc s
dépendants du système. Lorsque je diffuse des sources, aut oconf fait
le boulot à ma place et rajoute ce qu'il faut.
cela ne change rien au fait que l'on installe un binaire et pas un cod e
source
Je ne vois pas en quoi ta réponse répond à mon argument . Enfin,
c'est du rémy tout craché.
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, mê me à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.
l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, j uste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du grap he
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associ er à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la stru cture
Et c'est justement ce qui est idiot.
à force de vouloir tout coller
dans des structures génériques pour que les petits doigts du
programmeur ou de l'analyste ne souffrent pas, tu as des tas de
choses complètement inutile pour ton besoin. Sauf que ta
bibliothèque C++ ne le sait pas et le gère pour toi. D'où le côté
parfaitement sous-optimal.
Avec du temps, tu vas y arriver. Mais si tu avais un
fichier d'en-tête avec la définition du type 'graphe' et l es deux ou
trois routines associées à la gestion de ce graphe, ce ser ait
beaucoup plus simple (sans compter que ce serait plus efficace,
parce que le graphe de boost est un graphe bien plus génér al que
celui nécessaire à un A* et sa création prend un temp s dingue pour
rien).
je ne connais pas ton A* ni d'un point de vue mathématique ni d' un
point de vue algorithmique
C'est le b-a-ba de l'algorithmie.
Et non, mais c'est toi qui vois. Ce n'est pas parce que tu ne sais
pas programmer en C qu'il est permissif. En C, c'est à toi de
t'enquérir des erreurs. Si tu ne le fais pas, c'est ton problà ¨me,
pas celui du langage.
bien sur que si
c'est le problème du langage parce que comme tu le dis, tout le m onde ne
sait pas programmer en c ou que tout le monde a sa propre vision du
traitement de l'erreur ou exception, ou croit qu'il le fait dans les
règles
Ne me fais pas croire qu'on peut sérieusement programmer en C++ s ans
savoir programmer proprement en C. Les seuls types que j'ai vu
prétendre ça génèrent du code tout juste bon à jeter à la poubelle.
Si tu veux programmer sérieusement en C++, il faut une certaine
rigueur.
Si tu as une certaine rigueur, rien ne t'empêche de
programmer correctement en C.
et ton saut ou règle de saut dans ton anneau il correspond à quoi ?
Aux sauts d'une tâche à une autre. Quelle question ?! Tu i mplantes
un buffer circulant sous la forme d'un anneau chaîner, ce qui à ©viter
la gestion de fifo pour le coup parfaitement inefficaces.
et comment tu fais pour faire le distingo entre les différentes
priorités,
franchement si c'était juste pour dire que tu connaissais les buf feurs
circulaires c'était pas la peine
Tu n'as rien à m'apprendre en programmation système. La gest ion des
tâches, je la fais par un séquenceur qui va choisir la tâ che Ã
exécuter sur le buffer circulaire en question, en sautant les tà ¢ches
les moins prioritaires selon une certaine règle. Ce truc te perme t
même de faire du temps réel.
Tu es vraiment irrécupérable. Je viens de te dire comment éviter les
'buffer overflows' et tu me parles de rustine... Le fait d'avoir une
chaîne terminée par un 0 ou des fonctions de bas niveau ca pables de
déborder est la cause de l'immense majorité des failles. I l faut
donc changer de paradigme.
c'est pas ce que tu proposes "un changement de paradigne" tu
proposes un changement de structures, en gros introduire la taille dan s
la chaine ou buffeur
Il n'y a aucune notion de structure lorsqu'on parle de buffer ou de
chaîne de caractère en C. Et je te conseille aussi d'ouvrir un
dictionnaire, je pense que tu en a besoin pour comprendre certains
mots.
c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la dà ©finition du
langage ou de la librairie de manière à éviter tous l es contrôles
dynamiques qui existent dans un os
un exemple histoire d'être plus clair un driver
public MyDriver :: Driver
{
}
ben cette simple notation me donne accès aux espaces d'adressag es qui
correspondent au hard et m'imposent un canal de communication pour l es
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à péta
ouchnouke je protège de manière structurelle mon hard et j e ne fais pas
de test inutile
Bon, il vaut mieux lire ça qu'être aveugle... Réflà ©chis à ce que tu
viens d'écrire et tu verras à quel point c'est absurde.
huùmmmmmmmmmmmmmmmm
toujours pas trouvé, tu peux m'éclairer
Non. Ãa me prendrait beaucoup trop de temps.
si les threads sont bien pensés l'on pourra utiliser tous les c oeurs
d'une machine avec un seul thread maintenant on est d'accord ce n'e st
pas du scalaire dans sa définition exacte du terme si cela peut te faire
plaisir
Cen'est pas ce que tu écrivais puisque tu opposais parallè le et
scalaire.
copier /coller
en plus si les threads sont bien pensés on peut faire du scalaire ou
du vrai parallélisme
Ce qui veut dire que tu sous-entends que le scalaire est le
contraire du parallélisme, ce qui est _faux_.
l'obj est indissociable des design patent donc parfaitement
compréhensible et cela quel que soit la taille du dit programme.
Non. Le fait de manipuler des objets graphiques ne présuppose en
rien la façon dont ils sont implantés. Ce n'est pas parce qu e tu
utilises Motif avec des variables de type 'Widget' que tu dois
utiliser un langage objet. Il n'y a aucune raison à celà .
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
JKB
Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n 'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques ligne s,
surtout lorsque ce sont de sombres histoires de synchronisation
(cherche un peu race condition sur ton moteur de recherche favori).Lorsque tu prends la norme C ou Fortranquelque chose, tu _sais_ Ã quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnem ent
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la gue ule
des codes que tu as déjà soumis ici et dans fsm, ça ne m'étonne pas
trop) que ces problèmes n'existent pas.
Et au passage, lorsque tu as une
merde quelconque, tu ne sais plus si le bug est dans ton code, dans
l'OS ou dans ce qui est entre les deux, la JVM.et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les prog rammes
mais que l'on installe des exécutables, ne me dit pas que tu ne t'es
jamais retrouvé avec un binaire qui tourne sous une distributio n et pas
sur une autre à cause d'une sordide histoire de linker
Jamais, pour la simple raison que lorsque je suis contraint Ã
diffuser des binaires, j'écris un makefile aux petits oignons a vec
une édition des liens statique et juste les symboles néces saires.
L'exécutable est un peu plus gros et parfaitement portable puis qu'il
n'est dynamiquement lié qu'à la libc et deux ou trois truc s
dépendants du système. Lorsque je diffuse des sources, aut oconf fait
le boulot à ma place et rajoute ce qu'il faut.
cela ne change rien au fait que l'on installe un binaire et pas un cod e
source
Je ne vois pas en quoi ta réponse répond à mon argument . Enfin,
c'est du rémy tout craché.
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, mê me à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, j uste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du grap he
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associ er à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la stru cture
Et c'est justement ce qui est idiot.
à force de vouloir tout coller
dans des structures génériques pour que les petits doigts du
programmeur ou de l'analyste ne souffrent pas, tu as des tas de
choses complètement inutile pour ton besoin. Sauf que ta
bibliothèque C++ ne le sait pas et le gère pour toi. D'où le côté
parfaitement sous-optimal.
Avec du temps, tu vas y arriver. Mais si tu avais unfichier d'en-tête avec la définition du type 'graphe' et l es deux ou
trois routines associées à la gestion de ce graphe, ce ser ait
beaucoup plus simple (sans compter que ce serait plus efficace,
parce que le graphe de boost est un graphe bien plus génér al que
celui nécessaire à un A* et sa création prend un temp s dingue pour
rien).
je ne connais pas ton A* ni d'un point de vue mathématique ni d' un
point de vue algorithmique
C'est le b-a-ba de l'algorithmie.
Et non, mais c'est toi qui vois. Ce n'est pas parce que tu ne sais
pas programmer en C qu'il est permissif. En C, c'est à toi de
t'enquérir des erreurs. Si tu ne le fais pas, c'est ton problà ¨me,
pas celui du langage.
bien sur que si
c'est le problème du langage parce que comme tu le dis, tout le m onde ne
sait pas programmer en c ou que tout le monde a sa propre vision du
traitement de l'erreur ou exception, ou croit qu'il le fait dans les
règles
Ne me fais pas croire qu'on peut sérieusement programmer en C++ s ans
savoir programmer proprement en C. Les seuls types que j'ai vu
prétendre ça génèrent du code tout juste bon à jeter à la poubelle.
Si tu veux programmer sérieusement en C++, il faut une certaine
rigueur.
Si tu as une certaine rigueur, rien ne t'empêche de
programmer correctement en C.et ton saut ou règle de saut dans ton anneau il correspond à quoi ?
Aux sauts d'une tâche à une autre. Quelle question ?! Tu i mplantes
un buffer circulant sous la forme d'un anneau chaîner, ce qui à ©viter
la gestion de fifo pour le coup parfaitement inefficaces.
et comment tu fais pour faire le distingo entre les différentes
priorités,
franchement si c'était juste pour dire que tu connaissais les buf feurs
circulaires c'était pas la peine
Tu n'as rien à m'apprendre en programmation système. La gest ion des
tâches, je la fais par un séquenceur qui va choisir la tâ che Ã
exécuter sur le buffer circulaire en question, en sautant les tà ¢ches
les moins prioritaires selon une certaine règle. Ce truc te perme t
même de faire du temps réel.
Tu es vraiment irrécupérable. Je viens de te dire comment éviter les
'buffer overflows' et tu me parles de rustine... Le fait d'avoir une
chaîne terminée par un 0 ou des fonctions de bas niveau ca pables de
déborder est la cause de l'immense majorité des failles. I l faut
donc changer de paradigme.
c'est pas ce que tu proposes "un changement de paradigne" tu
proposes un changement de structures, en gros introduire la taille dan s
la chaine ou buffeur
Il n'y a aucune notion de structure lorsqu'on parle de buffer ou de
chaîne de caractère en C. Et je te conseille aussi d'ouvrir un
dictionnaire, je pense que tu en a besoin pour comprendre certains
mots.c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la dà ©finition du
langage ou de la librairie de manière à éviter tous l es contrôles
dynamiques qui existent dans un os
un exemple histoire d'être plus clair un driver
public MyDriver :: Driver
{
}
ben cette simple notation me donne accès aux espaces d'adressag es qui
correspondent au hard et m'imposent un canal de communication pour l es
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à péta
ouchnouke je protège de manière structurelle mon hard et j e ne fais pas
de test inutile
Bon, il vaut mieux lire ça qu'être aveugle... Réflà ©chis à ce que tu
viens d'écrire et tu verras à quel point c'est absurde.
huùmmmmmmmmmmmmmmmm
toujours pas trouvé, tu peux m'éclairer
Non. Ãa me prendrait beaucoup trop de temps.
si les threads sont bien pensés l'on pourra utiliser tous les c oeurs
d'une machine avec un seul thread maintenant on est d'accord ce n'e st
pas du scalaire dans sa définition exacte du terme si cela peut te faire
plaisir
Cen'est pas ce que tu écrivais puisque tu opposais parallè le et
scalaire.
copier /coller
en plus si les threads sont bien pensés on peut faire du scalaire ou
du vrai parallélisme
Ce qui veut dire que tu sous-entends que le scalaire est le
contraire du parallélisme, ce qui est _faux_.
l'obj est indissociable des design patent donc parfaitement
compréhensible et cela quel que soit la taille du dit programme.
Non. Le fait de manipuler des objets graphiques ne présuppose en
rien la façon dont ils sont implantés. Ce n'est pas parce qu e tu
utilises Motif avec des variables de type 'Widget' que tu dois
utiliser un langage objet. Il n'y a aucune raison à celà .
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
JKB
JKB a écrit :Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques lignes,
surtout lorsque ce sont de sombres histoires de synchronisation
le jour ou tu as besoin de synchronisation au demi pouillem prêt
c'est que ton algo est à revoir et pas qu'un peu
la communication inter thread se fait par appel de fonction
en gros un pointeur dans les 2 threads et celui qui a fini le dit à
celui qui attend, les délais ne doivent pas rentrer en ligne de compte,
celui qui attend soit délègue son sommeil soit il se rend dehors et se
réveille de manière autonome
(cherche un peu race condition sur ton moteur de recherche favori).Lorsque tu prends la norme C ou Fortranquelque chose, tu _sais_ à quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la gueule
des codes que tu as déjà soumis ici et dans fsm, ça ne m'étonne pas
trop) que ces problèmes n'existent pas.
je pourrais te montrer des usines à gaz quand je faisais du black
donc un en particulier avec graphiste qui m'a bien pourri la vie à
vouloir changer la couleur des petites flèches dans les barres
d'ascenseur ça s'invente pas ça
et bien grâce à la programmation obj c'est tout à fait faisable
et je n'ai pas réécrit la barre d'ascenseur bien trop fainéant pour cela
Et au passage, lorsque tu as une
merde quelconque, tu ne sais plus si le bug est dans ton code, dans
l'OS ou dans ce qui est entre les deux, la JVM.et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les programmes
mais que l'on installe des exécutables, ne me dit pas que tu ne t'es
jamais retrouvé avec un binaire qui tourne sous une distribution et pas
sur une autre à cause d'une sordide histoire de linker
Jamais, pour la simple raison que lorsque je suis contraint à
diffuser des binaires, j'écris un makefile aux petits oignons avec
une édition des liens statique et juste les symboles nécessaires.
L'exécutable est un peu plus gros et parfaitement portable puisqu'il
n'est dynamiquement lié qu'à la libc et deux ou trois trucs
dépendants du système. Lorsque je diffuse des sources, autoconf fait
le boulot à ma place et rajoute ce qu'il faut.
cela ne change rien au fait que l'on installe un binaire et pas un code
source
Je ne vois pas en quoi ta réponse répond à mon argument. Enfin,
c'est du rémy tout craché.
qui disait quoi rappelle moi
portabilité patati patata
Pas plus qu'un compilo C qui suit une norme précise et même moins.
et
cela ne change rien au fait que l'on installe un binaire et pas un code
source
voili voila
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, même à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du graphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associer à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la structure
Et c'est justement ce qui est idiot.
bien au contraire c'est cela qui est carrément génial
par un exemple un tri il suffit juste d'une interface pour déplacer
les obj et un bout de code qui les déplace et ce bout de code est
désolidarisé des obj à trier et parfaitement interchangeable
et cela sans aucune incidence sur tes obj
À force de vouloir tout coller
dans des structures génériques pour que les petits doigts du
programmeur ou de l'analyste ne souffrent pas, tu as des tas de
choses complètement inutile pour ton besoin. Sauf que ta
bibliothèque C++ ne le sait pas et le gère pour toi. D'où le côté
parfaitement sous-optimal.
complètement faux
Avec du temps, tu vas y arriver. Mais si tu avais unfichier d'en-tête avec la définition du type 'graphe' et les deux ou
trois routines associées à la gestion de ce graphe, ce serait
beaucoup plus simple (sans compter que ce serait plus efficace,
parce que le graphe de boost est un graphe bien plus général que
celui nécessaire à un A* et sa création prend un temps dingue pour
rien).
je ne connais pas ton A* ni d'un point de vue mathématique ni d'un
point de vue algorithmique
C'est le b-a-ba de l'algorithmie.
ben, j'ai pas dû le voir, voilà qu'est ce que tu veux que je te diseEt non, mais c'est toi qui vois. Ce n'est pas parce que tu ne sais
pas programmer en C qu'il est permissif. En C, c'est à toi de
t'enquérir des erreurs. Si tu ne le fais pas, c'est ton problème,
pas celui du langage.
bien sur que si
c'est le problème du langage parce que comme tu le dis, tout le monde ne
sait pas programmer en c ou que tout le monde a sa propre vision du
traitement de l'erreur ou exception, ou croit qu'il le fait dans les
règles
Ne me fais pas croire qu'on peut sérieusement programmer en C++ sans
savoir programmer proprement en C. Les seuls types que j'ai vu
prétendre ça génèrent du code tout juste bon à jeter à la poubelle.
Si tu veux programmer sérieusement en C++, il faut une certaine
rigueur.
toujours un petit peu, bien sûr mais nettement moins et de plus en plus
avec les ateliers de développement qui te remplissent les fonctions et
te rappellent à l'ordre au moindre écart et cela c'est lié aux règles
induites par l'obj
Si tu as une certaine rigueur, rien ne t'empêche de
programmer correctement en C.et ton saut ou règle de saut dans ton anneau il correspond à quoi ?
Aux sauts d'une tâche à une autre. Quelle question ?! Tu implantes
un buffer circulant sous la forme d'un anneau chaîner, ce qui éviter
la gestion de fifo pour le coup parfaitement inefficaces.
et comment tu fais pour faire le distingo entre les différentes
priorités,
franchement si c'était juste pour dire que tu connaissais les buffeurs
circulaires c'était pas la peine
Tu n'as rien à m'apprendre en programmation système. La gestion des
tâches, je la fais par un séquenceur qui va choisir la tâche à
exécuter sur le buffer circulaire en question, en sautant les tâches
les moins prioritaires selon une certaine règle. Ce truc te permet
même de faire du temps réel.
donc ton saut s'apparente à plusieurs fifos, rassures toi tu n'es pas le
seul à avoir étudier la programmation système j'ai même eu une uv, bon
ils me l'ont peut être donnée, maintenant j'en sais rien
Tu es vraiment irrécupérable. Je viens de te dire comment éviter les
'buffer overflows' et tu me parles de rustine... Le fait d'avoir une
chaîne terminée par un 0 ou des fonctions de bas niveau capables de
déborder est la cause de l'immense majorité des failles. Il faut
donc changer de paradigme.
c'est pas ce que tu proposes "un changement de paradigne" tu
proposes un changement de structures, en gros introduire la taille dans
la chaine ou buffeur
Il n'y a aucune notion de structure lorsqu'on parle de buffer ou de
chaîne de caractère en C. Et je te conseille aussi d'ouvrir un
dictionnaire, je pense que tu en a besoin pour comprendre certains
mots.c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la définition du
langage ou de la librairie de manière à éviter tous les contrôles
dynamiques qui existent dans un os
un exemple histoire d'être plus clair un driver
public MyDriver :: Driver
{
}
ben cette simple notation me donne accès aux espaces d'adressages qui
correspondent au hard et m'imposent un canal de communication pour les
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à péta
ouchnouke je protège de manière structurelle mon hard et je ne fais pas
de test inutile
Bon, il vaut mieux lire ça qu'être aveugle... Réfléchis à ce que tu
viens d'écrire et tu verras à quel point c'est absurde.
huùmmmmmmmmmmmmmmmm
toujours pas trouvé, tu peux m'éclairer
Non. Ça me prendrait beaucoup trop de temps.
dommage je me coucherai aussi con que je me suis levési les threads sont bien pensés l'on pourra utiliser tous les coeurs
d'une machine avec un seul thread maintenant on est d'accord ce n'est
pas du scalaire dans sa définition exacte du terme si cela peut te faire
plaisir
Cen'est pas ce que tu écrivais puisque tu opposais parallèle et
scalaire.
copier /coller
en plus si les threads sont bien pensés on peut faire du scalaire ou
du vrai parallélisme
Ce qui veut dire que tu sous-entends que le scalaire est le
contraire du parallélisme, ce qui est _faux_.
j'ai dit ça moi, bon ok mais j'ai un doute
tiens justement en parlant de scalaire j'aime bien les cell
hai
l'obj est indissociable des design patent donc parfaitement
compréhensible et cela quel que soit la taille du dit programme.
Non. Le fait de manipuler des objets graphiques ne présuppose en
rien la façon dont ils sont implantés. Ce n'est pas parce que tu
utilises Motif avec des variables de type 'Widget' que tu dois
utiliser un langage objet. Il n'y a aucune raison à celà.
tu confonds programmation obj et obj graphique à mon avis
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
et cela ne sera pas la dernière
JKB a écrit :
Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques lignes,
surtout lorsque ce sont de sombres histoires de synchronisation
le jour ou tu as besoin de synchronisation au demi pouillem prêt
c'est que ton algo est à revoir et pas qu'un peu
la communication inter thread se fait par appel de fonction
en gros un pointeur dans les 2 threads et celui qui a fini le dit à
celui qui attend, les délais ne doivent pas rentrer en ligne de compte,
celui qui attend soit délègue son sommeil soit il se rend dehors et se
réveille de manière autonome
(cherche un peu race condition sur ton moteur de recherche favori).
Lorsque tu prends la norme C ou Fortran
quelque chose, tu _sais_ à quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la gueule
des codes que tu as déjà soumis ici et dans fsm, ça ne m'étonne pas
trop) que ces problèmes n'existent pas.
je pourrais te montrer des usines à gaz quand je faisais du black
donc un en particulier avec graphiste qui m'a bien pourri la vie à
vouloir changer la couleur des petites flèches dans les barres
d'ascenseur ça s'invente pas ça
et bien grâce à la programmation obj c'est tout à fait faisable
et je n'ai pas réécrit la barre d'ascenseur bien trop fainéant pour cela
Et au passage, lorsque tu as une
merde quelconque, tu ne sais plus si le bug est dans ton code, dans
l'OS ou dans ce qui est entre les deux, la JVM.
et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les programmes
mais que l'on installe des exécutables, ne me dit pas que tu ne t'es
jamais retrouvé avec un binaire qui tourne sous une distribution et pas
sur une autre à cause d'une sordide histoire de linker
Jamais, pour la simple raison que lorsque je suis contraint à
diffuser des binaires, j'écris un makefile aux petits oignons avec
une édition des liens statique et juste les symboles nécessaires.
L'exécutable est un peu plus gros et parfaitement portable puisqu'il
n'est dynamiquement lié qu'à la libc et deux ou trois trucs
dépendants du système. Lorsque je diffuse des sources, autoconf fait
le boulot à ma place et rajoute ce qu'il faut.
cela ne change rien au fait que l'on installe un binaire et pas un code
source
Je ne vois pas en quoi ta réponse répond à mon argument. Enfin,
c'est du rémy tout craché.
qui disait quoi rappelle moi
portabilité patati patata
Pas plus qu'un compilo C qui suit une norme précise et même moins.
et
cela ne change rien au fait que l'on installe un binaire et pas un code
source
voili voila
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, même à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.
l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du graphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associer à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la structure
Et c'est justement ce qui est idiot.
bien au contraire c'est cela qui est carrément génial
par un exemple un tri il suffit juste d'une interface pour déplacer
les obj et un bout de code qui les déplace et ce bout de code est
désolidarisé des obj à trier et parfaitement interchangeable
et cela sans aucune incidence sur tes obj
À force de vouloir tout coller
dans des structures génériques pour que les petits doigts du
programmeur ou de l'analyste ne souffrent pas, tu as des tas de
choses complètement inutile pour ton besoin. Sauf que ta
bibliothèque C++ ne le sait pas et le gère pour toi. D'où le côté
parfaitement sous-optimal.
complètement faux
Avec du temps, tu vas y arriver. Mais si tu avais un
fichier d'en-tête avec la définition du type 'graphe' et les deux ou
trois routines associées à la gestion de ce graphe, ce serait
beaucoup plus simple (sans compter que ce serait plus efficace,
parce que le graphe de boost est un graphe bien plus général que
celui nécessaire à un A* et sa création prend un temps dingue pour
rien).
je ne connais pas ton A* ni d'un point de vue mathématique ni d'un
point de vue algorithmique
C'est le b-a-ba de l'algorithmie.
ben, j'ai pas dû le voir, voilà qu'est ce que tu veux que je te dise
Et non, mais c'est toi qui vois. Ce n'est pas parce que tu ne sais
pas programmer en C qu'il est permissif. En C, c'est à toi de
t'enquérir des erreurs. Si tu ne le fais pas, c'est ton problème,
pas celui du langage.
bien sur que si
c'est le problème du langage parce que comme tu le dis, tout le monde ne
sait pas programmer en c ou que tout le monde a sa propre vision du
traitement de l'erreur ou exception, ou croit qu'il le fait dans les
règles
Ne me fais pas croire qu'on peut sérieusement programmer en C++ sans
savoir programmer proprement en C. Les seuls types que j'ai vu
prétendre ça génèrent du code tout juste bon à jeter à la poubelle.
Si tu veux programmer sérieusement en C++, il faut une certaine
rigueur.
toujours un petit peu, bien sûr mais nettement moins et de plus en plus
avec les ateliers de développement qui te remplissent les fonctions et
te rappellent à l'ordre au moindre écart et cela c'est lié aux règles
induites par l'obj
Si tu as une certaine rigueur, rien ne t'empêche de
programmer correctement en C.
et ton saut ou règle de saut dans ton anneau il correspond à quoi ?
Aux sauts d'une tâche à une autre. Quelle question ?! Tu implantes
un buffer circulant sous la forme d'un anneau chaîner, ce qui éviter
la gestion de fifo pour le coup parfaitement inefficaces.
et comment tu fais pour faire le distingo entre les différentes
priorités,
franchement si c'était juste pour dire que tu connaissais les buffeurs
circulaires c'était pas la peine
Tu n'as rien à m'apprendre en programmation système. La gestion des
tâches, je la fais par un séquenceur qui va choisir la tâche à
exécuter sur le buffer circulaire en question, en sautant les tâches
les moins prioritaires selon une certaine règle. Ce truc te permet
même de faire du temps réel.
donc ton saut s'apparente à plusieurs fifos, rassures toi tu n'es pas le
seul à avoir étudier la programmation système j'ai même eu une uv, bon
ils me l'ont peut être donnée, maintenant j'en sais rien
Tu es vraiment irrécupérable. Je viens de te dire comment éviter les
'buffer overflows' et tu me parles de rustine... Le fait d'avoir une
chaîne terminée par un 0 ou des fonctions de bas niveau capables de
déborder est la cause de l'immense majorité des failles. Il faut
donc changer de paradigme.
c'est pas ce que tu proposes "un changement de paradigne" tu
proposes un changement de structures, en gros introduire la taille dans
la chaine ou buffeur
Il n'y a aucune notion de structure lorsqu'on parle de buffer ou de
chaîne de caractère en C. Et je te conseille aussi d'ouvrir un
dictionnaire, je pense que tu en a besoin pour comprendre certains
mots.
c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la définition du
langage ou de la librairie de manière à éviter tous les contrôles
dynamiques qui existent dans un os
un exemple histoire d'être plus clair un driver
public MyDriver :: Driver
{
}
ben cette simple notation me donne accès aux espaces d'adressages qui
correspondent au hard et m'imposent un canal de communication pour les
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à péta
ouchnouke je protège de manière structurelle mon hard et je ne fais pas
de test inutile
Bon, il vaut mieux lire ça qu'être aveugle... Réfléchis à ce que tu
viens d'écrire et tu verras à quel point c'est absurde.
huùmmmmmmmmmmmmmmmm
toujours pas trouvé, tu peux m'éclairer
Non. Ça me prendrait beaucoup trop de temps.
dommage je me coucherai aussi con que je me suis levé
si les threads sont bien pensés l'on pourra utiliser tous les coeurs
d'une machine avec un seul thread maintenant on est d'accord ce n'est
pas du scalaire dans sa définition exacte du terme si cela peut te faire
plaisir
Cen'est pas ce que tu écrivais puisque tu opposais parallèle et
scalaire.
copier /coller
en plus si les threads sont bien pensés on peut faire du scalaire ou
du vrai parallélisme
Ce qui veut dire que tu sous-entends que le scalaire est le
contraire du parallélisme, ce qui est _faux_.
j'ai dit ça moi, bon ok mais j'ai un doute
tiens justement en parlant de scalaire j'aime bien les cell
hai
l'obj est indissociable des design patent donc parfaitement
compréhensible et cela quel que soit la taille du dit programme.
Non. Le fait de manipuler des objets graphiques ne présuppose en
rien la façon dont ils sont implantés. Ce n'est pas parce que tu
utilises Motif avec des variables de type 'Widget' que tu dois
utiliser un langage objet. Il n'y a aucune raison à celà.
tu confonds programmation obj et obj graphique à mon avis
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
et cela ne sera pas la dernière
JKB a écrit :Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques lignes,
surtout lorsque ce sont de sombres histoires de synchronisation
le jour ou tu as besoin de synchronisation au demi pouillem prêt
c'est que ton algo est à revoir et pas qu'un peu
la communication inter thread se fait par appel de fonction
en gros un pointeur dans les 2 threads et celui qui a fini le dit à
celui qui attend, les délais ne doivent pas rentrer en ligne de compte,
celui qui attend soit délègue son sommeil soit il se rend dehors et se
réveille de manière autonome
(cherche un peu race condition sur ton moteur de recherche favori).Lorsque tu prends la norme C ou Fortranquelque chose, tu _sais_ à quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la gueule
des codes que tu as déjà soumis ici et dans fsm, ça ne m'étonne pas
trop) que ces problèmes n'existent pas.
je pourrais te montrer des usines à gaz quand je faisais du black
donc un en particulier avec graphiste qui m'a bien pourri la vie à
vouloir changer la couleur des petites flèches dans les barres
d'ascenseur ça s'invente pas ça
et bien grâce à la programmation obj c'est tout à fait faisable
et je n'ai pas réécrit la barre d'ascenseur bien trop fainéant pour cela
Et au passage, lorsque tu as une
merde quelconque, tu ne sais plus si le bug est dans ton code, dans
l'OS ou dans ce qui est entre les deux, la JVM.et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les programmes
mais que l'on installe des exécutables, ne me dit pas que tu ne t'es
jamais retrouvé avec un binaire qui tourne sous une distribution et pas
sur une autre à cause d'une sordide histoire de linker
Jamais, pour la simple raison que lorsque je suis contraint à
diffuser des binaires, j'écris un makefile aux petits oignons avec
une édition des liens statique et juste les symboles nécessaires.
L'exécutable est un peu plus gros et parfaitement portable puisqu'il
n'est dynamiquement lié qu'à la libc et deux ou trois trucs
dépendants du système. Lorsque je diffuse des sources, autoconf fait
le boulot à ma place et rajoute ce qu'il faut.
cela ne change rien au fait que l'on installe un binaire et pas un code
source
Je ne vois pas en quoi ta réponse répond à mon argument. Enfin,
c'est du rémy tout craché.
qui disait quoi rappelle moi
portabilité patati patata
Pas plus qu'un compilo C qui suit une norme précise et même moins.
et
cela ne change rien au fait que l'on installe un binaire et pas un code
source
voili voila
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, même à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du graphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associer à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la structure
Et c'est justement ce qui est idiot.
bien au contraire c'est cela qui est carrément génial
par un exemple un tri il suffit juste d'une interface pour déplacer
les obj et un bout de code qui les déplace et ce bout de code est
désolidarisé des obj à trier et parfaitement interchangeable
et cela sans aucune incidence sur tes obj
À force de vouloir tout coller
dans des structures génériques pour que les petits doigts du
programmeur ou de l'analyste ne souffrent pas, tu as des tas de
choses complètement inutile pour ton besoin. Sauf que ta
bibliothèque C++ ne le sait pas et le gère pour toi. D'où le côté
parfaitement sous-optimal.
complètement faux
Avec du temps, tu vas y arriver. Mais si tu avais unfichier d'en-tête avec la définition du type 'graphe' et les deux ou
trois routines associées à la gestion de ce graphe, ce serait
beaucoup plus simple (sans compter que ce serait plus efficace,
parce que le graphe de boost est un graphe bien plus général que
celui nécessaire à un A* et sa création prend un temps dingue pour
rien).
je ne connais pas ton A* ni d'un point de vue mathématique ni d'un
point de vue algorithmique
C'est le b-a-ba de l'algorithmie.
ben, j'ai pas dû le voir, voilà qu'est ce que tu veux que je te diseEt non, mais c'est toi qui vois. Ce n'est pas parce que tu ne sais
pas programmer en C qu'il est permissif. En C, c'est à toi de
t'enquérir des erreurs. Si tu ne le fais pas, c'est ton problème,
pas celui du langage.
bien sur que si
c'est le problème du langage parce que comme tu le dis, tout le monde ne
sait pas programmer en c ou que tout le monde a sa propre vision du
traitement de l'erreur ou exception, ou croit qu'il le fait dans les
règles
Ne me fais pas croire qu'on peut sérieusement programmer en C++ sans
savoir programmer proprement en C. Les seuls types que j'ai vu
prétendre ça génèrent du code tout juste bon à jeter à la poubelle.
Si tu veux programmer sérieusement en C++, il faut une certaine
rigueur.
toujours un petit peu, bien sûr mais nettement moins et de plus en plus
avec les ateliers de développement qui te remplissent les fonctions et
te rappellent à l'ordre au moindre écart et cela c'est lié aux règles
induites par l'obj
Si tu as une certaine rigueur, rien ne t'empêche de
programmer correctement en C.et ton saut ou règle de saut dans ton anneau il correspond à quoi ?
Aux sauts d'une tâche à une autre. Quelle question ?! Tu implantes
un buffer circulant sous la forme d'un anneau chaîner, ce qui éviter
la gestion de fifo pour le coup parfaitement inefficaces.
et comment tu fais pour faire le distingo entre les différentes
priorités,
franchement si c'était juste pour dire que tu connaissais les buffeurs
circulaires c'était pas la peine
Tu n'as rien à m'apprendre en programmation système. La gestion des
tâches, je la fais par un séquenceur qui va choisir la tâche à
exécuter sur le buffer circulaire en question, en sautant les tâches
les moins prioritaires selon une certaine règle. Ce truc te permet
même de faire du temps réel.
donc ton saut s'apparente à plusieurs fifos, rassures toi tu n'es pas le
seul à avoir étudier la programmation système j'ai même eu une uv, bon
ils me l'ont peut être donnée, maintenant j'en sais rien
Tu es vraiment irrécupérable. Je viens de te dire comment éviter les
'buffer overflows' et tu me parles de rustine... Le fait d'avoir une
chaîne terminée par un 0 ou des fonctions de bas niveau capables de
déborder est la cause de l'immense majorité des failles. Il faut
donc changer de paradigme.
c'est pas ce que tu proposes "un changement de paradigne" tu
proposes un changement de structures, en gros introduire la taille dans
la chaine ou buffeur
Il n'y a aucune notion de structure lorsqu'on parle de buffer ou de
chaîne de caractère en C. Et je te conseille aussi d'ouvrir un
dictionnaire, je pense que tu en a besoin pour comprendre certains
mots.c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la définition du
langage ou de la librairie de manière à éviter tous les contrôles
dynamiques qui existent dans un os
un exemple histoire d'être plus clair un driver
public MyDriver :: Driver
{
}
ben cette simple notation me donne accès aux espaces d'adressages qui
correspondent au hard et m'imposent un canal de communication pour les
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à péta
ouchnouke je protège de manière structurelle mon hard et je ne fais pas
de test inutile
Bon, il vaut mieux lire ça qu'être aveugle... Réfléchis à ce que tu
viens d'écrire et tu verras à quel point c'est absurde.
huùmmmmmmmmmmmmmmmm
toujours pas trouvé, tu peux m'éclairer
Non. Ça me prendrait beaucoup trop de temps.
dommage je me coucherai aussi con que je me suis levési les threads sont bien pensés l'on pourra utiliser tous les coeurs
d'une machine avec un seul thread maintenant on est d'accord ce n'est
pas du scalaire dans sa définition exacte du terme si cela peut te faire
plaisir
Cen'est pas ce que tu écrivais puisque tu opposais parallèle et
scalaire.
copier /coller
en plus si les threads sont bien pensés on peut faire du scalaire ou
du vrai parallélisme
Ce qui veut dire que tu sous-entends que le scalaire est le
contraire du parallélisme, ce qui est _faux_.
j'ai dit ça moi, bon ok mais j'ai un doute
tiens justement en parlant de scalaire j'aime bien les cell
hai
l'obj est indissociable des design patent donc parfaitement
compréhensible et cela quel que soit la taille du dit programme.
Non. Le fait de manipuler des objets graphiques ne présuppose en
rien la façon dont ils sont implantés. Ce n'est pas parce que tu
utilises Motif avec des variables de type 'Widget' que tu dois
utiliser un langage objet. Il n'y a aucune raison à celà.
tu confonds programmation obj et obj graphique à mon avis
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
et cela ne sera pas la dernière
Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Non, c'est parfaitement faux. Que tu le crois prouve simplement qu e
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques lig nes,
surtout lorsque ce sont de sombres histoires de synchronisation
le jour ou tu as besoin de synchronisation au demi pouillem prêt
c'est que ton algo est à revoir et pas qu'un peu
Tu n'as jamais eu à synchroniser des calculs parallèles oà ¹ des race
conditions à la noix peuvent tout te mettre par terre. Les
deadlocks, tu connais ?
la communication inter thread se fait par appel de fonction
en gros un pointeur dans les 2 threads et celui qui a fini le dit Ã
celui qui attend, les délais ne doivent pas rentrer en ligne de c ompte,
celui qui attend soit délègue son sommeil soit il se rend de hors et se
réveille de manière autonome
Ouaips, vraiment en gros alors...(cherche un peu race condition sur ton moteur de recherche favori).Lorsque tu prends la norme C ou Fortranquelque chose, tu _sais_ Ã quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionn ement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la g ueule
des codes que tu as déjà soumis ici et dans fsm, ça n e m'étonne pas
trop) que ces problèmes n'existent pas.
je pourrais te montrer des usines à gaz quand je faisais du black
donc un en particulier avec graphiste qui m'a bien pourri la vie Ã
vouloir changer la couleur des petites flèches dans les barres
d'ascenseur ça s'invente pas ça
et bien grâce à la programmation obj c'est tout à fait faisable
et je n'ai pas réécrit la barre d'ascenseur bien trop fainà ©ant pour cela
Ãa n'a _strictement_ rien à voir. Je peux te faire exactemen t la
même chose avec Motif qui n'est pas objet au sens du langage. Ce
n'est pas parce que tu manipules des structures (ou des objets
graphiques) que ton langage _doit_ être un langage objet !
Exprime-toi clairement parce que j'arrive pas à saisir la subtili té
de ton raisonnement.
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, mà ªme à la
relecture. Tu crées tes objets graphiques en les attachant le s uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeu r s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et n on maintenable
Non. La programmation objet, c'est l'illusion de la simplicité .
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du gr aphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux asso cier à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la st ructure
Et c'est justement ce qui est idiot.
bien au contraire c'est cela qui est carrément génial
par un exemple un tri il suffit juste d'une interface pour déplac er
les obj et un bout de code qui les déplace et ce bout de code est
désolidarisé des obj à trier et parfaitement interchang eable
et cela sans aucune incidence sur tes obj
Et c'est justement ce qui est ridicule. Lorsque tu veux trier un
une liste, tu commences à écrire un algorithme qui correspon d au
mieux aux objets que tu as à trier. Ãa peut aller d'un shell Metzner
à un tri bulle en passant par un tri par tas et tout un tas d'aut res
choses. Commenver par écrire un tri générique sur des o bjets
génériques est idiot et contre productif.
Je t'ai justement donné un
exemple avec la libbosst, mais tu refises de regarder ce qui se
passe :
1/ boost/graph décrit des graphes
2/ boost/astar implante un A*
Cette remarque liminaire mise à part, tu ne me feras jamais croir e
qu'on puisse être un bon programmeur si on n'arrive pas à à ©crire un
gros soft uniquement avec make, gcc, et vim. Tous les trucs qui
complètent les lignes à la façon netbeans sont des hà ©résies si tu ne
comprends pas ce que tu fais (et dans les détails, pas en gros !) .
Non, ce n'est pas la même chose, mais là encore, c'est toi q ui vois.
Je ne répondrai pas sur ton uv de programmation système vu l a
qualité de tes interventions sur le sujet.
tu confonds programmation obj et obj graphique à mon avis
MMmmmmmmmouarf ! Alors que tu t'emmêles les pinceaux depuis le dà ©but
avec ça ?... C'est l'hôpital qui se fout de la charité, ça !
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
et cela ne sera pas la dernière
Il ne faut jamais désespérer de toi.
Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Non, c'est parfaitement faux. Que tu le crois prouve simplement qu e
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques lig nes,
surtout lorsque ce sont de sombres histoires de synchronisation
le jour ou tu as besoin de synchronisation au demi pouillem prêt
c'est que ton algo est à revoir et pas qu'un peu
Tu n'as jamais eu à synchroniser des calculs parallèles oà ¹ des race
conditions à la noix peuvent tout te mettre par terre. Les
deadlocks, tu connais ?
la communication inter thread se fait par appel de fonction
en gros un pointeur dans les 2 threads et celui qui a fini le dit Ã
celui qui attend, les délais ne doivent pas rentrer en ligne de c ompte,
celui qui attend soit délègue son sommeil soit il se rend de hors et se
réveille de manière autonome
Ouaips, vraiment en gros alors...
(cherche un peu race condition sur ton moteur de recherche favori).
Lorsque tu prends la norme C ou Fortran
quelque chose, tu _sais_ Ã quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionn ement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la g ueule
des codes que tu as déjà soumis ici et dans fsm, ça n e m'étonne pas
trop) que ces problèmes n'existent pas.
je pourrais te montrer des usines à gaz quand je faisais du black
donc un en particulier avec graphiste qui m'a bien pourri la vie Ã
vouloir changer la couleur des petites flèches dans les barres
d'ascenseur ça s'invente pas ça
et bien grâce à la programmation obj c'est tout à fait faisable
et je n'ai pas réécrit la barre d'ascenseur bien trop fainà ©ant pour cela
Ãa n'a _strictement_ rien à voir. Je peux te faire exactemen t la
même chose avec Motif qui n'est pas objet au sens du langage. Ce
n'est pas parce que tu manipules des structures (ou des objets
graphiques) que ton langage _doit_ être un langage objet !
Exprime-toi clairement parce que j'arrive pas à saisir la subtili té
de ton raisonnement.
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, mà ªme à la
relecture. Tu crées tes objets graphiques en les attachant le s uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.
l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeu r s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et n on maintenable
Non. La programmation objet, c'est l'illusion de la simplicité .
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du gr aphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux asso cier à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la st ructure
Et c'est justement ce qui est idiot.
bien au contraire c'est cela qui est carrément génial
par un exemple un tri il suffit juste d'une interface pour déplac er
les obj et un bout de code qui les déplace et ce bout de code est
désolidarisé des obj à trier et parfaitement interchang eable
et cela sans aucune incidence sur tes obj
Et c'est justement ce qui est ridicule. Lorsque tu veux trier un
une liste, tu commences à écrire un algorithme qui correspon d au
mieux aux objets que tu as à trier. Ãa peut aller d'un shell Metzner
à un tri bulle en passant par un tri par tas et tout un tas d'aut res
choses. Commenver par écrire un tri générique sur des o bjets
génériques est idiot et contre productif.
Je t'ai justement donné un
exemple avec la libbosst, mais tu refises de regarder ce qui se
passe :
1/ boost/graph décrit des graphes
2/ boost/astar implante un A*
Cette remarque liminaire mise à part, tu ne me feras jamais croir e
qu'on puisse être un bon programmeur si on n'arrive pas à à ©crire un
gros soft uniquement avec make, gcc, et vim. Tous les trucs qui
complètent les lignes à la façon netbeans sont des hà ©résies si tu ne
comprends pas ce que tu fais (et dans les détails, pas en gros !) .
Non, ce n'est pas la même chose, mais là encore, c'est toi q ui vois.
Je ne répondrai pas sur ton uv de programmation système vu l a
qualité de tes interventions sur le sujet.
tu confonds programmation obj et obj graphique à mon avis
MMmmmmmmmouarf ! Alors que tu t'emmêles les pinceaux depuis le dà ©but
avec ça ?... C'est l'hôpital qui se fout de la charité, ça !
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
et cela ne sera pas la dernière
Il ne faut jamais désespérer de toi.
Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Non, c'est parfaitement faux. Que tu le crois prouve simplement qu e
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques lig nes,
surtout lorsque ce sont de sombres histoires de synchronisation
le jour ou tu as besoin de synchronisation au demi pouillem prêt
c'est que ton algo est à revoir et pas qu'un peu
Tu n'as jamais eu à synchroniser des calculs parallèles oà ¹ des race
conditions à la noix peuvent tout te mettre par terre. Les
deadlocks, tu connais ?
la communication inter thread se fait par appel de fonction
en gros un pointeur dans les 2 threads et celui qui a fini le dit Ã
celui qui attend, les délais ne doivent pas rentrer en ligne de c ompte,
celui qui attend soit délègue son sommeil soit il se rend de hors et se
réveille de manière autonome
Ouaips, vraiment en gros alors...(cherche un peu race condition sur ton moteur de recherche favori).Lorsque tu prends la norme C ou Fortranquelque chose, tu _sais_ Ã quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionn ement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la g ueule
des codes que tu as déjà soumis ici et dans fsm, ça n e m'étonne pas
trop) que ces problèmes n'existent pas.
je pourrais te montrer des usines à gaz quand je faisais du black
donc un en particulier avec graphiste qui m'a bien pourri la vie Ã
vouloir changer la couleur des petites flèches dans les barres
d'ascenseur ça s'invente pas ça
et bien grâce à la programmation obj c'est tout à fait faisable
et je n'ai pas réécrit la barre d'ascenseur bien trop fainà ©ant pour cela
Ãa n'a _strictement_ rien à voir. Je peux te faire exactemen t la
même chose avec Motif qui n'est pas objet au sens du langage. Ce
n'est pas parce que tu manipules des structures (ou des objets
graphiques) que ton langage _doit_ être un langage objet !
Exprime-toi clairement parce que j'arrive pas à saisir la subtili té
de ton raisonnement.
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, mà ªme à la
relecture. Tu crées tes objets graphiques en les attachant le s uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeu r s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et n on maintenable
Non. La programmation objet, c'est l'illusion de la simplicité .
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du gr aphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux asso cier à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la st ructure
Et c'est justement ce qui est idiot.
bien au contraire c'est cela qui est carrément génial
par un exemple un tri il suffit juste d'une interface pour déplac er
les obj et un bout de code qui les déplace et ce bout de code est
désolidarisé des obj à trier et parfaitement interchang eable
et cela sans aucune incidence sur tes obj
Et c'est justement ce qui est ridicule. Lorsque tu veux trier un
une liste, tu commences à écrire un algorithme qui correspon d au
mieux aux objets que tu as à trier. Ãa peut aller d'un shell Metzner
à un tri bulle en passant par un tri par tas et tout un tas d'aut res
choses. Commenver par écrire un tri générique sur des o bjets
génériques est idiot et contre productif.
Je t'ai justement donné un
exemple avec la libbosst, mais tu refises de regarder ce qui se
passe :
1/ boost/graph décrit des graphes
2/ boost/astar implante un A*
Cette remarque liminaire mise à part, tu ne me feras jamais croir e
qu'on puisse être un bon programmeur si on n'arrive pas à à ©crire un
gros soft uniquement avec make, gcc, et vim. Tous les trucs qui
complètent les lignes à la façon netbeans sont des hà ©résies si tu ne
comprends pas ce que tu fais (et dans les détails, pas en gros !) .
Non, ce n'est pas la même chose, mais là encore, c'est toi q ui vois.
Je ne répondrai pas sur ton uv de programmation système vu l a
qualité de tes interventions sur le sujet.
tu confonds programmation obj et obj graphique à mon avis
MMmmmmmmmouarf ! Alors que tu t'emmêles les pinceaux depuis le dà ©but
avec ça ?... C'est l'hôpital qui se fout de la charité, ça !
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
et cela ne sera pas la dernière
Il ne faut jamais désespérer de toi.
JKB a écrit :Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques lignes,
surtout lorsque ce sont de sombres histoires de synchronisation
le jour ou tu as besoin de synchronisation au demi pouillem prêt
c'est que ton algo est à revoir et pas qu'un peu
Tu n'as jamais eu à synchroniser des calculs parallèles où des race
conditions à la noix peuvent tout te mettre par terre. Les
deadlocks, tu connais ?
oui oui je connais pour le calcul parallèle il y a 2 approches
soit tu parallélises le calcul et tu as des temps de synchro inhérent au
calcul soit tu parallélises la méthode de calcul
pas sur d'être très clair en gros
une recherche de facteurs sur un nombre pq
2 threads
1 qui recherche les nombres premiers
et le 2 ieme qui se sert du premier pour vérifier la présence du facteur
dans pq
soit tu coupes en plusieurs morceaux l'espace de recherche des facteurs
dans le nombre
1 thread qui teste tous les nombres premiers jusqu'à n
et le deuxième qui teste de n à p*q
l'un est optimal l'autre merdique devine le quel
la communication inter thread se fait par appel de fonction
en gros un pointeur dans les 2 threads et celui qui a fini le dit à
celui qui attend, les délais ne doivent pas rentrer en ligne de compte,
celui qui attend soit délègue son sommeil soit il se rend dehors et se
réveille de manière autonome
Ouaips, vraiment en gros alors...(cherche un peu race condition sur ton moteur de recherche favori).Lorsque tu prends la norme C ou Fortranquelque chose, tu _sais_ à quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la gueule
des codes que tu as déjà soumis ici et dans fsm, ça ne m'étonne pas
trop) que ces problèmes n'existent pas.
je pourrais te montrer des usines à gaz quand je faisais du black
donc un en particulier avec graphiste qui m'a bien pourri la vie à
vouloir changer la couleur des petites flèches dans les barres
d'ascenseur ça s'invente pas ça
et bien grâce à la programmation obj c'est tout à fait faisable
et je n'ai pas réécrit la barre d'ascenseur bien trop fainéant pour cela
Ça n'a _strictement_ rien à voir. Je peux te faire exactement la
même chose avec Motif qui n'est pas objet au sens du langage. Ce
n'est pas parce que tu manipules des structures (ou des objets
graphiques) que ton langage _doit_ être un langage objet !
sauf que l'un l'impose, l'autre le souhaite
Exprime-toi clairement parce que j'arrive pas à saisir la subtilité
de ton raisonnement.
on parlait de la portabilité du code java et tu me disais que rien ne
remplacait un compilateur c, ce à quoi je te disais, peut être mais l'on
installe pas un code source, mais un binaire
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, même à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du graphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associer à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la structure
Et c'est justement ce qui est idiot.
bien au contraire c'est cela qui est carrément génial
par un exemple un tri il suffit juste d'une interface pour déplacer
les obj et un bout de code qui les déplace et ce bout de code est
désolidarisé des obj à trier et parfaitement interchangeable
et cela sans aucune incidence sur tes obj
Et c'est justement ce qui est ridicule. Lorsque tu veux trier un
une liste, tu commences à écrire un algorithme qui correspond au
mieux aux objets que tu as à trier. Ça peut aller d'un shell Metzner
à un tri bulle en passant par un tri par tas et tout un tas d'autres
choses. Commenver par écrire un tri générique sur des objets
génériques est idiot et contre productif.
mais non au contraire tu t'en fous de la nature de l'olj que cela soit
un entier ou un flottant (pelle à tarte mur en crépi)
tu n'as besoin que de déplacer l'obj donc tu mets ton machin dedans et
tu déplaces l'obj avec une interface et l'algo que tu veux
et cet algo est interchangeable ,l'algo ne voie que l'interface
Je t'ai justement donné un
exemple avec la libbosst, mais tu refises de regarder ce qui se
passe :
je ne connais pas et n'envisage pas de m'y intéresser
1/ boost/graph décrit des graphes
2/ boost/astar implante un A*
un quoi ?
Cette remarque liminaire mise à part, tu ne me feras jamais croire
qu'on puisse être un bon programmeur si on n'arrive pas à écrire un
gros soft uniquement avec make, gcc, et vim. Tous les trucs qui
complètent les lignes à la façon netbeans sont des hérésies si tu ne
comprends pas ce que tu fais (et dans les détails, pas en gros !).
ha là on est complètement d'accord c'est inutile sauf pour gagner du
temps et faire du contrôle d'erreur mais un vieux s'en passe très bien
Non, ce n'est pas la même chose, mais là encore, c'est toi qui vois.
Je ne répondrai pas sur ton uv de programmation système vu la
qualité de tes interventions sur le sujet.
c'est comme tu veux
tu confonds programmation obj et obj graphique à mon avis
MMmmmmmmmouarf ! Alors que tu t'emmêles les pinceaux depuis le début
avec ça ?... C'est l'hôpital qui se fout de la charité, ça !
et je veux bien passer pour un con mais
il faut pas pousser mémé dans les orties j'ai toujours fait le distingo
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
et cela ne sera pas la dernière
Il ne faut jamais désespérer de toi.
j'espère bien à demain
JKB a écrit :
Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques lignes,
surtout lorsque ce sont de sombres histoires de synchronisation
le jour ou tu as besoin de synchronisation au demi pouillem prêt
c'est que ton algo est à revoir et pas qu'un peu
Tu n'as jamais eu à synchroniser des calculs parallèles où des race
conditions à la noix peuvent tout te mettre par terre. Les
deadlocks, tu connais ?
oui oui je connais pour le calcul parallèle il y a 2 approches
soit tu parallélises le calcul et tu as des temps de synchro inhérent au
calcul soit tu parallélises la méthode de calcul
pas sur d'être très clair en gros
une recherche de facteurs sur un nombre pq
2 threads
1 qui recherche les nombres premiers
et le 2 ieme qui se sert du premier pour vérifier la présence du facteur
dans pq
soit tu coupes en plusieurs morceaux l'espace de recherche des facteurs
dans le nombre
1 thread qui teste tous les nombres premiers jusqu'à n
et le deuxième qui teste de n à p*q
l'un est optimal l'autre merdique devine le quel
la communication inter thread se fait par appel de fonction
en gros un pointeur dans les 2 threads et celui qui a fini le dit à
celui qui attend, les délais ne doivent pas rentrer en ligne de compte,
celui qui attend soit délègue son sommeil soit il se rend dehors et se
réveille de manière autonome
Ouaips, vraiment en gros alors...
(cherche un peu race condition sur ton moteur de recherche favori).
Lorsque tu prends la norme C ou Fortran
quelque chose, tu _sais_ à quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la gueule
des codes que tu as déjà soumis ici et dans fsm, ça ne m'étonne pas
trop) que ces problèmes n'existent pas.
je pourrais te montrer des usines à gaz quand je faisais du black
donc un en particulier avec graphiste qui m'a bien pourri la vie à
vouloir changer la couleur des petites flèches dans les barres
d'ascenseur ça s'invente pas ça
et bien grâce à la programmation obj c'est tout à fait faisable
et je n'ai pas réécrit la barre d'ascenseur bien trop fainéant pour cela
Ça n'a _strictement_ rien à voir. Je peux te faire exactement la
même chose avec Motif qui n'est pas objet au sens du langage. Ce
n'est pas parce que tu manipules des structures (ou des objets
graphiques) que ton langage _doit_ être un langage objet !
sauf que l'un l'impose, l'autre le souhaite
Exprime-toi clairement parce que j'arrive pas à saisir la subtilité
de ton raisonnement.
on parlait de la portabilité du code java et tu me disais que rien ne
remplacait un compilateur c, ce à quoi je te disais, peut être mais l'on
installe pas un code source, mais un binaire
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, même à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.
l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du graphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associer à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la structure
Et c'est justement ce qui est idiot.
bien au contraire c'est cela qui est carrément génial
par un exemple un tri il suffit juste d'une interface pour déplacer
les obj et un bout de code qui les déplace et ce bout de code est
désolidarisé des obj à trier et parfaitement interchangeable
et cela sans aucune incidence sur tes obj
Et c'est justement ce qui est ridicule. Lorsque tu veux trier un
une liste, tu commences à écrire un algorithme qui correspond au
mieux aux objets que tu as à trier. Ça peut aller d'un shell Metzner
à un tri bulle en passant par un tri par tas et tout un tas d'autres
choses. Commenver par écrire un tri générique sur des objets
génériques est idiot et contre productif.
mais non au contraire tu t'en fous de la nature de l'olj que cela soit
un entier ou un flottant (pelle à tarte mur en crépi)
tu n'as besoin que de déplacer l'obj donc tu mets ton machin dedans et
tu déplaces l'obj avec une interface et l'algo que tu veux
et cet algo est interchangeable ,l'algo ne voie que l'interface
Je t'ai justement donné un
exemple avec la libbosst, mais tu refises de regarder ce qui se
passe :
je ne connais pas et n'envisage pas de m'y intéresser
1/ boost/graph décrit des graphes
2/ boost/astar implante un A*
un quoi ?
Cette remarque liminaire mise à part, tu ne me feras jamais croire
qu'on puisse être un bon programmeur si on n'arrive pas à écrire un
gros soft uniquement avec make, gcc, et vim. Tous les trucs qui
complètent les lignes à la façon netbeans sont des hérésies si tu ne
comprends pas ce que tu fais (et dans les détails, pas en gros !).
ha là on est complètement d'accord c'est inutile sauf pour gagner du
temps et faire du contrôle d'erreur mais un vieux s'en passe très bien
Non, ce n'est pas la même chose, mais là encore, c'est toi qui vois.
Je ne répondrai pas sur ton uv de programmation système vu la
qualité de tes interventions sur le sujet.
c'est comme tu veux
tu confonds programmation obj et obj graphique à mon avis
MMmmmmmmmouarf ! Alors que tu t'emmêles les pinceaux depuis le début
avec ça ?... C'est l'hôpital qui se fout de la charité, ça !
et je veux bien passer pour un con mais
il faut pas pousser mémé dans les orties j'ai toujours fait le distingo
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
et cela ne sera pas la dernière
Il ne faut jamais désespérer de toi.
j'espère bien à demain
JKB a écrit :Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :JKB a écrit :Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).
jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java
Les problèmes, tu ne les as pas avec un exemple de quelques lignes,
surtout lorsque ce sont de sombres histoires de synchronisation
le jour ou tu as besoin de synchronisation au demi pouillem prêt
c'est que ton algo est à revoir et pas qu'un peu
Tu n'as jamais eu à synchroniser des calculs parallèles où des race
conditions à la noix peuvent tout te mettre par terre. Les
deadlocks, tu connais ?
oui oui je connais pour le calcul parallèle il y a 2 approches
soit tu parallélises le calcul et tu as des temps de synchro inhérent au
calcul soit tu parallélises la méthode de calcul
pas sur d'être très clair en gros
une recherche de facteurs sur un nombre pq
2 threads
1 qui recherche les nombres premiers
et le 2 ieme qui se sert du premier pour vérifier la présence du facteur
dans pq
soit tu coupes en plusieurs morceaux l'espace de recherche des facteurs
dans le nombre
1 thread qui teste tous les nombres premiers jusqu'à n
et le deuxième qui teste de n à p*q
l'un est optimal l'autre merdique devine le quel
la communication inter thread se fait par appel de fonction
en gros un pointeur dans les 2 threads et celui qui a fini le dit à
celui qui attend, les délais ne doivent pas rentrer en ligne de compte,
celui qui attend soit délègue son sommeil soit il se rend dehors et se
réveille de manière autonome
Ouaips, vraiment en gros alors...(cherche un peu race condition sur ton moteur de recherche favori).Lorsque tu prends la norme C ou Fortranquelque chose, tu _sais_ à quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnement
de tes logiciels sur la JVM cible.
connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents
Ce n'est pas parce que tu n'as _jamais_ eu de problème (vu la gueule
des codes que tu as déjà soumis ici et dans fsm, ça ne m'étonne pas
trop) que ces problèmes n'existent pas.
je pourrais te montrer des usines à gaz quand je faisais du black
donc un en particulier avec graphiste qui m'a bien pourri la vie à
vouloir changer la couleur des petites flèches dans les barres
d'ascenseur ça s'invente pas ça
et bien grâce à la programmation obj c'est tout à fait faisable
et je n'ai pas réécrit la barre d'ascenseur bien trop fainéant pour cela
Ça n'a _strictement_ rien à voir. Je peux te faire exactement la
même chose avec Motif qui n'est pas objet au sens du langage. Ce
n'est pas parce que tu manipules des structures (ou des objets
graphiques) que ton langage _doit_ être un langage objet !
sauf que l'un l'impose, l'autre le souhaite
Exprime-toi clairement parce que j'arrive pas à saisir la subtilité
de ton raisonnement.
on parlait de la portabilité du code java et tu me disais que rien ne
remplacait un compilateur c, ce à quoi je te disais, peut être mais l'on
installe pas un code source, mais un binaire
Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, même à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable
Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du graphe
associé.
tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associer à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la structure
Et c'est justement ce qui est idiot.
bien au contraire c'est cela qui est carrément génial
par un exemple un tri il suffit juste d'une interface pour déplacer
les obj et un bout de code qui les déplace et ce bout de code est
désolidarisé des obj à trier et parfaitement interchangeable
et cela sans aucune incidence sur tes obj
Et c'est justement ce qui est ridicule. Lorsque tu veux trier un
une liste, tu commences à écrire un algorithme qui correspond au
mieux aux objets que tu as à trier. Ça peut aller d'un shell Metzner
à un tri bulle en passant par un tri par tas et tout un tas d'autres
choses. Commenver par écrire un tri générique sur des objets
génériques est idiot et contre productif.
mais non au contraire tu t'en fous de la nature de l'olj que cela soit
un entier ou un flottant (pelle à tarte mur en crépi)
tu n'as besoin que de déplacer l'obj donc tu mets ton machin dedans et
tu déplaces l'obj avec une interface et l'algo que tu veux
et cet algo est interchangeable ,l'algo ne voie que l'interface
Je t'ai justement donné un
exemple avec la libbosst, mais tu refises de regarder ce qui se
passe :
je ne connais pas et n'envisage pas de m'y intéresser
1/ boost/graph décrit des graphes
2/ boost/astar implante un A*
un quoi ?
Cette remarque liminaire mise à part, tu ne me feras jamais croire
qu'on puisse être un bon programmeur si on n'arrive pas à écrire un
gros soft uniquement avec make, gcc, et vim. Tous les trucs qui
complètent les lignes à la façon netbeans sont des hérésies si tu ne
comprends pas ce que tu fais (et dans les détails, pas en gros !).
ha là on est complètement d'accord c'est inutile sauf pour gagner du
temps et faire du contrôle d'erreur mais un vieux s'en passe très bien
Non, ce n'est pas la même chose, mais là encore, c'est toi qui vois.
Je ne répondrai pas sur ton uv de programmation système vu la
qualité de tes interventions sur le sujet.
c'est comme tu veux
tu confonds programmation obj et obj graphique à mon avis
MMmmmmmmmouarf ! Alors que tu t'emmêles les pinceaux depuis le début
avec ça ?... C'est l'hôpital qui se fout de la charité, ça !
et je veux bien passer pour un con mais
il faut pas pousser mémé dans les orties j'ai toujours fait le distingo
<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>
Une connerie de plus à ton actif...
et cela ne sera pas la dernière
Il ne faut jamais désespérer de toi.
j'espère bien à demain
JKB a écrit :Le 01-04-2010, ? propos de
os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :c'est déjà pas mal que java depuis le rachat de
sun a un avenir incertain
Bof. Déjà, il faudrait voir en quoi java est essentiel à
l'informatique
comment ça c'est pas le premier, ok mais il apporte une vraie
portabilité du code "compilé"
et pourtant il y a un autre domaine où il pourrait être super utile au
hasard les os
Un OS en C++, p'taing, ce qu'il ne faut pas entendre. Il y a
de couches d'abstractions dans du C++ que c'est contre-productif,
c'est à toi de voir. Il y a régulièrement des batailles pour
C++ dans les noyaux Unix et ça termine toujours de la même
je serais assez partisan d'un peu d'obj dans les drivers cela
le changement d'interface à chaque nouvelle bibliothèque
quand pensez vous ?
JKB a écrit :
Le 01-04-2010, ? propos de
os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :
c'est déjà pas mal que java depuis le rachat de
sun a un avenir incertain
Bof. Déjà, il faudrait voir en quoi java est essentiel à
l'informatique
comment ça c'est pas le premier, ok mais il apporte une vraie
portabilité du code "compilé"
et pourtant il y a un autre domaine où il pourrait être super utile au
hasard les os
Un OS en C++, p'taing, ce qu'il ne faut pas entendre. Il y a
de couches d'abstractions dans du C++ que c'est contre-productif,
c'est à toi de voir. Il y a régulièrement des batailles pour
C++ dans les noyaux Unix et ça termine toujours de la même
je serais assez partisan d'un peu d'obj dans les drivers cela
le changement d'interface à chaque nouvelle bibliothèque
quand pensez vous ?
JKB a écrit :Le 01-04-2010, ? propos de
os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :c'est déjà pas mal que java depuis le rachat de
sun a un avenir incertain
Bof. Déjà, il faudrait voir en quoi java est essentiel à
l'informatique
comment ça c'est pas le premier, ok mais il apporte une vraie
portabilité du code "compilé"
et pourtant il y a un autre domaine où il pourrait être super utile au
hasard les os
Un OS en C++, p'taing, ce qu'il ne faut pas entendre. Il y a
de couches d'abstractions dans du C++ que c'est contre-productif,
c'est à toi de voir. Il y a régulièrement des batailles pour
C++ dans les noyaux Unix et ça termine toujours de la même
je serais assez partisan d'un peu d'obj dans les drivers cela
le changement d'interface à chaque nouvelle bibliothèque
quand pensez vous ?
> comment ça c'est pas le premier, ok mais il apporte une vraie
> portabilité du code "compilé"
Tu veux dire, comme l'applet de l'interface web des HP ProCurve, qui
fonctionne dans Firefox sur Windows et pas dans Firefox sur GNU/Linux ?
> comment ça c'est pas le premier, ok mais il apporte une vraie
> portabilité du code "compilé"
Tu veux dire, comme l'applet de l'interface web des HP ProCurve, qui
fonctionne dans Firefox sur Windows et pas dans Firefox sur GNU/Linux ?
> comment ça c'est pas le premier, ok mais il apporte une vraie
> portabilité du code "compilé"
Tu veux dire, comme l'applet de l'interface web des HP ProCurve, qui
fonctionne dans Firefox sur Windows et pas dans Firefox sur GNU/Linux ?
Pourquoi ? J'ai codé des trucs parfaitement aboutis avec un simple
compilo C et X11/Xt/Xm. Pas besoin de C++ pour cela. Et Motif est
un truc _très_ agréable à coder en C.
Maintenant, on peut ne pas aimer le
design de Motif, personnellement, j'aime assez parce que ce
design se fait par un fichier externe au soft compilé, ce qui est très
bien.
Pourquoi ? J'ai codé des trucs parfaitement aboutis avec un simple
compilo C et X11/Xt/Xm. Pas besoin de C++ pour cela. Et Motif est
un truc _très_ agréable à coder en C.
Maintenant, on peut ne pas aimer le
design de Motif, personnellement, j'aime assez parce que ce
design se fait par un fichier externe au soft compilé, ce qui est très
bien.
Pourquoi ? J'ai codé des trucs parfaitement aboutis avec un simple
compilo C et X11/Xt/Xm. Pas besoin de C++ pour cela. Et Motif est
un truc _très_ agréable à coder en C.
Maintenant, on peut ne pas aimer le
design de Motif, personnellement, j'aime assez parce que ce
design se fait par un fichier externe au soft compilé, ce qui est très
bien.
je ne connait pas motif, mais une interface graphique qui n'est pas obj
si elle ne l'est pas j'en veux pas
Tu peux faire _sans_ objet au sens programmation objet. Et pour
fait du Qt (objet) et du Motif (non objet), la programmation de
est bien plus efficace et facile.
je ne connait pas motif, mais une interface graphique qui n'est pas obj
si elle ne l'est pas j'en veux pas
Tu peux faire _sans_ objet au sens programmation objet. Et pour
fait du Qt (objet) et du Motif (non objet), la programmation de
est bien plus efficace et facile.
je ne connait pas motif, mais une interface graphique qui n'est pas obj
si elle ne l'est pas j'en veux pas
Tu peux faire _sans_ objet au sens programmation objet. Et pour
fait du Qt (objet) et du Motif (non objet), la programmation de
est bien plus efficace et facile.
Je te demande d'utiliser un calcul de trajet issu de pgrouting
C++) et le même algorithme codé à la main.
Je te demande d'utiliser un calcul de trajet issu de pgrouting
C++) et le même algorithme codé à la main.
Je te demande d'utiliser un calcul de trajet issu de pgrouting
C++) et le même algorithme codé à la main.