Est-ce que tu as seulement lu le lien que tu donnes sur ECMA ? Je vais t’aider et citer le passage. « 4.2 Decisions on acceptance shall be made by the General Assembly with a two thirds majority of all the ordinary members. » Tu continues sur le site, et tu as la liste des membres de l’Assemblée générale : 18 noms, de grosses entreprises. Pour entrer il te faut le soutien de 12 des ces entreprises
Toutes ces entreprises/fondations ne sont pas des grosses entreprises, et ils sont membres de l'assemblee generale.
Le C est multi-plateforme, dire le contraire n’est que l’aboutissement d’années de propagande (je soupçonne Java). Quand tu codes en C tu n’as pas a savoir si t’es en little ou big endian, ni la taille de tes pointeurs, ce sont des représentations internes de la machine et le C permet justement de s’en affranchir ! Quand j’écris un int, et durant tout le code, je me fiche des détails techniques de représentation des nombres : endianness, taille des données à la précision numérique près, etc. Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant (à la précision numérique près), la force du C est très précisément d’abstraire ces problèmes de représentation interne.
Ben va t'amuser a prendre du code qui tourne sur une machine A et porte le sur une machine B, tu vas comprendre, si tu ne fais pas extremement attention, tu te feras bouffer.
Au hasard le fait que ta taille de pointeur est passee de 4 a 8 bytes, que ton alignement des allocations a change, que le systeme A lance une exception en cas d'acces non-aligne alors que le systeme B ne le fait pas, ...
Visiblement tu n'a jamais eu a faire un portage.
Tu dis « la version normalisée est la 3.0 », j’attends tes sources, parce que ce n’est pas ce que dit Wikipedia, du coup je suis allé voir la liste des standard ECMA : C# 4ème édition : juin 2006, selon Wikipedia la sortie de la version 3.0 du langage chez Microsoft date d’Août 2007.
Et ? Ca n'empeche pas de normaliser le langage avant la sortie de Visual Studio hein...
In June 2005, the General Assembly of the international standardization organization Ecma approved edition 3 of the C# Language and the Common Language Infrastructure (CLI) specifications, as updated Ecma-334 and Ecma-335, respectively (see press release).
Concernant ACPI, au contraire j’ai parfaitement compris le problème, je l’ai posé en terme d’implémentation de référence : si l’implémentation de référence ne respecte pas le standard, ce dernier ne sert plus à rien. Je fais le parallèle avec la situation de Mono vs. l’implémentation de Microsoft.
Mais qui te parle d'implementation de reference ? Qui a designe le compilo de MS comme implementation de reference ? Ils disent clairement que ce compilo est la pour le support de Windows, pas autre chose.
T'utilises le compilo Intel, Windows tourne et Linux tourne, c'est pas un probleme. Et va pas me dire qu'Intel est un nain hein, ils font partie des createurs d'ACPI au meme titre que MS.
Mais il est difficile de faire la part des choses et de relever ce qui est couvert par les brevets de ce qui ne l’est pas. C’est déjà assez difficile concernant le noyau... c’est une guerre de communication : utiliser des techno. de chez Microsoft c’est donner de la force au FUD.
C'est tres clair, tout ce qui est dans la spec ECMA est protege contre les brevets, point a la ligne.
Mono est développé par Novell qui a des accords spécifiques avec Microsoft. Qu’en est-il du reste de l’éco-système, libre, non-libre, commerciaux, etc., qui utiliserait Mono, implémenterait une lib. avec des fonctionnalités proches d’une lib. non couverte par les accords, tout ceci sur une techno. spécifiquement Microsoft, tu vas me dire qu’il n’existe aucun risque de tomber sur une solution proche de ce qu’à utiliser, et breveté, Microsoft ? Le risque est àmha plus grand que de partir from scratch.
Et dis-moi, quel est le risque si tu implementes DirectX ou autre lib MS sous Linux ? Identique a implementer une lib MS sous Mono.
Tu vas me faire croire que par hasard tu vas reimplementer une lib MS sans t'en rendre compte ? Tu te fiches de moi ?
Dans ce cas il suit l’implémentation de référence : retour à la case départ, ce sera du Microsoft, ça ne sera plus couvert par un standard, donc soumis à des attaques ou FUD sur les brevets. Ou alors Mono suit sa propre voie, redéfinit un langage à lui, etc., mais on perd toute compatibilité. Je ne sais pas pourquoi je me répète, tu ne vas pas plus lire que la première fois.
N'importe quoi, tu m'expliques pourquoi il ne peut pas suivre LA SPEC plutot que l'implementation MS ?
Parce que tu vois, c'est ce qu'il fait, il implemente des elements de la spec que meme MS n'implemente pas.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
N'importe quoi !
http://www.ecma-international.org/memento/NFP.htm
http://www.ecma-international.org/memento/SPC.htm
http://www.ecma-international.org/memento/SME.htm
Toutes ces entreprises/fondations ne sont pas des grosses entreprises, et ils sont membres de l'assemblee generale.
Le C est multi-plateforme, dire le contraire n’est que l’aboutissement d’années de propagande (je soupçonne Java). Quand tu codes en C tu n’as pas a savoir si t’es en little ou big endian, ni la taille de tes pointeurs, ce sont des représentations internes de la machine et le C permet justement de s’en affranchir ! Quand j’écris un int, et durant tout le code, je me fiche des détails techniques de représentation des nombres : endianness, taille des données à la précision numérique près, etc. Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant (à la précision numérique près), la force du C est très précisément d’abstraire ces problèmes de représentation interne.
Ben va t'amuser a prendre du code qui tourne sur une machine A et porte le sur une machine B, tu vas comprendre, si tu ne fais pas extremement attention, tu te feras bouffer.
Au hasard le fait que ta taille de pointeur est passee de 4 a 8 bytes, que ton alignement des allocations a change, que le systeme A lance une exception en cas d'acces non-aligne alors que le systeme B ne le fait pas, ...
Visiblement tu n'a jamais eu a faire un portage.
Tu dis « la version normalisée est la 3.0 », j’attends tes sources, parce que ce n’est pas ce que dit Wikipedia, du coup je suis allé voir la liste des standard ECMA : C# 4ème édition : juin 2006, selon Wikipedia la sortie de la version 3.0 du langage chez Microsoft date d’Août 2007.
Et ? Ca n'empeche pas de normaliser le langage avant la sortie de Visual Studio hein...
http://msdn.microsoft.com/en-us/netframework/aa569283.aspx
In June 2005, the General Assembly of the international standardization organization Ecma approved edition 3 of the C# Language and the Common Language Infrastructure (CLI) specifications, as updated Ecma-334 and Ecma-335, respectively (see press release).
Concernant ACPI, au contraire j’ai parfaitement compris le problème, je l’ai posé en terme d’implémentation de référence : si l’implémentation de référence ne respecte pas le standard, ce dernier ne sert plus à rien. Je fais le parallèle avec la situation de Mono vs. l’implémentation de Microsoft.
Mais qui te parle d'implementation de reference ? Qui a designe le compilo de MS comme implementation de reference ? Ils disent clairement que ce compilo est la pour le support de Windows, pas autre chose.
T'utilises le compilo Intel, Windows tourne et Linux tourne, c'est pas un probleme. Et va pas me dire qu'Intel est un nain hein, ils font partie des createurs d'ACPI au meme titre que MS.
Mais il est difficile de faire la part des choses et de relever ce qui est couvert par les brevets de ce qui ne l’est pas. C’est déjà assez difficile concernant le noyau... c’est une guerre de communication : utiliser des techno. de chez Microsoft c’est donner de la force au FUD.
Non, cela n'a ABSOLUMENT RIEN de difficile : http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-(...)
C'est tres clair, tout ce qui est dans la spec ECMA est protege contre les brevets, point a la ligne.
Mono est développé par Novell qui a des accords spécifiques avec Microsoft. Qu’en est-il du reste de l’éco-système, libre, non-libre, commerciaux, etc., qui utiliserait Mono, implémenterait une lib. avec des fonctionnalités proches d’une lib. non couverte par les accords, tout ceci sur une techno. spécifiquement Microsoft, tu vas me dire qu’il n’existe aucun risque de tomber sur une solution proche de ce qu’à utiliser, et breveté, Microsoft ? Le risque est àmha plus grand que de partir from scratch.
Et dis-moi, quel est le risque si tu implementes DirectX ou autre lib MS sous Linux ? Identique a implementer une lib MS sous Mono.
Tu vas me faire croire que par hasard tu vas reimplementer une lib MS sans t'en rendre compte ? Tu te fiches de moi ?
Dans ce cas il suit l’implémentation de référence : retour à la case départ, ce sera du Microsoft, ça ne sera plus couvert par un standard, donc soumis à des attaques ou FUD sur les brevets. Ou alors Mono suit sa propre voie, redéfinit un langage à lui, etc., mais on perd toute compatibilité. Je ne sais pas pourquoi je me répète, tu ne vas pas plus lire que la première fois.
N'importe quoi, tu m'expliques pourquoi il ne peut pas suivre LA SPEC plutot que l'implementation MS ?
Parce que tu vois, c'est ce qu'il fait, il implemente des elements de la spec que meme MS n'implemente pas.