Oups, il semble que le message précédent soit parti trop vite...
J'ai un code dont le but est de mapper un type de base avec un type préd
éfini (pour faire de l'échange réseau binaire entre machines non homogèn
es). Il ressemble à ça :
template <typename T> struct NetworkType
{
};
Le code marche assez bien, sauf que quand je veux spécialiser le templat
e pour size_t, par exemple, j'ai un problème, puisque size_t est un type
def, et non un type à part entière.
Et il se peut que sur une machine size_t soit un int (et donc mappé avec
un int32), et sur une autre un long qui serait mappé avec un int64, alo
rs que je souhaite que size_t soit mappé sur un type unique.
Y a-t-il une solution à mon problème ?
--
Loïc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Article poste via Voila News - http://www.news.voila.fr
Le : Wed Oct 8 17:11:46 2003 depuis l'IP : clara2.renault.fr [VIP 8630229]
J'ai un code dont le but est de mapper un type de base avec un type préd éfini (pour faire de l'échange réseau binaire entre machines non homogèn es). Il ressemble à ça :
Le code marche assez bien, sauf que quand je veux spécialiser le templat e pour size_t, par exemple, j'ai un problème, puisque size_t est un type def, et non un type à part entière.
Et il se peut que sur une machine size_t soit un int (et donc mappé avec un int32), et sur une autre un long qui serait mappé avec un int64, alo rs que je souhaite que size_t soit mappé sur un type unique.
Si ton size_t est "mappé avec un int64", comment feras-tu pour encoder une valeur > 2^32 ?
Encoder en quel sens ? Si c'est pour transmission sur un reseau en tant que entier dans un protocol, tu ne peux pas. Mais c'est un problème général -- qu'est-ce que tu ferais si ton int a 64 bits (ou même 36) ? Il faut toujours vérifier que la valeur se trouve dans l'intervalle légal, et générer une erreur sinon.
À mon avis, tu risquerais davantage de problèmes en sens envers -- qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole transmet des entiers de 32 bits, et tu reçois quelque chose qui ne passe pas ?
Y a-t-il une solution à mon problème ?
J'ai peur que le problème soit mal posé, malheureusement.
Pour faire communiquer des machines non-homogènes, tu dois définir des types abstraits, avec un encodage fixe, les opérations qui sont permises dessus, les plages de valeur, et les conversions faites pour les machines réelles.
Non ?
Oui, mais je ne comprends pas où en est le problème. En général, je me contente des fonctions qui prenent des long et/ou des unsigned long, je valide l'intervalle, et génère une erreur le cas échéant.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote in message
news:<bm31mf$36v$1@news.cict.fr>...
In article <bm19fj$vlc$1@news.x-echo.com>, Loïc Joly wrote:
J'ai un code dont le but est de mapper un type de base avec un type
préd éfini (pour faire de l'échange réseau binaire entre machines
non homogèn es). Il ressemble à ça :
Le code marche assez bien, sauf que quand je veux spécialiser le
templat e pour size_t, par exemple, j'ai un problème, puisque size_t
est un type def, et non un type à part entière.
Et il se peut que sur une machine size_t soit un int (et donc mappé
avec un int32), et sur une autre un long qui serait mappé avec un
int64, alo rs que je souhaite que size_t soit mappé sur un type
unique.
Si ton size_t est "mappé avec un int64", comment feras-tu pour
encoder une valeur > 2^32 ?
Encoder en quel sens ? Si c'est pour transmission sur un reseau en tant
que entier dans un protocol, tu ne peux pas. Mais c'est un problème
général -- qu'est-ce que tu ferais si ton int a 64 bits (ou même 36) ?
Il faut toujours vérifier que la valeur se trouve dans l'intervalle
légal, et générer une erreur sinon.
À mon avis, tu risquerais davantage de problèmes en sens envers --
qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole
transmet des entiers de 32 bits, et tu reçois quelque chose qui ne passe
pas ?
Y a-t-il une solution à mon problème ?
J'ai peur que le problème soit mal posé, malheureusement.
Pour faire communiquer des machines non-homogènes, tu dois définir
des types abstraits, avec un encodage fixe, les opérations qui sont
permises dessus, les plages de valeur, et les conversions faites pour
les machines réelles.
Non ?
Oui, mais je ne comprends pas où en est le problème. En général, je me
contente des fonctions qui prenent des long et/ou des unsigned long, je
valide l'intervalle, et génère une erreur le cas échéant.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
J'ai un code dont le but est de mapper un type de base avec un type préd éfini (pour faire de l'échange réseau binaire entre machines non homogèn es). Il ressemble à ça :
Le code marche assez bien, sauf que quand je veux spécialiser le templat e pour size_t, par exemple, j'ai un problème, puisque size_t est un type def, et non un type à part entière.
Et il se peut que sur une machine size_t soit un int (et donc mappé avec un int32), et sur une autre un long qui serait mappé avec un int64, alo rs que je souhaite que size_t soit mappé sur un type unique.
Si ton size_t est "mappé avec un int64", comment feras-tu pour encoder une valeur > 2^32 ?
Encoder en quel sens ? Si c'est pour transmission sur un reseau en tant que entier dans un protocol, tu ne peux pas. Mais c'est un problème général -- qu'est-ce que tu ferais si ton int a 64 bits (ou même 36) ? Il faut toujours vérifier que la valeur se trouve dans l'intervalle légal, et générer une erreur sinon.
À mon avis, tu risquerais davantage de problèmes en sens envers -- qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole transmet des entiers de 32 bits, et tu reçois quelque chose qui ne passe pas ?
Y a-t-il une solution à mon problème ?
J'ai peur que le problème soit mal posé, malheureusement.
Pour faire communiquer des machines non-homogènes, tu dois définir des types abstraits, avec un encodage fixe, les opérations qui sont permises dessus, les plages de valeur, et les conversions faites pour les machines réelles.
Non ?
Oui, mais je ne comprends pas où en est le problème. En général, je me contente des fonctions qui prenent des long et/ou des unsigned long, je valide l'intervalle, et génère une erreur le cas échéant.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer
wrote:
Marc Boyer wrote in message news:<bm31mf$36v$...
In article <bm19fj$vlc$, Loïc Joly wrote:
J'ai un code dont le but est de mapper un type de base avec un type préd éfini (pour faire de l'échange réseau binaire entre machines non homogèn es). Il ressemble à ça : Et il se peut que sur une machine size_t soit un int (et donc mappé avec un int32), et sur une autre un long qui serait mappé avec un int64, alo rs que je souhaite que size_t soit mappé sur un type unique.
Si ton size_t est "mappé avec un int64", comment feras-tu pour encoder une valeur > 2^32 ?
Encoder en quel sens ? Si c'est pour transmission sur un reseau en tant que entier dans un protocol, tu ne peux pas. Mais c'est un problème général -- qu'est-ce que tu ferais si ton int a 64 bits (ou même 36) ? Il faut toujours vérifier que la valeur se trouve dans l'intervalle légal, et générer une erreur sinon.
Oui, tout à fait. Disons que ma question voulait faire comprendre au posteur initial que la solution pour size_t ne pouvait être vue que en rapport avec les autres règles de débordement. Mon intuition, c'est qu'il est partit dans le codage sans analyse complète du problème (sans quoi, il aurait donné une réponse à ma question). Mais mon intuition peut me jouer des tours.
À mon avis, tu risquerais davantage de problèmes en sens envers -- qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole transmet des entiers de 32 bits, et tu reçois quelque chose qui ne passe pas ?
Moi, je sais faire une conversion sans perte 16 bits -> 32 bits, alors le problème m'inquiette moins ;-)
Oui, mais je ne comprends pas où en est le problème. En général, je me contente des fonctions qui prenent des long et/ou des unsigned long, je valide l'intervalle, et génère une erreur le cas échéant.
Oui, mais si tu avais été le posteur initial, j'aurais jamais osé parler d'une erreur de conception.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
kanze@gabi-soft.fr wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote in message
news:<bm31mf$36v$1@news.cict.fr>...
In article <bm19fj$vlc$1@news.x-echo.com>, Loïc Joly wrote:
J'ai un code dont le but est de mapper un type de base avec un type
préd éfini (pour faire de l'échange réseau binaire entre machines
non homogèn es). Il ressemble à ça :
Et il se peut que sur une machine size_t soit un int (et donc mappé
avec un int32), et sur une autre un long qui serait mappé avec un
int64, alo rs que je souhaite que size_t soit mappé sur un type
unique.
Si ton size_t est "mappé avec un int64", comment feras-tu pour
encoder une valeur > 2^32 ?
Encoder en quel sens ? Si c'est pour transmission sur un reseau en tant
que entier dans un protocol, tu ne peux pas. Mais c'est un problème
général -- qu'est-ce que tu ferais si ton int a 64 bits (ou même 36) ?
Il faut toujours vérifier que la valeur se trouve dans l'intervalle
légal, et générer une erreur sinon.
Oui, tout à fait.
Disons que ma question voulait faire comprendre au posteur initial
que la solution pour size_t ne pouvait être vue que en rapport avec
les autres règles de débordement.
Mon intuition, c'est qu'il est partit dans le codage sans
analyse complète du problème (sans quoi, il aurait donné une
réponse à ma question). Mais mon intuition peut me jouer
des tours.
À mon avis, tu risquerais davantage de problèmes en sens envers --
qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole
transmet des entiers de 32 bits, et tu reçois quelque chose qui ne passe
pas ?
Moi, je sais faire une conversion sans perte 16 bits -> 32 bits,
alors le problème m'inquiette moins ;-)
Oui, mais je ne comprends pas où en est le problème. En général, je me
contente des fonctions qui prenent des long et/ou des unsigned long, je
valide l'intervalle, et génère une erreur le cas échéant.
Oui, mais si tu avais été le posteur initial, j'aurais jamais
osé parler d'une erreur de conception.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
J'ai un code dont le but est de mapper un type de base avec un type préd éfini (pour faire de l'échange réseau binaire entre machines non homogèn es). Il ressemble à ça : Et il se peut que sur une machine size_t soit un int (et donc mappé avec un int32), et sur une autre un long qui serait mappé avec un int64, alo rs que je souhaite que size_t soit mappé sur un type unique.
Si ton size_t est "mappé avec un int64", comment feras-tu pour encoder une valeur > 2^32 ?
Encoder en quel sens ? Si c'est pour transmission sur un reseau en tant que entier dans un protocol, tu ne peux pas. Mais c'est un problème général -- qu'est-ce que tu ferais si ton int a 64 bits (ou même 36) ? Il faut toujours vérifier que la valeur se trouve dans l'intervalle légal, et générer une erreur sinon.
Oui, tout à fait. Disons que ma question voulait faire comprendre au posteur initial que la solution pour size_t ne pouvait être vue que en rapport avec les autres règles de débordement. Mon intuition, c'est qu'il est partit dans le codage sans analyse complète du problème (sans quoi, il aurait donné une réponse à ma question). Mais mon intuition peut me jouer des tours.
À mon avis, tu risquerais davantage de problèmes en sens envers -- qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole transmet des entiers de 32 bits, et tu reçois quelque chose qui ne passe pas ?
Moi, je sais faire une conversion sans perte 16 bits -> 32 bits, alors le problème m'inquiette moins ;-)
Oui, mais je ne comprends pas où en est le problème. En général, je me contente des fonctions qui prenent des long et/ou des unsigned long, je valide l'intervalle, et génère une erreur le cas échéant.
Oui, mais si tu avais été le posteur initial, j'aurais jamais osé parler d'une erreur de conception.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
kanze
Marc Boyer wrote in message news:<bm5nlp$hh0$...
wrote:
Marc Boyer wrote in message news:<bm31mf$36v$...
[...]
À mon avis, tu risquerais davantage de problèmes en sens envers -- qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole transmet des entiers de 32 bits, et tu reçois quelque chose qui ne passe pas ?
Moi, je sais faire une conversion sans perte 16 bits -> 32 bits, alors le problème m'inquiette moins ;-)
Un protocole, ça marche dans les deux sens. Si le protocol utilise 32 bits, et tu en as 36, les seuls débordements se produisent en sortie, et tu peux les détecter avant l'émission -- ce que tu essaies d'émettre n'est pas conform. Si le protocol utilise 32 bits, et tu n'en as que 16, les débordements vont se produire en entrée : tu as reçu un message conforme, que le protocole exige que tu traites. Mais comment ?
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote in message
news:<bm5nlp$hh0$1@news.cict.fr>...
kanze@gabi-soft.fr wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote in message
news:<bm31mf$36v$1@news.cict.fr>...
[...]
À mon avis, tu risquerais davantage de problèmes en sens envers --
qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole
transmet des entiers de 32 bits, et tu reçois quelque chose qui ne
passe pas ?
Moi, je sais faire une conversion sans perte 16 bits -> 32 bits,
alors le problème m'inquiette moins ;-)
Un protocole, ça marche dans les deux sens. Si le protocol utilise 32
bits, et tu en as 36, les seuls débordements se produisent en sortie, et
tu peux les détecter avant l'émission -- ce que tu essaies d'émettre
n'est pas conform. Si le protocol utilise 32 bits, et tu n'en as que 16,
les débordements vont se produire en entrée : tu as reçu un message
conforme, que le protocole exige que tu traites. Mais comment ?
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
À mon avis, tu risquerais davantage de problèmes en sens envers -- qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole transmet des entiers de 32 bits, et tu reçois quelque chose qui ne passe pas ?
Moi, je sais faire une conversion sans perte 16 bits -> 32 bits, alors le problème m'inquiette moins ;-)
Un protocole, ça marche dans les deux sens. Si le protocol utilise 32 bits, et tu en as 36, les seuls débordements se produisent en sortie, et tu peux les détecter avant l'émission -- ce que tu essaies d'émettre n'est pas conform. Si le protocol utilise 32 bits, et tu n'en as que 16, les débordements vont se produire en entrée : tu as reçu un message conforme, que le protocole exige que tu traites. Mais comment ?
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer
wrote:
Marc Boyer wrote in message news:<bm5nlp$hh0$...
wrote:
Marc Boyer wrote in message À mon avis, tu risquerais davantage de problèmes en sens envers -- qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole transmet des entiers de 32 bits, et tu reçois quelque chose qui ne passe pas ?
Moi, je sais faire une conversion sans perte 16 bits -> 32 bits, alors le problème m'inquiette moins ;-)
Un protocole, ça marche dans les deux sens. Si le protocol utilise 32 bits, et tu en as 36, les seuls débordements se produisent en sortie, et tu peux les détecter avant l'émission -- ce que tu essaies d'émettre n'est pas conform. Si le protocol utilise 32 bits, et tu n'en as que 16, les débordements vont se produire en entrée : tu as reçu un message conforme, que le protocole exige que tu traites. Mais comment ?
Oui, tout dépend si le protocole existe déjà, et si le problème est de l'implémenter, ou si on cherche a definir le protocole. En lisant le peu de code de l'OP, j'avais tendance à croire que le protocole n'existait pas encore, et c'est pour cela que je soulignais l'importance de définir d'abord les types abstrait, leur plages de valeur, tout ça. Et une bonne analyse devrait permettre de voir tous ces problèmes, non ? (en tout cas, c'est comme ça que c'est écrit dans les livres ;-) )
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
kanze@gabi-soft.fr wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote in message
news:<bm5nlp$hh0$1@news.cict.fr>...
kanze@gabi-soft.fr wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote in message
À mon avis, tu risquerais davantage de problèmes en sens envers --
qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole
transmet des entiers de 32 bits, et tu reçois quelque chose qui ne
passe pas ?
Moi, je sais faire une conversion sans perte 16 bits -> 32 bits,
alors le problème m'inquiette moins ;-)
Un protocole, ça marche dans les deux sens. Si le protocol utilise 32
bits, et tu en as 36, les seuls débordements se produisent en sortie, et
tu peux les détecter avant l'émission -- ce que tu essaies d'émettre
n'est pas conform. Si le protocol utilise 32 bits, et tu n'en as que 16,
les débordements vont se produire en entrée : tu as reçu un message
conforme, que le protocole exige que tu traites. Mais comment ?
Oui, tout dépend si le protocole existe déjà, et si le problème
est de l'implémenter, ou si on cherche a definir le protocole.
En lisant le peu de code de l'OP, j'avais tendance à croire
que le protocole n'existait pas encore, et c'est pour cela
que je soulignais l'importance de définir d'abord les types
abstrait, leur plages de valeur, tout ça.
Et une bonne analyse devrait permettre de voir tous
ces problèmes, non ? (en tout cas, c'est comme ça que
c'est écrit dans les livres ;-) )
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Marc Boyer wrote in message À mon avis, tu risquerais davantage de problèmes en sens envers -- qu'est-ce que tu comptes faire si size_t a 16 bits, le protocole transmet des entiers de 32 bits, et tu reçois quelque chose qui ne passe pas ?
Moi, je sais faire une conversion sans perte 16 bits -> 32 bits, alors le problème m'inquiette moins ;-)
Un protocole, ça marche dans les deux sens. Si le protocol utilise 32 bits, et tu en as 36, les seuls débordements se produisent en sortie, et tu peux les détecter avant l'émission -- ce que tu essaies d'émettre n'est pas conform. Si le protocol utilise 32 bits, et tu n'en as que 16, les débordements vont se produire en entrée : tu as reçu un message conforme, que le protocole exige que tu traites. Mais comment ?
Oui, tout dépend si le protocole existe déjà, et si le problème est de l'implémenter, ou si on cherche a definir le protocole. En lisant le peu de code de l'OP, j'avais tendance à croire que le protocole n'existait pas encore, et c'est pour cela que je soulignais l'importance de définir d'abord les types abstrait, leur plages de valeur, tout ça. Et une bonne analyse devrait permettre de voir tous ces problèmes, non ? (en tout cas, c'est comme ça que c'est écrit dans les livres ;-) )
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Loïc Joly
Marc Boyer wrote:
J'ai peur que le problème soit mal posé, malheureusement. Pour faire communiquer des machines non-homogènes, tu dois définir des types abstraits, avec un encodage fixe, les opérations qui sont permises dessus, les plages de valeur, et les conversions faites pour les machines réelles. Non ?
J'ai en effet défini de tels types abstraits. Mais je n'avais pas envie que dans tout le reste du programme, les utilisateurs se retrouvent obligés de manipuler ces types. C'est pourquoi j'ai souhaité associer de façon transparente à l'utilisateur ces types abstraits avec les types qu'ils utilisent tout au long de leur programme.
Je peux très bien décider (et faire appliquer par le programme) que sur les architectures ciblées, 32 bits suffisent pour transmettre des int et 64 pour des long (mais avec effectivement le problème soulevé par James : que faire si une machine source génère un long trop grand pour pouvoir être géré par la machine réceptrice ?), mais, si je décide d'utiliser N bits pour transmettre un size_t, je ne sais pas comment le faire appliquer.
-- Loïc
Marc Boyer wrote:
J'ai peur que le problème soit mal posé, malheureusement.
Pour faire communiquer des machines non-homogènes, tu dois
définir des types abstraits, avec un encodage fixe, les
opérations qui sont permises dessus, les plages de valeur, et
les conversions faites pour les machines réelles.
Non ?
J'ai en effet défini de tels types abstraits. Mais je n'avais pas envie
que dans tout le reste du programme, les utilisateurs se retrouvent
obligés de manipuler ces types. C'est pourquoi j'ai souhaité associer de
façon transparente à l'utilisateur ces types abstraits avec les types
qu'ils utilisent tout au long de leur programme.
Je peux très bien décider (et faire appliquer par le programme) que sur
les architectures ciblées, 32 bits suffisent pour transmettre des int et
64 pour des long (mais avec effectivement le problème soulevé par James
: que faire si une machine source génère un long trop grand pour pouvoir
être géré par la machine réceptrice ?), mais, si je décide d'utiliser N
bits pour transmettre un size_t, je ne sais pas comment le faire appliquer.
J'ai peur que le problème soit mal posé, malheureusement. Pour faire communiquer des machines non-homogènes, tu dois définir des types abstraits, avec un encodage fixe, les opérations qui sont permises dessus, les plages de valeur, et les conversions faites pour les machines réelles. Non ?
J'ai en effet défini de tels types abstraits. Mais je n'avais pas envie que dans tout le reste du programme, les utilisateurs se retrouvent obligés de manipuler ces types. C'est pourquoi j'ai souhaité associer de façon transparente à l'utilisateur ces types abstraits avec les types qu'ils utilisent tout au long de leur programme.
Je peux très bien décider (et faire appliquer par le programme) que sur les architectures ciblées, 32 bits suffisent pour transmettre des int et 64 pour des long (mais avec effectivement le problème soulevé par James : que faire si une machine source génère un long trop grand pour pouvoir être géré par la machine réceptrice ?), mais, si je décide d'utiliser N bits pour transmettre un size_t, je ne sais pas comment le faire appliquer.
-- Loïc
Loïc Joly
wrote:
Marc Boyer wrote in message news:<bm31mf$36v$...
Pour faire communiquer des machines non-homogènes, tu dois définir des types abstraits, avec un encodage fixe, les opérations qui sont permises dessus, les plages de valeur, et les conversions faites pour les machines réelles.
Non ?
Oui, mais je ne comprends pas où en est le problème. En général, je me contente des fonctions qui prenent des long et/ou des unsigned long, je valide l'intervalle, et génère une erreur le cas échéant.
Je ne suis pas certain de ce que tu veux dire, mais si tu suggères d'envoyer tout type sous forme du type le plus long sur le réseau, c'est malheureusement impossible dans mon cas : La charge réseau est un facteur limitant de la version précedente de notre appli, je n'ai donc pas le droit d'être plus mauvais de ce côté, et nous devons donc nous assurer de ne pas utiliser plus de bits qu'il n'est absolument nécessaire.
-- Loïc
kanze@gabi-soft.fr wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote in message
news:<bm31mf$36v$1@news.cict.fr>...
Pour faire communiquer des machines non-homogènes, tu dois définir
des types abstraits, avec un encodage fixe, les opérations qui sont
permises dessus, les plages de valeur, et les conversions faites pour
les machines réelles.
Non ?
Oui, mais je ne comprends pas où en est le problème. En général, je me
contente des fonctions qui prenent des long et/ou des unsigned long, je
valide l'intervalle, et génère une erreur le cas échéant.
Je ne suis pas certain de ce que tu veux dire, mais si tu suggères
d'envoyer tout type sous forme du type le plus long sur le réseau, c'est
malheureusement impossible dans mon cas : La charge réseau est un
facteur limitant de la version précedente de notre appli, je n'ai donc
pas le droit d'être plus mauvais de ce côté, et nous devons donc nous
assurer de ne pas utiliser plus de bits qu'il n'est absolument nécessaire.
Pour faire communiquer des machines non-homogènes, tu dois définir des types abstraits, avec un encodage fixe, les opérations qui sont permises dessus, les plages de valeur, et les conversions faites pour les machines réelles.
Non ?
Oui, mais je ne comprends pas où en est le problème. En général, je me contente des fonctions qui prenent des long et/ou des unsigned long, je valide l'intervalle, et génère une erreur le cas échéant.
Je ne suis pas certain de ce que tu veux dire, mais si tu suggères d'envoyer tout type sous forme du type le plus long sur le réseau, c'est malheureusement impossible dans mon cas : La charge réseau est un facteur limitant de la version précedente de notre appli, je n'ai donc pas le droit d'être plus mauvais de ce côté, et nous devons donc nous assurer de ne pas utiliser plus de bits qu'il n'est absolument nécessaire.
-- Loïc
Loïc Joly
Marc Boyer wrote:
Oui, tout dépend si le protocole existe déjà, et si le problème est de l'implémenter, ou si on cherche a definir le protocole. En lisant le peu de code de l'OP, j'avais tendance à croire que le protocole n'existait pas encore, et c'est pour cela que je soulignais l'importance de définir d'abord les types abstrait, leur plages de valeur, tout ça.
En fait, le protocole existe déjà, mais comme on remet à jour notre système, on peut le modifier, tant qu'on peut faire entrer au chausse pied l'existant dans le nouveau moule.
-- Loïc
Marc Boyer wrote:
Oui, tout dépend si le protocole existe déjà, et si le problème
est de l'implémenter, ou si on cherche a definir le protocole.
En lisant le peu de code de l'OP, j'avais tendance à croire
que le protocole n'existait pas encore, et c'est pour cela
que je soulignais l'importance de définir d'abord les types
abstrait, leur plages de valeur, tout ça.
En fait, le protocole existe déjà, mais comme on remet à jour notre
système, on peut le modifier, tant qu'on peut faire entrer au chausse
pied l'existant dans le nouveau moule.
Oui, tout dépend si le protocole existe déjà, et si le problème est de l'implémenter, ou si on cherche a definir le protocole. En lisant le peu de code de l'OP, j'avais tendance à croire que le protocole n'existait pas encore, et c'est pour cela que je soulignais l'importance de définir d'abord les types abstrait, leur plages de valeur, tout ça.
En fait, le protocole existe déjà, mais comme on remet à jour notre système, on peut le modifier, tant qu'on peut faire entrer au chausse pied l'existant dans le nouveau moule.
-- Loïc
Loïc Joly
wrote:
Loïc Joly wrote in message news:<bm19fj$vlc$... [...]
Le code marche assez bien, sauf que quand je veux spécialiser le templat e pour size_t, par exemple, j'ai un problème, puisque size_t est un type def, et non un type à part entière.
Tu ne peux donc pas surcharger/spécialiser sur size_t. [...]
Y a-t-il une solution à mon problème ?
Spécialiser pour tous les types entiers ?
C'est ce que je fais. J'aurais juste aimé que quelle que soit la machine, on se retrouve au final avec la même spécialisation appelée quand on fait "<< sizeof(myData)".
-- Loïc
kanze@gabi-soft.fr wrote:
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<bm19fj$vlc$1@news.x-echo.com>...
[...]
Le code marche assez bien, sauf que quand je veux spécialiser le
templat e pour size_t, par exemple, j'ai un problème, puisque size_t
est un type def, et non un type à part entière.
Tu ne peux donc pas surcharger/spécialiser sur size_t.
[...]
Y a-t-il une solution à mon problème ?
Spécialiser pour tous les types entiers ?
C'est ce que je fais. J'aurais juste aimé que quelle que soit la
machine, on se retrouve au final avec la même spécialisation appelée
quand on fait "<< sizeof(myData)".
Loïc Joly wrote in message news:<bm19fj$vlc$... [...]
Le code marche assez bien, sauf que quand je veux spécialiser le templat e pour size_t, par exemple, j'ai un problème, puisque size_t est un type def, et non un type à part entière.
Tu ne peux donc pas surcharger/spécialiser sur size_t. [...]
Y a-t-il une solution à mon problème ?
Spécialiser pour tous les types entiers ?
C'est ce que je fais. J'aurais juste aimé que quelle que soit la machine, on se retrouve au final avec la même spécialisation appelée quand on fait "<< sizeof(myData)".
-- Loïc
Marc Boyer
Loïc Joly wrote:
Marc Boyer wrote:
J'ai peur que le problème soit mal posé, malheureusement. Pour faire communiquer des machines non-homogènes, tu dois définir des types abstraits, avec un encodage fixe, les opérations qui sont permises dessus, les plages de valeur, et les conversions faites pour les machines réelles. Non ?
J'ai en effet défini de tels types abstraits.
OK, pardon.
Mais je n'avais pas envie que dans tout le reste du programme, les utilisateurs se retrouvent obligés de manipuler ces types. C'est pourquoi j'ai souhaité associer de façon transparente à l'utilisateur ces types abstraits avec les types qu'ils utilisent tout au long de leur programme.
C'est à dire ? Les codes sur les hotes fonctionnent avec tes types MyInt, MySizeT, etc, ou tu offres une couche de transformation ?
Je peux très bien décider (et faire appliquer par le programme) que sur les architectures ciblées, 32 bits suffisent pour transmettre des int et 64 pour des long (mais avec effectivement le problème soulevé par James : que faire si une machine source génère un long trop grand pour pouvoir être géré par la machine réceptrice ?), mais, si je décide d'utiliser N bits pour transmettre un size_t, je ne sais pas comment le faire appliquer.
Il me semble qu'il faut d'abord définir les plages de valeur "communes", et décider ce qui se passe quand une machine tente d'envoyer à une autre une valeur "trop grande", indépendemment de ce qui passe sur le réseau. Une fois cette règle vue, on verra comment faire un truc cohérent avec les size_t. Non ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Loïc Joly wrote:
Marc Boyer wrote:
J'ai peur que le problème soit mal posé, malheureusement.
Pour faire communiquer des machines non-homogènes, tu dois
définir des types abstraits, avec un encodage fixe, les
opérations qui sont permises dessus, les plages de valeur, et
les conversions faites pour les machines réelles.
Non ?
J'ai en effet défini de tels types abstraits.
OK, pardon.
Mais je n'avais pas envie
que dans tout le reste du programme, les utilisateurs se retrouvent
obligés de manipuler ces types. C'est pourquoi j'ai souhaité associer de
façon transparente à l'utilisateur ces types abstraits avec les types
qu'ils utilisent tout au long de leur programme.
C'est à dire ?
Les codes sur les hotes fonctionnent avec tes types MyInt, MySizeT,
etc, ou tu offres une couche de transformation ?
Je peux très bien décider (et faire appliquer par le programme) que sur
les architectures ciblées, 32 bits suffisent pour transmettre des int et
64 pour des long (mais avec effectivement le problème soulevé par James
: que faire si une machine source génère un long trop grand pour pouvoir
être géré par la machine réceptrice ?), mais, si je décide d'utiliser N
bits pour transmettre un size_t, je ne sais pas comment le faire appliquer.
Il me semble qu'il faut d'abord définir les plages de valeur
"communes", et décider ce qui se passe quand une machine tente
d'envoyer à une autre une valeur "trop grande", indépendemment
de ce qui passe sur le réseau.
Une fois cette règle vue, on verra comment faire un truc cohérent
avec les size_t. Non ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
J'ai peur que le problème soit mal posé, malheureusement. Pour faire communiquer des machines non-homogènes, tu dois définir des types abstraits, avec un encodage fixe, les opérations qui sont permises dessus, les plages de valeur, et les conversions faites pour les machines réelles. Non ?
J'ai en effet défini de tels types abstraits.
OK, pardon.
Mais je n'avais pas envie que dans tout le reste du programme, les utilisateurs se retrouvent obligés de manipuler ces types. C'est pourquoi j'ai souhaité associer de façon transparente à l'utilisateur ces types abstraits avec les types qu'ils utilisent tout au long de leur programme.
C'est à dire ? Les codes sur les hotes fonctionnent avec tes types MyInt, MySizeT, etc, ou tu offres une couche de transformation ?
Je peux très bien décider (et faire appliquer par le programme) que sur les architectures ciblées, 32 bits suffisent pour transmettre des int et 64 pour des long (mais avec effectivement le problème soulevé par James : que faire si une machine source génère un long trop grand pour pouvoir être géré par la machine réceptrice ?), mais, si je décide d'utiliser N bits pour transmettre un size_t, je ne sais pas comment le faire appliquer.
Il me semble qu'il faut d'abord définir les plages de valeur "communes", et décider ce qui se passe quand une machine tente d'envoyer à une autre une valeur "trop grande", indépendemment de ce qui passe sur le réseau. Une fois cette règle vue, on verra comment faire un truc cohérent avec les size_t. Non ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
