Pour ECMA, les membres que tu cites ne font pas parti de l’assemblée générale, qui, seule, vote pour ou contre l’inclusion des nouveaux membres à la majorité des 2/3 et pour la publication des normes (dans le menu présentation il y a un pdf, je l’ai un peu parcouru). Les membres que tu cites ont des droits dans les comités techniques, c’est-à-dire l’élaboration des normes. Et en tout il n’y a que 60 entreprises regroupées sous ECMA, toutes ont nécessairement été acceptées par l’AG (c.-à-d. les 18 entreprises pré-citées).
Clairement il y a plus que les 18 grosses societes, y compris des petites societes, par contre il semble ne pas y avoir de fondations a but non lucratif.
Le C est portable, oui, il a été conçu pour ; Wikipedia le dit, mes professeurs me l’ont toujours dit, et je le constate tous les jours : je n’ai jamais eu à porter un code, oui, parce que précisément le C est portable, tous les jours j’utilise le même code sur des machines indifféremment 32 ou 64 bits. Que tu puisses faire des choses non-portables en C démontre juste que ce n’est pas un langage neuneu-proof, mais pas portable : non ; Malloc t’assure l’alignement des données, tu les dé-s-alignes : c’est ton problème.
Non desole, etre un langage portable signifie JUSTEMENT que tu n'es pas sense faire des pieds et des mains pour t'assurer que le code est portable.
Les problemes d'alignement dans les structures, de la definition de ce qu'est un int tout simplement (peut changer de taille d'une machine a l'autre, vive la gestion des overflows), etc... font que c'est un langage CHIANT pour le multiplateforme.
Pour revenir sur le cœur du sujet : je ne crois pas que le numéro du standard correspond à la version du langage, en tout cas les fonctionnalités qu’apportent la version du standard ECMA no4, si j’en crois ton lien, correspondent aux fonctionnalités du langage en version 2 de chez Microsoft, si j’en crois Wikipedia. La liste des fonctionnalités dans les version 3 et 4 sont donc non normalisées, avec les conséquences que j’ai exposées.
En effet tu avais raison, c'est la 3eme edition, mais elle correspond a C# 2.0, tu noteras par contre que sur http://msdn.microsoft.com/en-us/netframework/aa569283.aspx ils donnent les working drafts pour la 5eme edition du standard, ils y travaillent donc.
Mais je le répète tout ceci est une guerre de communication (c’est le principe du FUD), pour aller vérifier que telle implémentation d’un langage est conforme à telle standard, et donc non soumis à attaque par brevets, il faut avoir des compétences au seins de l’entreprise, et pas des moindres : tout ça pour vérifier qu’on peut utiliser Tomboy (je force le trait) ? Bref s’il faut parcourir une spécification d’un langage et son implémentation pour vérifier les choses, ça signifie que c’est loin d’être simple.
Arf super, et c'est EXACTEMENT la meme choes pour 3533 autre standards, tu vas arreter d'utiliser les codecs video, audio, les fontes etc... alors ?
là ACPI montre que grâce à une implémentation de référence, qui n’est rien d’autre que le standard de facto (hors toute considération de l’existence d’un standard institutionnel), Microsoft a su tourner la situation à son avantage. Il est difficile de croire qu’ils n’en feront pas de même pour le langage dont il est question ici.
Tu m'expliques pourquoi tu rejettes sur MS le fait que certains constructeurs prennent son compilo, qui est clairement labele comme etant fait pour Windows, plutot qu'un compilo ACPI tel que celui d'Intel ?
Enfin vient l’utilisation de techno. Microsoft, oui, le risque « par hasard » n’est pas si petit que ça une fois que tu t’es donné l’objectif de : ré-implémenter avec une technologie Microsoft, avoir une API proche de la lib. Microsoft, etc. Tu offres mécaniquement plus de possibilité de tomber sur le coup d’un brevet. Sans compter que tu as toujours ce problème de communication et de FUD qui vient : cela donne plus de poids à ce dernier pour faire croire qu’il y a lieu de s’inquiéter.
Oui bien sur, par hasard tu vas reimplementer asp.net ou ado.net , sans t'en rendre compte ! Un peu de serieux stp...
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
En fait on avait tous les 2 tort, voila les membres de l'AG : http://www.ecma-international.org/memento/GA.htm
Clairement il y a plus que les 18 grosses societes, y compris des petites societes, par contre il semble ne pas y avoir de fondations a but non lucratif.
Le C est portable, oui, il a été conçu pour ; Wikipedia le dit, mes professeurs me l’ont toujours dit, et je le constate tous les jours : je n’ai jamais eu à porter un code, oui, parce que précisément le C est portable, tous les jours j’utilise le même code sur des machines indifféremment 32 ou 64 bits. Que tu puisses faire des choses non-portables en C démontre juste que ce n’est pas un langage neuneu-proof, mais pas portable : non ; Malloc t’assure l’alignement des données, tu les dé-s-alignes : c’est ton problème.
Non desole, etre un langage portable signifie JUSTEMENT que tu n'es pas sense faire des pieds et des mains pour t'assurer que le code est portable.
Les problemes d'alignement dans les structures, de la definition de ce qu'est un int tout simplement (peut changer de taille d'une machine a l'autre, vive la gestion des overflows), etc... font que c'est un langage CHIANT pour le multiplateforme.
Pour revenir sur le cœur du sujet : je ne crois pas que le numéro du standard correspond à la version du langage, en tout cas les fonctionnalités qu’apportent la version du standard ECMA no4, si j’en crois ton lien, correspondent aux fonctionnalités du langage en version 2 de chez Microsoft, si j’en crois Wikipedia. La liste des fonctionnalités dans les version 3 et 4 sont donc non normalisées, avec les conséquences que j’ai exposées.
En effet tu avais raison, c'est la 3eme edition, mais elle correspond a C# 2.0, tu noteras par contre que sur http://msdn.microsoft.com/en-us/netframework/aa569283.aspx ils donnent les working drafts pour la 5eme edition du standard, ils y travaillent donc.
Mais je le répète tout ceci est une guerre de communication (c’est le principe du FUD), pour aller vérifier que telle implémentation d’un langage est conforme à telle standard, et donc non soumis à attaque par brevets, il faut avoir des compétences au seins de l’entreprise, et pas des moindres : tout ça pour vérifier qu’on peut utiliser Tomboy (je force le trait) ? Bref s’il faut parcourir une spécification d’un langage et son implémentation pour vérifier les choses, ça signifie que c’est loin d’être simple.
Arf super, et c'est EXACTEMENT la meme choes pour 3533 autre standards, tu vas arreter d'utiliser les codecs video, audio, les fontes etc... alors ?
là ACPI montre que grâce à une implémentation de référence, qui n’est rien d’autre que le standard de facto (hors toute considération de l’existence d’un standard institutionnel), Microsoft a su tourner la situation à son avantage. Il est difficile de croire qu’ils n’en feront pas de même pour le langage dont il est question ici.
Tu m'expliques pourquoi tu rejettes sur MS le fait que certains constructeurs prennent son compilo, qui est clairement labele comme etant fait pour Windows, plutot qu'un compilo ACPI tel que celui d'Intel ?
Enfin vient l’utilisation de techno. Microsoft, oui, le risque « par hasard » n’est pas si petit que ça une fois que tu t’es donné l’objectif de : ré-implémenter avec une technologie Microsoft, avoir une API proche de la lib. Microsoft, etc. Tu offres mécaniquement plus de possibilité de tomber sur le coup d’un brevet. Sans compter que tu as toujours ce problème de communication et de FUD qui vient : cela donne plus de poids à ce dernier pour faire croire qu’il y a lieu de s’inquiéter.
Oui bien sur, par hasard tu vas reimplementer asp.net ou ado.net , sans t'en rendre compte ! Un peu de serieux stp...