rendre un prog compilable sur plusieurs compilateurs

Olivier Azeau wrote:

nico wrote:

Don't use exceptions.
Don't use Run-time Type Information.
Don't use C++ standard library features, including iostream
Don't use namespace facility.

Don't use C++

Tout dépend de ce que l'on entend par C++.
Le temps n'est pas loin où la majorité des applis en C++ respectaient
toutes ces règles. :-)

Ce qui me fait le plus bizarre c'est qu'ils utilisent quand même des
templates...

Ouais enfin je trouve ca un peu restrictif, moi je m'arrange pour que ca
compile sous VC7 et 1 ou 2 version de GCC et c'est bon...

Et même qand je fournis les sources je donne la possibilité d'avoir un
package avec les binarires comme ca l'utilisateur n'a pas a recompiler et
donc pas de prob.

Ivan Vecerina wrote:

En pratique, je pense qu'il faut chercher avant tout à écrire du
code conforme au standard.

Y compris export ? En fait, le standard est surtout utile
aujourd'hui comme indication sur la direction future que
prendraient des compilateurs. (Enfin, je l'espère au moins.) En
fait, il faut prendre la norme moins certaines parties, avec en
plus des manipulations particulières pour s'adresser aux
compilateurs pré-normes.

Mais ce n'est pas dit qu'il faut une portabilité absolue à tous
les compilateurs possibles non plus. En fait...

Puis faire les adaptations nécessaires pour fonctionner avec
les compilos que l'on utilise.

C'est surtout ça -- s'adresser aux problèmes connus, et qu'on
peut tester. Par rapport à la norme, il y a une ou deux choses
qu'on sait peu implémenter : export et les paramètres de
template pour les templates, par exemple. AMHA, au moins de
savoir bien d'avance que tous les compilateurs ciblés les
supportent, je les éviterais. Norme ou non. Ensuite, il y a
quelque problèmes où on sait que les compilateurs varient : la
recherche des noms dans un template ou la portée d'une variable
définie dans une boucle for. Au moins dans le deuxième cas, et
en grande partie dans le premier aussi, il existe des écritures
« portables », des façons d'écrire le code pour qu'il marche
avec les deux. On privilègerait ces formes autant que possible,
et évidemment, dans la mésure qu'on est au courant du problème.

Reste aussi que l'on peut choisir d'être plus ou moins
aggressif dans l'utilisation des fonctionnalités avancées du
C++ (p.ex. spécialisation de templates).

Tout à fait. Tout dépend des exigeances de portabilité.

Les projets qui ont un grand souci de portabilité (p.ex.
Mozilla) tendent à être très conservateurs quant aux
fonctionnalités utilisées. En voici un exemple:
http://www.mozilla.org/hacking/portable-cpp.html
Clairement, certaines des contraintes imposée ci-dessus sont
handicapantes et inutile si l'on a pour cible de compilos
relativement récents tels que GCC 3.x et MSVC 7.x .

Voire même VC++ 6.0:-). Les contraints y sont draconiens. Mais
je crois en partie, ce n'est pas seulement les compilateurs,
mais le modèle de développement qui l'impose. Il est donc
possible aujourd'hui d'écrire des templates de façon portable.
Si on connaît un peu des problèmes qu'on risque d'avoir avec des
compilateurs plus anciens, et comment les éviter. Si j'ai un
groupe d'employés plus ou moins fermé, je peux m'assurer qu'ils
sont tous au courant ; du coup, pas de problème avec les
templates. Si je ne sais pas qui va écrire quoi, il vaut mieux
prendre les précautions. On peut écrire des templates de façon
portable, mais il faut savoir ce qu'on fait, et ce n'est pas
parce que le code se compile avec un ou deux compilateurs que
c'est portable.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

3dsman wrote:

Don't use C++ standard library features, including iostream
Don't use namespace facility.

heu pourquoi ces deux la? c quoi la justification? y en a une
au moin???

Pour les iostream, il en existe deux variantes assez répandues,
et incompatibles. C'est possible à écrire du code qui marche
avec les deux -- je le fais de temps en temps, mais il faut bien
être au courant du problème. Quand tu as un modèle de
développement aussi ouvert que le leur, il vaut mieux être
extrèmement prévoyant. Ça ne veut pas dire que la même règle
doit valoir dans une boîte où le développement est plus fermé.
(En passant, je crois aussi qu'ils ciblent certaines plateformes
où le compilateur C++ est vraiment ancien, du genre Palm. Je
crois que si tu ne cibles que des machines « classiques », et
que tu n'as pas du code existant qui impose un compilateur plus
ancien, tu peux ne prendre en considération que des iostream
standard. Donc, pas de problèmes de portabilité de ce côté-là.)

Pour les namespace, je sais que j'ai essayé à les introduire
dans ma bibliothèque, et que ça posait des problèmes avec VC++
6.0. J'imagine qu'une utilisation plus simple aurait peut-être
marché ; je n'ai pas d'accès régulier au compilateur pour
essayer. Mais encore, le modèle ouvert de développement dit de
ne pas prendre des risques, surtout que dans le cas des
namespace, la nouveauté n'apporte pas beaucoup.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On 15 Feb 2005 03:06:14 -0800, kanze@gabi-soft.fr:

Mais ce n'est pas dit qu'il faut une portabilité absolue à tous
les compilateurs possibles non plus.

La question stupide du jour : ne serait-il pas possible de développer
en C++ "moderne" sur une machine Windows ou Linux, puis d'utiliser un
"pseudo-compilateur" pour le transformer en code C, qui serait
compilable partout ?


--
;-)

Fabien LE LEZ wrote:

On 15 Feb 2005 03:06:14 -0800, kanze@gabi-soft.fr:

Mais ce n'est pas dit qu'il faut une portabilité absolue à tous
les compilateurs possibles non plus.

La question stupide du jour : ne serait-il pas possible de
développer en C++ "moderne" sur une machine Windows ou Linux,
puis d'utiliser un "pseudo-compilateur" pour le transformer en
code C, qui serait compilable partout ?

Sans doute. Tu nous écris le pseudo-compilateur:-).

Sérieusement, ça serait plus ou moins difficile, selon ce qu'on
cherche à remplacer. Les exceptions, par exemple, serait
extrèmement difficile de faire d'une façon efficace. (On ne peut
pas prendre l'adresse d'une étiquette pour générer les
tableaux.)

Dans tous les cas, il faudrait parser le C++ complètement. Dans
le cas des templates, il faudrait aussi faire l'instantiation et
la recherche du nom. Arrivé là, je crois qu'on a déjà les bases
d'un bon compilateur complet.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

"Fabien LE LEZ" <gramster@gramster.com> wrote in message
news:kph4115c2id07dm87guj2ftgpilanui2sn@4ax.com...

On 15 Feb 2005 03:06:14 -0800, kanze@gabi-soft.fr:

Mais ce n'est pas dit qu'il faut une portabilité absolue à tous
les compilateurs possibles non plus.

La question stupide du jour : ne serait-il pas possible de développer
en C++ "moderne" sur une machine Windows ou Linux, puis d'utiliser un
"pseudo-compilateur" pour le transformer en code C, qui serait
compilable partout ?

Oui mais - des astuces spécifiques spécifiques à une plate-forme C
donnée sont généralement nécessaires pour traduire le C++ (notamment
pour implémenter les exceptions), et pour générer au final du code
objet de qualité.
Comeau, qui se targue (avec raison) d'être un des compilateurs les
plus conformes au standard C++ ( très utile:
http://www.comeaucomputing.com/tryitout/ ), est un compilateur
qui génère du C. Voir des notes intéressantes sur cette page quant
à leur offre de portage vers de nouvelles plate-formes:
http://www.comeaucomputing.com/custom.html

Un autre angle d'attaque serait de dire que, à l'heure où gcc
peut même cibler un bon nombre de plate-formes 16 bit, quelles
sont les plate-formes majeures pour lesquelles ce compilo n'est
pas disponible?



Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form

Ivan Vecerina wrote:

"Fabien LE LEZ" <gramster@gramster.com> wrote in message
news:kph4115c2id07dm87guj2ftgpilanui2sn@4ax.com...

On 15 Feb 2005 03:06:14 -0800, kanze@gabi-soft.fr:

Mais ce n'est pas dit qu'il faut une portabilité absolue à
tous les compilateurs possibles non plus.

La question stupide du jour : ne serait-il pas possible de
développer en C++ "moderne" sur une machine Windows ou
Linux, puis d'utiliser un "pseudo-compilateur" pour le
transformer en code C, qui serait compilable partout ?

Oui mais - des astuces spécifiques spécifiques à une
plate-forme C donnée sont généralement nécessaires pour
traduire le C++ (notamment pour implémenter les exceptions),
et pour générer au final du code objet de qualité.
Comeau, qui se targue (avec raison) d'être un des compilateurs
les plus conformes au standard C++ ( très utile:
http://www.comeaucomputing.com/tryitout/ ), est un compilateur
qui génère du C. Voir des notes intéressantes sur cette page
quant à leur offre de portage vers de nouvelles plate-formes:
http://www.comeaucomputing.com/custom.html

Un autre angle d'attaque serait de dire que, à l'heure où gcc
peut même cibler un bon nombre de plate-formes 16 bit, quelles
sont les plate-formes majeures pour lesquelles ce compilo
n'est pas disponible?

C'est aussi la solution que je préconcise quand c'est possible.
En revanche :

-- Surtout, on rencontre des problèmes politiques. Pour
diverses raisons (dont certaines valables), beaucoup de
boîtes préfèrent se servir du compilateur « natif » du
système : Sun CC sous Solaris, VC++ sous Windows, g++ sous
Linux, etc.

-- Sinon, il y a encore des problèmes avec g++ et les threads.
Dans la mésure du possible, j'éviterais l'utilisation de g++
dans une application multi-threaded.

-- Et enfin, le compilateur n'est pas la seule source des
problèmes de portabilité. J'utilise pthread_create, etc.,
dans mon code, et je doute qu'il porte sur Windows, même si
j'ai le même compilateur. Dans la pratique, la norme C++ ne
suffit pas, parce qu'il ne couvre pas tout ce qui est
nécessaire pour écrire un programme. (Et je ne suis pas
complètement convaincu qu'elle le doit, même si des choses
comme l'absense d'une GUI standard sont souvent cité comme
argument contre C++.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[...]

Comeau, qui se targue (avec raison) d'être un des compilateurs les
plus conformes au standard C++ ( très utile:
http://www.comeaucomputing.com/tryitout/ )
<bêtise>

J'attends avec impatience le compilateur qui communiquera sur le thème:
"Le *seul* compilateur 100% compatible avec C++2012. Portabilité de
votre code *assurée* !"
</bêtise>
Bon, je comprends l'utilité d'un compilateur de référence. Ceci dit,
dans le même ordre d'idée, je trouve que du code 100% C99 bien
idiomatique est une bonne façon de se retrouver coincé dans la vie réelle.
--
Pierre

On 16 Feb 2005 01:44:38 -0800, kanze@gabi-soft.fr:

-- Et enfin, le compilateur n'est pas la seule source des
problèmes de portabilité. J'utilise pthread_create, etc.,

Oui mais bon, Mozilla est concerné par ce problème malgré ses normes
de codage très restrictives. Mon idée avait pour but de pouvoir
utiliser toutes les fonctionnalités du C++ dans des projets portables
style Mozilla.


--
;-)

Un autre angle d'attaque serait de dire que, à l'heure où gcc
peut même cibler un bon nombre de plate-formes 16 bit, quelles
sont les plate-formes majeures pour lesquelles ce compilo n'est
pas disponible?

Microsoft Windows?

Plus spécifiquement, ni MinGW ni Cygwin ne permettent vraiment de
développer du nouveau code sous Windows. Le compilateur et/ou l'éditeur
de liens sont incroyablement lents et le débogueur n'arrive pas à la
cheville de celui de Visual Studio.

Par contre ces compilateurs sont pratiques pour porter du code déjà
développé sous une autre platforme vers Windows.

Dimitri Papadopoulos