Discussion :

[yan]

Bonjour.
J'ai une structure qui contiens un tableau de type C qui est envoyé en brut à travers un réseau.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
struct foo
{
 int bar[10];
}
 
 
foo tmp;
 
send(&tmp,sizeof(foo));

j'aimerais savoir si la norme garantie si je peux remplacer le tableau C par std::array sans modifier l'envoie de la structure sur le réseau

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
struct foo
{
   std::array<int, 10> bar;
}
 
 
foo tmp;
 
send(&tmp,sizeof(foo));

merci

[bacelar]

Comme la norme ne spécifie pas le padding, même en n'utilisant que des tableaux C-style, tu n'as aucune garantie que cela fonctionne.
Encore moins avec std::array.
Utiliser un Framework de sérialisation serait bien plus simple et judicieux, je pense.

[yan]

Utiliser un Framework de sérialisation serait bien plus simple et judicieux, je pense.

Tu n'as pas à me convaincre sur ce points
Malheureusement, c'est dans le contexte du projet...
A moindre mal, je regarde ce qui est possible pour améliorer certaines chose.
Remplacer les tableaux C par des std::array en fait partie.

[yan]

Apparemment, rien ne l'oblige : http://stackoverflow.com/questions/1...ed-by-standard

Dommage.

Yan

[stendhal666]

A mon avis tu aggraves le problème avec std::array car tu perds des garanties sur la disposition en mémoire. Dès qu'il y a des membres avec des accessibilités (private/public/protected) différentes, ce qui est probablement le cas pour std::array, la disposition mémoire devient unspecified: un compilateur respectant le standard pourrait mettre les membres public à un autre endroit que les membres private, par exemple. C'est uniquement lorsque la struct C++ pourrait aussi bien être une struct C que la garantie de contiguïté (hors padding évidemment) tient.

[koala01]

Salut,

A mon avis tu aggraves le problème avec std::array car tu perds des garanties sur la disposition en mémoire. Dès qu'il y a des membres avec des accessibilités (private/public/protected) différentes, ce qui est probablement le cas pour std::array, la disposition mémoire devient unspecified: un compilateur respectant le standard pourrait mettre les membres public à un autre endroit que les membres private, par exemple. C'est uniquement lorsque la struct C++ pourrait aussi bien être une struct C que la garantie de contiguïté (hors padding évidemment) tient.

Tiens, pour ce que j'en sais (ou plutot pour ce que je croyais en savoir), l'ordre des données membres non statiques au sein d'une structure (ou d'une classe, vu que les deux fonctionnent de la même manière) ne dépendait que de l'ordre dans lequel les membres étaient déclarés, l'apsect de la visibilité disparaissant complètement dans le résultat final.

Est-ce que je me trompais si lourdement

[stendhal666]

@koala01: je pense que tu as raison en pratique car c'est l'option retenue par les gros compilateurs mais le standard, selon les renseignements glanés sur stackoverflow, ne garantit qu'un ordre défini (même pas l'ordre de déclaration) par bloc d'accessibilité.

[Bousk]

A moindre mal, je regarde ce qui est possible pour améliorer certaines chose.
Remplacer les tableaux C par des std::array en fait partie.

Mué, à ta place je laisserai ces tableaux tranquilles, surtout s'ils ont aussi modifié le padding pour les utiliser et c'est assez courant, surtout que tu dis que ça passe par le réseau.
Honnêtement, à part se donner "bonne conscience à utiliser les derniers éléments", changer des C-array pour std::array, c'est plutôt inutile amha.

[yan]

Honnêtement, à part se donner "bonne conscience à utiliser les derniers éléments", changer des C-array pour std::array, c'est plutôt inutile amha.

La seule raison est que sous visual en debug

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
std::array<int,4> toto;
toto[4] =1;

il y as un assert et donc me permet de détecter l’accès mémoire foireux.

Y as pas de bonne conscience la dedans :p

[Iradrille]

il y as un assert et donc me permet de détecter l’accès mémoire foireux.

Y as pas de bonne conscience la dedans :p

C'est très bien les tableaux aussi



(A moins que tous les problèmes ne soient pas détectés avec des tableaux types C ?)

[Bousk]

La seule raison est que sous visual en debug

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
std::array<int,4> toto;
toto[4] =1;

il y as un assert et donc me permet de détecter l’accès mémoire foireux.

Ben..

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
struct s {
#ifdef DEBUG
std::array<int,4> arr;
#else
int[4] arr;
#endif
};

Non ?