Est-il recommandé de mettre une boucle while, qui ne se termine jamais dans un constructeur? Ou devrais-je utiliser des threads pour obtenir le même résultat? Est-ce bon quand un constructeur ne se termine jamais? Ou est-il plus sûr d'éviter les fautes de segmentation?Alors que (1) dans le constructeur ou en utilisant des discussions?
espère que vous comprenez mon mauvais anglais ..
Un objet n'existe pas si son constructeur ne se termine pas. Donc, mettre une boucle while (1) dans un constructeur empêchera la création d'objets en utilisant ce constructeur. Vous devez décrire le problème que vous pensez résoudre cela.
et il va également bloquer l'appelant –
Il semble que l'OP cherche à modéliser une opération de longue durée avec une instance de classe. Si c'est le cas, * démarrer * l'opération dans le constructeur n'est pas la bonne idée, à moins que l'instance n'ait engendré une opération asynchrone qu'elle permettra alors à un appelant d'attendre, comme un futur. En fait * faire * le travail de longue durée dans le constructeur n'est pas acceptable. – seh
Rien de mal en soi à faire un travail de longue durée dans le constructeur - c'est un mythe C++. –
Je dirais qu'il est parfaitement possible de lancer un thread depuis un constructeur, et une idée horriblement mauvaise d'avoir une boucle sans fin dans le constructeur.
Dans le code, ce qui suit est OK:
void start_a_thread_with_a_loop()
{
while(1)
{
// consider a while(!stop_condition) or something
// do something in a loop
}
}
class x
{
public:
x()
{
start_a_thread_with_a_loop();
}
};
Et ce qui suit serait au moins une mauvaise idée:
class x
{
public:
x()
{
while(1)
{
}
}
};
bonne chose cependant, est que probable que vous ne seriez pas en mesure pour utiliser un tel objet, pour des raisons Neil a souligné :)
L'un des dangers de générer des threads dans les constructeurs est qu'il interagit mal avec le sous-classement. Lors de la création d'un objet d'une sous-classe, le thread peut commencer à s'exécuter avant l'exécution du constructeur de la sous-classe. Hormis le fait d'être simplement en train d'être iffy, en C++ cela signifie que les appels de méthode virtuelle dans le thread peuvent appeler des méthodes de classe de base au lieu de méthodes de sous-classe. (Bien sûr, si 'this' n'est pas utilisé dans le thread généré, il n'y a pas de problème.) –
Ne dérivez pas de la classe ensuite. Le donner à un destructeur non virtuel est généralement compris comme un indice fort que la classe n'est pas conçue pour en être dérivée. – jalf
Est-il recommandé de mettre une boucle while, qui ne se termine jamais dans un constructeur?
n °
Ou devrais-je utiliser les threads pour obtenir le même résultat?
No.
Est-il bien quand un constructeur se termine jamais?
n °
Ou est-il plus sûr d'éviter des erreurs de segmentation?
No.
Quel est le problème que vous essayez de résoudre?
Dans les systèmes embarqués, la plupart des boucles sans fin doivent être évitées. Ils devraient soit être chronométrés, soit compter les itérations. Si la boucle est terminée, une vérification d'erreur doit être effectuée. Cela évite que le système soit "verrouillé". Une exception à la règle est la boucle d'arrière-plan . C'est la boucle principale dans laquelle les événements sont vérifiés et maintient la machine en marche. Sans cette boucle, les machines peuvent simplement se terminer ou s'arrêter.
Votre code ne doit pas générer d'erreur de segmentation, qu'il utilise ou non plusieurs threads ou qu'il contienne des boucles infinies.
Aucun d'entre eux n'a quelque chose à voir avec les défauts de segmentation.Si cela se produit, vous devez corriger ce problème.
Certaines formes de 'while (1);' peuvent être optimisées en C++ 0x si elles fonctionnent: pas d'appel aux fonctions d'E/S, pas d'accès aux objets volatiles et n'effectue pas de synchronisation ou d'opérations atomiques. Alors méfiez-vous :) –
Si je comprends bien, vous voulez mettre une boucle principale dans un constructeur? C'est une idée étrange. Je vous suggère de mettre la boucle principale dans une méthode. –
C'est un bon moyen d'éviter les erreurs de segmentation. Un fil bloqué ne peut pas faire beaucoup de dégâts. –