CrEv a écrit 4577 commentaires

Avec CLang c'est un peu plus explicite :

main.cpp:4:20: error: 'auto' not allowed in lambda parameter
  auto square = [](auto x) { return x * x; };
                   ^~~~
main.cpp:5:19: error: 'auto' not allowed in lambda parameter
  auto twice = [](auto x, auto f) { return f(x) + f(x); };
                  ^~~~
main.cpp:5:27: error: 'auto' not allowed in lambda parameter
  auto twice = [](auto x, auto f) { return f(x) + f(x); };
                          ^~~~
main.cpp:7:16: error: no matching function for call to object of type '<lambda at main.cpp:5:16>'
  std::cout << twice(5,square) << std::endl;
               ^~~~~
main.cpp:5:16: note: candidate template ignored: couldn't infer template argument '$auto-0-0'
  auto twice = [](auto x, auto f) { return f(x) + f(x); };
               ^
main.cpp:8:16: error: no matching function for call to object of type '<lambda at main.cpp:5:16>'
  std::cout << twice(5.1,square) << std::endl;
               ^~~~~
main.cpp:5:16: note: candidate template ignored: couldn't infer template argument '$auto-0-0'
  auto twice = [](auto x, auto f) { return f(x) + f(x); };

La seule chose que je dis c'est que la grammaire XML est simple et elle est connu là où celle de cmake est spécifique.

Oué mais XML c'est bien pour du déclaratif, ce que n'est pas le langage de CMake.
Et on voit bien avec Maven que le déclaratif c'est bien sur le papier mais dans le vrai monde on fabrique des plugins en java pour pouvoir passer outre et avoir les comportements attendus.

ça fait une semaine que je dois retracer ce que fait un fichier de 3000 lignes.

hum, 3000 lignes c'est rien du tout hein :-)
Je connais des softs dont 1 méthode dépasse déjà plusieurs centaines de lignes et où les tailles de fichiers sont à 5 chiffres…

Heu, oui mais non.
Certes il sera inclus, mais comme il va rencontrer (là deuxième fois et les suiantes) un #findef BLABLA_H qui sera défini, il ne va rien inclure du tout.
Donc le code de ton .h sera bel est bien inclus une seule fois (sauf cas très particuliers)

et tu peux prouver que tu es plus efficace avec ton gros debuggeur lourdingue ? J'en doute.

Ok, tu en doutes. Et tu peux prouver que tu es plus efficace avec ton printf limité ? Genre comment tu affiches une structure un peu complexe sans y passer plein de temps ? Comment tu affiches une donnée que tu ne pensais pas initialement nécessaire (je veux dire sans modifier ton code, recompiler, réexécuter ?)

Et bon, un debuggeur ça ne se limite pas qu'à du printf/stacktrace. Si c'était le cas peut-être qu'on pourrait comparer un peu, mais ce n'est pas le cas du tout.
Comment tu fais pour que ton programme s'arrête à un état donné (un breakpoint conditionnel) ? Tu écris du code avec un while(true) ?
Et comment tu sautes à une instruction avec ton printf ?

Alors c'est sur que gdb et la pauvreté des interfaces dans le monde linux ça ne donne pas du tout envie de debugger quoi que ce soit, ça c'est vrai. Mais dire qu'on en a pas besoin moi ça me fait penser à tous ceux qui disent que les IDE ça ne sert à rien puisqu'il y a grep/sed/awk. Mais va faire un refactoring correct simplement avec ça…

les gens qui "debug" à coup de printf/qDebug/etc

Si encore quelqu'un expliquait qu'il ne debug pas mais fait tout par des tests (unitaires et autres) je comprendrais, mais là ça devient vraiment triste :-(

Pour le moment j'ai aucun problème avec, l'auto reload de cmake fonctionne plutôt bien, la complétion aussi.
Ça prend un peu de ram quand même… mais sinon c'est sympa, il y a des symboles pour passer du prototype à l'implémentation d'une méthode facilement, l'intégration aux gestionnaires de sources est bonne, etc.

Le problème des macros est quand même assez spécifique, genre si on utiliser __LINE__ ou __COUNTER__ pour créer des variables uniques, les deux macros ne sont pas bien interprétées et sont à 0. Résultat les variables uniques ne le sont plus pour l'IDE et il affiche en rouge.

Ex :

#define UNIQUE_2(name, line) name##line
#define UNIQUE_1(name, line) UNIQUE_2(name, line)
#define UNIQUE(name) UNIQUE_1(name, __LINE__)

int UNIQUE(plop);
int UNIQUE(plop);

Le résultat devrait être

int plop5;
int plop6;

pour CLion le résultat est

int plop0;
int plop0;

Et donc forcément ça ne passe pas. Bon c'est génant mais pas ultra horrible. Le problème c'est que c'est souvent utilisé dans les framework de tests unitaires.

D'ailleurs question bonus, si quelqu'un sait comment faire une macro pour avoir un nom de variable unique sans __LINE__ ni __COUNTER__ ça m'intéresse vraiment ;-)

Vous n'utilisez pas d'IDE ?

Mais c'est vrai que je n'ai toujours pas compris comment on peut être content à ce point de gdb (enfin non pas de l'outil en lui même mais de son "utilisabilité")

nan mais au final tu ne l'inclus qu'une seule fois.

Je pense que ce qu'il veut dire c'est un .h que tu inclus réellement plusieurs fois (donc sans #ifndef)

Bien.

Maintenant tu peux relire mon message jusqu'au bout :

Certes, si on lit wikipedia il parait que c'est pas standard et non supporté par tout le monde, mais bon quand on regarde la liste on a tout de suite 'achement moins peur. Donc #pragma once.

Ho tiens, c'est le même lien et la même information…

A utiliser que si on n'a pas pour but de diffuser son code plus que ça.

Ha oué ? Et tu peux m'expliquer dans quel cas normal ça ne passerait pas ? Parce que justement si on suit le lien on a :

Portability

Compiler	#pragma once
Clang	Supported
Comeau C/C++	Supported
C++Builder XE3	Supported
Digital Mars C++	Supported
GCC	Supported (since 3.4)
Intel C++ Compiler	Supported
Microsoft Visual C++	Supported
Pelles C	Supported
ARM DS-5	Supported
IAR C/C++	Supported

J'ai essayé quelques IDE, avant de me rendre compte que Eclipse ou Netbeans sont les seuls à proposer une bonne complétion, du refactoring qui marche et à ne pas planter lamentablement

Il y a aussi CLion. Je le teste depuis quelques temps et à part une mauvaise gestion des macros du type __LINE__ (il ne l'utilise pas bien et affiche des erreurs dans le code alors qu'il n'y en a pas, par exemple sur des macros qui créent des identifiants uniques) ça marche plutôt pas mal.

l'absence de système de modules: des entêtes avec #ifndef … #endf en 2014, c'est très moche.

Hein ? Nan mais ça fait un moment qu'on est plus obligé d'utiliser ce genre de truc pour gérer les .h…

#pragma once

Franchement je sais pas pour quelle foutu raison les gens ne se sortent pas les doigts pour l'utiliser. Certes, si on lit wikipedia il parait que c'est pas standard et non supporté par tout le monde, mais bon quand on regarde la liste on a tout de suite 'achement moins peur. Donc #pragma once.

Je caricaturais ton hypothèse qui consistait à dire - je caricature encore - "OSEF de l'expérience utilisateur, on veut pas payer 2 GUI". Donc j'allais jusqu'au bout de ton raisonnement.

Oué enfin sauf que c'est pas du tout ce que j'ai dit, surtout pas la partie "OSEF de l'expérience utilisateur" ou alors faut que tu m'explique.

mais tu me sors comme seul exemple un contrôleur Parrot. Youpi.

Nan mais c'est vrai que je ne t'ai pas donné comme cas d'utilisation :

• ceux qui exploitent les données / fichiers de ton device (photos, multimédia, documents divers, etc)
• ceux qui exploitent le matériel (capteurs, gyro, sensors, etc)

Et c'est vrai que ce sont des cas qui n'existent jamais hein.

Par contre croire que Qt est la solution […] pour faire du cross-plateform miraculeux à moindre coût, c'est juste de la branlette de geek persuadé d'avoir trouvé le graal technologique façon Java il y a 20 ans,

Je crois qu'il est l'heure de tes médocs. Parce que bon venir tailler sur des propos que tu es le seul a tenir c'est plutôt pas mal.
A moins que tu montres où on parle de "miraculeux à moindre coût" et de "graal technologique"

en oubliant le principal : l'expérience utilisateur.
OSEF de la réactivité non ?

Ha oui, c'est vrai que l'expérience utilisateur sans réactivité c'est quand même pas mal :/

En plus je gagne une plateforme, et pas des moindres, le web

Mouai, c'est pas toujours nécessaire, et si ne pas l'avoir te permet d'avoir d'autres avantages c'est bien.
Tiens, vu que tu es accro aux exemple, prend instagram qui avait des applis mobiles et pas d'applis web.

QGIS est un très bon exemple : ca donne quoi compilé en APK sur un nexus ? C'est utilisable ou c'est juste une blague ?

Tu te rend compte que c'est totalement con ta question là ?
Et un site web html4 non responsive et avec des iframes ça donne quoi sur un nexus ? C'est utilisable ou c'est juste une blague ?

Allez, pour répondre c'est juste une blague puisque ça ne peut pas fonctionner car l'UI est à base de QWidget et c'est QML qui fonctionne sur iOS/Android.

Sans parler des différences entre les dispositifs : tu proposes une ergonomie différente sur mobile, sur tablette, sur desktop+souris.

et alors ? c'est tout à fait possible avec Qt et qml, c'est même assez facile. En fait c'est même plus facile de faire du "responsive" en Qt qml qu'en html/css, bien plus puissant.

Encore une fois, donne des exemples concrêts !

ben prend n'importe quelle demande d'appli multi plateforme. Désolé je ne vais pas te faire une liste de toutes les applis possibles et imaginables.

Si ces applications ne nécessitent pas de calcul intensif, ils sont tous candidats à utiliser un toolkit HTML.

J'ai jamais dit qu'elles n'étaient pas candidates mais juste que l'html c'est plutôt bof, surtout en terme de réactivité.

J'ai jamais dis d'utiliser des appli web pour tout et n'importe quoi.

Ha ben désolé hein, moi j'étais parti de ta phrase « Si ce n'est pas un jeu, tant qu'à faire du cross-Platform avec le même look partout, autant utiliser les framworks à base d'HTML ». Donc je donne des exemple d'applications où il peut être intéressant de faire du cross plateforme non web, et donc dans ce cas d'utiliser Qt.

Donc des applis du type de parrot pour controler un matériel, ça peut être fait avec un framework comme Qt, et l'intégration graphique n'est pas forcément ce qui est recherché, tu peux plutôt avoir une identité propre commune à toutes les versions.
Ça c'est une cible.

Ensuite sur Google Drive et Dropbox faut aussi savoir généraliser, mais bon si tu préfères des applications qui vont manipuler des données sur ton téléphone, des documents, photos, etc. Dans ce cas il vaut mieux faire du natif, et dans pas mal de cas l'intégration graphique n'est pas forcément nécessaire car tu peux ajouter ton identité dessus. Dans tous les cas ce sera mieux que du web niveau perf/réactivité/fluidité et avec les toolkits cross platform qui commence à avoir des styles natifs (tiens, comme Qt) le côté où l'appli n'est pas intégré tend à disparaître.

Et après si tu veux vraiment avoir un large éventail d'applis où c'est pertinent de faire du Qt, en voilà un : toutes les applis multiplateformes où le client ne souhaite pas payer deux développements de GUI (dans le meilleur des cas, deux développements complets dans le pire). Ça va, c'est assez vaste ? Parce que c'est peut-être pas top mais en tout cas là tu en as du monde.

que tu t'en fou un petit peu de la cohérence ergonomique avec les plateformes cibles, que l'utilisateur utilise sont doigt sur un écran 4" ou sa souris sur un écran 32" Quad HD, c'est pas ton problème

Tu veux dire comme une appli web ?

mais j'imagine que tu as toujours des cas où c'est utile sur le terminal du client

Ben disons que lorsque tu veux faire des calculs provenant de ton matériel (par exemple utiliser les capteurs, gyro, gps, accéléro) et avoir un temps de traitement correct (et donc surtout pas de latence réseau) tu n'as d'autre choix que de le faire sur ton matériel.
Les web services c'est rigolo quand tu te fiche de la latence ou que tu peux te permettre d'avoir une application qui ne fonctionne que quand il y a du réseau.

que ton application doit être dispo sur plusieurs plateformes… sauf le web

Ben oui, ça existe encore les applications natives, et en général elles sont quand même plutôt agréable par rapport aux versions web (niveau ergonomie, temps de réaction de l'interface, fluidité)

Des exemples ? Ben j'en sais rien, imagine si Google Drive ou Dropbox étaient une appli web sur ton mobile ?
Ou tiens, prend l'application Parrot pour piloter leurs drones, ça serait marrant en web aussi.
Et j'ai juste pris les deux premières idées comme ça.

tant qu'à faire du cross-Platform avec le même look partout, autant utiliser les framworks à base d'HTML

Mouai, ça devient quand même tout de suite moins marrant dès que tu as des algos, veut accéder au matériel, avoir un poil de puissance de calcul, etc. Enfin faire des vrai applis métier et pas juste consommer 3 web services…

Le périmètre où QT est pertinent est vraiment limité.

Vraiment ?

Si tu veux faire des applications linux, mac, windows + mobiles, ça reste plutôt pertinent. Et je trouve ça pas mal comme périmètre.

Qt est pratique pour faire un port "à l'arrache" ou si on a une forte identité visuelle qui nous permet de nous affranchir des habitudes des utilisateurs sur certains OS

En fait ça dépend du type d'application. Si c'est une application avec beaucoup de contrôles (éléments graphiques) classiques, alors c'est pas forcément top. Si par contre c'est une application spécifique (graphiquement), un jeu, etc alors il n'y a pas vraiment de problème et le résultat est correct de ce que j'ai pu tester.

Si certains veulent voir comment ça marche, j'avais écrit il y a quelques temps une série d'articles sur le blog de ma boite présentant la création d'un petit projet (un 2048) en Qt, dont le but était de fonctionner aussi bien sur desktop que sur iOS et Android (partie 1, 2, 3, 4, 5, 6 et 7)

Diaspora dont tout le monde parle ces derniers temps

Sérieux ? On en parle ces derniers temps ?
Je pensais que c'était juste mort et enterré…

-_-'

Lapin compris le rapport (enfin en dehors du troll habituel plein de mauvaise fois)

mouais, enfin quand on voit ce que ça donne smtp et gpg on comprend vite que certains tentent de faire mieux.
Et "les gens" s'en fichent que ce soit centralisé ou non, ils veulent surtout quelque chose qui marche bien. d'ailleurs si c'était centralisé tout le monde serait sur gmail et rien d'autre, et c'est pas le cas justement. Même si on y va parfois.
Mais justement, le mail reste un bon exemple. Ça reste décentralisé et ça communique. Mais si les gens vont sur gmail c'est aussi justement pour le webmail gmail. Que d'autres fassent aussi bien et les gens iront peut-être (enfin c'est tout de même plus compliqué). Mais pour le moment, ben y'a pas grand chose de mieux. Les gens veulent le service, la facilité, centralisé ou non c'est pas le problème.
Et les hipsters de github ou autre non plus.

Ya que les barbus comme nous

C'est triste ton avis sur Mildred ;-)

Je ne pense pas qu'il soit ici une question de hipster en .io
Par contre c'est beaucoup plus question du fait d'avoir des clients qui soient serveur. Un peu comme l'étaient par exemple les premiers navigateurs, à la fois client et pouvant éditer des documents. Et les mails sont plus proches de ce mode tout de même.

En tout cas c'est en partie comme ça que je lis l'intro du billet que Mildred a écrit.

C'est triste ton avis sur Tout le monde.