Une autre source de undefined behaviour est quand on a des pointeur extern "C"
Par exemple:
extern "C" int my_function(int); // Une fonction d'une bibliothèque C
int foo() {
int (*f)(int) = my_function; // Compile sans warnings
f(42); // undefined behaviour
// undefined behaviour dans function_cast::operator()
return apply(my_function);
}
Peux tu détailler l'origine de ce comportement indéfini ? Je pensais que extern "C" changeait juste le name mangling, ça changerait aussi la convention d'appel?
Derrière la petite pique trollesque, tu pointes du doigt un vrai problème, qui est cependant partagé par d'autres couples (langage , compilateur) : le langage donne très peu de garantie d'optimisation ou non de certaines constructions, et le développeur en est réduit à faire confiance au compilateur pour apporter les propriétés de performance, abstraction à coût zéro etc. Autrement dit la phrase « C++ donne du code rapide » est bien moins pertinente que « GCC arrive généralement a compiler efficacement un code C++ ». Ce n'est pas du tout une propriété du langage, et du coup il est difficile de raisonner dessus…
un problème dont on n'est pas sûr qu'il en soit un
J'ai effectivement assez peu motivé mon cas d'usage. Si tu as une structure de tableau qui a comme variable membre un tableau qui contient à chaque indice le nombre d'éléments dans cette dimension, par exemple :
Si l'utilisateur sait que la dernière dimension vaut toujours 3, par exemple parce que c'est une matrice de pixels, cette représentation va être pénalisante quand on voudra par courir la dernière dimension, car le compilateur n'a pas moyen d'éviter l'itération. En résultent des temps d'exécution déplorables.
for(long i = 0, n = a.shape[2]; i < n; ++i)
a.data[index(i)];
Si on encode dans le type de shape l'information comme quoi la dernière dimension est constante (et petite), et que cette constante est connue, on arrive à
C'est surtout lors des rebuilds que ninja brille (curieux pour une profession de l'ombre, n'est ce pas ?). Comme le dit cet article c'est surtout valable pour les softs de grosse taille, mais à ce niveau ça devient significatif.
Une présentation par le dev de meson qui complète bien ce journal.
C'est effectivement totalement (shellement?) ironique. J'avais laissé la porte ouverte pour faire ça, mais une petite porte. Et voilà que des gens s'engouffrent dedans avec enthousiasme.
complètement :-/ Tu remarqueras aussi le joli travail de l'éditeur qui a pas été fichu de faire le rendu correct des commandes laTeX (bon, j'aurais du mieux relire son pre print aussi hein)
Dans ce cas le decltype dépend du type de retour de la lambda, ce qui rentre dans la catégorie lambda expression in unevaluated context et c'est interdit. Mais ça passe en c++14 il me semble (vu que le type de retour est inféré).
C'est pour supporter l'argument axis de numpy.argmin ou numpy.argmax dans pythran. Le commit complet, à peu près autour de la bonne ligne, est là :
https://github.com/serge-sans-paille/pythran/pull/803/files#diff-b20072554ff33a1cd786318f40ff0368R110 (attention, réponse demandant un peu de connaissance de l'API numpy)
Comme le paramètre d'entrée est une expression-tableau de dimension N (paramètre template), et qu'on veut calculer argmin en suivant l'axe axis (paramètre non connu à la compilation), il faut générer les N patrons de boucle possibles suivant la valeur de l'axe.
Petit exemple pour N = 3, on peut vouloir générer (cas du min qui est un peu plus simple, mais c'est l'idée)
[^] # Re: extern "C", pointer to member function,
Posté par serge_sans_paille (site web personnel) . En réponse au journal Conversion entre pointeurs de fonctions incompatibles. Évalué à 2.
Peux tu détailler l'origine de ce comportement indéfini ? Je pensais que
extern "C"
changeait juste le name mangling, ça changerait aussi la convention d'appel?[^] # Re: Mensonges !
Posté par serge_sans_paille (site web personnel) . En réponse au journal Conversion entre pointeurs de fonctions incompatibles. Évalué à 3.
Un cas proche dans LLVM (bon, plus exactement dans compiler-rt), mais qui porte sur le type de retour :
https://github.com/llvm-mirror/compiler-rt/blob/23b063668e563dd5cc8fc37e00c3199a9afa595f/lib/sanitizer_common/sanitizer_linux.cc#L1715
On retrouve la même dans https://github.com/python/cpython/pull/6008 d'ailleurs.
Un autre cas détecté par GCC qui fait froid dans le dos
[^] # Re: C'est mieux si les paramètres sont inconnus lors de la compilation
Posté par serge_sans_paille (site web personnel) . En réponse au journal Mémorisation partielle de fonction constexpr. Évalué à 4. Dernière modification le 26 septembre 2018 à 20:28.
Complètement d'accord, mon exemple est bien mauvais :-) Merci d'avoir pointé ça !
[^] # Re: Ça pique les yeux
Posté par serge_sans_paille (site web personnel) . En réponse au journal Mémorisation partielle de fonction constexpr. Évalué à 7. Dernière modification le 25 septembre 2018 à 20:41.
Si ça peut te rassurer, ou à défaut t'arracher un sourire, j'ai un sentiment similaire en assistant à CppCon. On est tous le noob de quelqu'un :-)
[^] # Re: simd explicite ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran - 0.8.7. Évalué à 3.
Pour xsimd, non (la lib fournit une abstraction des registres vectoriels).
Pour sleef, elle fournit de nouvelles fonctions compatibles avec l'usage d'intrinsèques, comme le montre cet exemple tiré de leur doc
[^] # Re: simd explicite ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran - 0.8.7. Évalué à 3.
Ce qui répond un peu à la question :-) Il y a plusieurs libs qui fournissent une version vectorisée de la makorité des fonctions de la lib math, p.e. https://software.intel.com/en-us/node/524352, http://sleef.org/, ou https://github.com/QuantStack/xsimd. Pythran utilise ces libs car le compilo ne le fait pas (mais ça bouge, et llvm sait représenter ça au niveau IR, cf. https://reviews.llvm.org/D24951)
[^] # Re: simd explicite ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran - 0.8.7. Évalué à 3.
Malheureusement non. Petit exemple qui illustre mes propos : https://godbolt.org/z/pNNPhx
[^] # Re: static if -> if constexpr
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran - 0.8.7. Évalué à 3.
Tu as… carrément raison :-) Merci pour la piqure de rappel, les exemples ont été écrits de tête, je serais surpris que ce soit la seule erreur…
# Edit
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran - 0.8.7. Évalué à 1.
Mouarf, je me suis vautré sur l'indentation des listes à puces, si un modo peut modifier ça, c'est cool !
# Début de solution
Posté par serge_sans_paille (site web personnel) . En réponse au message script pour déplacer des fichiers vers répertoires de même noms. Évalué à 3. Dernière modification le 04 septembre 2018 à 09:20.
En shell POSIX, pour déplacer une fichier vers un répertoire qui porte son nom, tu peux utiliser ça :
[^] # Re: Godbolt
Posté par serge_sans_paille (site web personnel) . En réponse au journal Le quiz c++ de l'été. Évalué à 7.
Derrière la petite pique trollesque, tu pointes du doigt un vrai problème, qui est cependant partagé par d'autres couples (langage , compilateur) : le langage donne très peu de garantie d'optimisation ou non de certaines constructions, et le développeur en est réduit à faire confiance au compilateur pour apporter les propriétés de performance, abstraction à coût zéro etc. Autrement dit la phrase « C++ donne du code rapide » est bien moins pertinente que « GCC arrive généralement a compiler efficacement un code C++ ». Ce n'est pas du tout une propriété du langage, et du coup il est difficile de raisonner dessus…
# Mort à toutes les polices
Posté par serge_sans_paille (site web personnel) . En réponse au journal Répliquer ses vidéos Peertube − premiers pas. Évalué à 6.
Et pourtant il y a plein de polices utiles voire très jolies !
[^] # Re: Le C++ est terrible... et ce journal l'illustre bien
Posté par serge_sans_paille (site web personnel) . En réponse au journal Une structure partiellement constante en C++. Évalué à 10.
J'ai effectivement assez peu motivé mon cas d'usage. Si tu as une structure de tableau qui a comme variable membre un tableau qui contient à chaque indice le nombre d'éléments dans cette dimension, par exemple :
Si l'utilisateur sait que la dernière dimension vaut toujours 3, par exemple parce que c'est une matrice de pixels, cette représentation va être pénalisante quand on voudra par courir la dernière dimension, car le compilateur n'a pas moyen d'éviter l'itération. En résultent des temps d'exécution déplorables.
Si on encode dans le type de
shape
l'information comme quoi la dernière dimension est constante (et petite), et que cette constante est connue, on arrive àet le compilo aura toutes les informations pour dérouler complètement l'itération.
J'espère que maintenant qu'elle est motivée, son intérêt transparait mieux :-)
Le demi-sec, c'est moyen, j'ai une nette préférence pour le brut bien râpeu, mais bon, les goûts et les couleurs…
[^] # Re: Analyse très subjective!
Posté par serge_sans_paille (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 5.
C'est surtout lors des rebuilds que ninja brille (curieux pour une profession de l'ombre, n'est ce pas ?). Comme le dit cet article c'est surtout valable pour les softs de grosse taille, mais à ce niveau ça devient significatif.
Une présentation par le dev de meson qui complète bien ce journal.
# build sous android
Posté par serge_sans_paille (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 3.
On notera que depuis quelques temps, ils offrent aussi une intégration à CMake.
[^] # Re: Liste des fonctions de numpy supportées
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran, en plein délire. Évalué à 4.
http://pythran.readthedocs.io/en/latest/SUPPORT.html
Tu y liras que
np.mgrid
n'est pas supporté. Je vais jouer avec ton bout de code, il est marrant. J'ai ouvert un ticket dessus pour garder une trace https://github.com/serge-sans-paille/pythran/issues/918[^] # Re: bidouille
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran, en plein délire. Évalué à 7.
C'est effectivement totalement (shellement?) ironique. J'avais laissé la porte ouverte pour faire ça, mais une petite porte. Et voilà que des gens s'engouffrent dedans avec enthousiasme.
Je jubile.
[^] # Re: Au passage : Pythran: Crossing the Python Frontier
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pythran, en plein délire. Évalué à 4.
complètement :-/ Tu remarqueras aussi le joli travail de l'éditeur qui a pas été fichu de faire le rendu correct des commandes laTeX (bon, j'aurais du mieux relire son pre print aussi hein)
[^] # Re: XPM
Posté par serge_sans_paille (site web personnel) . En réponse au journal Pixel Art et C++14. Évalué à 2.
Mais mais… tu as raison, très amusant ce petit format :-)
[^] # Re: Pas C++11
Posté par serge_sans_paille (site web personnel) . En réponse au journal Obfusque ton code avec C++. Évalué à 2.
Si tu lis bien le code
std::make_index_sequence
n'est pas utilisé, mais une version naïve est fournie.Quant au plantage sous GCC, je le constate aussi, mais je l'attribuerai plutôt à une limitation de GCC :-)
[^] # Re: Sans macro
Posté par serge_sans_paille (site web personnel) . En réponse au journal Obfusque ton code avec C++. Évalué à 3.
J'aurais bien aimé, mais non, la raison étant que si on passe par une fonction template on aurait un truc du genre
(parenthèsage non contractuel).
Dans ce cas le
decltype
dépend du type de retour de la lambda, ce qui rentre dans la catégorie lambda expression in unevaluated context et c'est interdit. Mais ça passe en c++14 il me semble (vu que le type de retour est inféré).[^] # Re: Namespace bits ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Jouons avec le ``switch`` et C++17. Évalué à 4.
Ça s'appelle Boost.operators non ?
[^] # Re: Lisibilité
Posté par serge_sans_paille (site web personnel) . En réponse au journal Jouons avec le ``switch`` et C++17. Évalué à 8.
C'est pour supporter l'argument
axis
denumpy.argmin
ounumpy.argmax
dans pythran. Le commit complet, à peu près autour de la bonne ligne, est là :
(attention, réponse demandant un peu de connaissance de l'API numpy)https://github.com/serge-sans-paille/pythran/pull/803/files#diff-b20072554ff33a1cd786318f40ff0368R110
Comme le paramètre d'entrée est une expression-tableau de dimension
N
(paramètre template), et qu'on veut calculerargmin
en suivant l'axeaxis
(paramètre non connu à la compilation), il faut générer les N patrons de boucle possibles suivant la valeur de l'axe.Petit exemple pour N = 3, on peut vouloir générer (cas du min qui est un peu plus simple, mais c'est l'idée)
le code pointé plus haut génère ces différentes boucles quelque soit
N
, dans le cas deargmin
, en gardant un typage correct.Je ne sais pas si je suis clair :-/
[^] # Re: Namespace bits ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Jouons avec le ``switch`` et C++17. Évalué à 4.
La fonction template en question est marquée
noinline
, ceci explique cela :-)[^] # Re: Namespace bits ?
Posté par serge_sans_paille (site web personnel) . En réponse au journal Jouons avec le ``switch`` et C++17. Évalué à 4.
complètement !
On peut aussi voir ça comme un exercice de style, une sorte de jeu, ce qui est le cas de ce journal :-)