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

Compteur du TdCCT · Le 30/06/2011, à 07:42

Scores de la période en cours :

1) 266    Πυλάδης
2) 229    nesthib
3) 178    samuncle
4) 175    Кຼزດ
5) 158    cm-t
6) 101    na kraïou
7) 74    tshirtman
8) 70    nathéo
9) 38    grim7reaper
10) 37    The Uploader
11) 36    :!pakman
12) 21    Rolinh
13) 8    Kanor
14) 6    Le Rouge
15) 4    \\Ouranos//
15) 4    kamui57
15) 4    Pylade
18) 3    xapantu

Кຼزດ · Le 30/06/2011, à 08:49

grim7reaper a écrit :

Hello World!

Кຼزດ a écrit :
…
(et je trouve sale d’utiliser les paramètres une fois pour éviter les warnings , __UNUSED__ ftw)
, c'est sûr que ta solution non portable est propre…
Et puis c'est pas si moche que ça, vu qu'il met déjà (comme BSD) des (void) partout (pour montrer qu'il ignore consciemment le retour de certaines fonctions) ça ne jure pas avec le reste du code.
Sinon, quand t'auras une vraie solution propre ET portable tu pourras repasser et être constructif, en attendant « stop bullshit, thanks ».

Enlever -Wunused-parameter, vu qu’à chaque fois qu’on utilise une fonction d’API il faut le contourner… (ou ignorer le warning)

grim7reaper · Le 30/06/2011, à 08:56

Koin a écrit :

Enlever -Wunused-parameter

Ouais génial, comme ça quand t'as vraiment des paramètres inutilisés (introduit par inadvertance ou qui sont devenu inutilisé suite à une évolution du code) ça passe à la trappe.
C'est l'idée du siècle ça !

Koin a écrit :

vu qu’à chaque fois qu’on utilise une fonction d’API il faut le contourner…

Pas à chaque qu'on utilise une fonction de l'API, faut pas déconner non plus.
Mais à chaque que l'on utilise un callback où les paramètres sont inutiles, oui.

Edit : désolé pour le pseudo : Windows, IE, font en mousse, toussa...

Dernière modification par grim7reaper (Le 30/06/2011, à 09:09)

Pylades · Le 30/06/2011, à 12:24

grim7reaper a écrit :

Hello World!

Кຼزດ a écrit :
…
(et je trouve sale d’utiliser les paramètres une fois pour éviter les warnings , __UNUSED__ ftw)
, c'est sûr que ta solution non portable est propre…
Et puis c'est pas si moche que ça, vu qu'il met déjà (comme BSD) des (void) partout (pour montrer qu'il ignore consciemment le retour de certaines fonctions) ça ne jure pas avec le reste du code.
Sinon, quand t'auras une vraie solution propre ET portable tu pourras repasser et être constructif, en attendant « stop bullshit, thanks ».

Ben en fait c’est portable, pour ça tu définis une macro :

#ifndef __GNUC__
#define __attribute__ (attr)
#endif

Ce qui fait que quand tu ne compiles pas avec GCC, l’attribut est ignoré (faut voir alors si d’autres compilateurs ont des mécanismes de ce types, même si ça peut vite devenir très lourd) ; et quand tu compile avec GCC, il est content.
Après c’est sûr que si tu n’utilises pas à la base les attributs GCC pour des choses plus utiles, comme pour l’optimisation, l’intérêt de les introduire pour ça est assez limité…

grim7reaper · Le 30/06/2011, à 13:13

Youhou, et quand c'est pas GCC bah t'as les warning (ouais, y a pas que GCC qui signale ce genre de choses).
Je rappelle à toutes fins utiles que gcc c'est pas l'alpha et l'oméga des compilateurs
Super soluce (mais oui c'est portable, horriblement moche mais portable...)

Ou alors, comme tu le dis, on peut faire une série de #if #elif #else pour supporter tout les compilos du marché.
Bah vas-y, je te regarde ^^(surtout que c'est pas dit que les compilos supportent tous ce genre de truc).
Tu vas bien t'amuser à maintenir ça (déjà par le nombre de compilos, ensuite pas le fait des différentes versions desdits compilos).

L'intérêt des attributs GNU est de toutes manières limité car tu imposes le compilateur et ça, pour moi, ça ne justifie pas (sauf cas très particuliers) les apports de ces extensions.
Après il reste toujours la solution de faire un set de macro, inmaintenable et qui va pourrir ton code, pour être indépendant de gcc...
Après chacun son trip, perso je considère le C en lui-même comme suffisamment difficile sans se rajouter des boulets de ce genre.

En parlant des attributs GNU, il me semble qu'il y a un patch qui traine et dont l'effet est de virer ces merdes du noyau Linux afin de pouvoir le compiler avec icc.

Au moins ma solution (enfin "ma", c'est vite dit car c'est pas moi qui l'ai inventé), même si visuellement on à fait mieux c'est un fait (encore que, dans le code de Rolinh, ça passe très bien), à l'avantage d'être compatible avec tous les compilos qui respecte au moins le C89. Pas besoin d'extension de compilo, pas besoin de macros.
C'est KISS quoi.

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

Pylades · Le 30/06/2011, à 13:32

Je parle pas de spécificités GCC, je parle d’attributs. Quand il y a des attributs GCC, tu peux compiler avec Clang ou icc ; donc tu n’impose pas le compilateur. Ça permet juste aux devs de les utiliser pour les développement, après en release tu peux bien désactiver tout simplement les warnings ce n’est pas bien grave. Bon, là on peut simplement supprimer le warning de façon standard, donc si c’est juste pour ça l’intérêt est limité, mais ces attributs apportent aussi des trucs bien qui ne sont pas disponibles en standard. Et quand tu fais le choix de supporter GCC dans le makefile (même si la plupart du temps tu pourrais utiliser Clang à la place, ça ne changerait rien), bien pourquoi pas le supporter aussi dans les sources…

grim7reaper · Le 30/06/2011, à 13:53

Pylade a écrit :

Je parle pas de spécificités GCC, je parle d’attributs.

Oui, et ?
Ce sont des extensions du langages quand même. C'est pas défini dans la norme que je sache donc c'est compiler-dependant.

Pylade a écrit :

Quand il y a des attributs GCC, tu peux compiler avec Clang ou icc ; donc tu n’impose pas le compilateur.

clang supporte les attributs GCC car il a un mode de compatibilité GCC (c'est pour ça qu'il dépend encore de gcc, c'est d'ailleurs très moche).
Pour icc, c'est la même : Intel a écrit un wrapper pour icc (kicc) qui permet supporter les bidouilles de GCC (donc le patch dont je parlait est en fait obsolète).
Mais tu crois vraiment que tous compilos ont un mode de compat' GCC ? Tu rêves là...

Pylade a écrit :

Ça permet juste aux devs de les utiliser pour les développement, après en release tu peux bien désactiver tout simplement les warnings ce n’est pas bien grave.

Oui, tu peux désactiver les warnings si tu veux. Si le compilo supportent pas les attributs il compileras pas ton code donc t'auras même pas à te soucier des warnings
(sauf si tu subtitues tout les attributs grâce à un set de macro moches et inmaintenable).

Pylade a écrit :

mais ces attributs apportent aussi des trucs bien qui ne sont pas disponibles en standard.

C'est bien ça le problème !

Pylade a écrit :

Et quand tu fais le choix de supporter GCC dans le makefile (même si la plupart du temps tu pourrais utiliser Clang à la place, ça ne changerait rien), bien pourquoi pas le supporter aussi dans les sources…

Bah parce que si tu le supporte jusque dans les sources ton code sera plus compatible avec d'autres compilo.
Si encore y'avait un moyen propre et simple de les activer/désactiver (i.e, sans foutre des macros partout), mais c'est pas le cas.

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

Dr Le Rouge · Le 30/06/2011, à 14:25

Pour relancer un petit "PHP saymal" : un mail de la ML debian-security !

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -------------------------------------------------------------------------
Debian Security Advisory DSA-2266-1                   security@debian.org
[url]http://www.debian.org/security/[/url]                        XX un gus qui n'a peut-être pas envie de voir son nom ici XX
June 29, 2011                          [url]http://www.debian.org/security/faq[/url]
- -------------------------------------------------------------------------

Package        : php5
Vulnerability  : several
Problem type   : remote
Debian-specific: no
CVE ID         : CVE-2010-2531 CVE-2011-0420 CVE-2011-0421 CVE-2011-0708 
                 CVE-2011-1153 CVE-2011-1466 CVE-2011-1471 CVE-2011-2202 

Several vulnerabilities were discovered in PHP, which could lead to 
denial of service or potentially the execution of arbitrary code.

CVE-2010-2531

   An information leak was found in the var_export() function.

CVE-2011-0421

   The Zip module could crash.

CVE-2011-0708

   An integer overflow was discovered in the Exif module.

CVE-2011-1466

   An integer overflow was discovered in the Calendar module.

CVE-2011-1471

   The Zip module was prone to denial of service through malformed
   archives.

CVE-2011-2202

   Path names in form based file uploads (RFC 1867) were incorrectly 
   validated.

Problem PHP ?

edit : c'esy quand même vachement long, donc je remplace les "quote" par des "code".

Dernière modification par Dr Le Rouge (Le 30/06/2011, à 14:26)

grim7reaper · Le 30/06/2011, à 14:38

T'es un vrai trolleur PHP toi :]
Plus sérieusement, j'ai cru comprendre que dans tes études t'avais une composante info alors s'ils te font juste faire du PHP et du Java c'est que tu t'es fait entuber
Surtout que bon, PHP pour un matheux voilà quoi... Même Java c'est la panacée.

Dernière modification par grim7reaper (Le 30/06/2011, à 14:38)

Pylades · Le 30/06/2011, à 15:21

@ grim7reaper : mais justement, ça compile parfaitement avec les autres compilos. Et ce n’est pas un jeu de macros immaintenable, c’est juste une seule macro. Et puis ces attributs sont limités aux headers (enfin, moi personnellement je n’en mettrai que dans les headers), donc on ne peut pas dire que cela pourrisse la lecture du code plus que ça…

Dr Le Rouge · Le 30/06/2011, à 15:24

Nan mais là je suis en stage !

Dans la composante info obligatoire on fait du C++, un gloubiboulga HTML/CSS/PHP/MySQL (tout en même temps !), de l'UML et des trucs de culture générale (un cours sur les réseaux, un cours sur les SI des entreprises, etc.). Après, j'avais choisi des modules d'info (entre autres) : j'ai fait du C++ (algo théorique : backtrack, branch and bound et autres joyeusetés) et un autre sur la programmation logique (Prolog).

Avec mon CV blindé d'un point de vue info pour un centralien, j'ai été pris en stage dans le labo de maths info de l'école (de toute façon, le prof' qui avait vu ma soutenance du premier module me l'avait proposé ), c'est à ce moment là que je me suis mis au Java et au PHP

Il y a des cours avancés de Java en 3ème année, mais j'm'en fous j'serais au pays des prix Nobel ^^

The Uploader · Le 30/06/2011, à 15:42

http://www.railsbrain.com/api/rails-2.3 … select_tag
http://api.rubyonrails.org/classes/Acti … elper.html
http://railsforum.com/viewtopic.php?id=4986
http://shiningthrough.co.uk/Select-help … y-on-Rails
http://railsforum.com/viewtopic.php?id=34500

Fuck, depuis ce matin j'arrive pas à récupérer la valeur du select/select_tag/collection_select! >_<

J'ai des envies de meurtre!

Dernière modification par The Uploader (Le 30/06/2011, à 15:44)

tshirtman · Le 30/06/2011, à 15:48

t'as perdu ton rail-fu?

grim7reaper · Le 30/06/2011, à 15:49

Pylade a écrit :

@ grim7reaper : mais justement, ça compile parfaitement avec les autres compilos.

Non, stop les conneries là.
C'est pas standard, le support est au bon vouloir du développeur du compilateur.
Y'en a qui le supportent oui (certainement pas la majorité), mais dire que ça compile parfaitement avec les autres (vu que tu ne nommes pas de compilo, je suppose que tu veux dire "tous les compilos") c'est une connerie sans nom.

Pylade a écrit :

Et ce n’est pas un jeu de macros immaintenable, c’est juste une seule macro.

Oui en effet, j'était resté sur ton idée de supporter les attributs de divers compilo >_<"

Pylade a écrit :

Et puis ces attributs sont limités aux headers (enfin, moi personnellement je n’en mettrai que dans les headers), donc on ne peut pas dire que cela pourrisse la lecture du code plus que ça…

Bah d'autant plus. Les headers c'est le trucs que tu regardes le plus quand t'utilise un code (surtout quand c'est pas le tien). Tu vas voir le source quand t'as besoin de précision où que tu veux mettre les mains dans le camboui.
Bon après effectivement, vu que c'est qu'une macro la pollution visuelle est moins importante que ce je disais.
Cela dit, ça reste inélégant au possible et donc à n'utiliser que lorsque c'est justifié (et surtout si ça ne change pas le comportement du code !)

Le Rouge a écrit :

Nan mais là je suis en stage !

Je sais :]

Le Rouge a écrit :

Dans la composante info obligatoire on fait du C++, un gloubiboulga HTML/CSS/PHP/MySQL (tout en même temps !), de l'UML et des trucs de culture générale (un cours sur les réseaux, un cours sur les SI des entreprises, etc.). Après, j'avais choisi des modules d'info (entre autres) : j'ai fait du C++ (algo théorique : backtrack, branch and bound et autres joyeusetés) et un autre sur la programmation logique (Prolog).

Ha, c'est déjà mieux.
Même si je me demande ce que fiche le HTML/CSS/PHP/MySQL ici, ça peut toujours servir.
T'as pas de Fortran ?
C'est dommage (non sérieusement, c'est vrai qu'on l'utilise beaucoup moins mais y'a encore masse de code matheux qui tournent en Fortran donc c'est pas impossible que tu tombes dessus)

Le Rouge a écrit :

Avec mon CV blindé d'un point de vue info pour un centralien, j'ai été pris en stage dans le labo de maths info de l'école (de toute façon, le prof' qui avait vu ma soutenance du premier module me l'avait proposé ), c'est à ce moment là que je me suis mis au Java et au PHP

[troll]Chui pas sûr qu'en disant qu'ils font du Java et du PHP tu fasses une bonne pub au labo de maths info de ton école [/troll]

Dernière modification par grim7reaper (Le 30/06/2011, à 15:58)

The Uploader · Le 30/06/2011, à 15:51

tshirtman a écrit :

t'as perdu ton rail-fu?

Ouais, on dirait!

tshirtman · Le 30/06/2011, à 15:58

Ben je connais pas rail, hein, mais je pense que si tu cherches à faire un truc impossible à faire, c'est qu'il y doit y avoir un moyen plus éléguant (surtout pour un truc aussi con…)

The Uploader · Le 30/06/2011, à 16:01

Je crois que j'ai trouvé : suffit d'utiliser un remote_form_for et le form builder.... comme partout ailleurs dans mes formulaires!

A force de regarder le code parfois bizarre de Redmine (mais c'est la première fois qu'il ne serait pas à suivre!), on fait des conneries!

'fin c'est pas encore confirmé.. *croise les doigts*

Dernière modification par The Uploader (Le 30/06/2011, à 16:02)

Elzen · Le 30/06/2011, à 16:10

Hmm, j'viens de me rendre compte qu'il y avait une bêtise dans ma doc : je disais que le module wallman de Touhy ne dépendait de rien en particulier, en fait j'ai un import Xlib qui traîne, donc il y a quand même besoin du paquet python-xlib pour lui…

Ce qui est d'autant plus dommage que je ne m'en sers même pas vraiment, en fait, j'ai laissé ça depuis mes tentatives infructueuses de transmission de clic de la fenêtres du bureau à la fenêtre racine (confer ce sujet, c'était pour une option de Pylade-proofabilité).

D'ailleurs, à ce sujet, si quelqu'un avait une suggestion ou des infos, ça pourrait être sympa que j'arrive à gérer ça d'ici à la prochaine release…

The Uploader · Le 30/06/2011, à 16:30

C'ayez je récupère la valeur! \o/

Quel con je fais...

Bon ben maintenant j'ai presque fini la feature concernée (merci Rails, en PHP j'aurais pas fini ). \o/

Dernière modification par The Uploader (Le 30/06/2011, à 16:47)

Dr Le Rouge · Le 30/06/2011, à 16:39

@ grim : le Java c'est pour la portabilité sans s'embêter. L'usage de PHP aurait été limité au minimum syndical (affichage du header et du footer de pages web) si l'entreprise avec laquelle on bosse n'avait pas décidé de changer son API en cours de route (mais je crois avoir déjà évoqué cet « incident » ici ^^).

Sinon, pour le HTML/etc, c'est parce que la formation se veut (et est) généraliste : le but n'est pas qu'on soit bons en PHP mais qu'on sache un minimum ce que c'est histoire de pas se faire enfumer par un informaticien. Le Fortran est apparemment encore utilisé dans certains labos, mais j'en ai jamais vu à centrale (que ce soit en info ou en méca).

Pylades · Le 30/06/2011, à 16:45

grim7reaper a écrit :

Non, stop les conneries là.
C'est pas standard, le support est au bon vouloir du développeur du compilateur.
Y'en a qui le supportent oui (certainement pas la majorité), mais dire que ça compile parfaitement avec les autres (vu que tu ne nommes pas de compilo, je suppose que tu veux dire "tous les compilos") c'est une connerie sans nom.

Ben si puisque si tu compiles avec un autre compilo que GCC, tu définis une macro qui expand les attributs en… rien du tout. Donc l’autre compilo compile sans broncher.

grim7reaper a écrit :

Bon après effectivement, vu que c'est qu'une macro la pollution visuelle est moins importante que ce je disais.

Et voir un attribut après certains prototype, avec un nom explicite (comme noreturn, warn_unused_result, deprecated ou format), je trouve que c’est même plutôt utile pour comprendre le code.

grim7reaper a écrit :

Cela dit, ça reste inélégant au possible et donc à n'utiliser que lorsque c'est justifié (et surtout si ça ne change pas le comportement du code !)

Bien entendu que ces attributs ne changent pas le comportement du code ! Il servent juste à modifier les warnings émis par GCC et affiner les optimisations. Ce qui est quand même pas mal. Penses-tu que cela justifie leur emploi ?

(Enfin, certains attributs peuvent modifier le comportement du code, et pour moi ils sont à bannir. Mais ce n’est pas la majorité (en fait, je pense juste à alias).)

Dernière modification par Πυλάδης (Le 30/06/2011, à 16:49)

The Uploader · Le 30/06/2011, à 17:24

feature finie! \o/\o/\o/\o/\o/

grim7reaper · Le 30/06/2011, à 18:00

Πυλάδης a écrit :

grim7reaper a écrit :
Non, stop les conneries là.
C'est pas standard, le support est au bon vouloir du développeur du compilateur.
Y'en a qui le supportent oui (certainement pas la majorité), mais dire que ça compile parfaitement avec les autres (vu que tu ne nommes pas de compilo, je suppose que tu veux dire "tous les compilos") c'est une connerie sans nom.
Ben si puisque si tu compiles avec un autre compilo que GCC, tu définis une macro qui expand les attributs en… rien du tout. Donc l’autre compilo compile sans broncher.

Ok, tu parlais avec la macro. Dans ce cas oui.
Je pensais que tu parlais des attribute seuls.

Πυλάδης a écrit :

grim7reaper a écrit :
Bon après effectivement, vu que c'est qu'une macro la pollution visuelle est moins importante que ce je disais.
Et voir un attribut après certains prototype, avec un nom explicite (comme noreturn, warn_unused_result, deprecated ou format), je trouve que c’est même plutôt utile pour comprendre le code.

Si la syntaxe était vraiment comme ça, oui ça serait utile.
Sauf qu'en l'état actuel c'est plus un truc du genre

 __attribute__((noreturn))

donc oui, c'est de la pollution visuelle (dans le sens où ça « jure » avec le langage).

Πυλάδης a écrit :

grim7reaper a écrit :
Cela dit, ça reste inélégant au possible et donc à n'utiliser que lorsque c'est justifié (et surtout si ça ne change pas le comportement du code !)
Bien entendu que ces attributs ne changent pas le comportement du code !

Bah si, tu le dis toi‑même : certains le font.
Me contredire sur un point précis pour être d'accord 2 lignes plus bas sur ce même point c'est un peu inutile…

Πυλάδης a écrit :

Penses-tu que cela justifie leur emploi ?

Personnellement, non.
Mais ce n'est qu'un avis personnel.
Si je veux utilisé un C plus « puissant » je passe au C99 (ou bientôt au C1X), au moins c'est standard et bien intégré au langage.
Et si ça ne suffit toujours pas, je considère que j'ai choisi le mauvais langage et j'en change (je préfère faire ça plutôt que d'utiliser des bidouilles de compilateurs).

Pylades · Le 30/06/2011, à 18:31

grim7reaper a écrit :

Si la syntaxe était vraiment comme ça, oui ça serait utile.
Sauf qu'en l'état actuel c'est plus un truc du genre
 __attribute__((noreturn))
donc oui, c'est de la pollution visuelle (dans le sens où ça « jure » avec le langage).

Tu peux aussi juste mettre __noreturn__, mais le soucis c’est que ça ne se désactive pas
pour les autres compilos.
Donc à moins de faire une macro par attribut utilisé, on ne peut pas améliorer les choses.

grim7reaper a écrit :

Bah si, tu le dis toi‑même : certains le font.
Me contredire sur un point précis pour être d'accord 2 lignes plus bas sur ce même point c'est un peu inutile…

Oui, j’ai pensé à alias plus tard… Sans alias, le code ne compilerait pas.
Enfin, on peut quand même n’utiliser que les attributs sains.

grim7reaper a écrit :

Si je veux utilisé un C plus « puissant » je passe au C99 (ou bientôt au C1X), au moins c'est standard et bien intégré au langage.

Ouais mais non.
Dans le C99, il y a quelques de trucs que je n’aime pas, comme pouvoir déclarer un tableau de longueur variable (truc inutilement lourd à implémenter et qui jure avec le C, qui n’est quand même pas un langage de très haut niveau), ou pouvoir mélanger les déclarations et le code (ça rend le code moins structuré et facilite les erreurs). Je vois ça comme le C plus des fonctionnalités inutiles, donc ce n’est pas terrible. En revanche un C qui répare les erreurs du passé (supprimer ou corriger gets, éventuellement faire prendre le FILE* en premier à toutes les fonction d’IO, quitte à briser la compatibilité…) tout en ajoutant quelques trucs utiles (comme la possibilité de déclarer le compteur au moment de l’initialisation dans les boucles for), ça me plairait bien.

On peut même imaginer ajouter des qualifiers standard qui joueraient le rôle d’attributs, la décision de les traiter ou de les ignorer étant laissée à la discrétion du compilateur.

grim7reaper a écrit :

Et si ça ne suffit toujours pas, je considère que j'ai choisi le mauvais langage et j'en change (je préfère faire ça plutôt que d'utiliser des bidouilles de compilateurs).

Ce n’est pas pour pallier aux manques du langage, ces attributs servent juste à améliorer le déclenchement des warnings et les optimisations.
(OK, j’en vois un qui permet de définir un alias, d’ailleurs je ne comprends pas pourquoi ne pas utiliser le préprocesseur à la place, mais c’est tout.)

grim7reaper · Le 30/06/2011, à 18:56

Πυλάδης a écrit :

grim7reaper a écrit :
Si je veux utilisé un C plus « puissant » je passe au C99 (ou bientôt au C1X), au moins c'est standard et bien intégré au langage.
Ouais mais non.
Dans le C99, il y a quelques de trucs que je n’aime pas, comme pouvoir déclarer un tableau de longueur variable (truc inutilement lourd à implémenter et qui jure avec le C, qui n’est quand même pas un langage de très haut niveau)

Perso ça me choque pas, je trouve juste ça gadget (et plutôt inutile) donc je ne l'utiliserais pas mais bon…

Πυλάδης a écrit :

ou pouvoir mélanger les déclarations et le code (ça rend le code moins structuré et facilite les erreurs).

Quasiment tout les langages permettent ça.
Et puis, c'est pas parce que tu peux le faire que tu dois le faire.

Πυλάδης a écrit :

Je vois ça comme le C plus des fonctionnalités inutiles, donc ce n’est pas terrible.

Faut pas jeter le bébé avec l'eau du bain.
Y a des trucs bien comme le type bool, le mot‑clef inline, les commentaires // (ça existait quand même dans BCPL, l'ancêtre du C…), améliorations du support des flottants (plus conforme à IEEE) et le qualificateur restrict.

Et le C1X me semble encore plus alléchant : support du multithreading, amélioration du support de l'Unicode, suppression de gets justement , _Noreturn est intégré (ainsi que des qualificateurs d'alignements).

Πυλάδης a écrit :

grim7reaper a écrit :
Et si ça ne suffit toujours pas, je considère que j'ai choisi le mauvais langage et j'en change (je préfère faire ça plutôt que d'utiliser des bidouilles de compilateurs).
Ce n’est pas pour pallier aux manques du langage, ces attributs servent juste à améliorer le déclenchement des warnings et les optimisations.

Bah c'est bien des manques du langage quand même (la preuve, certains sont intégré en C99 et en C1X).

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#651 Le 30/06/2011, à 07:42

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

#652 Le 30/06/2011, à 08:49

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

#653 Le 30/06/2011, à 08:56

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

#654 Le 30/06/2011, à 12:24

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

#655 Le 30/06/2011, à 13:13

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

#656 Le 30/06/2011, à 13:32

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

#657 Le 30/06/2011, à 13:53

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

#658 Le 30/06/2011, à 14:25

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

#659 Le 30/06/2011, à 14:38

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

#660 Le 30/06/2011, à 15:21

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

#661 Le 30/06/2011, à 15:24

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

#662 Le 30/06/2011, à 15:42

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

#663 Le 30/06/2011, à 15:48

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

#664 Le 30/06/2011, à 15:49

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

#665 Le 30/06/2011, à 15:51

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

#666 Le 30/06/2011, à 15:58

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

#667 Le 30/06/2011, à 16:01

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

#668 Le 30/06/2011, à 16:10

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

#669 Le 30/06/2011, à 16:30

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

#670 Le 30/06/2011, à 16:39

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

#671 Le 30/06/2011, à 16:45

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

#672 Le 30/06/2011, à 17:24

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

#673 Le 30/06/2011, à 18:00

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

#674 Le 30/06/2011, à 18:31

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

#675 Le 30/06/2011, à 18:56

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

Pied de page des forums