J'ai trouvé 5 mn alors je reviens sur ce que je n'ai pas dit dans mon post d'avant.

D'abord quelque chose comme:

double valeur;
cin >> valeur;

Ensuite:
On a vu que:
region *m_region;
était générateur d'une fuite mémoire.
Je t'ai donné une solution à base de auto_ptr. Ca marche *MAIS* seulement dans le strict cadre de ton code. Dans un cadre plus général, il faudrait gérer la copie et l'affectation des objets ville. Sans cela il y aurait de gros problèmes. Je pourrais le montrer ici, mais je pense que si tu as écrit

region *m_region;

C'est parce que tu n'a pas su écrire

region m_region;

Ou plutôt que tu l'as écrit mais qu'après tu n'as pas su initialiser l'objet en passant des paramètres au constructeur. Ca se fait dans la liste d'initialisation du constructeur, comme ceci:

ville::ville(const string& name_region, const string& name_ville, const vector<double>& vtemperature)
	: m_region(name_region, name_ville), temperature(vtemperature)
{
}

Comme tu vois, j'ai aussi ajouté plein d'autres choses. Un vector pour remplacer le tableau, ainsi que plein de const là où il était pertinent d'en mettre. Du moins pour ce que tu montres du code. Par exemple dans ce que tu montres, on peut penser que ville ne change pas de nom de region, donc

const region m_region;

est naturel.
Bien employer le mot-clé const est très important en C++

A la fin de mon post tu va donc trouver tout ton code réécrit en C++ ;)

*MAIS* avant de te quitter pour ce soir, je tiens à ajouter une chose, qui ne tient pas cette fois à la manière d'écrire en C++, mais à la POO seule.

Il me semble que tu veux travailler avec des classes se faisant mutellement référence (au niveau des données pas au niveau des instances de classes, du moins si je me base sur le code que tu as donné). Une ville détient un membre région, un région détient un membre ville. Je ne suis pas sûr que ça soit une bonne approche. Ca va vite être ingérable.
Une région contenant un vector de villes semblerait plus adapté.

Voici toutefois ton code ré-écrit:
(remarque la disparition de #include )

#include <iostream>
#include <string>
#include <vector>

using namespace std;

class region
{
private:
	const string region2;
	const string ville2;
  
public:
	region(const string& region_name, const string& ville_name);
	string affnom_region() const;
	string affnom_ville() const;
};

class ville
{
private:
	const region m_region;
	const vector<double> temperature;           

public:
	ville(const string& name_region, const string& name_ville, const vector<double>& vtemperature);
	string affname_region() const;                 
}; 


region::region(const string& region_name, const string& ville_name)
: region2(region_name), ville2(ville_name)
{
}

string region::affnom_region() const
{
	return region2;
}

string region::affnom_ville() const
{
	return ville2;
}

ville::ville(const string& name_region, const string& name_ville, const vector<double>& vtemperature)
	: m_region(name_region, name_ville), temperature(vtemperature)
{
}

string ville::affname_region() const
{
	 return m_region.affnom_region();
} 

int main(int argc, char *argv[])
{
	// j'ai la flemme d'en mettre 12 :)
	vector<double> tabtp(3);
	tabtp[0] = 19.0;
	tabtp[1] = 20.0;
	tabtp[2] = 21.0;
    
	string regiona="PACA";
	string villea="Marseille";
   
	ville ville1(regiona, villea, tabtp);
 
	cout << endl;
	cout<< "nom de la region : " << ville1.affname_region() << endl;
  
	cin.get();
	return EXIT_SUCCESS;
} 

Bienvenue dans le monde de C++ et sur notre forum :).
Ton post me change agréablement de l'infâme et omniprésent Java.

Salut k-lo :)

const type nom_variable;

On en est pas sûr du tout :lol:
Quand on déclare une variable ou un membre const, cela veut dire que le codeur considère que ça doit être const et donc le rester.
Mais il y a toujours la possibilité d'un petit malin dégage le const par un const_cast. Attention je dis pas que c'est une bonne pratique. Dans ce cas c'en est même une très mauvaise. Selon la norme ça aboutit à un comportement indéterminé. Par exemple ça selon la machine et le compilo ça peut marcher. Ou bien par exemple le compilo s'est appuyé sur const pour placer la variable dans une zone de mémoire en lecture seule et là tu as un plantage :) Tu as aussi la possibilié qu'un fûté vienne attaquer ta variable const avec une petite routine en assembleur :) Donc tu n'es **SUR** de rien.

Par contre en déclarant const:
- tu exprimes clairement en tant qu'auteur du code que c'est const et que ça doit le rester.
- tu peux donc compter que ça restera const si tu as affaire à d'autres codeurs bien élévés et qui connaissent C++. (Oui je sais ça devient rare... mais il en reste encore heureusement :) )
Tu augmentes la sécurité et le cohérence de ton code, le compilateur t'interdisant (sauf si tu joues toi même avec const_cast bien entendu) de modifier une variable const et ainsi de te contredire mille lignes de code et un coup de fatigue plus loin
- tu permets au compilo de procéder tout seul comme un grand, telle que celle que j'ai évoqué plus haut, ou encore la suppression pure et simple d'objets temporaires, ou encore, etc, etc :)

Ce n'est pas si simple
Quand tu écris

string& getStr1() { return str1; }

string& getStr1() const {return str1;}

Alors tu annonces que getStrr1 ne modifiera pas l'état de ton objet ce qui est franchement faux puisque on peut modifier la chaîne membre comme dit plus haut donc modifier l'état interne de l'objet. Donc ce que tu dois écrire est:

const string& getStr1() const {return str1;} Et là c'est ok.

En revanche dans le code que j'ai donné dans mon post précédent tu as l'équivalent de:

string getStr1() const {return str1;}

Là on retourne une copie du membre. Si l'appelant modifie la copie, l'état de l'objet reste quand même inchangé et donc la déclaration qui dit que getStr1 ne modifie pas l'état interne de l'objet est ok :)

Mais si :)

Tu as compris :)
Mais si le membre est const c'est bon aussi :)

PS: Je ne sais pas si on pourra continuer cette discussion très loin. A partir de cet après midi, je vais quitter le forum quelques semaines pour cause de vacances (bien méritées :) )