Link (./428) :
On voit mieux les détails en C++/CLI, qui utilise des pin_ptr<> pour empêcher un objet managé de bouger lors de la réorganisation (et je crois que c'est un wrapper de GCHandle::Alloc(GCHandleType::Pinned)).
C'est comme
HLock, quoi.
Link (./437) :
Par ailleurs, dans les compilos où la RTTI est désactivable, soit le switch RTTI-off ment, soit les exceptions ne marchent pas; car l'identification d'exceptions C++ nécessite de la RTTI, on ne peut (à ma connaissance) la faire en statique.
Dans les systèmes d'exceptions qui utilisent un unwinder (genre DWARF, utilisé sous GNU/Linux), c'est possible en général sans RTTI. (En revanche, c'est le dépilement (unwinding) qui est "runtime".) Les informations d'unwinding te disent non seulement comment dépiler et quels destructeurs appeler (une sorte de bytecode VM exécuté par l'unwinder), mais aussi où se trouvent des
try et quels types ils attendent. Or, le
throw sait dès la compilation (sauf dans un cas décrit dans le prochain paragraphe) de quel type est la variable qu'on lui passe. Du coup, le compilateur peut générer du code qui passe ce type statique à l'unwinder, qui n'a ensuite plus qu'à comparer ce type avec ce qu'attendent les blocs
try. Ce n'est pas équivalent à du RTTI parce qu'on n'a pas besoin d'identifier le type d'un objet en temps d'exécution, donc les objets n'ont pas besoin de porter l'overhead pour l'identification de leur type, seul l'unwinder a besoin de certaines connaissances sur les types. Donc il n'y a pas d'overhead par objet.
Maintenant, pourquoi ai-je dit "en général"? Bah, parce que quelqu'un pourrait s'amuser à faire du
throw avec des pointeurs, et du coup le type runtime n'est pas forcément connu en temps de compilation. Mais du coup, je suppose que ce qui va se passer avec
-fno-rtti, c'est que l'exception en question ne sera pas attrappée. Mais là c'est vraiment le problème du programmeur. Faut pas lancer des pointeurs comme exceptions en C++, et encore moins des pointeurs polymorphes si on a désactivé le RTTI.
Folco (./440) :
Tiens, ma classe DateException, je l'ai déclarée comme ça :
class DateException
{
public:
DateException(const std::string & error);
~DateException();
std::string getErrorString();
private:
std::string m_ErrorString;
};C'est bien ou pas ? J'ai pas eu l'impression que c'était dans vos idée de faire les choses...
Uther (./441) :
Personnellement j'aurais fait pareil
Personnellement j'aurais lancé un
const char * (voire un
int à la AMS), mais bon.
GoldenCrystal (./443) :
puis retourne un const std::string& sur cet objet
Euh, retourner un
const & est dangereux et absolument déconseillé. Comme l'explique
krazy2, l'outil utilisé par KDE pour détecter le code sale:
For binary compatibility reasons avoid const references for return types. For example, "const QList<int> &someProperty() const" should be rewritten to return a value instead, eg "QList<int> someProperty() const". See <http://techbase.kde.org/Policies/Library_Code_Policy#Const_References> for more details. En gros, si tu retournes un
const &, tu ne peux pas créer l'objet dynamiquement dans la fonction (parce que si tu le crées sur la pile, il sera détruit trop tôt, si tu le crées dans le tas, tu leakes de la mémoire), il faut l'avoir dans la classe, donc ça fixe une contrainte à l'implémentation, donc tu ne peux pas modifier ton code après sans casser la compatibilité binaire. De plus, si la classe appelante garde la référence au lieu de la recopier (ce qui ne donnera aucun warning si la valeur a été retournée par référence), elle peut se retrouver avec une valeur modifiée.
Cela dit, je comprends pourquoi tu fais ça avec
std::string, c'est bien le problème des classes qui ne sont pas implicitement partagées, tu contournes une erreur de design de
std::string là. Avec
QString, retourner une valeur ne serait pas si coûteux.
squalyl (./447) :
non c'est le constructeur qui throw l'exception, que tu testes ou pas avant.
pour que ton truc soit utile il faudrait que le constructeur lance une sousclasse de RuntimeException au lieu d'une IOException qu'il faut catcher.
Tester avant n'est pas suffisant, cf. race condition (en particulier: TOCTOU – Time Of Check vs. Time Of Use). De plus, un test d'existence du fichier n'est pas suffisant pour garantir une ouverture avec succès.
)
)
