Le topic de la programmation: Et envoyez des sioux!

[BentheXIII]

Des gens ont essayé d'installer gcc 7.3 (tout frais d'il y a 4 jours) via Homebrew et de compiler un programme utilisant openMP avec? J'ai ces erreurs qui sortent de nulle part à l'exécution d'une boucle précédée par #pragma omp parallel for (sur un système faisant tourner MacOS 10.13.2) :

dyld: lazy symbol binding failed: Symbol not found: ___emutls_get_address
  Referenced from: /usr/local/opt/gcc/lib/gcc/7/libgomp.1.dylib (which was built for Mac OS X 10.13)
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: ___emutls_get_address
  Referenced from: /usr/local/opt/gcc/lib/gcc/7/libgomp.1.dylib (which was built for Mac OS X 10.13)
  Expected in: /usr/lib/libSystem.B.dylib

[Mayalabielle]

Par curiosité vous travaillez avec quels langages et dans quels domaines ?

Python && Golang dans l'infogérence, hébergement (Devopseries), côté perso, plutôt du fonctionnel (Haskell, Elixir/Erlang)

[Nattefrost]

Au boulot Python et shell (bash) principalement, chez un éditeur logiciel. Côté perso python, perl6 (j'aime faire n'importe quoi) et toujours shell (tcsh en ce moment).
Pour revenir à la discussion sur les conventions, ce qui est pratique avec python c'est que le styleguide est énoncé par python.org lui-même. Après libre à chaque projet de s'en éloigner mais au moins ça fait office de "default". Et tous les linters python (pylama, pylint) dans leur config par défaut prennent en compte ce styleguide.
J'imagine que certains vont trouver ça d'un fascisme intolérable mais en pratique c'est une bonne chose : pas besoin de chier un papier qui énonce nos conventions et des outils existants le prennent déjà en compte, y a qu'à les installer.

Y a encore quelques mois on n'utilisait pas de linter, on avait par endroits des inconsistances dans le nommage et autres saletés. Depuis qu'on a rendu obligatoire le linter on a un code beaucoup plus homogène. Pour l'ancien code on repasse dessus petit à petit, ça va être long mais on devrait y arriver.

[rOut]

C'est pas ce que dit mon cerveau rOut.
Il dit qu'il faut que tout le monde se mette d'accord et après on peut y aller progressivement.
Quand chacun y met sa sauce sans concertation ça devient un putain de dawa pire que tout.

Sérieux, si on te dit camelCase pour les variables , mais putain pourquoi tu discutes ?

En fait, il faudrait réussir à faire comprendre que ce n'est pas une activité d'autiste solitaire, la programerie, mais un sport d'équipe.

rOut ne parlait pas de défauts mais de conventions de codes et de styles, ça n'a rien à voir. Personne ne défend l'uniformité des mauvaises pratiques !
On ne va pas dire "ah non ici on ne bound checke pas nos tableaux".

Voilà, merci à ceux qui suivent

rOut est un gros intégriste et il a raison.



J'aimerais qu'on soit plus nombreux à en faire chez nous

J'ai tendance à penser que vous êtes de gros intégristes, mais pour le coup je suis d'accord avec rOut.

Le pire c'est qu'on me le reproche souvent. Alors que pour moi c'est justement l'inverse de l'intégrisme, dès que je code avec d'autres, j'essaie de faire gaffe à la manière dont le code est écrit pour intégrer le mien proprement dedans, donc en suivant les règles existantes même si elles sont des fois implicites. Peu importe le style, qu'est ce que ça change pour moi de mettre 2 ou 4 espaces ou m_ devant les membres, même si ce n'est pas le style que je privilégie pour des projets perso. Pour moi l'intégrisme se situe plutôt au niveau de ceux qui refusent de changer leurs petites habitudes sous prétexte que leur style est objectivement meilleur.

Après je ne dis pas que je n'ai pas un avis sur tel ou tel aspect du code, mais sur beaucoup de choses je pense qu'il n'y a pas objectivement de manière meilleure qu'une autre donc je ne cherche pas spécialement à imposer ma préférée si ce n'est pas utile.

[Orhin]

Par curiosité vous travaillez avec quels langages et dans quels domaines ?

En ce moment principalement web avec Typescript/Angular/RxJS (un peu d'Ionic aussi pour des application hybrides). J'aimerais bien toucher un peu React aussi sur mon temps libre si j'ai le temps.
Et du Kotlin de temps en temps en soutient de collègues sur les projets Android.

Y a encore quelques mois on n'utilisait pas de linter, on avait par endroits des inconsistances dans le nommage et autres saletés. Depuis qu'on a rendu obligatoire le linter on a un code beaucoup plus homogène. Pour l'ancien code on repasse dessus petit à petit, ça va être long mais on devrait y arriver.

Sachant que y'a pas mal de linter qui peuvent auto-corriger une bonne partie des erreurs de style.
Et que les bons IDE fournissent aussi des outils pour auto-formatter le code en prenant en compte les fichiers de config des linter.

[Max_well]

Java/Spring/Banques

[William Vaurien]

@rOut et les autres: je vais pas continuer à alimenter le débat qui n'est pas très utile:
dans le fond tu as presque totalement raison, c'est peut être dans la forme et la manière de dire les choses que j'ai un peu tiqué: oui, ça sonnait un peu intégriste comme même


Sinon j'ai trouvé cette étude assez sympa sur l'état des lieux du dev dans le monde (basé sur 40000 dev):
https://research.hackerrank.com/developer-skills/2018/

C'est assez sympa de voir les langages chers aux dev en fonction de leurs âges

spoiler: Python gagne à la fin avec VI

Et sinon, pour ma part c'est Java/Banque suivi de Java/Groovy/Administration et maintenant C/Java/Administration. Du web pour le tout.

Edit:
En fait si quand même, je ne peux pas me retenir (oui je suis casse pied): comment on fait quand on arrive dans un projet avec un code truffé de mauvaises pratiques devenu habitudes et donc "standard de-facto" ?
Généralement toute volonté de changement est mal vécu par l'équipe en place: les membres de ce genre d'équipes sont souvent fusionnels avec leur code et il n'y a pas eu des masses de code review ni beaucoup de brassage dans les personnes.

[Charmide]

Le truc qui m'avait fait marrer en lisant ça c'est les compétences de debug plus recherchées que celles de test

[Møgluglu]

Le truc qui m'avait fait marrer en lisant ça c'est les compétences de debug plus recherchées que celles de test

Et les compétence en preuves de correction, elles n'apparaissent même pas dans la table.

Je retiens aussi :
- Les jeunes apprennent à programmer plus tard que les générations d'avant.
- Plus de la moitié ont appris à programmer sur le tas plutôt qu'à l'université.

[Dross]

Par curiosité vous travaillez avec quels langages et dans quels domaines ?

C# .NET Web (ASP.NET MVC/API/Core) et Desktop (WPF). Ainsi que du front (on a commencé sur Knockout.js y'a deux ans, j'ai tout migré sous Angular 4 cet été), et on était déjà sur une stack en Typescript.
Je bosse dans une start-up (On est 3 Devs, je suis le 2ème à y être rentré) et on développe des outils autour d'une techno maison de recherche géométrique. (Google pour les modèles 3D, en gros).

Du coup chez nous, c'est le foutoir complet niveau homogénéisation. On suis un peu les recommandations MS, et Resharper (le saupoudrage JetBrains sur VisualStudio) nous a poussé à homogénéiser un peu, mais rien de fou non plus.
Aujourd'hui, tant que le code est testable par des tests ne faisant pas 50 lignes d'initialisations, pour moi c'est du bon code. (De mon point de vu, les tests unitaires sont vachement révélateur de la qualité sous-jacente : pas testable facilement = pas bon, et on vois le "facilement" avec la quantité de conneries à stuber/mocker avant). Sachant que pour nos besoins, la maintenabilité prime sur l'efficacité : on n'optimise qu'en cas de besoin, après coup. Et ça n'arrive presque jamais.

Concernant nos migrations sur nos gros projets (on maintient plus de 5 produits desktop, et des API/Plateforme en ligne), on fait des revues de code où on décide ce qu'on devrait faire pour améliorer les choses, et on a comme règle de ne faire la migration que quand on met les mains dedans, donc nos projets sont hétérogènes, mais avec un objectif défini sans que ça nous plombe 3 semaines de travail. Et elle se fait progressivement sur la durée.
(bon après quand il n'en reste plus que 20% non migré, on prends quand même le temps de terminer tout ça).

[Tramb]

En fait si quand même, je ne peux pas me retenir (oui je suis casse pied): comment on fait quand on arrive dans un projet avec un code truffé de mauvaises pratiques devenu habitudes et donc "standard de-facto" ?
Généralement toute volonté de changement est mal vécu par l'équipe en place: les membres de ce genre d'équipes sont souvent fusionnels avec leur code et il n'y a pas eu des masses de code review ni beaucoup de brassage dans les personnes.

Ouais, c'est très chaud, et il faut marcher sur des œufs.
Si les gens ne sont pas pro, tu es quand même pas mal coincé.
A mon avis, il faut y aller par
a) petites touches : ne pas révolutionner tout dès le début, choisir ses petits combats, si possibles factuellement efficaces, trouver des bugs, les corriger
b) l'exemplarité : ne pas se faire gauler à faire des conneries sinon la confiance ne sera jamais regagnée
Au bout d'un moment soit tu es respecté, soit tu te casses après un shooting.

[William Vaurien]

@Tramb oui c'est un peu ce que j'ai fait... Après plus d'un an dans l'équipe ça passe mieux, mais il y a eu une phase de clash avec l'un de mes coéquipier qui prenait toute critique sur le code très personnellement...
le côté b) est assez pervers car j'ai toujours peur de committer quelque chose de foireux et d'être pris à défaut... J'ai fini par mettre en place un système de test unitaire en C pour me rassurer...

Question GDB pour les pros du C et autres compilateurs humains... (moi je suis débutant dans ces 2 domaines )

Donc mon appli utilise le preprocesseur pro*c pour faire des requêtes vers une base de données Oracle.
En gros il s'agit d'un préprocesseur qui permet de générer tout le code d'interaction avec la base de donnée.

Le programme n'a pas de couche distincte entre l'accès aux données et le business. Donc le code est un gros mille-feuilles ressemblant à

...
code technique 
EXEC SQL SELECT ...
code gestion erreur

EXEC SQL SELECT...
code gestion erreur

code métier

EXEC SQL INSERT...
code gestion erreur

code métier

EXEC SQL UPDATE...
code gestion erreur
...

Pour passer à l'étape pro*c une première passe est effectuée pour faire tout la partie pre-processeur du C (gcc -E). Le préprocesseur pro*c semble nécessité cette étape...
Du coup le source est transformé 2 fois avant la compilation finale:
.pc -> le source
.sq -> le source préprocessé
.c -> le source préprocessé + code généré pour le SQL avec pro*c

au final le code passe de quelques centaines (voir milliers dans le pire des cas ...) de lignes à 20000: (gros import dégueux)+ les lignes + (30/50 lignes * nombre instructions SQL).
et du coup debugger le code est un peu pénible: trouver l'emplacement des breakpoints doit se faire à partir du .c final, le code truffé de code généré n'est pas facile à suivre... Bref c'est la plaie.

Le pro*c permet de générer un .c avec des instructions #line qui permettent de faire un mapping entre plusieurs lignes du .c vers le .sq, et donc de rendre invisible le code généré:

#line 23257 "toto.pc"
 struct sqlexd sqlstm;
#line 23257 "toto.sq"
 sqlstm.sqlvsn = 12;
#line 23257 "toto.sq"
 sqlstm.arrsiz = 3;
#line 23257 "toto.sq"
 sqlstm.sqladtp = &sqladt;
#line 23257 "toto.sq"
 sqlstm.sqltdsp = &sqltds;
...

Questions auxquelles je n'ai pas trouvé de réponse:
1) Est-ce qu'il est possible de faire générer le code préprocessé avec le même genre d'instruction #line ???
Dans mes .sq j'ai bien des lignes du genre: # 22 "FichierSource.pc" mais cela ne semble pas faire beaucoup d'effet au debugger et contrairement au bouts de code générés par pro*c il ne s'agit que de marqueur sur certaines lignes.

Il y a moyen de configurer ça ? (c'est un vieux gcc: v4.4.7 de 2010 / oui, c'est une 'best practice' de mon équipe de ne pas être à jour)

2) Est-ce qu'il est possible de chaîner les fichiers --> fichier.sq:22512 --> fichier.pc:21465 --> fichier.c:215 ?
C'est sensé marcher tout seul ou il faut configurer gdb ?

Je n'ai pas trouvé beaucoup de documentation à ce sujet, je prends toutes vos idées et conseils

[rOut]

A mon avis les marqueurs ajoutés par le préprocesseur GCC devraient suffire pour indiquer les lignes correctes ensuite, il ne les mets que là ou les lignes de code source ne se suivent pas. Le problème, AMHA c'est la deuxième phase de préprocesseur qui repasse dessus et doit sans doute virer les lignes originelles pour les remplacer par les nouvelles.

Est-ce que la phase .pc -> gcc -E -> .sq est vraiment nécessaire ? J'ai l'impression que pro*c est capable de se démerder tout seul pour faire .pc -> .c, mais peut être que le code contient des macros supportées uniquement par gcc et qu'il faut donc passer par là pour l'aider... Si pro*c supporte correctement les #line en entrée, il faudrait sans doute remplacer les # n "fichier" sortis par gcc en #line n "fichier" pour qu'il les reconnaisse.

[William Vaurien]

Ce découpage est probablement due à une combinaison d'une mauvaise compréhension de l'outil pro*c à la base (vers 1992 donc...) et de ses limitations techniques.
En gros c'est à la fois des instructions SQL et des 'flags'. Par example il est possible d'installer un handler d'erreur SQL.
Cette installation marche comme un #define : elle commence à partir de la déclaration et se termine dès qu'il y a une redéfinition.
Les variables qui doivent être utilisés dans les instruction SQL doivent également être 'balisées'.
Le résultat c'est qu'il y a des instruction pro*c dans les headers...

La solution simple consiste donc à faire une première phase de preprocessing pour générer un source géant avec tous les includes incorporés au code, puis de passer le pro*c dessus...
Et il y a une passe de nettoyage via un fichier d'expressions sed de 30 linges qui fait un grand ménage dont plus personne ne sait pourquoi ..
Les instruction #line ne sont pas supporté en entrée par proc, il part en boucle infinie quand il en trouve ! Par contre lui en génère bien: j'essai de ruser un peu en modifiant les #line en instructions inoffensives avant le passage au proc, puis de les réactiver dans le source avant la vrai compilation gcc... mais c'est pas encore au point...

La doc du proc montre qu'il y a peut-être moyen de faire autrement (il y a possibilité de 'compiler' les headers et les #include sont dans ce cas transformé à la volée, il y a moyen de filer les chemins des include dirs au proc pour qu'il ne râle pas pendant la génération du code (oui, le C est parsé et pro*c n'aime pas trop certaines 'nouvelles' features, comme les commentaires simples ...).

Je n'ai pas spécialement envie de trifouiller le build pour le moment, d'un parce que c'est particulièrement chiant, de deux par parce que c'est un sujet sensible (le fameux "tu comprends ça marche comme ça depuis 30 ans").

Donc j'essaie juste de bricoler un peu...

Et ça ne marche pas des masses: gdb remonte bien tout seul vers le .sq, mais pas vers le .pc original, même avec les bonnes instructions #line.
Je ne comprends pas bien comment le mapping est retrouvé avec ces instructions. Est-ce que dans le binaires il y a une indication ? Parce qu'en modifiant à la main les sources en donnant des lignes des .pc il n'y pas aucun effet...

[Tomaka17]

Par curiosité vous travaillez avec quels langages et dans quels domaines ?

Rust ! Faites passer le mot, le Rust c'est bien.

[William Vaurien]

Bon je laisse tomber le mapping complet des lignes, déjà pouvoir masquer les instruction SQL est du grand confort !

J'en profite pour poser une question sur "Canard Overflow" d'ordre plus général sur la gestion de la mémoire et le scope des variables en C.

Si on prend une définition comme par ici: https://stackoverflow.com/questions/...stack-and-heap,
il y a cette propriété:

Variables created on the stack will go out of scope and are automatically deallocated.

Qu'est-ce qui ce passe si je stocke l'adresse d'une telle variable dans un pointeur qui a lui été alloué dynamiquement ?


Par exemple dans le code suivant, est-ce que le buffer est bien alloué dans la stack ?
Si c'est bien le cas est-ce que c'est dangereux de faire 'myStuff->data=buffer;' comme dans la méthode helloSTACK() ?

Quand est-ce que la phase de deallocation automatique arrive (prédictible ou non prédictible) ?

typedef struct stuff { char *data;} stuff;

void helloSTACK(stuff* myStuff) 
{		
	puts("--> helloSTACK()");
	char buffer[13] = "HELLO STACK!";
	myStuff->data=buffer;	
	printf("value of buffer inside method:			%s\n",buffer);
	printf("value of myStuff->data inside method:	%s\n", myStuff->data);
	puts("<-- helloSTACK()");
}

void helloHEAP (stuff* myStuff)
{
	puts("/* allocation on the STACK*/");
	char *buffer = calloc(16, sizeof(char));
	sprintf(buffer, "%s", "HELLO HEAP!");
	myStuff->data = buffer;	
}

void prepareStuff() {
	/*dynamic allocation: in the HEAP, not removed until free is called */
	stuff* myStuff = calloc (1, sizeof(stuff));
	puts("--------------------------------------------------");
	helloSTACK(myStuff);
	printf("Stack data: %s\n", myStuff->data);		
	puts("--------------------------------------------------");
	helloHEAP(myStuff);
	printf("Heap data: %s\n", myStuff->data);			
}

Ayez pitié d'un pauvre dev Java égaré dans les contrées inhospitalières des méthodes foireuses des 'strings' de la stdlib du C et a qui le Garbage Collector manque énormément

PS oui, j'ai volontairement oublié de faire les free() sur ma mémoire allouée dynamiquement...

[Tramb]

Bon je laisse tomber le mapping complet des lignes, déjà pouvoir masquer les instruction SQL est du grand confort !

J'en profite pour poser une question sur "Canard Overflow" d'ordre plus général sur la gestion de la mémoire et le scope des variables en C.

Si on prend une définition comme par ici: https://stackoverflow.com/questions/...stack-and-heap,
il y a cette définition:


Qu'est-ce qui ce passe si je stocke l'adresse d'une telle variable dans un pointeur qui a lui été alloué dynamiquement ?


Par exemple dans le code suivant, est-ce que le buffer est bien alloué dans la stack ?
Si c'est bien le cas est-ce que c'est dangereux de faire 'myStuff->data=buffer;' ?
Quand est-ce que la phase de deallocation automatique arrive (prédictible ou non prédictible) ?

typedef struct stuff { char *data;} stuff;

void helloSTACK(stuff* myStuff) 
{		
	puts("--> helloSTACK()");
	char buffer[13] = "HELLO STACK!";
	myStuff->data=buffer;	
	printf("value of buffer inside method:			%s\n",buffer);
	printf("value of myStuff->data inside method:	%s\n", myStuff->data);
	puts("<-- helloSTACK()");
}

void helloHEAP (stuff* myStuff)
{
	puts("/* allocation on the STACK*/");
	char *buffer = calloc(16, sizeof(char));
	sprintf(buffer, "%s", "HELLO HEAP!");
	myStuff->data = buffer;	
}

void prepareStuff() {
	/*dynamic allocation: in the HEAP, not removed until free is called */
	stuff* myStuff = calloc (1, sizeof(stuff));
	puts("--------------------------------------------------");
	helloSTACK(myStuff);
	printf("Stack data: %s\n", myStuff->data);		
	puts("--------------------------------------------------");
	helloHEAP(myStuff);
	printf("Heap data: %s\n", myStuff->data);			
}

Ayez pitié d'un pauvre dev Java égaré dans les contrées inhospitalières des méthodes foireuses des 'strings' de la stdlib du C et a qui le Garbage Collector manque énormément

Tu ne peux plus accéder à myStuff->data sans undefined behaviour à partir de la } fermante de helloSTACK

[William Vaurien]

ok merci
c'est ce que j'avais compris mais je n'étais pas complètement sûr... donc avec ce petit exemple il y a de grosses chances pour que ça ai l'air de fonctionner sauf qu'en vrai la mémoire peut être modifiée a tout moment.

J'ai l'impression de marcher sur des œufs en permanence avec le C !

[Tramb]

Ouais, le C, c'est des oeufs posés sur des oeufs posés sur des oeufs !

[Cwningen]

Quand est-ce que la phase de deallocation automatique arrive (prédictible ou non prédictible) ?

C'est l'avantage du C (et autres langages similaires) sur le java (et autres langages à GC), tu sais parfaitement quand les données sont libérées (et détruites pour le C++) : à la fin du scope où elles sont déclarées. Donc on ne doit jamais retourner (par return ou effet de bord dans ton cas) un pointeur vers une variable locale.

[William Vaurien]

ouais, sauf que c'est 'undefined behaviour', donc le comportement n'est pas non plus flagrant, et du coup un bug peut se planquer pendant un bon bout de temps avant de faire des dégâts...

Et en Java 'tu sais aussi parfaitement'* à partir de quand la donnée n'est plus référencée et donc sujette au GC.
Par contre tu ne sais pas quand le roomba va venir faire le ménage.

*parfois c'est bien planqué, quand même

[Cwningen]

Je parlais de la désallocation, qui est parfaitement prédictible. Le comportement indéfini, c'est seulement si tu utilises la variable après sa fin de vie.

[William Vaurien]

Je vois pas vraiment l'avantage par rapport à un Garbage Collector... d'autant plus aujourd'hui avec les GC moderne qui arrivent à se faire discret (ils ne bloquent plus la VM pendant parfois de longues secondes comme pouvaient parfois le faire les anciennes générations).
C'est pas un troll, c'est une vrai question: à part pour de l'embarqué avec une mémoire minus ou du temps réel avec de fortes contraintes, quel est l'avantage ?

[Cwningen]

J'avoue qu'en C c'est pas si important. J'ai le C++ en tête, et connaître le moment où les destructeurs sont appelés est important.

[Tramb]

Je vois pas vraiment l'avantage par rapport à un Garbage Collector... d'autant plus aujourd'hui avec les GC moderne qui arrivent à se faire discret (ils ne bloquent plus la VM pendant parfois de longues secondes comme pouvaient parfois le faire les anciennes générations).
C'est pas un troll, c'est une vrai question: à part pour de l'embarqué avec une mémoire minus ou du temps réel avec de fortes contraintes, quel est l'avantage ?

Discrets, faut le dire vite, quand même.
Un des problèmes c'est quand un garbage collector fait plus que récupérer de la mémoire, mais s'occupe de finalisation de ressources. On est dans le brittle.

[Benav]

C'est pas un troll, c'est une vrai question: à part pour de l'embarqué avec une mémoire minus ou du temps réel avec de fortes contraintes, quel est l'avantage ?

Aucun. Mais le GC c'est un outil comme un autre, c'est génial dans certains contextes (une appli web), mais inutilisable dans d'autres (le temps réel).

[William Vaurien]

je pense pareil, je réagissais juste sur le côté "c'est un avantage" et pour voir si je n'avais pas raté un truc subtil...

[Cwningen]

Je n'ai pas dit que le C est mieux que les langages à GC. La prédictibilité reste un avantage (et je n'ai pas parlé de vitesse non plus). Mais, c'est peut être un avantage qui ne t'intéresse pas. Ou alors c'est moi qui ai raté un truc subtil et la prédictibilité des désallocations peut être un inconvénient ?

[William Vaurien]

Non, c'est juste qu'en dehors de certains type d'environnement je ne vois pas ce que ça apporte et que je me suis demandé qu'est-ce que ça pouvait apporter concrètement.

[Dross]

la prédictibilité des désallocations peut être un inconvénient ?

Un des inconvénient est que cette désallocation est systématique et utilise du cycle CPU qui aurai pus être fait plus tard (à un moment où la machine est moins sollicité par exemple) ou de manière plus efficace (on vire que quand la machine à besoin de place, sinon on touche pas).