striiiiiiiiiiiiiiing - Page 56

1650

Le 29/05/2010 à 02:36

Link (./1624) :
@Kevin: On ne peut pas toujours mettre à jour les programmes.

C'est bien pour ça que les logiciels propriétaires, ça sux! Sous GNU/Linux, on refuse par principe d'introduire des workarounds pour les applications boguées, et ça ne dérange pas tant que ça, sauf pour les quelques applications propriétaires qui n'arrêtent pas de casser. Quand il y a un problème avec un logiciel libre, quelqu'un le corrige et pouf, il n'y a plus de problème!

GoldenCrystal (./1635) :
Tu veux dire les 0.15% restant une fois qu'on a décompté Windows, Mac OS X (Cocoa), .NET, Java, Qt & co. ?

OS X utilise des locales UTF-8 par défaut, tout comme GNU/Linux etc. Maintenant, il y a des toolkits qui utilisent l'UTF-16 par dessus, mais le codage système, et le codage utilisé partout où on a besoin d'un codage "8 bits" (c'est-à-dire compatible ASCII), c'est l'UTF-8. Il n'y a vraiment qu'un seul système qui persiste à utiliser des codepages 8 bits obsolètes et à essayer de forcer tout le monde de passer à l'UTF-16 pour gérer le Unicode, même quand ça implique d'être incompatible avec les APIs existantes et portables parce qu'elles travaillent avec des chaînes de caractères 8 bits (pratiquement toutes les APIs C, par exemple).

Zerosquare (./1638) :
Oui, mais ça n'empêche qu'il est censé faire 16 bits au minimum (j'ai vérifié dans le K&R).

Le K&R n'est pas un document normatif. Mais ton affirmation est correcte d'après 6.2.5 §5 et 5.2.4.2.1 §1 (11^ème et 12^ème énumérés) du standard ISO C99 (cf. le document n1256.pdf WG14/N1256 ISO/IEC 9899:TC3 téléchargeable gratuitement) qui garantissent que int doit pouvoir représenter au moins l'ensemble [-32767,32767] ∩ ℤ. (Je signale cependant que -32768 n'est pas garanti être représentable dans un int, parce que la représentation "complément de 2" n'est pas obligatoire.)

Link (./1642) :
^^Quelle est exactement la différence entre inttypes.h et stdint.h?

inttypes.h inclut stdint.h et rajoute des trucs en plus.

Brunni (./1646) :
\o/ GCC vient de me laisser faire:
const u32 colors[] = {
    colors[0], colors[1], colors[2], colors[3]
};
Je voulais évidemment accéder à ma propriété colors, mais il trouve rien de mieux que prendre les éléments du tableau que je suis en train d'initialiser... je pouvais bien chercher pourquoi c'était tout noir

Zerosquare (./1647) :
Je me suis déjà fait avoir de la même façon... Kevin m'avait répondu que c'était pas un bug, mais je ne me rappelle plus de la justification...

C'est parce que int x=x; est la manière proposée par GCC pour supprimer les warnings au sujet des variables non initialisées (quand il y a un faux positif).

Brunni (./1648) :
Il fait une deuxième passe pour déjà connaître 'color' dans le corps de 'set'? Je croyais que c'était pas le cas.

Contrairement au C, le C++ n'est pas un langage parsable en une seule passe linéaire.

Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

1651

Le 29/05/2010 à 13:15

    catch (char* errorStr)
    {
        SDL_FreeSurface (m_Background);
        while (m_IconList.size () != 0)
        {
            delete m_IconList.back ();
            m_IconList.pop_back ();
        }
        throw (errorStr);
    }
    catch (std::bad_alloc)
    {
        SDL_FreeSurface (m_Background);
        while (m_IconList.size () != 0)
        {
            delete m_IconList.back ();
            m_IconList.pop_back ();
        }
        throw ((char*) "Out of memory\n");
    }

Savez-vous s'il y a un moyen d'éviter la duplication de code dans un handler d'exception ? Je n'ai pas trouvé dans mon bouquin...

1652

Le 29/05/2010 à 13:45

void cleanup(char *msg) {
  SDL_FreeSurface(m_Background);
  while (m_IconList.size() != 0)
  {
    delete m_IconList.back();
    m_IconList.pop_back();
  }
  throw msg;
}

...

catch (char* errorStr)
{
  cleanup(errorStr);
}
catch (std::bad_alloc)
{
  cleanup("Out of memory\n");
}

« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

1653

Le 29/05/2010 à 14:02

même si personnellement je trouve plus logique de garder le throw. Je ne pense pas que ce soit le role d'une fonction de nettoyage de lancer des exceptions.

1654

Le 29/05/2010 à 14:32

Ah pas con, sachant qu'on était dans un handler exception, je n'ai même pas pensé à ça

Je me fais des montagnes pour des taupinières des fois...
Et oui, "visuellement", je préfère garder le throw dans le handler, on voit mieux que l'interception est récupérée, traitée, et relancée.

1655

Le 29/05/2010 à 14:41

Tu peux aussi appeler ta fonction handleExnAndThrowBack

« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

1656

Le 29/05/2010 à 15:26

C'est ce que j'ai fait, merci bien (cleanAndThrow chez moi, je rajouterai le back quand j'aurai compris la subtilité que cette préposition ajoute ici

)

1657

Le 29/05/2010 à 17:46

./1650> Merci beaucoup

Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

1658

Le 29/05/2010 à 21:30

    catch (...) // oui, les ... tels quels!
    { 
        SDL_FreeSurface (m_Background); 
        while (m_IconList.size () != 0) 
        { 
            delete m_IconList.back (); 
            m_IconList.pop_back (); 
        } 
        throw;
    }

1659

Le 29/05/2010 à 21:36

Ça fait quoi le dernier throw ?

« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

1660

Le 29/05/2010 à 21:59

ça relance à l'identique l'exception catchée, il me semble

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

1661

Le 29/05/2010 à 21:59

Ça ne correspond donc pas à ce que veut Martial.

« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

1662

Le 29/05/2010 à 22:02

En effet, pas quand j'intercepte bad_alloc, mais merci pour les tips du "throw" et du "..."

1663

Le 29/05/2010 à 22:11

D'après ma doc, je pourrais utiliser unexpected, mais son comportement n'est pas normalisé, et ça peut appeler abort. Il faut donc redéfinir son handler, mais si je ne sais pas si c'est bad_alloc ou une erreur SDL qui s'est produite, je ne saurai pas quoi afficher comme erreur (ce qui est aussi le cas avec '...').

1664

Le 29/05/2010 à 23:28

Bon à part ça, je suis super content, j'ai recommencé pour la 4ème fois mon programme (C->C++->C->C++, rigolez pas

). La dernière fois, je butais tout simplement sur des conneries de visibilité des objets les uns par rapport aux autres : à force d'encapsuler tout et de ne pas vouloir créer de dépendances, je ne savais plus comment communiquer

Le faire en C (qui plus est façon objet, avec constructeurs, méthodes, destructeurs et membres) m'a tout simplement fait voir comment fallait s'y prendre en C++. Comme d'habitude, trop de prise de tête lors de ma première fois en C++, à vouloir trop faire bien au lieu d'avancer.

En deux jours, j'ai refait en C++ ce que j'ai mis beaucoup plus de temps à faire en C. Ca va vraiment plus vite, grâce entre autres aux classes de la STL (strings, conteneurs) et à tous vos conseils (dont ces putains d'exceptions, j'ai enfin trouvé la manière de les lancer puis quitter sans perdre des objets dans la nature, la communication façon Golden etc...).

Merci encore infiniment à tous.

(prochaine étape, refaire la lecture/écriture d'un fichier de manière portable, sans utiliser la libc, ça risque d'être rigolo

)

1665

Le 30/05/2010 à 01:19

My fucking god.

1666

Le 30/05/2010 à 01:44

Sasume (./1661) :
Ça ne correspond donc pas à ce que veut Martial.

Bah, AMHA on s'en fout si l'exception passée en haut est bad_alloc ou un const char *. (D'ailleurs, c'est très sale de transtyper un const char * en char *, le const est là pour une bonne raison!)

Mais s'il veut absolument convertir l'exception, il peut toujours imbriquer les try:

try {
  try {
    // le code
  } catch (...) { // oui, les ... tels quels! 
    SDL_FreeSurface (m_Background);  
    while (m_IconList.size () != 0) {  
      delete m_IconList.back ();  
      m_IconList.pop_back ();  
    }  
    throw; 
  }
} catch(std::bad_alloc) {
  throw "out of memory";
}

(Je me suis permis de reformater le code selon les conventions K&R, les accolades à la ligne, ça sux.

)

1667

Le 30/05/2010 à 01:53

(stoi qui sux...
c'est tres bien les accolades a la ligne)

HURRRR !

1668

Le 30/05/2010 à 02:16

Kevin Kofler (./1666) :
les accolades à la ligne, ça sux roxe

je tenais absolument à ce que tu le saches.

Kevin Kofler (./1666) :
(D'ailleurs, c'est très sale de transtyper un const char * en char *, le const est là pour une bonne raison!)

Propose un patch aux dev de la SDL pour que GetError() renvoie un const char*.

1669

Le 30/05/2010 à 05:45

Transtyper un char * en const char * est parfaitement sûr, c'est l'inverse qu'il ne faut surtout pas faire.

1670

Le 30/05/2010 à 10:10

Bon, alors faut que je caste mes GetError()...

Done, (const char*) SDL_GetError () + catch (const char* strError) partout, merci bien.

1671

Le 30/05/2010 à 11:28

Il me semble que dans ce sens là tu n’as même pas besoin de caster, si ?

« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

1672

Le 30/05/2010 à 11:45

Il me semble qu'un catch (const char*) intercepterait un throw (char*) si le gestionnaire d'exception ne trouve pas mieux comme correspondance de type. Je vais vérifier. Mais là au moins, je suis sûr de mes billes, tout simplement.

edit -> d'après mon bouquin, le const n'est visiblement pas pris en compte pour l'interception, ce qui veut dire qu'intercepter un char* ou un const char* est la même chose.

1673

Le 30/05/2010 à 19:48

Sûr? Pour un char * vs. char * const, je veux bien, mais char * et const char *, ce n'est pas la même chose! Ce ne sont pas juste des variantes const et non-const du même type, ce sont des types de pointeur différents. Indice: si ŧypedef char *T;, alors un const T est un char * const, pas un const char *.

1674

Le 30/05/2010 à 20:37

Je sais pas, mais essaye

1675

Le 02/06/2010 à 14:25

J'avais gardé un mauvais souvenir des stream, et en fait c'est beaucoup plus simple de les utiliser en C++ qu'en C. Etant donné qu'on peut choisir de lancer une exception en cas de mauvaise lecture/eof, ça devient vraiment tout bête. Et avec le code répétitif dans un constructeur, ça devient bcp plus clair.

lecture fichier

    ifstream file ("careers", fstream::in | fstream::binary);
    if (file.is_open ())
    {
        file.exceptions ( fstream::eofbit | fstream::failbit | fstream::badbit );
        try
        {
            file.read (tmp, 2);
            numCareers = (tmp [0] << 8) + tmp [1];
            if ((numCareers == 0) || (numCareers > 5))
                throw (strInvalidCareer);
            for (i = 0; i < numCareers; i++)
            {
                m_CareersList.push_back (new Career (&file));
            }
        }
        catch (ios_base::failure)
        {
            file.close();
            throw (strInvalidCareer);
        }
        catch (const char* strError)
        {
            file.close();
            throw strError;
        }

        file.close ();
    }
    else
    {
        cout << strNoCareers << endl;
    }

1676

Le 03/06/2010 à 11:35

J'ai à nouveau encore un problème de conception et de cast.

Le résumé de mes classes :
Task est un objet global.
Task contient une list de Module* et instancie des Module' dont le pointeur est enregistré dans la liste.
Les Module' contiennent une liste de Icon et instancient des Icon' dont les pointeurs sont enregistrés dans la liste.

Mon problème est de réussir à faire accéder mes Icon' au Module'.

Solution 1 :
Task a une méthode getCurrentModulePtr () qui renvoie un pointeur sur le dernier Module' de la liste (celui qui est courant). Mais le pointeur renvoyé est de type Module*, alors que j'ai besoin d'un Module'*.

=> Je ne sais pas faire faire à Task le cast de Module* en Module'*. Y a-t-il un moyen ?

Solution 2 :
Les Module' passent un 'this' aux Icon'. Je n'aime pas trop, je préfèrerais un accesseur au niveau de Task qui est global justement pour que tout le monde puisse y accéder.

N'y a-t-il que la solution 2 de réalisable ? Je préfèrerais implémenter la 1...

Note : les Classe' sont des dérivées de Classe.

1677

Le 03/06/2010 à 11:47

La solution 2 est la meilleure : le conteneur passe un pointeur vers lui au contenu quand celui-ci est ajouté
Mais avec ta solution 1, je ne vois pas trop à quel Module l'Icon veut accéder ? tu parles du courant, ce n'est pas celui qui est parent de l'Icon ?

enfin dans tous les cas, tu n'as pas à faire de cast. tu dois passer le pointeur vers le Module* parent dans le constructeur de Icon, et utiliser des méthodes virtuelles pour accéder aux fonctionnalités spécifiques des Module' sans avoir à les caster

1678

Le 03/06/2010 à 11:52

La question qui me vient à l'esprit est: « Pourquoi as-tu besoin de ce Module' ? »

Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

1679

Le 03/06/2010 à 12:01

aze (./1677) :
Mais avec ta solution 1, je ne vois pas trop à quel Module l'Icon veut accéder ? tu parles du courant, ce n'est pas celui qui est parent de l'Icon ?

Si.

Et ok pour la solution 2, je pensais que ce n'était pas très propre...

GoldenCrystal (./1678) :
La question qui me vient à l'esprit est: « Pourquoi as-tu besoin de ce Module' ? »

Un module représente une partie du jeu (un écran d'intro, de highscore, etc). Il contient tous les objets de l'interface (icones, listes, sprites) et lance les méthodes de gestion et d'interface de tous ces objets.

Module contient le seul élément commun à tout ça : le background, et une méthode virtuelle pure (manage()).
Les Module' implémentent tous le reste. Le polymorphisme me permet de gérer le chargement/déchargement des Modules à un seul endroit (c'est Task qui s'en occupe).

1680

Le 03/06/2010 à 13:27

aze (./1677) :
le conteneur passe un pointeur vers lui au contenu quand celui-ci est ajouté

C'est pas l'équivalent du pointeur 'parent' dans Qt ? Je crois qu'il y a ça dans un QOBJECT. C'est donc une pratique courante et recommandée qu'un objet qui en instancie d'autres passe un pointeur vers lui-même à ceux qu'il crée ? Par exemple, pour que les objets créés puissent communiquer entre eux ?