Voila, dans le cadre d'un projet en C++, je dois traiter un certains nombre de documents, je comptais donc créer une classe document, puis créer autant d'objets que nécessaire.
 
Mon problème est que je ne vois pas comment créer plusieurs(nombre indéfinis) objets puis me balader de l'un à l'autre pour les traiter.
Ca aurait été en C, je me serais servi des listes chaînées, mais est-il possible d'utiliser ce principe avec les objets.
Si vous avez une solution, merci
 
 
 
 
 
PS: je ne pourrais certainement pas répondre avant demain.

Ben oui, une liste ...
En C++, tu as meme un template list tout pret pour ca. Il fait partie de la STL, le librairie du C++. Ca se charge de l'alloc dynamique, ... tout ca pour toi.
http://www.sgi.com/tech/stl/table_of_contents.html

 
desolé mais je me perds la dedans, je ne sais meme pas kelle categorie choisir ??

Équivalences en très bref:

choisis un conteneur.
list semble tout indiquee

Si tu veux je te file mon propre conteneur (type list) que j'ai implémenté moi même pour 5?  payable par cheque
Nan je deconne.    
Mais bon si t'as besoin d'une implementation sans te faire chier j'en ai une

J'vais essayer merci.
 
Karim je te tiens au courant si besoin

Au risque de me faire tuer par Musaran et Taz, je te déconseille l'emploi de la directive using.
 
Tape plutot directement le nom du namespace :
 

 
J'ai toujours trouvé que la directive using enlevait un grand avantage procuré par les namespaces : rendre la collision de noms impossible.

Y'a du vrai...
 
Mais dans les exemples de 10 lignes, on va pas se prendre la tête.

 
G kk questions, merci

oui, plus précisément tu créés une instance de la classe conteneur list de la STL afin de créer une liste d'int appelée Docs
 

non, ça rajoute l'int de valeur 10 à la fin de ta liste de docs
 

créé un objet iterator (objet qui te permet de parcourir ta liste) référençant le début de ta liste (en gros, ça créé un marqueur sur le début de ta liste)
 

boucle qui parcourt ta liste via l'iterateur déclaré ci dessus. à chaque passage, itor pointera sur l'élément suivant.

 
Je ne pensais pas que l'on pouvait déclarer un itérateur comme cela, j'ai toujours fait :

 
Est-ce qu'il existe une différence entre les deux déclarations ? Et si oui, pourquoi et qu'est-ce que ça implique ?

 
J'ai pensé exactement la même chose que toi en quotant, mais comme Musaran disait que c'était "très bref", j'ai supposé qu'il avait eu la flemme de faire la déclaration correcte, car je t'avouerais que je n'ai jamais vu non plus ce genre de déclaration !
 
Musaran > Alors, es-tu fainéant ou sais tu des choses que nous ne savons pas ?

 
Ca sert a koi ?

A quoi sert une liste si tu ne peux pas lui rajouter d'éléments ?

 
Dommage
Parce que au bout d'un moment les déclarations peuvent être très longues :

 
Bon, c'est vrai que c'est un exemple extrême et qu'il y a les typedefs ou les usings , mais parfois ça devient bien compliqué pour pas grand chose.

 
C une liste d'objets, pas d'int

Une liste est une liste !! Et si la classe list est une classe template, c'est pas pour rien...
 
edit: et un coup de balai, un

Fainéant et distrait.
Ça ne marche pas chez pas chez moi non plus, désolé de vous avoir donné de faux espoirs à toi et gatorette.
 
. ne permet pas (d'après test) de sélectionner un type membre (d'ailleurs on dit imbriqué, pas membre).
Pourquoi
 
exceptionnalnain:
L'iterator joue pour un conteneur le même rôle que le pointeur pour un tableau.
++ ou -- pour parcourir
* pour accéder à l'élément dessous.
Mais comme ce type est potentiellement complexe, il est fourni par le conteneur.
 
Dans mon exemple, remplace int par le type que tu veux stocker.
 
Je vais pas faire un cours complet sur les conteneurs: The Méga Cours de C++.

J'ai rajouté un interateur dans mon type container.
Mais je me rend donc compte que c'est plus possible de le passer en const, car l'iterateur est incrementé dans l'objet lui même, donc on modifie l'objet.
Sinon je comprend pas ce que tu veux dire par acceder a l'objet avec * .
J'ai rajouté une methode genre bidule.getcurrent pos, mais y ptetre un operateur unaire qui signifie cela.

C'est pour ca qu'il y a deux types dans la STL: iterator et const_iterator
 

l'opérateur * permet de récupérer l'objet auquel l'itérateur fait  actuellement référence dans le conteneur

Si l'itérateur est dans la classe, c'est comme la 'position' de FILE* (qui ne peut être constant).
Ou alors tu spécifie ce membre comme mutable.
 
Si l'itérateur est crée par l'utilisateur à partir d'un type dans le conteneur, cela permet de suivre plusieurs positions.

 
mutable ? comment ?
 

 
je vois pas de quoi tu parles.

 
ben tu vas pas mourrir aujourd'hui: j'utilise using namespace que  dans des main de test, sinon, soit j'explicite les noms, soit je fais des using atomiques (using std::list, par exemple)

mutable s'emploie comme const: ça confère au variables déclarées de la sorte la possibilité d'acces non-const et ce meme si this est const

 
faut dire a quoi ca sert :
par exemple modifier un etat interne qui sert de cache
sans pour autant casser la constness de l'objet.
 
Exemple: j'ai un etat qui doit etre calcule a chaque get mais qui ne change pas souvent. Plutot de le calculer a chaque fois j'ai un membre prive qui sert de cache et qui retient la valeur.
 
Evidemment si la methode a des effets de bords trop importants sur l'objet il ne vaut mieux pas la mettre en const..
 
LeGreg

A propos de using namespace
desole mais le using namespace est bien la pour  
ne pas avoir a se taper std:: partout
un mal pour un bien mais non merci (c'est mon point de vue)
 
Je crois que les gens n'ont pas saisi tout l'interet des namespace (en tout cas ces posts le montrent).
C'est comme en java avec la methode import
tu peux faire import machin.* en debut de fichier
ou bien specifier entierement toute classe mais c'est la galere..
 
La PRINCIPALE difference c'est que en java il n'y a pas
de fichier include et donc, l'import dans un fichier java n'ira pas polluer l'import dans un fichier java qui utilise la classe en question. (et que l'on ne specifie pas explicitement de namespace, ceux ci sont directement relies a l'architecture des repertoires)
 
Et le fait de specifier using namespace std
ne fait pas passer ces objets du namespace std au namespace
global, ils restent dans leur namespace, le fait est qu'ils sont juste promus par un systeme d'alias.
 
list est l'alias de std::list promu
et s'il y a collision (ca arrive sinon les namespaces n'existeraient pas en premier lieu)
alors un std::list ou un ::list ou whatever::whatelse::list
resoudra aisement le conflit.
 
On peut aussi eviter de specifier ::quelquechose sauf  
si l'on veut explicitement faire reference a un objet du domaine global parce que l'on peut toujours avoir des remords et decider de changer un objet de namespace et tout respecifier a la main c'est un peu lourd.
 
LeGreg

 
A quoi servent les namespace ? A éviter la collision de noms dans le cas de code maintenu par plusieurs personnes par exemple. Chaque membre de l'équipe de dev mettre ses objets dans son namespace, et la collision sera impossible.
 
Using, mal utilisé, annule cet avantage. Regarde l'exemple suivant :
 

 
Merci de me rappeler ce qu'est un namespace j'avais du mal
a m'en rappeler
 
Bref relis un peu ce que j'ai ecrit et ne sort pas d'exemples
a deux balles qui ne montrent rien. (?)
 
LeGreg

bon je suis gentil cette nuit:
 

 
Voila tu vas te coucher moins bete ce soir..
 
LeGreg

inutile de monter sur tes gds chevaux ! y'avait aucune aggression dans mes propos... j'ai parfaitement lu tes posts et je suis d'accord avec toi..
 
quant à mon "exemple qui ne montre rien", certes très basique, il a le mérite d'être très explicite, et de bien montrer que "using" mal employé peut conduire à pas mal d'ambiguités.

je ne suis pas enerve  
je suis juste las de lire ce genre de chose.
 
j'imagine bien devoir me taper ce genre de chose sur le projet sur lequel je bosse:
gap::tests::testgfx::maclasse::maMethode()
a chaque ligne de mon programme
 
 
LeGreg

Tu as un pb ou quoi ? Je t'ai insulté dans un de mes précédents topics ?

 
cf ma reponse: aucun pb avec toi
 
LeGreg

Un peu de perspective:
 
Qu'apporte le langage C++ par rapport a C?
 
Imagine le cas java:
La lib standard est enorme et depasse largement la STL. Sans les namespace tu aurais tous les fichiers .class dans le meme repertoire. Le risque de collision grandit, grandit et grandit encore lorsque tu ajoutes tes propres classes. Tu es condamne a choisir un nom de classe different a chaque librairie que tu ajoutes et tu ne controles pas les librairies que tu n'as pas ecrit.. (bonjour l'angoisse).
 
Oublie java. Imagine que tu es un fournisseur de librairie au format .obj ou .lib. Dans ton developpement tu utilises C++, tu as des classes publiques et des classes que ne verra jamais le client mais qui sont en interne dans des fichiers .h.
Si tu n'utilises pas les namespaces, toutes tes classes seront visibles a l'edition des liens au niveau global meme celles dont le client n'a aucune connaissance de leur existence (il n'y a pas de documentation sur les classes internes a ta librairie).
Il peut modifier son propre code pour ne pas avoir de collision avec les librairies a la compilation ou a l'edition des liens; ca peut etre tricky et il peut ne pas comprendre l'erreur. Mais la ou ca devient impossible pour lui c'est s'il utilise deux librairies qui n'ont pas de conventions de nommage strictes pour leurs objets et qui manque de bol utilisent le meme nom pour un objet en particulier !
C'est ce genre de probleme que cherche a resoudre l'utilisation
des namespace et using ne remet pas en question cet avantage!
 
Sincerement je me fais l'avocat du using:
using evite d'avoir a taper du code inutile
et tout bon programmeur est faineant. Si
le programmeur faineant doit taper trop de code supplementaire
pour utiliser les namespace, il va reflechir a deux
fois avant d'utiliser intensivement les namespaces.
Et si le programmeur doit se poser la question s'il doit
utiliser les namespace alors les namespaces
n'auront rien resolu.
 
LeGreg

Question bête : une colision de namespace ca donne quoi ?

juste une erreur à la compilation. tu résouds en spécifiant le namespace sur la référence ambigüe. (nomDuNameSpace::laRéférenceAmbigüe)
 

moi aussi. autant dans les .h c'est utile dès que le projet grossit beaucoup, autant dans l'implémentation on peut très souvent s'en sortir avec les using. flemmardise ? ça tombe bien, je considère la flemme comme une des principales qualités d'un programmeur.
 
pinailler sur l'utilisation d'"using" dans un langage bâtard qui plante sur une mauvaise indirection ... la matière grise est mieux utilisée ailleurs

nan nan, je veux dire si 2 include possèdent (accidentellement)le même nom de namespace et que tu include les 2 ...

Non rien.
Je me demandais juste ce que ca fesait si par exemple, accidentellement, j'appelle mon namespace std;
C'est tout con, ca fait rien. J'enrichie juste ce namespace.