C'est quoi ce bazarre ?

[lforg37]

Salut, je ne comprend absolument pas l'intérêt d'avoir, pour la classe Sphero qui est une classe paramétrée, d'avoir un fichier .tpp, un fichier .hpp (jusque là tout va bien) et un fichier .cpp o_O Pourriez-vous m'indiquer la raison de cette hérésie ? Bien à vous,

[slock83]

j'avais pas vu le tpp mais de toutes façon ça sert à rien, l'extension tpp ne change rien, à part peut être rende le pattern du makefile plus compliqué

[lforg37]

Euh... En tous cas il ne /faut pas/ faire un .cpp qui inclue le .hpp mais un .hpp qui inclue le .cpp (et ce dernier ne doit pas être compilé, d'où l'absence de problème de pattern du makefile).

[slock83]

bah change si tu veux, moi j'm'en fous xD

[lforg37]

Ce n'est pas qu'une question d'extension... Mettre des sphero::nomfonction() n'a pas non plus grand sens...

[slock83]

ça refuse de passer sans

[slock83]

et c'est des sphero, au moins le compilo râle pas, eclipse râle pas, et au runtime ça marche :)

[lforg37]

Et ça refuse de passer avec ;-) Quand tu en a besoin il faut utiliser template void sphero::nomfonction(...)

[lforg37]

Pardon, la faute de github : template < typename T >

[slock83]

ok, je change ça après les templates je m'en sers pas trop en général

[lforg37]

void sphero::nomFonction() {

}

[lforg37]

Impeccable ! Les templates sont quand même à la base du développement en couches ;-)

[slock83]

petite pensée émue pour feue la coloration syntaxique "intelligente", qui semble ne pas aimer ça du tout

[lforg37]

??

[lforg37]

Mais il en reste plein o_O

[slock83]

de qwa ?

[lforg37]

Des sphero

[slock83]

il en reste 2, et c'est pour les implem spécifiques à bluez

[lforg37]

Mais ça n'a vraiment aucun sens... Le but c'est justement d'utiliser les primitives de la classe bluetooth_adaptor. Et chez moi, ton code ne compile pas.

[slock83]

chez moi, ça passe !

[lforg37]

Au lieu d'utiliser le sendPacket, ne pourrions nous pas nous contenter de la primitive send_data(size_t data_length, uint8_t const * data) de bluetooth_connector ? Comme ça tu peux te contenter de faire des fonctions ne dépendant pas de l'implémentation (puisqu'on a que des classes filles de bluetooth_connector).

[lforg37]

Et la réponse précédente n'est pas hyper constructive ;-)

[slock83]

bah sendPacket est pas mal, elle nous permet de convertir le clientCommandPacket en un truc envoyable directement, ça fait moins de copier coller et comme mon ordi a décidé qu'il ne voulait pas ouvrir bluetooth_connector.h... et de mon coté, la compilation se passe très bien si ce n'est un warning, mais il est normal et voulu

[lforg37]

Eh bien dans ce cas je vais passer sendPacket dans bluetotth connector (ce qui est pas très propre, mais si tu y tiens) mais tu seras prié d'utiliser la version générique !

[slock83]

fait un formatPacket si tu préfère ... NA :tongue:

[slock83]

sinon sendpacket dans sphero en privé je vois pas ce qui te gêne, on envoie un packet à un sphero, et c'est juste lui qui fera l'interface avec la couche basse, c'est à lui de s'adapter, pas aux couches inférieures

[lforg37]

En fait c'est vraiment trop moche de le mettre dans bluetooth connector, peux tu implémenter une méthode de CommandPacket, par exemple ClientCommandPacket::send_datat(bluetooth_connector btc) qui s'occupe de faire les appels ? Ce serait nettement plus propre... :package:

[slock83]

c'est pas mieux de laisser dans sphero ?

[lforg37]

Mais tu t'assois complètement sur le princpe du template si tu fais comme ça : on ne veut pas avoir à spécialiser à la main chaque implémentation :zap:

[lforg37]

Non

[lforg37]

:no_good:

[lforg37]

Elles sont marrantes leurs frimousses :)

[lforg37]

Si tu veux je m'occupe de l'implémenter mais c'est plus propre comme ça.

[slock83]

nan mais ma méthode sendpacket le but c’était juste qu'elle mette en forme et ensuite elle utilise la methode générique du bluetooth_connector oui elles sont marrantes :smile:

[lforg37]

Mais tu vois bien que la mise en forme du paquet en tableau d'octets est une méthode de la classe paquet. De plus, la méthode d'envoi pour les bluetooth connector est la même quel que soit la classe fille concernée... :evergreen_tree:

[slock83]

un truc genre send_data(sizeof(packet),packet.toByteArray()) ça passe ?

[lforg37]

Je ne mettrais pas sizeof(packet) : en effet, il tient compte du nombre d'attribut mais pas de la taille des attributs (il comptera toujours 8 pour le pointeur sur la charge utile, alors que la taille de celle-ci peut varier. Il vaut donc mieux utiliser une valeur calculée (genre 5 + DLEN si ma mémoire est bonne). Sinon, sous réserve que le toByteArray mette les morceaux dans le bon ordre c'est bon !

[lforg37]

( :+1: )

[slock83]

aller hop, une méthode getsize en rab xD (ouai j'avais oublié le coup du pointeur xD) il me semble que c’était moi qui avait écrit toByteArray, et que j'avais vérifié l'ordre

[slock83]

c'est ok, on close ?