Le topic de la programmation: Et envoyez des sioux!

[vectra]

* il me manque cette fonction de completion contextuelle laxiste, qui propose des mots parmi ceux de tous les buffers ouverts. C'est génial avec emacs en mode LaTeX, mais ça serait aussi bien pratique sous CLion. J'ai pas encore trouvé de telle fonction.

C'est cyclic-expand-word (dabbrev-expand sur emacs).

Ca commence à prendre forme... J'arrive même à être un peu moins perdu face au mécanisme de build, même si là je rame un peu quand-même.
En gros, sur emacs, je tapais make sur la console, et c'était à peu près tout (cmake . était appellé en cas de modif. de CMakeLists.txt si je me souviens bien).

Là, c'est une autre histoire. Tu fais 'build', mais ça suffit pas à détecter tous les soucis ni à faire apparaitre les nouveaux exécutables. Il faut passer par un menu pour recharger le projet, sélectionner le nouvel executable par F9, et son exécution lance sa compilation. Euh...

[vectra]

Tiens, une question sur C++11 au sujet d'un test CLion.

Mon projet est bien configuré en C++11, mais quand je veux créer un .h, il me met d'office ceci dedans:

#ifndef MYVTK_VOLUMESORTERUTIL_H
#define MYVTK_VOLUMESORTERUTIL_H

#endif //MYVTK_VOLUMESORTERUTIL_H

Je suis tout décontenancé, je pensais qu'il suffisait simplement de faire ceci:

#pragma once

Il y a une différence entre les deux? Il y a une bonne raison pour utiliser l'ancienne méthode?

[Patate]

Aucune idée, mais j'ai toujours vu le #pragma sous visual studio mais jamais utilisé sous linux pour ma part.

- - - Mise à jour - - -

Aucune idée, mais j'ai toujours vu le #pragma sous visual studio mais jamais utilisé sous linux pour ma part.

Merci pour tous vos retours. Je fais du python pour tout mes scripts, outils en console. Maintenant je voudrais faire un peu de gui/db et de la console, donc je vais peut-être plus regarder kotlin. Dernière question, pour les développeurs rust, vous avez déjà fait du gui et de la base de données ? J'ai vu qu'il y avait un binding gtk alors pourquoi pas.

[vectra]

Bon bah pragma once n'est déjà pas standard. Il est supporté sérieusement par tous les compilateurs que je connais AMHA, mais possède des failles connues.

cf: https://stackoverflow.com/questions/...include-guards

Dommage, c'est pratique à utiliser.

[Sahnvour]

#pragma once fonctionne bien partout dans 99.9% des cas.
Et puis un jour tu tombes sur la faute à pas de chance qui fait péter le truc et là ... bonne chance.
En creusant un peu (a fortiori sur windows j'imagine) y'a un bon gros potentiel de pétage quand entrent en jeu des outils externes qui lisent les dépendances de fichiers dans les pdbs, que t'as ton code dans un dossier accédé par un psubst et ce genre de joyeusetés.

[Munshine]

Oui mais t'es blindé de thunes.
Avoue.

Non en CDD. Et le service informatique est taillé jusqu'à l'os.
Mais ils sont très friands de Windev dans la boite où je bosse malgré le cout de la licence ( 1000 euros par poste quand même).

[William Vaurien]

Windev, je croyais que c'était une légende urbaine

Je me rappel juste des pubs très avec des jeunes femmes en maillot de bain dans les magazines de devs que j'achetais à l'époque

[vectra]

C'est bien résumé.
J'ai un collègue qui en a fait à une époque, il n'a pas rigolé le pauvre.

Après, il est parti directement coder sur GPU pour se laver les yeux

[gros_bidule]

WinDev, avec leur VCS il est toujours possible de poser un lock sur un fichier, mais aussi et surtout de le piquer, l'action de piquage affichant un simple timer ("vous avez 2 min pour sauver, sinon allez pleurer") au détenteur du lock ?
Quand j'étais stagiaire, les collègues (pas sympas) piquaient mes locks sans arrêt
Rien que pour ça : WinDev, plus jamais. Et tu peux même pas aller sur Git, vu que tu ne travailles pas avec des fichiers source texte, mais des binaires à la noix.

[Tramb]

Après un système de lock sur un VCS que tu ne peux pas forcer, ça ne marche juste pas, entre Dédé qui part en vacances, le graphiste qui locke tout depuis la racine, etc...
C'est un outil de communication, pas de sécurité. Par contre faut être civilisé.

[Dross]

WinDev et le plaisir d'écrire du code source en langue de molière.

( )

[gros_bidule]

A la limite, avec la plupart des VCS, ce n'est pas grave si tu perds ton lock. Tu attends que le voleur fasse son travail, il push, puis toi tu pull, tu gères les conflits, et tu peux pusher tes propres modifs.
Avec WinDev (11, je précise, donc ça date), perdre le lock signifie aussi perdre ses modifs
Ca s'est amélioré depuis ?

[vectra]

Quoi, c'est des binaires, les sources windev?
lls se sont inspirés de Word qui sauve du texte en pas-texte?

[ducon]

Maintenant, Word sauve son texte en texte, c’est du xml propriétaire.

[vectra]

Ah ok, donc maintenant Windev doit passer en mode XML lui aussi.
A moins que ça ne l'empêche d'encoder les pinups qui servent d'assistant(e)s sur l'IDE?

[TiNitro]

Quoi, c'est des binaires, les sources windev?
lls se sont inspirés de Word qui sauve du texte en pas-texte?

C'est pas du texte, un document Word, faut pas exagérer non plus.
Ce serait comme de dire qu'un soft de CAO devrait sauvegarder en format image.

Par ailleurs la première version est sortie en 1983, donc bon les standards XML de l'époque, m'voyez.
Je hais ce soft (je m'en sers depuis la version 2.0 et j'ai du écrire je sais pas, 10 000 pages mini avec), il est bourré de défauts mais critiquer systématiquement ce qui n'a pas lieu d'être critiqué....

[vectra]

Oui mais là c'est off-topic comme bash
En vrai, je ne dis plus de mal d'Office depuis que j'ai été obligé de travailler sur LibreOffice.

[ducon]

Wabon ?
Je l’utilise depuis Star Office.

[TiNitro]

c'est bien LibreOffice en fait. Mais c'est certes off-topic.
Alors que Windev

Je trouve ça pas déconnant que les sources ne soient pas stockés comme du texte, sur le principe, ça fait très 20e siècle de se dire qu'on compile un texte.
Alors Windev a l'air d'être une merde galactique mais l'idée d'un soft qui permet d'éditer directement les structures sans passer par une représentation textuelle existe depuis longtemps et est sensée... J'avais vu il y a longtemps des protos sympas (me souvient plus, aux débuts de Rational peut-être).

[Orhin]

c'est bien LibreOffice en fait. Mais c'est certes off-topic.

Mouais, c'est quand même loin en dessous d'Office niveau ergonomie.

[gros_bidule]

L'intérêt d'avoir des sources texte, c'est de faciliter la vie du dev : diff, analyse, choix de l'IDE, etc.
Vas faire tourner un Sonar sur du WinDev Tu es bloqué dans l'univers PCSoft : s'ils n'ont pas dev (ou mal dev) un truc, bah tu es coincé

[TiNitro]

ah mais je suis bien d'accord, et c'est pour ça que c'est toujours la norme.

Le proto dont je me souviens te permettait de naviguer et d'éditer directement les structures syntaxiques, d'associer du commentaire mis en forme aux structures etc...
La base était quand même un source texte avec des tags, mais évidemment il te faut toute la boite à outils complète.

Par ailleurs, cet éditeur ne te permettait pas d'avoir un source syntaxiquement incorrect, ce qui est chiant par moment.

[vectra]

De ce que je vois, c'est le cas de tout IDE moderne (*). Entre Clang-tidy qui te gueule dessus dès que tu as une mauvaise pratique et le passage en rouge vermillon dès que tu tapes un truc incorrect, je crois que c'est plié là.


(* oui, même emacs)

[GrandFather]

Windev s’est posé dès le départ en concurrent de Visual Basic 6. Et à ce dernier ils ont repris le principe du fichier source intégrant la définition de l’IHM et le code événementiel. Ils en sont visiblement restés là...

[vectra]

Dans Qt, t'as un fichier texte .ui que tu peux compiler automatiquement, et éditer en mode texte (si tu y tiens, mais déjà fait) ou avec un éditeur de GUI.

[ducon]

Mouais, c'est quand même loin en dessous d'Office niveau ergonomie.

Non.
Je déteste celle de Microsoft Office surtout depuis qu’il est repeint en bleu.

[William Vaurien]

Il doit dater un peu ton office... moi il a un joli theme 'dark' disponible en natif.

[vectra]

Tu t'es trompé, ça c'est IntelliOffice

[vectra]

Je plaisantais, hein.

Sinon, une vraie question sur CLion et CMake.

Quand je tape make dans le terminal (intégré à CLion ou non), j'ai droit à la compilation des fichiers sources modifiés et à l'édition de lien des exécutables qui en dépendent.
Quand je fais C-F9 (build) sous CMake, c'est visiblement autre chose, mais passe encore. En tous cas, ce qui est certain, c'est que l'édition de liens n'est pas faite.
Il faut impérativement que je fasse F9 et que je sélectionne un exécutable pour que l'édition de lien se fasse, uniquement pour lui, voire même sa compilation tout court.

C'est pas pratique du tout, voire contre-intuitif.

Je suppose que je ne comprends pas bien le workflow Clion, mais tout ce que je veux, c'est pourvoir lancer la compilation de tout le projet maintenant, et pas avec des parties en différé.
Je n'ai pas trouvé comment faire cela avec CLion pour le moment, et ça me gêne (des erreurs de compils sont déjà apparues à cause de ça donc stop).

Le savriez-vous comment faire?

[William Vaurien]

Un petit tutoriel pour aider à avoir un Office plus "hype": https://www.youtube.com/watch?v=hP6nFZXWk4M
Désolé pour ceux qui sont coincé avec un vieil office moche :D

Mais sinon je suis bien content que les thèmes 'dark' soient à la mode.
Je m'étais bricolé le mien pour Intellij avant darkula et mes collègues se foutaient de ma gueule...
En même temps c'était des collègues bloqués avec des œillères sous Eclipse...


Sinon j'ai une vrai question C: quels sont moyen pour faire de la gestion d'erreur propre (et pas trop chiante) dans le cadre d'un programme mono-threadé ?
Avec les contraintes suivantes:
- possibilité de changer le gestionnaire de base suivant le contexte: le code de base est utilisé dans des batchs et dans des écrans web.
Dans le premier cas je veux pouvoir sortir en erreur (truc qui risque de tout faire péter) ou continuer (cas d'un dossier foireux dans un ensemble)
Dans le second cas il faut d'abord afficher un écran d'erreur avant de continuer ou sortir de l'appli.

- émuler le plus possible les exceptions et leur propagation: en gros chaque ligne de C doit être potentiellement être testé pour voir si c'est pas une erreur.
Dans une librairie je voudrais pouvoir faire le minimum au moment des tests d'erreurs et ne passer au traitement de cette dernière qu'au dernier moment.

- comment gérer le cas ou la fonction retourne une vrai valeur et ne peut pas juste retourner un code d'erreur ?


J'ai vu différentes techniques:
- passer une struct 'error' à chaque appel (par exemple dans Jansson: json_load_file("/path/to/file.json", 0, &error) ; )
- définir des handlers (dans le proc d'oracle pour faire faire du SQL) qui peuvent être modifié via un pointeur de fonction
- stocker le résultat dans une variable "globale privé" et accessible via un appel de méthode (comme dans CURL :
long response_code;
curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &response_code) ;


J'ai un peu l'impression que c'est la foire à ce niveau, chaque lib proposant sa solution avec au final le besoin pour l'utilisateur des lib de se faire une petite couche d'intégration liant toutes les autres.
Si en plus je crée ma propre lib, je vais devoir rajouter encore un peu d'intégration. Autant que ce soit le moins crado possible...