Socket et protocole UDP, ne lire que la dernière donnée reçue

au démarrage du programme, j'ai [I]dataLen = 0, donc aucune donnée à lire. C'est d'ailleurs le premier élément que je vérifie. S'il est différent de 0 je lis le contenu de [I]data.

D'ailleurs je me suis trompé dans le code posté. Ce n'est pas

Code:

---

data[id].id = id;

---

mais

Code:

---

data[id].id = recvData.id;

---

Auteur, dans ma tête, l'index de lecture c'était "n" et pas "n-1" :aie:

Citation:

---

Envoyé par jblecanard

Là tu proposes le lock-free ring buffer, c'est une bonne idée mais c'est assez compliqué à coder et ça nécessite d'avoir std::atomic_flag.

---

en FIFO j'imagine que ça doit être plus délicat, mais là c'est du LIFO... Est-ce que ça change quelque chose ?

merci pour le lien ;)

Citation:

---

Envoyé par minnesota

Auteur, dans ma tête, l'index de lecture c'était "n" et pas "n-1" :aie:

---

ça ne peut-être que l'index n-1 car l'index n correspond à la donnée courante celle qui est en train d'être mise à jour.

Oui, ça dépend de l'organisation interne. Dans ma vision des choses, la dernière donnée ne pouvait être sur un plan logique à "n-1", sinon c'est pas la dernière, en quelque sorte, ça ne pourrait pas être le sommet de la pile, même si là c'est circulaire, c'est comme si je mettais une brique pleine, et au dessus, une brique vide.

Moi je voyais la chose comme : je mets d'abord à jour ma donnée, ensuite seulement, je mets à jour mon index de lecture qui pointera donc sur la dernière donnée de lecture disponible au moment où je ferrai mon appel de lecture.

Mais bon, c'est juste une question de point de vue... et du coup peut-être aussi un détail...

Après, peut-être qu'on pourrait arrivée à quelque chose de plus élégant sans se trimbaler un index avec la SL ou Boost, mais comme je programme très très peu, à chaque fois il faut que je replonge dans la doc... et ouais... ça semble pas être comme le vélo... donc je me contente de seulement mettre en lumière la possibilité...