[C++] Obtenir le thread_id d'un thread

[invite48ca7510]

Bonjour à tous,

Je souhaite obtenir l'id de threads que je créé, mais je n'y parviens pas (la valeur retourné est à chaque fois la même)

J'ai un programme principal (main), dans lequel je créé 8 agents (OperationThread) de cette manière

for(int i = 0; i < 8; i++){
     OperationThread *opThr = new OperationThread();
}

Le constructeur de OperationThread ressemble à ça :

OperationThread::OperationThread(){
     pthread_create(&this->tid, nullptr, &laFonctionQueLeThreadDoitLancer, desParams);

}

(tid est un attribut privé de la classe OperationThread, de type pthread_t)

Lorsque dans la fonction laFonctionQueLeThreadDoitLance r, j'affiche pthread_self();, j'obtiens 8 fois la même valeurs, alors que je pensais que chacun des threads allait avoir un id différent...

Auriez-vous une idée ?

Je vous remercie par avance !
-----

[polo974]

tu ranges tes 8 OperationThread dans le même opThr...

du coup, tu ne peux accéder qu'au dernier...

tu dois utiliser un tableau ou une liste ou ... dans ton for.

[inviteb9f49292]

tu ranges tes 8 OperationThread dans le même opThr...

Si je calque ce que je crois savoir en C ça devrait fonctionner il me semble... L'instance de classe est locale au corps de boucle, donc à chaque passage de boucle "opThr" devrait être une nouvelle instance. A moins qu'il n'y ait un "static" qui traîne quelque part. Ceci dit (et si je ne dis pas une connerie), c'est vrai que du coup tu perds les références sur les instances de classe qui tu as créé dans ta boucle, pourtant il faudra que tu y accèdes, au moins pour libérer la mémoire, i.e. appeler le "delete" sur toutes les instances créées avec "new"

[invite48ca7510]

Merci pour vos réponses.

Je vais tenter de mettre tout ça dans un tableau ou une liste et je vous tiens au courant !

Merci en tout cas

[A voir en vidéo sur Futura]

[invite48ca7510]

Bonsoir,

je viens de ré-essayer, sans succès

Voici mon code main :

std::vector<OperationThread*> vectTmpThead(8);

for (int i = 0; i < vectTmpThead.size(); i++) {
	vectTmpThead[i] = new OperationThread());
	
}

Et encore une fois, tous ont le même id ...

[inviteb9f49292]

J'étais en train d'écrire un petit test quand je me suis posé la question, comment fais tu pour afficher le tid ?
Le problème vient peut-être de ce côté-ci ?

[invite48ca7510]

Jusqu'à tout à l'heure, mon compilo acceptait le (unsigned long int) this->tid, mais là, plus rien (erreur: conversion impossible de pthread_t vers unsigned long) ...

Bizarre tout ça...
Vous avez une idée de comment l'obtenir ?

[inviteb9f49292]

Jusqu'à tout à l'heure, mon compilo acceptait le (unsigned long int) this->tid, mais là, plus rien (erreur: conversion impossible de pthread_t vers unsigned long) ...

attention aux casts en C++

Vous avez une idée de comment l'obtenir ?

Je viens de faire le test:

include <pthread.h>
#include <stdio.h>

struct thread_data_t {
    pthread_t tid;
    int arg;
    int ret;
};

static void * _dummy (void * arg) {
    struct thread_data_t * data = (struct thread_data_t *) arg;
    printf ("tid = %x (%x), arg = %d, ret = %d\n",
            data->tid, pthread_self (), data->arg, data->ret);
    return arg;
}

#define THREADS_NB 8

int main (void) {
    int k;
    for (k = 0; k < THREADS_NB; k++) {
        struct thread_data_t data;
        data.arg = k;
        data.ret = pthread_create (&data.tid, NULL, _dummy, &data);
        if (data.ret >= 0) {
            printf ("thread %d (%x) created\n", data.arg, data.tid);
            pthread_join (data.tid, NULL);
            printf ("thread %d (%x) finished\n", data.arg, data.tid);
        } else {
            printf ("thread %d error %d\n", k, data.ret);
        }
    }
    return 0;
}

avec "gcc -pthread thread_test.c" ça marche, remplacez gcc par g++ et ça ne marche plus...

(on se tuvoie ?)

[invite48ca7510]

Avec un (unsigned int)pthread_self, aucun problème de compilation.

Par contre, les 8 threads ont le même id ...

Peut-être est-ce à cause de l'instanciation (dans le main) ?

[invite473b01b1]

Salut,

pthread est une librairie C qui fonctionne avec des méthodes statiques, il faut donc créer une méthode statique à laquelle tu passeras l'instance de ta classe et qui appellera la méthode voulue...

Voir l'exemple ici, ils montrent un exemple en C et un en C++.

[inviteb9f49292]

OK je pense que j'ai compris (pour le C en tout cas).

Mon bout de code ne marche que par chance, tout ce qui est déclaré dans la boucle doit se fait à la même adresse.
Tu étais dans le même cas temps que tu n'utilisais pas de "vector".

Pour l'identifiant du thread, il ne semble valide qu'après la sortie du "pthread_create", ou par l'intermédiaire de "pthread_self" quand le thread à commencer.

Pour la blague de l'unsigned int, ça ne m'étonne qu'à moitié avec le C++...

[inviteb9f49292]

Voir l'exemple ici, ils montrent un exemple en C et un en C++.

Par contre l'exemple en C++, il pique les yeux ou c'est moi qui n'ai pas l'habitude... Heureusement que j'ai les QThread pour faire du C++...

[invite473b01b1]

Par contre l'exemple en C++, il pique les yeux ou c'est moi qui n'ai pas l'habitude... Heureusement que j'ai les QThread pour faire du C++...

C'est un code d'exemple avec pas mal de print... Si on les enlève il ne reste presque rien, à moins que tu n'aies "scrollé" trop vite et que tu sois tombé directement sur le deuxième exemple C++ qui est plus complet et effectivement un peu plus "barbare"!

Pour les QThread, si je me souviens bien il faut soit implémenter l'interface ce qui peu vite devenir assez "lourd", soit utiliser QConcurrent::run() ou truc du genre et qui sera géré par un thread pool de Qt...

[inviteb9f49292]

Je devais être trop fatigué hier soir... je ne voudrais pas laisser des imprécisions à mon nom traîner sur le net...
Le code un peu modifié:

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>

struct thread_data_t {
    pthread_t tid;
    int arg;
    int ret;
};

static void * _dummy (void * arg) {
    struct thread_data_t * data = (struct thread_data_t *) arg;
    printf ("\tTHREAD pthread_self %x: arg@%p, "
            "arg->tid = %x, arg->arg = %d, arg->ret = %d\n",
            (unsigned int) pthread_self (), arg,
            (unsigned int) data->tid, data->arg, data->ret);
    return arg;
}

#define THREADS_NB 8

int main (void) {
    int k;
    for (k = 0; k < THREADS_NB; k++) {
        #if 1
        struct thread_data_t* data = (struct thread_data_t*) malloc (sizeof(struct thread_data_t));
        data->arg = k;
        data->ret = 12345;
        data->ret = pthread_create (&data->tid, NULL, _dummy, data);
        if (data->ret >= 0) {
            printf ("MAIN thread#%d, tid %x, created\n",
                    data->arg, (unsigned int) data->tid);
        } else {
            printf ("MAIN thread %d error %d\n", k, data->ret);
        }
        #else
        struct thread_data_t data;
        data.arg = k;
        data.ret = 12345;
        data.ret = pthread_create (&data-tid, NULL, _dummy, data);
        if (data.ret >= 0) {
            printf ("MAIN thread#%d, tid %x, created\n",
                    data.arg, (unsigned int) data.tid);
        } else {
            printf ("MAIN thread %d error %d\n", k, data.ret);
        }
        #endif
    }
    while (1) {};
    return 0;
}

Comme je le disait, mon exemple en C ne pouvais pas marcher à cause de l'allocation statique de la structure sur la pile (stack), du coup toujours à la même l'adresse, les appels successifs à pthread_create écrase le contenu de la structure alors qu'elle n'a pas forcément été consommée par le thread créé. Un exemple en faisant tourner le code ci-dessus (avec le #if à 0):

MAIN thread#0, tid e0283700, created
	THREAD pthread_self e0283700: arg@0x7ffeb172bd40, arg->tid = e0283700, arg->arg = 0, arg->ret = 0
MAIN thread#1, tid dfa82700, created
	THREAD pthread_self dfa82700: arg@0x7ffeb172bd40, arg->tid = dfa82700, arg->arg = 2, arg->ret = 12345
MAIN thread#2, tid df281700, created
	THREAD pthread_self df281700: arg@0x7ffeb172bd40, arg->tid = df281700, arg->arg = 3, arg->ret = 12345
MAIN thread#3, tid dea80700, created
	THREAD pthread_self dea80700: arg@0x7ffeb172bd40, arg->tid = dea80700, arg->arg = 3, arg->ret = 0
MAIN thread#4, tid de27f700, created
	THREAD pthread_self de27f700: arg@0x7ffeb172bd40, arg->tid = de27f700, arg->arg = 5, arg->ret = 12345
MAIN thread#5, tid dda7e700, created
MAIN thread#6, tid dd27d700, created
	THREAD pthread_self dda7e700: arg@0x7ffeb172bd40, arg->tid = dca7c700, arg->arg = 7, arg->ret = 12345
MAIN thread#7, tid dca7c700, created
	THREAD pthread_self dd27d700: arg@0x7ffeb172bd40, arg->tid = dca7c700, arg->arg = 7, arg->ret = 0
	THREAD pthread_self dca7c700: arg@0x7ffeb172bd40, arg->tid = dca7c700, arg->arg = 7, arg->ret = 0

On voit bien que le dernier appel a pthread_create écrase le contenu de la structure (regarder les arg->tid, arg->arg et arg->ret).
Si j'alloue sur le tas (heap), ce qui ressemble plus au bout de code initial puisqu'il y a un new (utiliser la branche #if 1 du code ci-dessus), alors tout ce passe bien et je n'observe plus la différence que je voyais hier entre le tid "retourné" par pthread_create et celui de pthread_self:

MAIN thread#0, tid 70ac700, created
	THREAD pthread_self 70ac700: arg@0x20f1010, arg->tid = 70ac700, arg->arg = 0, arg->ret = 0
MAIN thread#1, tid 68ab700, created
	THREAD pthread_self 68ab700: arg@0x20f1150, arg->tid = 68ab700, arg->arg = 1, arg->ret = 0
MAIN thread#2, tid 60aa700, created
	THREAD pthread_self 60aa700: arg@0x20f1290, arg->tid = 60aa700, arg->arg = 2, arg->ret = 0
MAIN thread#3, tid 58a9700, created
	THREAD pthread_self 58a9700: arg@0x20f13d0, arg->tid = 58a9700, arg->arg = 3, arg->ret = 0
MAIN thread#4, tid 50a8700, created
	THREAD pthread_self 50a8700: arg@0x20f1510, arg->tid = 50a8700, arg->arg = 4, arg->ret = 0
MAIN thread#5, tid 48a7700, created
MAIN thread#6, tid 40a6700, created
MAIN thread#7, tid 38a5700, created
	THREAD pthread_self 48a7700: arg@0x20f1650, arg->tid = 48a7700, arg->arg = 5, arg->ret = 0
	THREAD pthread_self 38a5700: arg@0x20f18d0, arg->tid = 38a5700, arg->arg = 7, arg->ret = 0
	THREAD pthread_self 40a6700: arg@0x20f1790, arg->tid = 40a6700, arg->arg = 6, arg->ret = 0

Je ne sais pas si je n'avais pas les yeux en face des trous hier soir, ou si il y a une différence de compilateur / de synchro qui fait disparaître le phénomène (j'ai nue bête de course à 8coeurs au boulot, et seulement 2 à la piaule). Je vérifierai ce soir...
Et si j'utilise g++ à la place de gcc, j'ai les même résultats...

Si on les enlève il ne reste presque rien, à moins que tu n'aies "scrollé" trop vite et que tu sois tombé directement sur le deuxième exemple C++ qui est plus complet et effectivement un peu plus "barbare"!

oui je parlais bien de l'exemple en C++, et ce n'est pas le problème des printf (ou des cout), mais la gymnastique qu'il faut faire pour lancer un thread... Et je ne le trouve pas plus "complet" que l'exemple en C puisqu'ils sont sensés faire la même chose non, lancer un thread ? Ce lien me donne une raison de plus de ne pas aimer le C++.

Pour les QThread, si je me souviens bien il faut soit implémenter l'interface ce qui peu vite devenir assez "lourd", soit utiliser QConcurrent::run() ou truc du genre et qui sera géré par un thread pool de Qt...

Si je me souviens bien, justement il n'y a pas grand chose à faire, dériver une classe de QThread qui doit implémenter la méthode "run", la fonction coeur du thread, et c'est tout... A vérifier.

[invite473b01b1]

oui je parlais bien de l'exemple en C++, et ce n'est pas le problème des printf (ou des cout), mais la gymnastique qu'il faut faire pour lancer un thread...

Oui mais il y a deux exemples C++, dont un qui est un poil plus léger parce qu'il ne gère pas le passage de paramètre (et pas très réutilisable), le deuxième est effectivement un peu plus "obscure"...
Cela dit, la mécanique est effectivement peu ergonomique puisqu'il faut à créer une méthode intermédiaire avec l'instance de classe en paramètre, mais c'est parce que pthread est une lib C et non C++.
Il suffit cependant d'encapsuler ça une fois dans une petite classe générique pour avoir l'équivalent de QThread (c'est d'ailleurs ce que fait le deuxième exemple)

Ce lien me donne une raison de plus de ne pas aimer le C++.

Disons que le C++ permet le meilleur comme le pire, Qt est un exemple de C++ relativement digeste (pas parfait...), il est possible d'écrire du C++ aussi propre que du C#...

[inviteb9f49292]

Disons que le C++ permet le meilleur comme le pire, Qt est un exemple de C++ relativement digeste (pas parfait...), il est possible d'écrire du C++ aussi propre que du C#...

Je ne vais pas m'étendre sur le sujet, trop HS, mais du fait de la complexité syntaxique du C++ je pense qu'il est beaucoup plus facile de faire des spaghettis dangereux en C++ qu'avec n'importe quel autre langage (sauf peut-être brainfuck).

[Jack]

Pourtant la classe thread de la bibliothèque standard me semble assez abordable.

[inviteb9f49292]

Pourtant la classe thread de la bibliothèque standard me semble assez abordable.

C'est clairement plus digeste...

[Jack]

C'est assez récent me semble-t-il.

[invite473b01b1]

C'est assez récent me semble-t-il.

Oui ça fait partie des nouvelles normes C++, qui elles par contre rendent le C++ encore plus obscure et illisible...
Syntaxe plus lourde, toujours autant de méthodes statiques plutôt que sur les instances d'objet, toujours plus de "méta programmation" et autres gadget pour faire du code concis mais au détriment de la lisibilité.
La classe thread fait partie des exceptions, mais là encore, le fait de le nommer en minuscule montre qu'il y a une réticence énorme au code "lisible" dans les hautes sphères des non-développeurs que sont ceux qui décident de ce que doit contenir le C++

[inviteb9f49292]

mais là encore, le fait de le nommer en minuscule montre qu'il y a une réticence énorme au code "lisible" dans les hautes sphères des non-développeurs que sont ceux qui décident de ce que doit contenir le C++

Mais qu'as tu contre les minuscules ! Je suis piqué au vif, moi-même étant passé du CamelCase au minuscules_underscore. Blague à part, mis de côté les préférences personnelles, il y a des "standards" historiques qu'on subi (en C en tout cas, les suffixes en _t étant normalement réservé à POSIX, les préfixes en simple underscore, en double underscore pour les "intrisics", avec les inconsistances de format comme le FILE*...).
Mais là où je fais des pirouettes sur mon sièges, tu crois vraiment que les gonzes qui rédigent le standard ne sont pas des développeurs ? Au contraire ce sont bien souvent de très bon développeurs avec de profondes connaissances sur ces sujets...

[invite473b01b1]

Mais qu'as tu contre les minuscules ! Je suis piqué au vif, moi-même étant passé du CamelCase au minuscules_underscore. Blague à part, mis de côté les préférences personnelles, il y a des "standards" historiques qu'on subi (en C en tout cas, les suffixes en _t étant normalement réservé à POSIX, les préfixes en simple underscore, en double underscore pour les "intrisics", avec les inconsistances de format comme le FILE*...).

Le problème étant l'orientation objet qui n'évolue pas et qui maintient le C++ dans un langage fourre-tout alors qu'il est essentiellement utilisé comme langage orienté objet!
En programmation objet, il est clairement plus lisible et préférable d'utiliser une majuscule pour nommer les entités, cela les distingue plus facilement des types primitifs et des autres variables...
Le fait d'avoir toujours autant de méthodes statiques et de ne pas avoir d'objet de base n'est pas pour aider non plus à faire du code "propre".
Mais tout ça reste subjectif bien entendu!

Mais là où je fais des pirouettes sur mon sièges, tu crois vraiment que les gonzes qui rédigent le standard ne sont pas des développeurs ? Au contraire ce sont bien souvent de très bon développeurs avec de profondes connaissances sur ces sujets...

Selon moi ce sont plus des théoriciens de la programmation que des développeurs, cela ne veut pas dire qu'ils ne sont pas extrêmement compétent, mais ils évoluent dans un autre monde!
Les dernières révisions (11, 14 et 17) vont je pense précipiter la fin de ce langage, il ne s'est pas modernisé il s'est complexifié, pour un langage déjà réputé comme complexe je ne peux que le regretter... Vous le dites d'ailleurs un peu vous-même:

Ce lien me donne une raison de plus de ne pas aimer le C++.

mais du fait de la complexité syntaxique du C++ je pense qu'il est beaucoup plus facile de faire des spaghettis dangereux en C++ qu'avec n'importe quel autre langage

C'est effectivement la réputation qu'a le C++ et hormis ceux qui le pratiquent depuis des années, il y a de moins en moins d'intérêt pour ce langage...

[inviteb9f49292]

Le problème étant l'orientation objet qui n'évolue pas et qui maintient le C++ dans un langage fourre-tout alors qu'il est essentiellement utilisé comme langage orienté objet!

La pieuvre à 19 tentacules... C'est un des reproches que je lui fais, surtout parce que ça complexifie encore plus une syntaxe déjà lourdingue...

En programmation objet, il est clairement plus lisible et préférable d'utiliser une majuscule pour nommer les entités, cela les distingue plus facilement des types primitifs et des autres variables...

Je ne vois pas vraiment le rapport avec la POO, tu as des types (classes, structures, enum...) et des instances de type, il est préférable d'avoir un format de nom différent pour identifier en un coup d'oeil, nous sommes complètement d'accords. TU préfères les majuscules pour les nom de classes et les minuscules pour les variables, il existe d'autres moyens. Avant la préférence esthétique, je pense qu'il est primordial d'être constant, donc copier le format dans lequel tu t'inscris.

Le fait d'avoir toujours autant de méthodes statiques et de ne pas avoir d'objet de base n'est pas pour aider non plus à faire du code "propre".

le "static" au sens du C n'est pas une bonne pratique de programmation, c'est objectif (c'est bien souvent une variable globale cachée, effet de bord etc...), en revanche le "static" dans le sens "méthode qui n'a pas besoin d'une instance de classe pour être appelée", je ne vois ce que vous lui reprochez ?

C'est effectivement la réputation qu'a le C++ et hormis ceux qui le pratiquent depuis des années, il y a de moins en moins d'intérêt pour ce langage...

Bref on est grosso-modo d'accords, serait-ce une "querelle d'experts" ? Ou de la zoophilie droophile (bien souvent la frontière est mince)... mais bien HS de l'origine du thread...

Vous le dites d'ailleurs un peu vous-même

Je suis un adepte du tuvoiement sur les forums... Tuvoyons-nous ?

[inviteb9f49292]

J'ai oublié de répondre à l'objet de mes pirouettes:

Selon moi ce sont plus des théoriciens de la programmation que des développeurs, cela ne veut pas dire qu'ils ne sont pas extrêmement compétent, mais ils évoluent dans un autre monde!

Mon dieu non ! Un standard est quelque chose de beaucoup trop important et sérieux pour être laisser entre les mains de savants fous ! Pour les comités rédigeant les standards C et C++ ce sont essentiellement les "acteurs" du monde des compilateurs (c'est logique, en dehors des développeurs, c'est eux que ça intéresse, et c'est eux qui ont intérêts à ce qu'un standard existe).
Pour avoir butiner quelques "polémiques" par rapport aux standards C, je peux te garantir qu'on est loin d'imaginer le #$*@ que c'est...

[invite473b01b1]

J'ai oublié de répondre à l'objet de mes pirouettes:

Mon dieu non ! Un standard est quelque chose de beaucoup trop important et sérieux pour être laisser entre les mains de savants fous ! Pour les comités rédigeant les standards C et C++ ce sont essentiellement les "acteurs" du monde des compilateurs (c'est logique, en dehors des développeurs, c'est eux que ça intéresse, et c'est eux qui ont intérêts à ce qu'un standard existe).

Oui mais c'est là que je ne suis pas d'accord, oui il faut que ça tienne la route à la compilation, mais la "facilité" de compilation ne doit pas influencer le langage, on doit définir le langage sur des critères de simplification de LECTURE du code (l'écriture est secondaire selon moi) et ensuite s'arranger pour que ça tienne la route. Le compromis doit être fait dans le sens contraire de ce qui est fait.
Cela dit je pratique le C++ tous les jours et je m'en accommode, je donne juste mon avis sur la tournure de ce dernier que je trouve décevante...

Pour avoir butiner quelques "polémiques" par rapport aux standards C, je peux te garantir qu'on est loin d'imaginer le #$*@ que c'est...

Oui c'est certain, cela dit du Java ou du .Net c'est joli, moderne et ça compile très bien

en revanche le "static" dans le sens "méthode qui n'a pas besoin d'une instance de classe pour être appelée", je ne vois ce que vous lui reprochez ?

Je reproche que dans beaucoup de cas, la lib standard nous fasse faire:

methode_static(monObject, mesArgs);
Plutôt que:
monObjet.methode(mesArgs);

Sans compter que le nom des méthodes standard sont souvent des abrégés peu parlants, comme s'il y avait un intérêt à gagner 3 caractères dans le nom d'une méthode...

Mais je suis d'accord avec toi, tout ceci est HS!

[Jack]

le "static" au sens du C n'est pas une bonne pratique de programmation, c'est objectif (c'est bien souvent une variable globale cachée, effet de bord etc...)

C'est d'une part indispensable je trouve, et d'autre part il me semble que c'est justement d'avoir les avantages d'une variable globale sans les problèmes d'effet de bord puisque finalement une variable statique est locale pour le compilateur.

[sandrecarpe]

Je reproche que dans beaucoup de cas, la lib standard nous fasse faire:

methode_static(monObject, mesArgs);
Plutôt que:
monObjet.methode(mesArgs);

Sans compter que le nom des méthodes standard sont souvent des abrégés peu parlants, comme s'il y avait un intérêt à gagner 3 caractères dans le nom d'une méthode...

Même si le c++ est orienté objet, je trouve normal qu'il n'est pas possible de faire du 100% objet. Si la moindre fonction que nous fournirais le c++ serait une fonction membre, je pense que, là, ça serait illisible.
Je m'imagine pas du tout taper à répétition un System.out.print("ma chaine a afficher") façon Java. cout << "chaine" c'est simple, rapide et précis
Je vois plutôt les fonctions standards comme les briques qui nous servent à créer nos objets!
Mais bon, après tout je suis pas programmeur professionnel

[inviteb9f49292]

C'est d'une part indispensable je trouve, et d'autre part il me semble que c'est justement d'avoir les avantages d'une variable globale sans les problèmes d'effet de bord puisque finalement une variable statique est locale pour le compilateur.

Effectivement mon intervention et bien trop radicale, je remplace par:
le "static", lorsqu'il est utilisé en C comme "mémoire d'état" (l'exemple bateau du compteur d'appels de fonction) est rarement une bonne pratique de programmation, à cause de l'effet de bord qu'il accompagne. Mais il faut parfois savoir sacrifier les règles académiques par pragmatisme. Et en plus le static reste indispensable pour "cacher" des "objets au sens C" (fonctions, instances...).

[inviteb9f49292]

mais la "facilité" de compilation ne doit pas influencer le langage, on doit définir le langage sur des critères de simplification de LECTURE du code

Pour la lecture du code tu prêches un converti (et c'est peut être ma principale raison d'aimer le C, et de détester le C++). J'apporte quand même une nuance par rapport à "la facilité à compiler", pour deux raison:
- ce n'est certainement pas incompatible, une syntaxe simple est plus simple à lire (pour un humain), mais le compilateur est certainement plus simple à réaliser, son travaille étant ... plus simple.
- un compilateur qui fait un travail plus simple c'est un outils plus fiable

Oui c'est certain, cela dit du Java ou du .Net c'est joli, moderne et ça compile très bien

Ca ne compile pas (ou ça perd son principal intérêt), et tu ne peux pas faire de système, bas-niveau... ni même de machine virtuelle...