stdatomic.h & g++ - Page 1

Je tiens à pousser un coup de gueule contre le fait que stdatomic.h (header standard du C11) soit inutilisable avec G++ !
Le moindre source aussi simple soit-il, par exemple juste : #include <stdatomic.h> induit des erreurs à la pelle :

error: ‘_Atomic’ does not name a type

Le bug a été remonté https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
Conclusion: not a bug.
Solution de contournement officielle 1: #if !__has_extension(c_atomic) && !__has_extension(cxx_atomic) #define _Atomic(T) struct { T volatile __val; } #endif (mais ca ne résoud pas tous les problèmes)
ou #ifdef __cplusplus #include <atomic> using namespace std; #else #include <stdatomic.h> #endif (on appréciera le using namespace std inconditionnel).

Ils auraient du proposer un DTC, ca serait mieux passer !

Résultat: si la moindre librairie C utilise stdatomic.h dans ses headers, alors le pauvre programmeur C++ ne pourra rien en faire et serra coincé !
Au moins clang définit _Atomic... mais pas _Bool !

Normalisation et/ou standardisation non effectuée par les personnes concernées ?

Discussion non finie semblerait-il :
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3137.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html

On va peut être se limiter au C89, en espérant que ce soit révisé et stable maintenant.

Heu ......

#include <atomic> ??????

PpHd (./1) :
si la moindre librairie C utilise stdatomic.h dans ses headers, alors le pauvre programmeur C++ ne pourra rien en faire et serra coincé !

atomic est C++ only.

Ok, j'ai mal lu

Tu devrais faire comme les développeurs de GCC font eux-mêmes: un script fixincludes qui patche les headers de GCC pour qu'ils fonctionnent convenablement.

Ou utiliser un compilateur qui fonctionne.

En plus, je me rends compte que la solution #ifdef __cplusplus #include <atomic> using namespace std; #else #include <stdatomic.h> #endif ne marche pas non plus !

J'ai des warnings à l'édition de lien (avec -flto):

type of ‘my_func’ does not match original declaration [-Wlto-type-mismatch]

et my_func est une fonction dont la déclaration utilise une structure utilisant des atomic_int... Il détecte donc que les structures sont incompatibles

C'est le C++ qu'il faut taper et non le C.

Ce n'est pas la seul fonction des revisions récente du C que les gens qui se pensent mieux que tout le monde qui définissent le C++ refuse d'ajouter (genre l'initialisation nommée pour les structures)

Godzil (./11) :
(genre l'initialisation nommée pour les structures)

Tu veux parler des listes d'initialiseurs? C'est la merde, aucun compilo gère ça pareil, du coup perso je préfère éviter.

Heu, le C99 a définie ca clairement:
struct toto { int bla, blo, blu; }; struct toto tata = { 1, 2, 3 }; struct toto titi = { .bla = 1, .blo = 2, .blu = 3, };

Maya:Desktop godzil$ cat test.c 
struct toto
{ 
 int bla, blo, blu;
};

struct toto tata = { 1, 2, 3 };
struct toto titi = {
  .bla = 1,
  .blo = 2,
  .blu = 3,
};

Maya:Desktop godzil$ clang -Wall -c test.c -o test.o
Maya:Desktop godzil$ 

Si ton compilateur ne supporte pas ca, tu peux le foutre a la poubelle des non C99 compliant. (et cette facon de faire est la seule officiel, meme GCC a supprimé sa version (moche) antérieur au profit de la version C99

Ca, j'en suis fan, perso je définis toutes mes api sous forme de structure comme présenté ici :

http://stackoverflow.com/questions/1472138/c-default-arguments#answer-7937139

De fait, avec un peu d'écriture (struct pour l'api + prototype + macro) on obtient :

- du C avec paramètres par défaut
- paramètres pouvant être écrit dans le désordre
- si l'ordre des membres de la structure change, ce n'est pas grave
- bien plus lisible, mais légèrement plus verbeux à écrire

Et ouais, on serait à même d'attendre un minimum des compilateurs, en 2016.

./13 Je n'avais pas compris ça. m'en suis jamais servi.

Ben si tu fait du C++ tu peux oublier parceque les (idiots) qui définissent la norme C++ dans leur soucis de faire compatible avec le C (rappel, le C++ est une surcouche au C, et non un nouveau language) ils n"ont pas voulu integrer cette fonctionnalité dans le C++..

bref

Il me semblait que le C++ n'était pas une surcouche (en tout cas maintenant) du C, justement ? Contrairement à l'ObjectiveC (n'importe quel code C peut compiler avec un compilo ObjC).

Je trouve ça curieux d'appeler ça une surcouche de toute façon, à partir du moment où il y a un compilateur standalone qui compile en assembleur, et des incompatibilités source (sans même parler de stdatomic).

Historiquement c'est une surcouche, et ca reste une extension du C.

D'ailleurs, c'est rare d'avoir un compilateur qui ne fait que le C++, les languages partagent beaucoup.

Stroustrup a forké à la base on est d'accord, mais aujourd'hui c'est devenu incompatible. Mais oui, les langages partagent beaucoup.
Ceci dit : https://fr.vikidia.org/wiki/C%2B%2B

Le C++ est, contrairement aux préjugés, un langage bien différent du C : Ce n'est pas une surcouche de celui-ci, contrairement à l'opinion de nombreux débutants. D'ailleurs, un code C ne compilera pas forcément avec un compilateur C++ (implicit cast de void*, etc...)

Je n'aurai pas l'effronterie de te traiter de débutant, mais ici et là il y a des explications intéressantes expliquant que ce n'est pas le cas.

Quel noob ce Godzil

Change de crémerie, je ne connais pas vikidia, mais ce n'est pas la vérité, ou du moins extrêmement parcellaire car :

Stroustrup commença à améliorer le langage C avec des fonctionnalités similaires à celle de Simula. C fut choisi parce qu'il est rapide, portable et d'usage général. En outre, il était une bonne base pour le principe original et fondateur de C++ : « vous ne payez pas pour ce que vous n'utilisez pas ». Dès le départ, le langage ajoutait à C la notion de classe (avec encapsulation des données), de classe dérivée, de vérification des types renforcés (typage fort), d'« inlining », et d'argument par défaut.

Comme Stroustrup développait C avec classes, il écrivit CFront, un compilateur qui générait du code source C à partir de code source C avec classes. La première commercialisation se fit en octobre 1985. En 1983, le nom du langage passa de C avec classes à celui de « C++ ». Parmi les nouvelles fonctionnalités qui furent ajoutées au langage, il y avait les fonctions virtuelles, la surcharge des opérateurs et des fonctions, les références, les constantes, le contrôle du typage amélioré et les commentaires en fin de ligne.

Le C++ est bel et bien une extension du C, et ce qui a rendu le C et le C++ incompatible sur certains points, sont principalement les nouvelles extensions du C (C99 et +) que le comité du C++ a refusé d'intégrer.

Et pour ce qui est de l'Objective C, oui c'est une surcouche bien plus evidente vu que le language ObjectiveC est un language dans le C, il utilise le C pour tout ce qui ne lui est pas natif, c'est d'ailleur de la que viens le Swift, garder le coeur d'ObjectiveC et lui ajouter ce qui manque a language pour etre 100% autonome.

Et l'article sur CFront le confirme: https://en.wikipedia.org/wiki/Cfront
Qu'on retrouve aussi partiellement sur la FAQ de BS: https://web.archive.org/web/20111029054653/http://www.research.att.com/~bs/bs_faq.html#bootstrapping

Simulation du C++ à partir du C :

http://gnu.gds.tuwien.ac.at/directory/all/lwc.html
https://github.com/funny-falcon/lwc

Ce truc est encore plus incompatible avec le C que le C++, par exemple, il passe toutes les structures par référence!

Dans la vie, y'a quelque chose qui arrive encore à t'émouvoir ?

Positive++ un peu et apprécie la performance.

./10: Bug report ouvert https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71789

Et si tu ajoutes tout simplement -Wno-lto-type-mismatch -fno-strict-aliasing aux flags de compilation?

le c amélioré, maintenant, c'est vala.

Le Vala est un langage totalement GNOME-only, l'objet de base est GObject, donc si tu veux utiliser par exemple Qt, c'est mal parti.

mais QT c'est du C++ sucré aussi, spas vraiment mieux, spice de fanboy