Comment puis-je empêcher mon "inutilisé" variables globales être compilé en sortir?

Je suis à l'aide d'initialisation statique pour faciliter le processus d'enregistrement de certaines classes, avec une usine en C++. Malheureusement, je pense que le compilateur optimisant les "inutilisé" des objets qui sont censés faire le travail utile dans leurs constructeurs. Est-il possible de dire au compilateur de ne pas optimiser une variable globale?

class SomeClass {
    public:
        SomeClass() {
            /* do something useful */
        }
};

SomeClass instance;

Mon point d'arrêt dans SomeClass constructeur de ne pas se faire frapper. Dans mon code, SomeClass est dans un fichier d'en-tête de l'instance et est dans un fichier source, plus ou moins seul.

EDIT: Comme deviné par KJAWolf, ce code est compilé en static lib, pas l'exécutable. Son but est d'enregistrer certains types fournis par la lib statique avec une liste statique des types et de leurs créateurs, pour une usine de lire ensuite de la construction. Étant donné que ces types sont fournis avec la lib, ajoutez ce code à l'exécutable n'est pas souhaitable.

Aussi j'ai découvert qu'en déplaçant le code dans un autre fichier source qui contient du code existant, il fonctionne très bien. Il semble que le fait d'avoir un fichier purement composé de ces objets globaux est ce qui est à l'origine du problème. C'est comme si que l'unité de traduction a été totalement ignoré.

Est de votre fichier source une partie de l'exécutable, ou fait-il partie d'une bibliothèque statique?
Aha, bon la divination de travail. En fait le fichier source est partie d'une lib statique. Serait-ce causer un problème? Je suis à 80% que j'ai fait exactement la même chose avant et il est travaillé.
j'ai eu le même problème: stackoverflow.com/questions/599035/...
J'ai eu aussi! Putain!
Pourquoi êtes-vous en utilisant une variable globale?
Comme je l'ai dit, afin d'exécuter du code lors de la phase d'initialisation statique, pour inscrire une classe avec une usine. J'ai pris la décision consciente d'utiliser à cette fin, dans le cas où cela conduit, dans un amphithéâtre 🙂 La raison pour laquelle je vais avoir de la difficulté, c'est que je suis un bon programmeur, donc je n'ai jamais vraiment utiliser et ne comprennent pas pourquoi ils ne travaillent pas que j'attends!

InformationsquelleAutor Ben Hymers | 2009-08-04

c++global-variables

37

Le compilateur n'est pas autorisé à optimiza à l'écart des objets globaux.

Même si elles ne sont jamais utilisées.

Quelque chose d'autre qui se passe dans votre code.

Maintenant, si vous avez construit une bibliothèque statique avec votre global de l'objet et que l'objet global n'est pas référencé à partir de l'exécutable, il ne sera pas tiré dans le exécutables par l'éditeur de liens.
- J'ai upvoted cela parce que je pense que c'est la seule réponse que les clous, le vrai problème, Comme l'interlocuteur dit "Il semble que le fait d'avoir un fichier purement composé de ces objets globaux est ce qui est à l'origine du problème. C'est comme si que l'unité de traduction a été totalement ignorée". L'unité de traduction est ignoré dans le sens où il est omis par l'éditeur de liens parce que c'est dans une bibliothèque. Si un objet est dans une bibliothèque et n'est pas appelé par quoi que ce soit dans l'application, il est omis, c'est toute l'idée de la libaries!
- Idem, qui a frappé le clou sur la tête. Je upvoted Pavel réponse trop depuis, il a également obtenu le droit 🙂
- Alors, comment pouvons-nous résoudre ce problème?
- Comment réparer cela dépend de ce que vous faites. En utilisant des objets globaux seulement pour les effets secondaires de leur construction/destruction n'est pas vraiment une bonne idée.
- Il semble être une bonne solution ici: stackoverflow.com/questions/599035/...
- J'ai la même expérience et elle est terrible (social.msdn.microsoft.com/Forums/vstudio/en-US/...). Les variables globales n'étaient pas référencées, mais leurs constructeurs avaient observables effets secondaires (c'est à dire l'enregistrement d'une usine). J'ai fini par faire artificiels, les références à ces objets globaux pour empêcher l'enlèvement. Seulement si le linker peut prouver que globals ne pas faire quelque chose, ALORS il peut jeter afaiac.
InformationsquelleAutor Martin York
5

Le compilateur ne devrait jamais optimiser tels globals - s'il le fait, il est tout simplement cassé.
- Si le compilateur ne peut détecter aucune utilisation du mondial, il peut les omettre. GCC G++ dans ce contexte) peut omettre certaines variables, par exemple, l'ancien "intégrer une version dans le fichier d'objet de" trucs ne fonctionnent pas avec moderne GCC - le fichier statique de valeur est détecté comme non utilisé et optimisé de l'objet fichier.
- fichier statique != mondial
- Si ils ont un cnstructor puis il y a un risque d'effet secondaire de l'utilisation du constructeur. Que gcc ne pas faire de la croix-analyse de la fonction, il ne serait jamais capable de détecter le potentiel d'un effet secondaire et ne serait donc pas être autorisé à le supprimer.
- Ce que Martin a dit. Si le constructeur a un effet secondaire observable, il ne peut pas être supprimé, qu'il soit statique ou non. Aussi, je ne suis pas sûr que je comprends votre remarque, Neil - IIRC, le C spec ne définit pas "global" de toute façon, de sorte que sa définition est ouvert, et "mondial est quelque chose qui n'est pas local ou un membre" est assez raisonnable (mais pas le seul, évidemment).
- Quelque chose comme static int x; il ne peut évidemment pas être "global" et pourrait certainement être gommés par le compilateur. Mon point était que les choses qui pourraient être global (c'est à dire liés par d'autres unités de compilation) ne peuvent être gommés par le compilateur, constructeur ou pas, parce que le compilateur ne peut pas savoir si ils vont être liés.
- C'est toujours un mondial pour autant que je suis concerné (c'est visible par toutes les fonctions dans l'unité de compilation, donc qu'est-ce donc?), mais en arguant de la définition des termes est inutile. Cependant, même pour un "global statique", si son constructeur a observables effets secondaires, le compilateur ne peut pas légalement éluder il.
- Bien sûr, il n'est pas si visible (selon l'endroit où elle est définie), mais nous semblons être à contre-courant. J'ai nulle part dit que je suis en désaccord avec le point sur le constructeur elidation
InformationsquelleAutor Pavel Minaev
2

Pour se développer à partir d'Arthur Ulfeldt, volatile indique au compilateur que cette variable peut changer de l'extérieur de la connaissance du compilateur. Je l'ai utilisé pour mettre une déclaration afin de permettre le débogueur pour définir un point d'arrêt. Il est également utile pour les registres du matériel qui peut changer en fonction de l'environnement ou qui ont besoin d'une séquence particulière. c'est à dire Port Série de recevoir registre et de certains de surveillance des registres.
- Non, simplement, il indique au compilateur qu'il doit pas le cache auparavant de lire la valeur de la variable.
- Il est utile pour le multithreading 🙂
- volatile est de ne pas la pour le multithreading 🙁
InformationsquelleAutor Robert
1

vous pouvez utiliser
```
#pragma optimiser off 
int globalVar 
#pragma optimiser sur 
```
mais je ne sais pas si cela fonctionne uniquement dans Visual Studio ( http://msdn.microsoft.com/en-us/library/chh3fb0k(SV.80).aspx ).

Vous pouvez également indiquer au compilateur de ne pas optimiser du tout, surtout si vous êtes de débogage...
- Ce n'est pas compatible avec tous les IDE et les compilateurs.
- mais j'aimerais que ça!
- Sur Visual Studio, la syntaxe est #pragma optimiser("", off), mais pour moi, il n'empêche que la variable globale sera supprimée dans une bibliothèque statique.
InformationsquelleAutor atk
1

Vous pouvez forcer qu'un objet (votre liste de types) tire quelques autres objets par partiellement la liaison avant la construction de la statique complet lib.

Avec Éditeur de liens GNU:
```
ld -Ur -o TypeBundle.o type1.o type2.o type3.o static_list.o
ld -static -o MyStaticLib.a type_bundle.o other_object.o another_object.o ...
```
Ainsi, chaque fois que la liste statique est référencée par le code à l'aide de la bibliothèque, de la complète "TypeBundle.o" de l'objet à être reliés dans le binaire résultant, y compris type1.o, type2.o, et de type3.o.

Tout à lui, faites vérifier le sens de "Ur" dans le manuel.

InformationsquelleAutor gatopeich
0

Êtes-vous à l'aide de gcc avec gdb? Il y avait un problème dans le passé où gdb ne pouvait pas définir avec précision les points d'arrêt dans les constructeurs.

Aussi, êtes-vous à l'aide d'un niveau d'optimisation qui permet au compilateur de méthodes inline dans la définition de classe.

InformationsquelleAutor Juan
0

Vous devez utiliser l'entier de l'archive lors de la liaison. Voir la réponse ici:

l'éditeur de liens ld question: --toute-option d'archivage

InformationsquelleAutor Sam
0

J'ai la même configuration & problème sur VS2008.
J'ai trouvé que si vous déclarez la classe avec dllexport il n'est pas optimale.
```
class __declspec( dllexport ) Cxxx
{
.
}
```
Toutefois, cela génère beaucoup de mises en garde dans mon cas parce que je doit déclarer toutes les classes utilisées dans cette classe aussi comme dllexport.

Toutes les optimisations sont hors tension (en mode debug), c'est toujours optimisé. Aussi volatile/pragma optimiser off. Sur des variables globales créées de cette classe (dans le même fichier cpp), etc ne fonctionne pas.

Juste trouvé que dllexport nécessite au moins pour inclure les fichiers d'en-tête de ces classes dans certaines autres rpc fichier à partir de l'exe pour travailler! Donc, la seule option est d'ajouter un fichier avec les appels à certains membres statiques pour chaque classe, et ajouter ce fichier à tous les projets ont utilisé ces classes.

InformationsquelleAutor fil
-2

Comment sur l'utilisation du mot-clé volatile? Il va empêcher le compilateur de trop de l'optimisation.

InformationsquelleAutor Partial

Vous devez vous connecter pour publier un commentaire.