appel explicite au constructeur
Bonsoir,
voilà j'essaie d'implementer une classe String, pour débuter je veux juste surdéfinir l'opérateur = afin de pouvoir faire :
Code:
1 2 3 4
| String str1 ("bb");
String str2;
str2 = str1; |
J'ai donc pondu le code suivant :
Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
| #include <iostream>
using namespace std;
class String
{
private :
char* m_string;
public :
String (char *string = "")
{
m_string = new char[strlen (string) + 1];
strcpy (m_string, string);
}
~String ()
{
delete m_string, m_string = NULL;
}
String & operator= (const String &right)
{
delete m_string, m_string = NULL;
String (right.m_string);
return *this;
}
void display ()
{
cout << m_string;
}
};
int main ()
{
String str1;
String str2 ("Salut jonjon");
str1 = str2;
str1.display ();
return EXIT_SUCCESS;
} |
dans la fonction operator= j'essaie d'appeler le constructeur de l'objet pour pouvoir changer sa valeur, mais ça ne marche pas.
j'aimerais éviter de faire
Code:
1 2 3 4 5 6 7 8 9
| String & operator= (const String &right)
{
delete m_string, m_string = NULL;
m_string = new char[strlen (right.m_string) + 1];
strcpy (m_string, right.m_string);
return *this;
} |
merci
volatile n'est pas pour le multithread
Citation:
Envoyé par
babar63
Hum...
Déjà, Introduction to the Volatile Keyword commence par une description incomplète :
Citation:
Envoyé par Introduction to the Volatile Keyword
In practice, only three types of variables could change:
- Memory-mapped peripheral registers
- Global variables modified by an interrupt service routine
- Global variables within a multi-threaded application
L'auteur oublie le cas de setjmp (il parle de "C/C++", et du "C keyword volatile", donc setjmp est pertinent).
Par le suite, on lit :
Citation:
Envoyé par Introduction to the Volatile Keyword
Multi-threaded applications
[...] another task modifying a shared global is conceptually identical to the problem of interrupt service routines discussed previously. So all shared global variables should be declared volatile.
Le site est "Embedded.com", et l'article commence par
Citation:
Have you experienced any of the following in your C/C++ embedded code?
cependant beaucoup de programmeurs sur PC ne vont pas prêter attention à ça et vont penser que l'article parle des threads en général.
Hors, si l'usage de volatile a des chances de suffire sur un système embarqué, probablement pas symétriquement multi-processeurs, volatile ne donne pas au programmeur les garanties nécessaires sur un ordinateur multi-processeurs, multi-core (ce qui revient au même) ou HyperThread. L'article ne mentionne cela à aucun moment! :evilred:
Dans Bruce Eckel's Thinking in C++, 2nd Ed, qui à priori ne parle pas spécialement de programmation embarquée, cette section :
Citation:
Envoyé par Section 'Specifying storage allocation', sous-section 'volatile'
If you’re watching a particular flag that is modified by another thread or process, that flag should be volatile so the compiler doesn’t make the assumption that it can optimize away multiple reads of the flag.
:evilred:
et là :
Citation:
Envoyé par Section 'volatile'
Somehow, the environment is changing the data (possibly through multitasking, multithreading or interrupts), and volatile tells the compiler not to make any assumptions about that data, especially during optimization.
volatile ne doit pas être utilisé à la place des primitives de synchronisation multi-taches (mutex, conditions, sémaphores, rwlock, évènements, barrières...) ni des opérations atomiques (compteur atomique, compare-échange...) qui elles ont un comportement multi-tache bien défini.
En résumé :
En règle générale, volatile n'a pas un comportement multi-tache bien défini.
Si des références disent ou laisse entendre le contraire, c'est mal barré pour apprendre aux gens à programmer correctement. :?