[KDevelop] Script de formattage de source - Page 2

Tiens: https://dfighter1985.wordpress.com/2015/08/28/new-linter-integration-plugins-for-kdevelop/

Voilà qui va mettre Flanker à KDevelop (la version OS X sort bientôt ).

Ton lien est intéressant. Voici aussi les 3 projets de plugins du GSoC :
https://www.google-melange.com/gsoc/project/details/google/gsoc2015/sklin/5634387206995968
https://www.google-melange.com/gsoc/project/details/google/gsoc2015/maciej_poleski/5639274879778816
https://www.google-melange.com/gsoc/project/details/google/gsoc2015/dfighter1985/5897337989758976

En espérant que les efforts ne sont pas trop dispersés, car il semble y avoir des recouvrements. On verra bien.

Malheureusement, le plugin JSHint est inutilisable parce que JSHint est non-libre. (C'est une œuvre dérivée de JSLint, dont la licence interdit l'utilisation pour "Evil".)

[03/09/2015 16:27:59] <kfunk> lots of new features in master already, we should try to get it out to the public sooner rather than later
....
[03/09/2015 16:48:04] <milian> if you do that, I'll create a first release tomorrow

\o/

(ayé : https://www.kdevelop.org/news/first-beta-release-kdevelop-500-available )

Oui, enfin!

Cela dit, l'utilisation de Clang pour le parsing, annoncée et développée depuis longtemps, me fait un peu peur, parce que ça risque de marcher très mal avec les sources qui ne compilent pas avec Clang. Et Clang n'est toujours pas fichu gérer correctement des fonctionnalités essentielles comme par exemple les tableaux de taille variable en C++.

Tu parle du truc qui est GNU only et non dans les standard du C++ ?
Si ce n'est pas dans le standard ce n'es pas pour rien.

Non, c'est du C++ 14.
Kevin -> Comme ils l'expliquent, ça permet de consacrer du manpower ailleurs que dans l'évolution du parseur perso, et c'est pas idiot comme idée.:

De ce que j'ai vu les VLA (au sens C99) ne sont pas dans le standard C++ o_O

(et de toute maniere c'est une sacres connerie que ce truc mis dans le C99.. a vrai dire l'evolution du C est douteuse, le C99 a apporte pas mal de truc important interessant, mais aussi des trucs douteux comme le type _Bool, et un gros manque de coherence, et les standard suivant sont de pire en pire..)

Folco (./38) :
Non, c'est du C++ 14.

Malheureusement, ça a été retiré du C++14 et repoussé à date indéterminée. Par conséquent, g++ est revenu à son implémentation GNU existante (même en mode C++14). Clang veut toujours implémenter le draft tel quel, mais ce n'est pas fait, du moins pas de manière complète.

Et en C, ce qui manque le plus à Clang, ce sont les fonctions imbriquées (nested). (On ne peut pas les utiliser en C++ parce que g++ ne les gère pas non plus malheureusement, seulement le frontend C.)

les fonctions imbriquées ne sont pas non plus standard.

quand aux VLA, GNU C les alloue sur la pile. Non merci.

Warpten (./41) :
les fonctions imbriquées ne sont pas non plus standard.

Je sais. Je m'en fous. GCC compile mon code, donc si un autre compilateur ne l'accepte pas, il est moins bien que GCC.

quand aux VLA, GNU C les alloue sur la pile. Non merci.

C'est exactement le but des VLAs. Si je veux un truc alloué sur le tas, j'utilise malloc (ou new[] en C++).

Si tu veux des fonctions imbriquées, propose de nommer les lambdas dans un draft pour C++17 ?

Du code "public" doit pouvoir compiler, que ce soit avec GCC, Clang, ou msbuild. Le compilo, on s'en branle, si ton code est standard il passe partout.

[EDIT] Oh bah. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2511.html Vieux, par contre

[EDIT2] J'avais oublié std::function.

void foo()
{
std::function<int(int)> f = [=](int n){return 2*n; };
std::cout << f(10);
}

(J'avoue, je n'ai jamais été un grand fan de la syntaxe des lambdas)

(Les templates sont vraiment immondes)

Bah c'est ni plus ni moins que l'équivalent d'un typedef de fonction? Ces machins ont toujours été moches, encore plus quand tu fais du détour et que tu dois indiquer la convention d'appel (surtout quand tu détournes des thiscall, obligé de passer par un fastcall avec un paramètre en trop)
void empty() { } typedef void(*foo)(); std::function<foo> a = &empty; // Equivalent std::function<void(void)> b = &empty; // Equivalent

Ha non, un typedef de fonction n'a rien a voir avec les templates.. (et on n'utilise normalement un typedef sur un prototype uniquement pour faire des callback, ca n'a aucune autre utilite en C.

Et non serieusement plus je vois du code C++ avec template moins j'ai envie de refaire du C++, c'est je crois une des pires choses du C++..

Grave, plus je vois des templates, plus je m'éloigne de la STL

(et on n'utilise normalement un typedef sur un prototype uniquement pour faire des callback, ca n'a aucune autre utilite en C.

Et tant qu'on a pas compris ça, on cherche comme un damné à faire ces foutues callbacks
C'est toi qui m'avait indiqué le truc, et depuis, bizarrement, ça va beaucoup mieux.

Tu peux faire sans ceci dit, c'est juste chiant a taper

J'ai jamais réussi sans un typedef...

Les templates c'est le bien. Sur des size_t non, mais sur des types, c'est parfait pour gérer le polymorphisme... (C'est le but, à la base)

Warpten (./41) :
quand aux VLA, GNU C les alloue sur la pile. Non merci.

Tu voudrais les allouer où ?

Nouvelle release de KDevelop pour Windows : http://krf.kollide.net/files/work/kdevelop/
Buildé à ma demande, ce matin sur IRC, j'admire les devs Faut dire que la release précédente datait d'août, donc vu le rythme de développement, ça commençait à être dur de donner un bon support.

"Hé les gars, on a un utilisateur, sortez le champagne !"

ben sous windows, comme c'est nouveau, encore en bêta, c'est pas étonnant ^^
c'est plus le testeur que l'utilisateur dont ils ont besoin.

Bon, au moins ça marche \o/ Faut juste le lancer depuis un shell VS2015, c'est le côté bêta faut pas s'inquiéter
Ah, maintenant, faut que j'apprenne à adapter un CmakeLists.txt pour nux et windows à la fois. J'imagine que c'est prévu pour de toute façon, non ? Juste à trouver les bonnes instructions ^^

Oui, la portabilité est un des principaux buts de CMake, ça ne s'appelle pas "Cross-platform Make" pour rien.

Et ça, c'est portable ?

In order for find_package to be successful, Qt 5 must be found below the CMAKE_PREFIX_PATH, or the Qt5<Module>_DIR must be set in the CMake cache to the location of the Qt5WidgetsConfig.cmake file. The easiest way to use CMake is to set the CMAKE_PREFIX_PATH environment variable to the install prefix of Qt 5.

Donc autant hardcoder les chemins plutôt que d'utiliser leurs variables générées automatiquement, au moins on sait où on met les pieds, de toute façon il faut faire le travail...

Bah, sous un système d'exploitation bien fichu, le paquetage s'installe dans le CMAKE_PREFIX_PATH par défaut.

Et si tu as ton dossier Qt/bin dans ton PATH (ce qui est de toute façon une bonne idée si tu veux pouvoir appeler les outils de Qt en ligne de commande), find_package trouvera automatiquement le dossier parent comme un préfixe (cf. entrée 4. dans la liste).

Merci, mais ça ne fonctionne pas non plus. Il doit y avoir autre chose, et comme pour le moment ça compile, ça attendra.

Bon, j'ai avancé.
J'ai ça :

find_package(Qt5Core REQUIRED)

link_directories(
    C:/Qt/Qt5.5.1/5.5/msvc2013/lib
#    ${Qt5Core_LIBRARY_DIRS}
    )

include_directories(
    ${Qt5Core_INCLUDE_DIRS}
    )

target_link_libraries(
    imPG2
    Qt5Core
    )

Deux choses : J'arrive pas à me passer de link_directories, ce qui me parait normal pour le linker, et pourtant la doc dit que c'est rarement utilisé, target_link_libraries devant faire le boulot.
Ensuite, pour target_link_libraries, si je remplace Qt5Core par Qt5::Core ou autre variable sensée faire ce boulot, ça compile, ça linke, mais ça crashe instantanément au lancement de l'exécutable (j'ai pas de détails sur le crash).

Une idée ?