specification de std::array

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

Code:

---

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:

---

1 2 3 4 5 6 7 8 9 10

struct foo { std::array<int, 10> bar; }     foo tmp;   send(&tmp,sizeof(foo));

---

merci

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.

Citation:

---

Envoyé par bacelar

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.

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

Dommage.

Yan

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.

Citation:

---

Envoyé par yan

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.

Citation:

---

Envoyé par Bousk

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:

---

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

Citation:

---

Envoyé par yan

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 ;)

http://i.imgur.com/osAprX9.png

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

Citation:

---

Envoyé par Iradrille

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

---

ben y as pas de validation de l'index possible dans un tableau C :koi:
tu peux faire ceci sans problème

Code:

---

1 2 3 4 5 6

int toto[4];   toto[-1] = 0; toto[4] = 0;

---

Le std::array sous visual (je ne sais pas pour les autres compilateur) as un assert sur l'index en debug.

La Run-Time Check détecte un "stack smashing", mais pas une variable locale qui déborde seulement sur les autres variables locales à la même fonction.

Citation:

---

Envoyé par Médinoc

La Run-Time Check détecte un "stack smashing", mais pas une variable locale qui déborde seulement sur les autres variables locales à la même fonction.

---

Ok merci.

@yan, je pensais que les tests sur les tableaux C étaient suffisants, my bad.

Citation:

---

Envoyé par Médinoc

La Run-Time Check détecte un "stack smashing", mais pas une variable locale qui déborde seulement sur les autres variables locales à la même fonction.

---

Effectivement, après quelques tests supplémentaires, en Debug VS alloue un peu de mémoire avant / après les variables pour détecter les débordements, mais si le débordement arrive sur une autre variable, c'est pas détectable.

Code:

---

1 2 3 4 5 6 7

int after[4]; int toto[4]; int before[4];   toto[6] = 0; // OK -> modif de "after" toto[5] = 0; // pile corrompue -> espace réservé avant "after" toto[4] = 0; // pile corrompue -> espace réservé après "toto"

---

sous visual 2013 avec ce code en debug

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <array>     struct foo { int tab[4]; //std::array<int,4> tab; };     int main (int argc, char* argv[]) {   foo * bar = new foo {}; bar->tab[-1] =0;   return 0; }

---

* tableau C : aucune détection
* std::array : assert

le Run-Time Check n'aurais pas du détecter l'erreur mémoire?

Le cookie de sécurité se trouve quelque part entre les variables locales et l'adresse de retour. Là, tu as écrit de l'autre côté (dans la zone "libre" de la pile).

Citation:

---

Envoyé par yan

La seule raison est que sous visual en debug

Code:

---

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:

---

1 2 3 4 5 6 7 8

struct s { #ifdef DEBUG std::array<int,4> arr; #else int[4] arr; #endif };

---

Non ?

Citation:

---

Envoyé par Bousk

Non ?

---

Pourquoi je voudrais utiliser un std::array en debug et un tableau C en release???

Salut,

Citation:

---

Envoyé par 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.

---

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 :question:

@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é.

Citation:

---

Envoyé par yan

Pourquoi je voudrais utiliser un std::array en debug et un tableau C en release???

---

Ben parce qu'en debug tu fais tes tests, TU etc, et en release tu laisses inchangé pour t'assurer que le fonctionnement n'a pas changé, notament sur le padding et la sérialisation des données. :weird:
Ca me parait pas plus stupide que de vouloir les changer sans maitriser le scope de tout ça. Puisque je trouve ça toujours inutile depuis mon premier post.

Citation:

---

Envoyé par Bousk

Ca me parait pas plus stupide que de vouloir les changer sans maitriser le scope de tout ça. Puisque je trouve ça toujours inutile depuis mon premier post.

---

:weird:
La question est justement de savoirs si le fait de remplacer des tableaux C par un std::array pouvais poser des problèmes dans mon cas. Et la réponse est apparemment oui car la norme ne garantie rien sur l'agencement mémoire .
Je ne voie pas l’intérêt d'utiliser des structures différent entre la debug et le release. C'est soit l'un soit l'autre.

Et comme je l'ai expliqué je voulais faire cela pour détecter des index foireux (sans devoir modifier tout le code existant). Ce qui n'est pas possible avec un tableau C. Je ne trouve pas cela inutile.

Y a aussi d'autre raisons qui donne un intérêt à std::array : https://isocpp.org/wiki/faq/containers