striiiiiiiiiiiiiiing - Page 26

Sauf quand le client est le grand public, bien sûr. Dans ces cas-là, c'est l'éditeur qui a toujours raison.

Bof…
"Windows N"…

Vu le nombre de patches que sort Microsoft, je dirais que si, quand même...

euh... ya encore quelqu'un ?

J'ai une classe d'exception, mais ya un mécanisme que je conçois mal...

J'ai écrit ça :

class ScreenException
{
    public :

        ScreenException();
        ScreenException(const std::string & Error);
        ~ScreenException();

        std::string getErrorString();


    private :

        std::string m_ErrorString;
};

Mais comment faire, dans mon exception, pour appeler getErrorString (et donc afficher l'erreur).
J'essaye ça :

     catch (ScreenException)
    {
        fprintf(stderr, ScreenException.getErrorString.c_str());
        return EXIT_FAILURE;
    }

Mais je devine que c'est pas ça
"error: expected primary-expression before ‘.’ token"

Alors comment faire svp et pourquoi svp ?

déja, il y a des parenthèses à getErrorString()

après, si les exceptions en C++ sont pareilles qu'en Java, tu devrais faire:

   catch (ScreenException screenException) 
    { 
        fprintf(stderr, screenException.getErrorString().c_str()); 
        return EXIT_FAILURE; 
    }

ou peut être:

   catch (ScreenException *screenException) 
    { 
        fprintf(stderr, screenException->getErrorString().c_str()); 
        return EXIT_FAILURE; 
    }

Ah oui, j'avais essayé, mais non, toujours rien (oué je reprends à l'instant le c++, donc je tatône à mort (enfin, plus que d'habitude quoi ))

(han il a édité )

bingo, t'as raison, ça marche.

Mais je croyais avoir essayé, je me suis loupé quelque part :/

Hmm, je sais pas si tu as vu les 8 lignes rajoutées donc je repost.

edit: ah

Pour ma culture, c'est "catch (ScreenException *screenException)" ou "catch (ScreenException screenException)" qui marche?

oublié : merci beaucoup !

(cross)

Alors :
catch (ScreenException except) : except.getErrorString()
catch (ScreenException *except) : except->getErrorString()
catch (ScreenException & except) : except.getErrorString()

Valeur, pointeur, référence. Ca compile, mais j'ai pas encore essayé.

Normalement, on utilise catch (ScreenException screenException) ou catch (const ScreenException &screenException) (plus efficace, et normalement le compilateur est censé faire en sorte que ça fonctionne, c'est une exception aux règles de scoping). catch (ScreenException *screenException), c'est si tu alloues tes exceptions avec new comme en Java, pratique pas vraiment conseillée.

Ah, j'ai oublié le const, ça me revient en effet, merci.

Kevin Kofler (./761) :
plus efficace, et normalement le compilateur est censé faire en sorte que ça fonctionne, c'est une exception aux règles de scoping

AAAAAAHHHHH !
C'est bien ce que je disais Brunni, il y a quelques mois, c'est ce que décris mon bouquin, le fait que l'objet devrait être détruit, mais est conservé dans le catch (donc hors scope de création). Et c'est pour ça que le passage par référence marche, c'est un comportement en effet "anormal" par rapport aux règles, mais c'est prévu ainsi par la norme. En tout cas, le compilateur optimise ça sans problème.

Yup ^^ C'est pas logique, mais tant mieux que ça marche

J'avais étudié les mécanismes des exceptions lancées par valeur sous Visual, notamment au niveau de la position des variables dans la pile.

L'exception est au sommet de la pile ("sur" les objets du try), mais les destructeurs des objets du try sont quand même appelés avant. Pendant le catch, les objets du try sont donc détruits mais toujours sur la pile, en attendant que l'exception soit détruite (à la fin du dernier catch).

Avec les normes C++ un tant soit peu récentes, il est bel et bien déconseillé de lancer les exceptions en les allouant sur le tas. À ma connaissance, il n'y a plus que MFC qui fait ça, parce que MFC date d'avant les normes en question (dans les premières versions de MFC, il n'y avait même pas de mécanisme d'exception standard, d'où les macros).

PS: Il me semble que la référence const en général est une exception aux règles de scoping, pas seulement dans le contexte des traitements d'exception: Notamment, je crois me rappeler qu'une référence const vers un temporaire non-nommé étend sa durée de vie à celle de la référence.

C'est probable ou t'es sûr ? Et ça étend la durée jusqu'à quand ?
Mais ça reste propre après comme programmation ?

Disons qu'il faudrait que je relise la norme et/ou le(s) GotW correspondant(s)...

Mais ce sont je suis sûr, c'est que ça n'était pas mentionné comme "un détail d'implémentation", mais comme une vérité universelle normalisée.
Et puis, j'ai bien dit le temporaire lui-même, hein: Je ne m'avance pas pour des trucs plus obscurs, comme une référence const vers un membre d'un temporaire non-nommé...

Merci bien.

Bon, j'ai un truc qui m'emmerde bien. j'ai écrit quelque chose que j'ai vu dans des sources, et ça compile, mais je ne comprends pas pourquoi... Je ne comprends pas le sens de ce que j'ai écrit...

Header :
std::string getErrorString() const;
Implémentation :

std::string ScreenException::getErrorString() const
{
    return m_ErrorString;
}

Uitilisation :

    catch (const ScreenException & exception)
    {
        fprintf(stderr, exception.getErrorString().c_str());
        return EXIT_FAILURE;
    }

Le truc, c'est que dans le header et l'implémentation, j'ai rajouté un const à la fin du proto !
Qu'est-ce que ça veut dire ? D'habitude je mets des const avant les types (const int, const char* etc...), mais là tout à la fin, ça signifie quoi ?

J'avais lu ça dans des sources, et je m'étais dit que j'étudierai ça quand j'en serai rendu là, que pour le moment c'était pas la peine de regarder ça de près, mais visiblement, pour les exceptions telles qu'on en parle (catch (const ScreenException & exception)), c'est le seul moyen de faire. Et je ne comprends pas, ça me gonfle.

le const à la fin porte sur le premier argument implicite de ta méthode, c'est à dire "this" (la syntaxe n'est pas spécialement logique, c'est sûr)

Ah !!! Pour essayer de compiler, j'avais écrit classe::fonction(const & this), il me semblait bien que le const s'appliquait à l'objet ! Intuitivement, c'était ça, mais en effet, la syntaxe ne coule pas de source.

Merci !

Ça permet d’indiquer que ta méthode est pure : elle ne modifie pas l’objet this.

constante, pas pure (sauf erreur de ma part, une méthode est pure quand elle est virtuelle sans implémentation, ce qui implique donc que la classe qui la contient est abstraite)

Ah oui en C++ on appelle « virtuelle pure » les opérations sans implémentation, mais en fait, de manière générale en programmation (du moins en méthodes formelles), une méthode sans effet de bords (qui ne modifie pas l’objet this) est dite « pure ».

ah ok, je n'avais jamais entendu le terme dans ce sens

Tout comme le terme "fonction membre virtuelle pure" est traduit en "méthode abstraite" en java-speak...

(Ce qui contribue à faire du Java un langage bien plus compréhensible)

Carrément

Link (./775) :
fonction membre virtuelle pure

-fonction membre + méthode, ça revient au même hein, pas la peine de complique pour s'acharner à démontrer que c'est plus compliqué. D'un autre côté, ce que je vous vois dire du java me semble être un véritable carcan, les deux ont certainement leurs avantages et leurs inconvénients.

Ce sont des langages opposés sur énormément de points (mais pas tous, certes… par exemple ils jouent dans la même catégorie de langage, ce sont des langages objets impératifs et basés sur un système de classes)
Mais à moins que tu ne veuilles lancer un troll C++ vs Java (auquel je prendrais joie à participer), je n'irai pas plus loin.

Oh non, j'en veux pas de ce troll, ou alors forker, mais j'aurais certainement d'autres questions très C++ d'ici peu