Et comment tu récupères l'information lors de la lecture ? Sur une machine avec une autre architecture de pointeur, par exemple ?
Il n'est pas donné que je puisse lire la sortie d'un void* sur une autre machine. Et si je réussis à le lire, qu'est-ce que j'en fait -- les objets sont prèsque certainement à d'autres adresses.
Je les mets dans un tableau associatif ? Avec éventuellement une classe pointeur qui gère ça de façon transparente ? Si on n'a pas de contrainte de persistance des identifiants et pas trop de problèmes de performance, ça peut passer, non ?
Si le programme qui lit ne les traite que comme des chaînes de caractères. Je suppose alors que c'est un générateur de chaîne aléatoire comme un autre, avec l'avantage qu'il garantit que les clés soient uniques automatiquement. Ceci dit, dans ce cas-là, je n'en vois pas l'avantage sur ++nextId.
Moi non plus. D'ailleurs, dans les cas que je connais c'est ce "++nextId" qui est utilisé...
Note que dans le cas de l'utilisation de void*, tu n'es pas garantie qu'un autre programme puisse les lire comme void*. Et qu'il faut s'occuper des séparateurs. Dans le contexte de XML, on ferait « dest << '"' << (void*)&obj << '"' », mais dans des protocols plus simple, on ne veut pas forcément avoir à gérer les chaînes arbitraires délimitées par des ". Or, si je sais que ++nextId ne génèrerait jamais que [1-9][0-9]*, c'est loin d'être le cas avec (void*)&obj.
kanze@gabi-soft.fr wrote:
Olivier Azeau wrote:
kanze@gabi-soft.fr wrote:
drkm wrote:
kanze@gabi-soft.fr writes:
Seulement, je ne connais pas de façon à gérer ces
identificateurs de façon générique.
Et comment tu récupères l'information lors de la lecture ?
Sur une machine avec une autre architecture de pointeur, par
exemple ?
Il n'est pas donné que je puisse lire la sortie d'un void*
sur une autre machine. Et si je réussis à le lire, qu'est-ce
que j'en fait -- les objets sont prèsque certainement à
d'autres adresses.
Je les mets dans un tableau associatif ? Avec éventuellement
une classe pointeur qui gère ça de façon transparente ? Si on
n'a pas de contrainte de persistance des identifiants et pas
trop de problèmes de performance, ça peut passer, non ?
Si le programme qui lit ne les traite que comme des chaînes de
caractères. Je suppose alors que c'est un générateur de chaîne
aléatoire comme un autre, avec l'avantage qu'il garantit que les
clés soient uniques automatiquement. Ceci dit, dans ce cas-là,
je n'en vois pas l'avantage sur ++nextId.
Moi non plus. D'ailleurs, dans les cas que je connais c'est ce
"++nextId" qui est utilisé...
Note que dans le cas de l'utilisation de void*, tu n'es pas
garantie qu'un autre programme puisse les lire comme void*. Et
qu'il faut s'occuper des séparateurs. Dans le contexte de XML,
on ferait « dest << '"' << (void*)&obj << '"' », mais dans des
protocols plus simple, on ne veut pas forcément avoir à gérer
les chaînes arbitraires délimitées par des ". Or, si je sais que
++nextId ne génèrerait jamais que [1-9][0-9]*, c'est loin d'être
le cas avec (void*)&obj.
Et comment tu récupères l'information lors de la lecture ? Sur une machine avec une autre architecture de pointeur, par exemple ?
Il n'est pas donné que je puisse lire la sortie d'un void* sur une autre machine. Et si je réussis à le lire, qu'est-ce que j'en fait -- les objets sont prèsque certainement à d'autres adresses.
Je les mets dans un tableau associatif ? Avec éventuellement une classe pointeur qui gère ça de façon transparente ? Si on n'a pas de contrainte de persistance des identifiants et pas trop de problèmes de performance, ça peut passer, non ?
Si le programme qui lit ne les traite que comme des chaînes de caractères. Je suppose alors que c'est un générateur de chaîne aléatoire comme un autre, avec l'avantage qu'il garantit que les clés soient uniques automatiquement. Ceci dit, dans ce cas-là, je n'en vois pas l'avantage sur ++nextId.
Moi non plus. D'ailleurs, dans les cas que je connais c'est ce "++nextId" qui est utilisé...
Note que dans le cas de l'utilisation de void*, tu n'es pas garantie qu'un autre programme puisse les lire comme void*. Et qu'il faut s'occuper des séparateurs. Dans le contexte de XML, on ferait « dest << '"' << (void*)&obj << '"' », mais dans des protocols plus simple, on ne veut pas forcément avoir à gérer les chaînes arbitraires délimitées par des ". Or, si je sais que ++nextId ne génèrerait jamais que [1-9][0-9]*, c'est loin d'être le cas avec (void*)&obj.
