/* Topic des codeurs [8] */

grim7reaper · Le 03/04/2013, à 14:41

Titus007 a écrit :

grim7reaper a écrit :
Edit : aller hop, un lien vers celle 2011 (j’ai aussi là 2012 sous le coude, mais à priori pas de différence).
Tiens, il me semble que quand tu avais mis le lien vers le brouillon de la norme C, pour mon info, elle tenait en plus de 15 pages…

Oui, c’est sûr que la norme du C fait plus de 15 pages (bon ce n’est pas la norme du C++ non plus ).
Là j’ai donné le lien vers la norme Epitech.
La norme C (enfin le dernier brouillon) elle est là.

Dernière modification par grim7reaper (Le 03/04/2013, à 14:41)

Titus007 · Le 03/04/2013, à 14:48

En fait, mon propos était plutôt un petit euphémisme pour signaler que la norme Epitech avait sacrément synthétisé la norme C…

(Dans mon idée, une école qui apprendrait à coder du C devrait logiquement reprendre les principales lignes directrices de la norme, au minimum.)

Elzen · Le 03/04/2013, à 14:59

Pour le « pas considéré comme un mot-clef », je pense que c'est pour répondre à la remarque précédente qui dit qu'il doit forcément y avoir une espace (ils ont mis espace au masculin, d'ailleurs, ces noobs) entre un mot-clef et la parenthèse qui suit ; ç'juste une façon super maladroite de dire qu'ils veulent qu'on écrive « sizeof(machin) » plutôt que « sizeof (machin) ».

Mais bon, pour un truc qui se prétend pédagogique, dire ça comme ça, ça fait peur… et le reste de ce torchon (je pèse mes mots. Et je suis très méchant envers les torchons, là) ne vaut pas mieux.

grim7reaper · Le 03/04/2013, à 15:07

Bon, faut quand même être honnête et reconnaître qu’ils se sont améliorés.
Dans l’ancienne, il y a quand même des perles du genre :

L’ancienne norme a écrit :

[…]
On évitera aussi d'avoir plus de 5 fonctions par fichier, une serait l'idéal.
[…]
Il faut mettre le moins de fonctions possible par fichier (idéalement une seule fonction par fichier .c)
[…]

Bah voyons
Une fonction par fichier (idéalement, oui j’ai lu que ce n’est pas obligatoire mais c’est quand même recommandé), allons y gaiement…

L’ancienne norme a écrit :

[…]
(La fonction qui possédera au maximum 4 paramètres aura une vitesse exécution plus rapide que celle qui en passera plus).
[…]

Vous reprendrez bien d’un peu de vérité générale qui est en fait tout sauf générale (dépendant de l’architecture).
Et puis franchement, même sur les archi’ où cela est vrai, à moins que ta fonction prenne 147 paramètres (oui, ça sent le vécu ) je suis quasi sûr que le temps passé à dépiler les arguments est négligeable dans 98,42% des cas.

[…]
Certaines fonctions de la bibliothèque C peuvent retourner une valeur particulière lorsqu'elles échouent. Le code principal ne doit pas être pollué par le traitement de ces valeurs exceptionnelles, aussi faut-il introduire des versions de ces fonctions qui traitent les erreurs elles-mêmes par un appel à exit.
[…]

Je ne sais pas pour vous, mais pour moi quitter le programme comme un gros bourrin à coup d’exit je n’appelle pas ça « traiter les erreurs ».
Parce que avec exit il n’y a pas de libération de la mémoire (entre autre).
Oui, je sais que les OS modernes (Linux, Mac, Windows et sûrement BSD) passe derrière pour nettoyer, mais c’est pas le rôle de l’OS (et tous ne le font pas) de nettoyer la merde que le boulet de développeur a laissé derrière lui.
Et à côté de ça, ils interdisent goto dont l’un des seuls usages propres c’est justement de faire du traitement d‘erreurs (local certes) sans polluer le code principal…
Logique où es tu ?

Au moins, la nouvelle version de leur norme ne contient plus ces choses-là.
Mais bon, c’est encore très loin d’être une bonne norme à suivre.

Dernière modification par grim7reaper (Le 03/04/2013, à 15:10)

nathéo · Le 03/04/2013, à 15:39

Au moins j'apprends pas mal de choses intéressantes sur le C.

sweetly · Le 03/04/2013, à 16:48

nathéo a écrit :

Au moins j'apprends pas mal de choses intéressantes sur le C.

C'est dommage que tu n'aies pas payé 7500€ pour ça.

nathéo · Le 03/04/2013, à 16:56

Franchement, j'en ai un peu marre de ce genre de commentaire.

Shanx · Le 03/04/2013, à 17:03

Ne t’inquiète pas…

The Uploader · Le 03/04/2013, à 17:29

grim7reaper a écrit :

Oui, je sais que les OS modernes (Linux, Mac, Windows et sûrement BSD) passe derrière pour nettoyer, mais c’est pas le rôle de l’OS (et tous ne le font pas) de nettoyer la merde que le boulet de développeur a laissé derrière lui.

Pas sûr que un OS sans protection mémoire (AmigaOS 3.X, Windows 9X, ...) l'OS fasse ce genre de nettoyage, par exemple.

grim7reaper a écrit :

Et à côté de ça, ils interdisent goto dont l’un des seuls usages propres c’est justement de faire du traitement d‘erreurs (local certes) sans polluer le code principal…
Logique où es tu ?

Pas là

grim7reaper a écrit :

Au moins, la nouvelle version de leur norme ne contient plus ces choses-là.
Mais bon, c’est encore très loin d’être une bonne norme à suivre.

Le seul usage normal de cette norme, c'est de l'imprimer pour se torcher avec.

nathéo a écrit :

Au moins j'apprends pas mal de choses intéressantes sur le C.

Le C est passionnant, au contraire de l'Epic Fail Tech.

Pylades · Le 03/04/2013, à 21:18

The Uploader a écrit :

size_of n'est pas un mot clé

sizeof, s’il te plaît, là ça pique les yeux. ><"

The Uploader · Le 03/04/2013, à 21:40

Oups! Corrigé.

Shanx · Le 03/04/2013, à 22:10

nathéo a écrit :

Franchement, j'en ai un peu marre de ce genre de commentaire.

Voilà…

Pylades · Le 03/04/2013, à 22:53

Ah, évidemment. On n’a plus le droit de rien critiquer, aujourd’hui.

:!pakman · Le 03/04/2013, à 23:17

Shanx a écrit :

nathéo a écrit :
Franchement, j'en ai un peu marre de ce genre de commentaire.
Voilà…

Incroyable

grim7reaper · Le 04/04/2013, à 03:34

Ha ouais, quand même…
Epitech va devenir le PC SOFT des écoles.
Pour rappel, critiquer ou dire du mal de PC SOFT ou d’un de ses produits (genre Windev…) est souvent synonyme de procès dans ta gueule. En même temps, quand on n’a rien d’autre que son image, on peut comprendre qu'il faille la défendre.

Bon après, je trouve ça franchement naze (pas la réaction des admin/modo qui, elle, est compréhensible) car maintenant il suffit d’envoyer un petit email au forum pour dire ça c’est de la diffamation, et hop c’est censuré (car les forums veulent rarement, et c’est plutôt compréhensible, se lancer dans un procès pour prouver que l’utilisateur est dans son bon droit). Super pratique comme truc pour contrôler à moindre frais ce qui se dit sur toi…

Tiens, faudrait peut-être faire des sauvegardes des dernières pages de ce topic, au cas où les admin’ recevrait encore un email…

Dernière modification par grim7reaper (Le 04/04/2013, à 03:36)

The Uploader · Le 04/04/2013, à 16:23

La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert

A lire pour ceux qui aiment :
- le Web
- les jeux vidéo
- les langages
- les optimisations
-etc...

:!pakman · Le 04/04/2013, à 16:27

The Uploader a écrit :

La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert
A lire pour ceux qui aiment :
- le Web
- les jeux vidéo
- les langages
- les optimisations
-etc...

Thx

Mindiell · Le 05/04/2013, à 05:57

moi-même a écrit :

Le veau n'est pas frais.
Contrepètrie de programmeur trouvée sous ma douche à l'instant, sous licence CC0

(et page 42 en plus )

Rolinh · Le 08/04/2013, à 12:21

Hy: Lisp en Python (comprendre: une variante de Lisp qui génère du code Python AST)

(import requests)
 
(setv req (requests.get "http://hy.pault.ag"))
(if (= req.status_code 200)
  (for (kv (.iteritems req.headers))
    (print kv))
  (throw (Exception "Wrong status code")))

C'est testable ici.

Heu... Marrant mais j'ai vraiment du mal à saisir l'intérêt... L'un de vous en voit-il un?

Rolinh · Le 08/04/2013, à 12:39

@grim: le coup du

add_definitions(-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64)

fonctionne pour la personne qui m'avait rapporté le bug de dfc qui échoue sur des systèmes 32-bits avec volume de +4To. Du coup, la question que je me pose est est-ce que cela est suffisamment propre ou faudrait que je teste dans le CMakelist.txt si on est dans un système 64-bit ou non (comment d'ailleurs?) et le définir seulement dans ce cas là? C'est surtout le _FILE_OFFSET_BITS=64 qui me dérange de setter comme ça à l'arrache.

EDIT: sorry pour le double-post

Dernière modification par Rolinh (Le 08/04/2013, à 12:39)

grim7reaper · Le 08/04/2013, à 13:04

Rolinh a écrit :

@grim: le coup du
add_definitions(-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64)
fonctionne pour la personne qui m'avait rapporté le bug de dfc qui échoue sur des systèmes 32-bits avec volume de +4To.

Ok, cool

Rolinh a écrit :

Du coup, la question que je me pose est est-ce que cela est suffisamment propre ou faudrait que je teste dans le CMakelist.txt si on est dans un système 64-bit ou non (comment d'ailleurs?) et le définir seulement dans ce cas là?

Tu pourrais tester ouais, mais je ne suis pas sûr que le jeu en vaille la chandelle.
D’une part, parce qu’il semblerait que si tu compiles pour du 64-bit ça ne change rien :

http://users.suse.com/~aj/linux_lfs.html a écrit :

64 bit systems like Alpha, IA64 and x86-64 don't have problems with large files but do support the new interfaces also. In this case the new interface is mainly an alias to the normal interface.

D’autre part parce que ce n’est pas si simple à tester correctement (cas de la cross-compilation => architecture du système hôte différente de l’architecture du système cible).
Après, tu peux faire une solution un peu plus manuelle, mais plus sûr (même en cas de compilation croisée) : ajouter un flag ENABLE_LFS (tout comme tu as un flag ENABLE_NLS).

Rolinh a écrit :

C'est surtout le _FILE_OFFSET_BITS=64 qui me dérange de setter comme ça à l'arrache.

C’est-à-dire ?

Dernière modification par grim7reaper (Le 08/04/2013, à 13:06)

Rolinh · Le 08/04/2013, à 13:26

grim7reaper a écrit :

Après, tu peux faire une solution un peu plus manuelle, mais plus sûr (même en cas de compilation croisée) : ajouter un flag ENABLE_LFS (tout comme tu as un flag ENABLE_NLS).

Ah ouais, très bonne idée. Je vais faire comme ça tiens.

grim7reaper a écrit :

C’est-à-dire ?

Je sais pas trop, ça me semblait un peu bourrin.

EDIT: bah voilà, dfc 3.0.2 est de sortie.

Dernière modification par Rolinh (Le 08/04/2013, à 14:33)

Epehj · Le 08/04/2013, à 15:21

Salut les dev',

J'ai une question, mais je trouve pas la réponse.

Dans un code que je lis, un des dev' fait toujours ça :

bool bLoadOk = deviceSync.loadFile(strFile, iFileType);
	if (bLoadOk==false)
	{
         blablabla
	}
    else …

Est ce qu'il y a un intérêt à faire ça plutôt que if(!bLoadOk) ?
Si vous avez une opinion, je prends.

-- Edit
Ah pardon, c'est du C++.

Dernière modification par Epehj (Le 08/04/2013, à 15:33)

Pylades · Le 08/04/2013, à 15:24

Euh… c’est quel langage ?

Rolinh · Le 08/04/2013, à 15:43

Bah a priori aucun... c'est juste un peu moche.

D'ailleurs, je trouverais quand même plus logique de faire un

if (bLoadOk) {
    // traitement quand vrai
} else {
    // traitement quand faux
}

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1026 Le 03/04/2013, à 14:41

Re : /* Topic des codeurs [8] */

#1027 Le 03/04/2013, à 14:48

Re : /* Topic des codeurs [8] */

#1028 Le 03/04/2013, à 14:59

Re : /* Topic des codeurs [8] */

#1029 Le 03/04/2013, à 15:07

Re : /* Topic des codeurs [8] */

#1030 Le 03/04/2013, à 15:39

Re : /* Topic des codeurs [8] */

#1031 Le 03/04/2013, à 16:48

Re : /* Topic des codeurs [8] */

#1032 Le 03/04/2013, à 16:56

Re : /* Topic des codeurs [8] */

#1033 Le 03/04/2013, à 17:03

Re : /* Topic des codeurs [8] */

#1034 Le 03/04/2013, à 17:29

Re : /* Topic des codeurs [8] */

#1035 Le 03/04/2013, à 21:18

Re : /* Topic des codeurs [8] */

#1036 Le 03/04/2013, à 21:40

Re : /* Topic des codeurs [8] */

#1037 Le 03/04/2013, à 22:10

Re : /* Topic des codeurs [8] */

#1038 Le 03/04/2013, à 22:53

Re : /* Topic des codeurs [8] */

#1039 Le 03/04/2013, à 23:17

Re : /* Topic des codeurs [8] */

#1040 Le 04/04/2013, à 03:34

Re : /* Topic des codeurs [8] */

#1041 Le 04/04/2013, à 16:23

Re : /* Topic des codeurs [8] */

#1042 Le 04/04/2013, à 16:27

Re : /* Topic des codeurs [8] */

#1043 Le 05/04/2013, à 05:57

Re : /* Topic des codeurs [8] */

#1044 Le 08/04/2013, à 12:21

Re : /* Topic des codeurs [8] */

#1045 Le 08/04/2013, à 12:39

Re : /* Topic des codeurs [8] */

#1046 Le 08/04/2013, à 13:04

Re : /* Topic des codeurs [8] */

#1047 Le 08/04/2013, à 13:26

Re : /* Topic des codeurs [8] */

#1048 Le 08/04/2013, à 15:21

Re : /* Topic des codeurs [8] */

#1049 Le 08/04/2013, à 15:24

Re : /* Topic des codeurs [8] */

#1050 Le 08/04/2013, à 15:43

Re : /* Topic des codeurs [8] */

Pied de page des forums