Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Contigüité des éléments d'un `std::vector´

Contigüité des éléments d'un `std::vector´

167 réponses
Avatar
drkm
Je viens de tomber sur un message de Michel, d'il y a un mois, dont
voici un extrait :

> From: "Michel Michaud" <mm@gdzid.com>
> Subject: Re: buffer et std::vector<char> passage de l'un a l'autre
> Message-ID: <pQnHa.816$5d.225371@news20.bellglobal.com>
> Date: Mon, 16 Jun 2003 14:16:52 -0400

> Avec

> vector<char> v(taille);

> &v[0] est un char* qui peut être passé aux fonctions attendant un
> char[]/char*. La norme ne dit pas explicitement que les char sont
> contigus, mais c'est un fait et il y a une correction à la norme qui
> l'indique aussi.

J'avais toujours entendu dire que la contigüités des éléments d'un
vecteur était garantie. Apparemment non. Pour ce qui est de la
correction à la norme, je suppose que tu parlais d'un DR. En as-tu la
référence, stp ?

--drkm
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
13 14 15 16 17
Avatar
Gabriel Dos Reis
"Christophe Lephay" writes:

| "Gabriel Dos Reis" a écrit dans le message de
| news:
| > | Pff, si c'est pas du mauvais esprit, ça.. ;)
| >
| > Je n'ai pas vu le message de Arnaud Debaene...
|
| Moi si, mais c'est parce que j'accède aux news via l'excellent serveur
| news.wanadoo.fr (*)

JE n'en doute pas une seconde.

| (*) Pff, si c'est pas du mauvais esprit, ça - bis repetita...

ah bon ?!

-- Gaby
Avatar
Alain Naigeon
"Gabriel Dos Reis" a écrit dans le message
news:
"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le
message

| news:
| >
| > Ben j'avoue que je ne comprends pas très bien où tu veux en venir.
|
| Bon, je suppose que je n'utilise pas les mots corrects.
| De l'exemple de l'intervalle [1...8] du Pascal, remplacé
| en C++ par ta réponse avec template<typename T, int m, int M>
| je tire l'impression que ce qui est "cablé" dans un langage, et
| ce qui doit être écrit soi-même, est une limite qui peut bouger,
| selon le langage considéré.

Effectivement.

Pour C++,la règle générale a toujours été : pas de machins
particuliers, mais des mécanismes généraux réutilisables. Et on met un
accent sur la bibliothèque.
L'un des points est que si on veut câbler des constructions
particulières dans le langage, on se retrouvera vite avec un vaisseau
surchargé, ingérable et pourtant ne fournit pas assez de primitives.



Eh bien, je ne regrette pas d'avoir dû m'expliquer longuement pour
avoir les réponses que tu donnes ici...

En particulier le passage ci-dessous :

| Il n'empêche, je suis frappé que la déclaration d'un sous-type
| d'entier puisse être exprimée à l'aide d'une simple déclaration
| en Pascal, alors même qu'elle contient un peu de sémantique
| (restriction entre deux bornes).

C'est que Pascal associe à cette syntaxe, une sémantique qu'on ne
pourrait exprimer autrement. J'appelerais cela de la magie.

| En regard de cela, je constatais que la contiguïté, elle, semble
| plus résistante à une expression aussi immédiate.

Mais le C ou C++ ont fait la même chose, pour une syntaxe
particulière : T[N]. Mais la magie ne plait pas à tout le monde.
std::vector<> est quelque chose exprimable avec le reste du langage.
On souhaite simplement qu'elle garantisse une certaine propriété, sans
avoir à faire encore de la magie.
En fait, moins il y a de la magie, mieux c'est. C'est une opinion.

| Ma question était donc : y aurait-il des propriétés dont on pourrait
| démontrer qu'elles ne sont "câblables" dans aucun langage,

Il suffit de prendre n'importe quelle propriété connue et d'asserner
sa négation ;-)

| et la contiguïté serait-elle l'une d'entre elles ?

non, on peut faire de la magie pour la contiguité dans un langage de
son crû si on le veut. Le C et C++ l'ont fait pour T[N] et malloc().



Dont j'extrais cette phrase que je trouve *très* éclairante :
std::vector<> est quelque chose exprimable avec le reste du langage.


Pourquoi l'enseignement consiste-t-il trop souvent à stocker des
"évidences", alors qu'on apprend bien plus en observant les petites
bêtes qui s'échappent lorsqu'on soulève les cailloux ?
AMHA le point soulevé (magie non reproductible par l'usager du
langage) mériterait à lui seul tout un chapitre de cours.
Encore que... ça dépend du but du cours : former des gens embauchables
dans les 2 semaines après le diplôme, ou des gens qui comprennent un peu
ce qu'ils font ? Mais ceci est plus question sur les employeurs potentiels
que sur les enseignants, finalement...

Merci !

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France

Avatar
Bertrand Motuelle
"Gabriel Dos Reis" schrieb im Newsbeitrag
news:
"Christophe Lephay" writes:

| "Gabriel Dos Reis" a écrit dans le
message de

| news:
| > | (http://minilien.com/?gra8xqCXGz)
| >
| > Ton lien indique "service indisponible".
|
| Hum, j'y accède personnellement sans problème...

Yep, je peux y accéder de nouveau. Cela deviat être un problème
temporaire.

Ces first/second me semblent trop particuliers pour avoir
effectivement une chance de faire partie de la norme, et aussi pour le
genre de problème qu'ils son cesnsés résoudre.


Effectivement, mais ce que j'avais proposé à l'époque ce n'est pas des
foncteurs first/second mais des adapteurs pour accéder aux données membres
d'une classe(comme tu l'as montré dans ta réponse avec les select/selector).
C'est le premier message de la discussion pointée par le lien.
Et ceux ci ne sont particuliers mais plutôt généraux.

Bertrand

Avatar
Gabriel Dos Reis
"Bertrand Motuelle" writes:

| "Gabriel Dos Reis" schrieb im Newsbeitrag
| news:
| > "Christophe Lephay" writes:
| >
| > | "Gabriel Dos Reis" a écrit dans le
| message de
| > | news:
| > | > | (http://minilien.com/?gra8xqCXGz)
| > | >
| > | > Ton lien indique "service indisponible".
| > |
| > | Hum, j'y accède personnellement sans problème...
| >
| > Yep, je peux y accéder de nouveau. Cela deviat être un problème
| > temporaire.
| >
| > Ces first/second me semblent trop particuliers pour avoir
| > effectivement une chance de faire partie de la norme, et aussi pour le
| > genre de problème qu'ils son cesnsés résoudre.
|
| Effectivement, mais ce que j'avais proposé à l'époque ce n'est pas des
| foncteurs first/second mais des adapteurs pour accéder aux données membres
| d'une classe(comme tu l'as montré dans ta réponse avec les select/selector).
| C'est le premier message de la discussion pointée par le lien.
| Et ceux ci ne sont particuliers mais plutôt généraux.

C'est vrai que le selecteur template est général, mais est-ce qu'il
s'attaque à un problème récurrent pour l'intégrer à la norme ?

-- Gaby
Avatar
Bertrand Motuelle
"Gabriel Dos Reis" schrieb im Newsbeitrag
news:
"Bertrand Motuelle" writes:
[snip]

| Effectivement, mais ce que j'avais proposé à l'époque ce n'est pas des
| foncteurs first/second mais des adapteurs pour accéder aux données
membres

| d'une classe(comme tu l'as montré dans ta réponse avec les
select/selector).

| C'est le premier message de la discussion pointée par le lien.
| Et ceux ci ne sont particuliers mais plutôt généraux.

C'est vrai que le selecteur template est général, mais est-ce qu'il
s'attaque à un problème récurrent pour l'intégrer à la norme ?


Ben si j'en crois les quelques réponses que j'ai eu sur le sujet, non :-)

Bertrand

Avatar
Loïc Joly
Christophe Lephay wrote:
"Julien Blanc" a écrit dans le message de
news:3f17bc0c$0$7239$

Gabriel Dos Reis wrote:

Pourquoi est-ce une erreur ? Qu'est-ce qu'on veut abstraire avec
std::pair ? Qu'est-ce qu'on veut protéger ?


je pense que cela peut se révéler gênant sur certaines instanciations
particulières. Si j'ai un invariant que dois respecter ma paire, le fait
d'avoir un accès direct en écriture aux éléments de pair supprime toute
garantie sur cet invariant. Le fait d'avoir des accesseurs en écriture
me permettrait de les redéfinir pour garantir cet invariant.



De toute façon, tu ne peux pas coder tes invariants dans pair. Si tu en as
besoin, il faut faire une nouvelle structure (ou classe)...


Tu peux spécialiser std::pair pour tes propres types, et si tu accèdais
à tes données par des fonctions, tu pourrais ajouter tes propres
invariants. Je ne dis pas que ce serait une bonne chose, juste que ce
serait possible...

--
Loïc



Avatar
Gabriel Dos Reis
Loïc Joly writes:

| Christophe Lephay wrote:
| > "Julien Blanc" a écrit dans le message de
| > news:3f17bc0c$0$7239$
| >
| >>Gabriel Dos Reis wrote:
| >>
| >>>Pourquoi est-ce une erreur ? Qu'est-ce qu'on veut abstraire avec
| >>>std::pair ? Qu'est-ce qu'on veut protéger ?
| >>
| >>je pense que cela peut se révéler gênant sur certaines instanciations
| >>particulières. Si j'ai un invariant que dois respecter ma paire, le fait
| >>d'avoir un accès direct en écriture aux éléments de pair supprime toute
| >>garantie sur cet invariant. Le fait d'avoir des accesseurs en écriture
| >>me permettrait de les redéfinir pour garantir cet invariant.
| > De toute façon, tu ne peux pas coder tes invariants dans pair. Si tu
| > en as
| > besoin, il faut faire une nouvelle structure (ou classe)...
|
| Tu peux spécialiser std::pair pour tes propres types, et si tu
| accèdais à tes données par des fonctions, tu pourrais ajouter tes
| propres invariants.

Le mot clé ici est *spécialiser*, i.e. définir une *autre* classe, ou
« une nouvelle structure » comme disait Christophe.

-- Gaby
13 14 15 16 17