/* Topic des codeurs couche-tard [3] */

xapantu · Le 30/01/2011, à 20:10

Pylade a écrit :

Le premier warning est un bug de GCC (le voilà, ArkSeth)

Tu es sûr ? Tu as un lien vers le rapport de bug ?

Pylades · Le 30/01/2011, à 20:13

Je ne sais pas s'il y a déjà un rapport de bug pour ça, mais c'est sûr que c'est un bug. Il y en a un autre aussi, avec -Wfloat-equal…

xapantu · Le 30/01/2011, à 20:15

Mais comment tu es sûr ? Enfin, je veux dire, c'est connu que gcc a des bugs comme ça ? (ça m'étonne vu que j'avais jamais vu ça)

Pylades · Le 30/01/2011, à 20:23

Ben, dans les deux cas, ce sont des warnings complétement non-appropriés, dus à l'absence d'une vérification supplémentaire (vérifier qu'il y a bien un opérateur logique dans le premier cas, et vérifier qu'on ne teste pas INFINITY, NAN, HUGE_VAL, HUGE_VALF ou HUGE_VALL dans le second cas).

Ce sont donc des bugs.

Dernière modification par Pylade (Le 30/01/2011, à 20:23)

xapantu · Le 30/01/2011, à 20:26

Mouais. Je suis pas franchement convaincu. gcc te suggère de mettre des parenthèses, même si ça ne change rien, à mon avis… il faut mieux les mettre. Mais c'est sûr que la lisibilité en prend un coup.

Dernière modification par xapantu (Le 30/01/2011, à 20:26)

xapantu · Le 30/01/2011, à 20:39

Et pour aller jusqu'au bout de ma pensée, le bug que tu aurais découvert se produirais dans ce cas if(truc = machin()), c'est ça ? Sauf que ça ne doit pas être un truc hyper rare dans le codage en C, alors ça m'étonnerais que les devs de gcc, qui ne sont pas les plus inexpérimentés aient "oublié" ce cas là.

Pylades · Le 30/01/2011, à 20:43

Ben pourtant… tu peux le constater toi-même…

xapantu · Le 30/01/2011, à 20:46

Peut-être simplement parce qu'à partir du moment où tu compile avec des flags très stricts, gcc s'attend à que ton code soit très strict ?

Dernière modification par xapantu (Le 30/01/2011, à 20:49)

Pylades · Le 30/01/2011, à 20:56

Mais cette partie du code est strictement correcte !
En plus, ce warning fait partie du groupe activé par -Wall, le groupe le moins strict…

Dernière modification par Pylade (Le 30/01/2011, à 20:56)

grim7reaper · Le 30/01/2011, à 22:11

:!pakman a écrit :

Hey les codeurs
Vous connaitriez pas une bonne bibliothèque de gestion du son sous licence libre ?
fmod n'est pas libre il me semble, gratuite seulement...
Et d'après le sdz, la librairie SDL_audio n'est pas top
J'aimerais que mon pakman ne dépende d'aucune lib propriétaire

SDL_audio n'est pas mal (après ça dépend ce que tu veux faire, mais je pense que tu peux tenter).

Кຼزດ a écrit :

:!pakman a écrit :
Hey les codeurs
Vous connaitriez pas une bonne bibliothèque de gestion du son sous licence libre ?
fmod n'est pas libre il me semble, gratuite seulement...
Et d'après le sdz, la librairie SDL_audio n'est pas top
J'aimerais que mon pakman ne dépende d'aucune lib propriétaire
La sfml permet de gérer le son.

À ce compte-là autant laisser tomber la SDL (sfml fait tout ce que fait la SDL avec ses extensions).
Le truc c'est que la sfml c'est plutôt du C++ (je crois qu'il y a bien un binding pour le C mais je ne sais pas ce qu'il vaut).

Pylade a écrit :

Mais cette partie du code est strictement correcte !
En plus, ce warning fait partie du groupe activé par -Wall, le groupe le moins strict…

gcc ne dit pas le contraire, il signale une ambiguïté pas une erreur.
Libre à toi de la lever ou pas.

Dernière modification par grim7reaper (Le 30/01/2011, à 22:13)

Кຼزດ · Le 30/01/2011, à 22:43

grim7reaper a écrit :

Кຼزດ a écrit :
:!pakman a écrit :
Hey les codeurs
Vous connaitriez pas une bonne bibliothèque de gestion du son sous licence libre ?
fmod n'est pas libre il me semble, gratuite seulement...
Et d'après le sdz, la librairie SDL_audio n'est pas top
J'aimerais que mon pakman ne dépende d'aucune lib propriétaire
La sfml permet de gérer le son.
À ce compte-là autant laisser tomber la SDL (sfml fait tout ce que fait la SDL avec ses extensions).
Le truc c'est que la sfml c'est plutôt du C++ (je crois qu'il y a bien un binding pour le C mais je ne sais pas ce qu'il vaut).

En effet .
La SFML, est, dans une énorme majorité de cas, plus rapide et plus simple que la SDL à utiliser.

The Uploader · Le 30/01/2011, à 22:49

je note : SFML PWN SDL.

want!

DOSBox devrait passer à la SFML alors!
A moins que la SDL soit meilleure pour un émulateur..

grim7reaper · Le 30/01/2011, à 22:53

Кຼزດ a écrit :

En effet .
La SFML, est, dans une énorme majorité de cas, plus rapide et plus simple que la SDL à utiliser.

Exact (quoique que plus rapide que la SDL de base, mais c'est kif-kif avec le couple SDL/OpenGL).
Mais quid du binding C ?
Il est bien lui aussi (:!pakman code en C) ?

gnuuat · Le 31/01/2011, à 00:33

Termcaps ?
Il parait que c'est super portable... *sifflote*

grim7reaper · Le 31/01/2011, à 00:40

HS.
Il demande une bibliothèque pour gérer de l'audio.

Pylades · Le 31/01/2011, à 00:49

grim7reaper a écrit :

[…]
Pylade a écrit :
Mais cette partie du code est strictement correcte !
En plus, ce warning fait partie du groupe activé par -Wall, le groupe le moins strict…
gcc ne dit pas le contraire, il signale une ambiguïté pas une erreur.
Libre à toi de la lever ou pas.

Oui mais là ce n'est pas ambigu du tout, puisque je n'ai pas d'opérateur logique…
Un bug, je vous dis !

Dernière modification par Pylade (Le 31/01/2011, à 00:49)

grim7reaper · Le 31/01/2011, à 00:55

Non, car ce warning ne porte pas que sur les opérateur logiques.

man gcc a écrit :

Warn if parentheses are omitted in certain contexts, such as when there is an assignment in a context where a truth value is expected, or when operators are nested whose precedence people often get confused about.
Also warn if a comparison like x<=y<=z appears; this is equivalent to (x<=y ? 1 : 0) <= z, which is a different interpretation from that of ordinary mathematical notation.
Also warn about constructions where there may be confusion to which "if" statement an "else" branch belongs. Here is an example of such a case:
{
if (a)
if (b)
foo ();
else
bar ();
}
In C/C++, every "else" branch belongs to the innermost possible "if" statement, which in this example is "if (b)". This is often not what the programmer expected, as illustrated in the above example by indentation the programmer chose. When there is the potential for this confusion, GCC will issue a warning when this flag is specified. To eliminate the warning, add explicit braces around the innermost "if" statement so there is no way the "else" could belong to the enclosing "if". The resulting code would look like this:
{
if (a)
{
if (b)
foo ();
else
bar ();
}
}
This warning is enabled by -Wall.

Dernière modification par grim7reaper (Le 31/01/2011, à 00:57)

Pylades · Le 31/01/2011, à 01:24

D'accord, mais si une telle construction est dépourvue d'ambiguïté (ce qui se produit lorsqu'aucun (comment ça, cette locution n'existe pas ? Merci de m'éclairer…) opérateur logique n'est utilisé), alors je ne vois pas ce qui justifie le warning. Et puis, les constructions du style ((…)), ce n'est pas joli, même si ça évite un warning.

Dernière modification par Pylade (Le 31/01/2011, à 01:24)

Кຼزດ · Le 31/01/2011, à 01:26

Bon allez, zou…

grim7reaper · Le 31/01/2011, à 01:38

Pylade a écrit :

D'accord, mais si une telle construction est dépourvue d'ambiguïté

Ce qui n'est pas la cas de la tienne.
On pourrait croire à une faute de frappe (un = au lieu d'un ==). Bien sûr qu'ici il est évident que tu ne testes pas l'adresse de la fonction car base est déclaré deux lignes avant et on voit bien que son type est magic_t.
Mais ça gcc n'est pas censé le savoir, un test comme ça sorti de son contexte n'est pas clair (base pourrait être déclarer bien avant et donc rendre ta condition bien moins explicite) donc il t'avertit.
Ça ne me choque pas.

Pylade a écrit :

Et puis, les constructions du style ((…)), ce n'est pas joli, même si ça évite un warning.

Oui ce n'est pas super élégant, mais il faut savoir ce que l'on veut (0 warning ou pas).
Perso je trouve moche de faire des affectations dans les conditions, je préfère bien séparer les deux actions => affectation puis test (du coup la question de l'élégance ne se pose pas vu que je n'ai pas de warning ).

Dernière modification par grim7reaper (Le 31/01/2011, à 03:29)

helly · Le 31/01/2011, à 02:08

Кຼزດ a écrit :

Bon allez, zou…

samυncle · Le 31/01/2011, à 02:35

samυncle · Le 31/01/2011, à 03:05

.

cm-t · Le 31/01/2011, à 03:27

'Nuit;

nesthib · Le 31/01/2011, à 03:42

plop

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1651 Le 30/01/2011, à 20:10

Re : /* Topic des codeurs couche-tard [3] */

#1652 Le 30/01/2011, à 20:13

Re : /* Topic des codeurs couche-tard [3] */

#1653 Le 30/01/2011, à 20:15

Re : /* Topic des codeurs couche-tard [3] */

#1654 Le 30/01/2011, à 20:23

Re : /* Topic des codeurs couche-tard [3] */

#1655 Le 30/01/2011, à 20:26

Re : /* Topic des codeurs couche-tard [3] */

#1656 Le 30/01/2011, à 20:39

Re : /* Topic des codeurs couche-tard [3] */

#1657 Le 30/01/2011, à 20:43

Re : /* Topic des codeurs couche-tard [3] */

#1658 Le 30/01/2011, à 20:46

Re : /* Topic des codeurs couche-tard [3] */

#1659 Le 30/01/2011, à 20:56

Re : /* Topic des codeurs couche-tard [3] */

#1660 Le 30/01/2011, à 22:11

Re : /* Topic des codeurs couche-tard [3] */

#1661 Le 30/01/2011, à 22:43

Re : /* Topic des codeurs couche-tard [3] */

#1662 Le 30/01/2011, à 22:49

Re : /* Topic des codeurs couche-tard [3] */

#1663 Le 30/01/2011, à 22:53

Re : /* Topic des codeurs couche-tard [3] */

#1664 Le 31/01/2011, à 00:33

Re : /* Topic des codeurs couche-tard [3] */

#1665 Le 31/01/2011, à 00:40

Re : /* Topic des codeurs couche-tard [3] */

#1666 Le 31/01/2011, à 00:49

Re : /* Topic des codeurs couche-tard [3] */

#1667 Le 31/01/2011, à 00:55

Re : /* Topic des codeurs couche-tard [3] */

#1668 Le 31/01/2011, à 01:24

Re : /* Topic des codeurs couche-tard [3] */

#1669 Le 31/01/2011, à 01:26

Re : /* Topic des codeurs couche-tard [3] */

#1670 Le 31/01/2011, à 01:38

Re : /* Topic des codeurs couche-tard [3] */

#1671 Le 31/01/2011, à 02:08

Re : /* Topic des codeurs couche-tard [3] */

#1672 Le 31/01/2011, à 02:35

Re : /* Topic des codeurs couche-tard [3] */

#1673 Le 31/01/2011, à 03:05

Re : /* Topic des codeurs couche-tard [3] */

#1674 Le 31/01/2011, à 03:27

Re : /* Topic des codeurs couche-tard [3] */

#1675 Le 31/01/2011, à 03:42

Re : /* Topic des codeurs couche-tard [3] */

Pied de page des forums