ps -> j'essaye de comprendre le principe et de refaire derrière, donc pas de recopier bêtement, spour ça. Et en revenant sur ton post, j'ai pas vu là où je m'étais trompé, à cause de cette confusion justement. Merci bien, maintenant j'ai compris.
squalyl (./360) :
Nil : les références java, perso je vois ça comme des HANDLE de nos TIs ^^
try
{
Date Date(29, 2, 2001);
Date.printDate();
}
catch (DateException & e)
{
std::cout << e.getErrorString();
}
Brunni (./423) :
Marrant. Ca veut dire que la mémoire peut être réorganisée de façon transparente? Comment ça se passe avec le code unsafe à ce moment? Si tout ton code est unsafe et que tu gardes un pointeur global je me demande comment il s'en sort...
Brunni (./427) :
Pas terrible ton DateException&, ça veut dire que tu dois faire throw (*new DateException), donc qu'il faut la libérer en bas, ou alors que tu lances une exception que tu as déclaré statiquement... (là ok, mais tu ne peux pas mettre de texte)
N'oublie pas que si tu fais throw DateException(...) tu vas créer un objet sur la pile, et qu'il sera détruit à la fin de la fonction appelante (donc au passage dans le catch).
try {
// Fonction qui lève une exception d'un certain type "par valeur"
fonction();
}
catch (...) {
// Comment savoir quoi libérer? Et même combien d'octets restaurer sur la pile?
// Même problème si on attrape ici un objet superclasse du type en question et que le destructeur n'est pas virtuel
}Brunni (./427) :
Pas terrible ton DateException&, ça veut dire que tu dois faire throw (*new DateException), donc qu'il faut la libérer en bas, ou alors que tu lances une exception que tu as déclaré statiquement... (là ok, mais tu ne peux pas mettre de texte)N'oublie pas que si tu fais throw DateException(...) tu vas créer un objet sur la pile, et qu'il sera détruit à la fin de la fonction appelante (donc au passage dans le catch).
donc mes souvenirs étaient faux, sorry.quel avantage de passer une valeur d'exception par référence si le handler en reçoit de toute façon une copie ?
), une copie signifie une valeur, et nom une simple référence ou un pointeur.
)class DateException
{
public:
DateException(const std::string & error);
~DateException();
std::string getErrorString();
private:
std::string m_ErrorString;
};Kevin Kofler (./426) :
Au fait, bug report: la longueur du mois de février n'est pas (Year%4 ? 28 : 29) mais ((Year%4) || (!(Year%100) && (Year%400)) ? 28 : 29).
Link (./439) :Bien sur que si...
Disons que je suis contre les exceptions "abusives", c'est-à-dire les exceptions pour les cas non-exceptionnels. Typiquement, en java/.Net, j'aimerais pouvoir tester l'ouverture d'un fichier sans avoir systématiquement une exception. On a bien ça pour les dictionnaires en .Net (choix entre l'opérateur[] qui lance une exception et la méthode TryGetValue() qui n'en lance pas), mais il n'y a jamais d'équivalent pour les fichiers...
class DateException
{
private:
std::string m_ErrorString;
public:
DateException(const std::string& error) : m_ErrorString(error) { }
~DateException() { }
const std::string& getErrorString() const { return m_ErrorString; }
};
Link (./439) :
Disons que je suis contre les exceptions "abusives", c'est-à-dire les exceptions pour les cas non-exceptionnels. Typiquement, en java/.Net, j'aimerais pouvoir tester l'ouverture d'un fichier sans avoir systématiquement une exception. On a bien ça pour les dictionnaires en .Net (choix entre l'opérateur[] qui lance une exception et la méthode TryGetValue() qui n'en lance pas), mais il n'y a jamais d'équivalent pour les fichiers...
File f = new File("/tayst");
if (f.canRead()) {
FileInputStream fis = new FileInputStream(file);
...
}).