Quel compilateur C++ pour develloper sous Linux (KDE)

pascal

04/07/2004 à 14:42

Gabriel Dos Reis wrote in message :

Loïc Joly writes:

| NLS = ?

Native Language Support

En gros, pour GCC, tu aurais les diagnostiques traduits en français
par exemple. J'ai toujours configuré avec --disable-nls, ce qui
probablement ne m'a pas permit de mesurer le désastre dont parle
Fabien.

Je l'ai utilisé, une fois. Si je me souviens bien, j'essayais la
plupart du temps de faire une traduction à l'envers. Découvrir quelle
expression anglaise avait pu être traduite par ces mots affichés
devant moi, pour pouvoir refaire moi-même la traduction. Donc oui, à
déconseiller ;-)

Et je ne parle pas des plantages déjà évoqués.

--drkm

y'a t'il un "organisme" ou une "team" qui s'occupe de la traduction en language
natif ou faut il simplement recompiler gcc et g++ avec les modif effectives?
par exemple faire un fichier .PO comme sur la plateforme kde?

-Pascal

Gabriel Dos Reis

04/07/2004 à 16:07

pascal writes:

| y'a t'il un "organisme" ou une "team" qui s'occupe de la traduction en
| language natif

Oui.

-- Gaby

James Kanze

04/07/2004 à 18:10

Gabriel Dos Reis writes:

|> writes:

|> | > Leur bibliothèque respecte-t-elle vraiment si bien le standard?

|> | C'est ce qui se fait de mieux actuellement.

|> Même en face de RogueWave?

La seule RogueWave avec laquelle j'ai de l'expérience, c'est celle
livrée avec Sun CC, et c'est un désastre. Au moins, pris dans
l'ensemble -- c'est vrai qu'elle implémente toute la norme. Mais la
qualité de l'implémentation est telle de le rendre quasiment
inutilisable.

Je ne sais pas comment RogueWave a évolué -- la version livrée avec Sun
CC n'est pas des plus récentes. Mais le fait que et Sun et Borland s'en
éloigne est suggestif.

|> [...]
|> Est-ce que tu ne saurais pas implémenter vector<T> en te servant
|> uniquement de C++ ?

Probablement.

Qu'est-ce que tu essaies de dire : que vector<T> ne doit pas faire
partie de la norme, étant donné que son implémentation est assez facile
pour l'utilisateur ?

--
James Kanze
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

drkm

04/07/2004 à 19:19

pascal writes:

y'a t'il un "organisme" ou une "team" qui s'occupe de la traduction en
language natif ou faut il simplement recompiler gcc et g++ avec les
modif effectives?
par exemple faire un fichier .PO comme sur la plateforme kde?

GCC utilise en effet également gettext. Et les traductions sont
maintenues par des volontaires. <URL:http://gcc.gnu.org> et
<URL:http://www.gnu.org/software/gettext/gettext.html> devraient
t'apporter la réponse à tous les détails.

--drkm

Gabriel Dos Reis

05/07/2004 à 00:16

James Kanze writes:

| Gabriel Dos Reis writes:
|
| |> writes:
|
| |> | > Leur bibliothèque respecte-t-elle vraiment si bien le standard?
|
| |> | C'est ce qui se fait de mieux actuellement.
|
| |> Même en face de RogueWave?
|
| La seule RogueWave avec laquelle j'ai de l'expérience, c'est celle
| livrée avec Sun CC, et c'est un désastre. Au moins, pris dans

Est-ce un probleme de compilateur ?

[...]

| |> [...]
| |> Est-ce que tu ne saurais pas implémenter vector<T> en te servant
| |> uniquement de C++ ?
|
| Probablement.
|
| Qu'est-ce que tu essaies de dire : que vector<T> ne doit pas faire
| partie de la norme, étant donné que son implémentation est assez facile
| pour l'utilisateur ?

Non.

Pour savoir ce que j'essaie de dire, il aurait fallu que tu gardes la
citation que tu as subrepticement enlevee.

-- Gaby

Andre Heinen

05/07/2004 à 18:03

Je voudrais répondre à James, mais comme son article n'est pas
relayé par mon FAI, je réponds à Gaby à la place. Sorry.

Gabriel Dos Reis wrote:

writes:

[...]

| Quel rapport ? C'est de toute façon impossible à implémenter la
| bibliothèque standard sans utiliser des constructions non standard.

Ce n'est pas ce que je voulais dire. Prenons un exemple:

for (int i=0 ; i<10 ; ++i) action();
for (int i=0 ; i<10 ; ++i) action();
Bien que ce code soit correct, il ne compilera pas avec VC++ (en
tout cas pas avec ma version): la deuxième ligne provoquera une
erreur en raison de la soi-disant redéclaration de i.

Pour VC++ il faut écrire:
for (int i=0 ; i<10 ; ++i) action();
for ( i=0 ; i<10 ; ++i) action();
Mais ce code-ci ne compilera pas avec un compilateur plus
respectueux du standard.

Si la bibliothèque Dinkum utilise la deuxième construction, elle
est inutilisable avec d'autres compilateurs que Visual. Du moins
c'est ce que j'ai entendu dire. D'où ma question.

--
Andre Heinen
My address is "a dot heinen at europeanlink dot com"

Matthieu Moy

05/07/2004 à 20:38

Andre Heinen writes:

for (int i=0 ; i<10 ; ++i) action();
for (int i=0 ; i<10 ; ++i) action();
Bien que ce code soit correct, il ne compilera pas avec VC++ (en
tout cas pas avec ma version): la deuxième ligne provoquera une
erreur en raison de la soi-disant redéclaration de i.

Parait-il que c'est corrigé dans VC++ 7.

Sinon, il y a la ruse de sioux :

#define for if(1) for

qui permet de rendre ça portable.

--
Matthieu

Loïc Joly

05/07/2004 à 20:53

Andre Heinen wrote:

Ce n'est pas ce que je voulais dire. Prenons un exemple:

for (int i=0 ; i<10 ; ++i) action();
for (int i=0 ; i<10 ; ++i) action();
Bien que ce code soit correct, il ne compilera pas avec VC++ (en
tout cas pas avec ma version): la deuxième ligne provoquera une
erreur en raison de la soi-disant redéclaration de i.

Pour VC++ il faut écrire:
for (int i=0 ; i<10 ; ++i) action();
for ( i=0 ; i<10 ; ++i) action();

Non, il faut écrire :
for (int i=0 ; i<10 ; ++i) action();
for (int j=0 ; j<10 ; ++j) action();

Mais ce code-ci ne compilera pas avec un compilateur plus
respectueux du standard.

Et le mien compile partout. Si on veut la portabilité VC6.0, c'est il me
semble la meilleur solution (ou alors ne jamais écrire deux for à la suite).

Si la bibliothèque Dinkum utilise la deuxième construction, elle
est inutilisable avec d'autres compilateurs que Visual. Du moins
c'est ce que j'ai entendu dire. D'où ma question.

La bibliothèque Dinkumware n'est pas celle livrée avec Visual C++ 6.0.
Elle a été volontairement modifiée pour prendre en compte les vraies
faiblesses du compilateur. Et de plus, la version accompagnant VC6.0 est
très ancienne (pour des raisons juridiques), ce qui peut expliquer que
par rapport à des bibliothèques C++ récente, elle puisse être à la
traine. Mais si tu compares par exemple à celle de gcc version 2.x, elle
est significativement en avance.

Pour plus d'info, voir par exemple,
http://www.cuj.com/documents/s27/cuj0104sutter/sutter.htm

C'est un peu vieux, mais bon, je ne connais pas de mises à jour.

--
Loïc

Gabriel Dos Reis

06/07/2004 à 04:38

Loïc Joly writes:

[...]

| > Si la bibliothèque Dinkum utilise la deuxième construction, elle
| > est inutilisable avec d'autres compilateurs que Visual. Du moins
| > c'est ce que j'ai entendu dire. D'où ma question.
|
| La bibliothèque Dinkumware n'est pas celle livrée avec Visual C++
| 6.0.

C'est la première fois que je vois cette curieuse interprétation.

Si cette interprétation est à la mode, alors la même chose vaut pour
celle de RogueWave vs. Sun CC.

Si la bibliothèque livrée avec Visual C++ 6.0 n'est pas celle de

| Elle a été volontairement modifiée pour prendre en compte les
| vraies faiblesses du compilateur. Et de plus, la version accompagnant
| VC6.0 est très ancienne (pour des raisons juridiques), ce qui peut
| expliquer que par rapport à des bibliothèques C++ récente, elle puisse
| être à la traine. Mais si tu compares par exemple à celle de gcc
| version 2.x, elle est significativement en avance.

La bbbliothèque livrée avec GCC-2.x n'est pas celle de GNU. <G>.

|
| Pour plus d'info, voir par exemple,
| http://www.cuj.com/documents/s27/cuj0104sutter/sutter.htm

Oui, mais ta version est vachement colorée, comparée à (extrait du site
en question) :

[...] because of the popularity of Dinkumware Ltd.?s library as a
replacement for the older Dinkumware library shipped with
Microsoft?s compiler, we additionally tested Dinkumware?s library
on Microsoft Visual C++.

| C'est un peu vieux, mais bon, je ne connais pas de mises à jour.
|

<quote bs>
Looking at the numbers, I felt a strong urge to ask questions about
specific features. For example, which compilers (correctly) require
template<> to precede a specialization? I can get a pretty good idea
if I can ?dig? into the data to the subsection level (14.7) and I
would be even happier if I could dig to the paragraph level
(14.7[3]). It would be wonderful if vendors would publish their
detailed scores [Perennial, at least, has in fact done this. See the
Perennial's test results. ? mb]. A collection of links to such
vendor scores would be an extremely useful tool for C++ programmers
with sufficient knowledge to use the Standard. What would it take to
make test suite output a practical tool for expert C++ programmers
in addition to serving implementers?

[...]

Naturally, the test suites place a lot of emphasis on showing which
features are present and correctly implemented. In addition, I?d like
to see an increased emphasis on detecting extensions. I?d like to know
what extensions are present in an implementation as default installed,
and also which ones might still be present after throwing an ?ISO
standard? switch. For example, which compilers accept specializations
without a template<> prefix?
</quote bs>

Je voudrais savoir qui place hash_map dans std::. ;-)

<quote ark>
Similarly, suppose a test suite makes an assumption that is true of
most ? but not all ? C++ implementations. Then some implementations
may fail a bunch of tests for the wrong reason: even though they
implement correctly the feature being tested, the test makes an
inappropriate assumption for those implementations.

Let?s make this discussion more concrete: the <string> standard
header is required to declare (among other things) an operator<<
that takes an ostream as its left argument (the actual types are
more complicated than that, but the idea is right), so that
programmers can write strings onto output streams. Most
implementations meet that requirement by having <string> include
<iostream>. Implementations are permitted to work that way, but they
are not required to do so.

Now consider the following program:

// include <string> but not <iostream>
#include <string>
int main()
{
std::cout << "Hello, world!" << std::endl;
return 0;
}
</quote ark>

Note : selon cette page, GCC ne représente pas une part majeur de la
communité C++, alors toute comparaison avec GCC est inique, insidueuse
et sans intérêt ;-)

-- Gaby,

Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:

[...]

| > Si la bibliothèque Dinkum utilise la deuxième construction, elle
| > est inutilisable avec d'autres compilateurs que Visual. Du moins
| > c'est ce que j'ai entendu dire. D'où ma question.
|
| La bibliothèque Dinkumware n'est pas celle livrée avec Visual C++
| 6.0.

C'est la première fois que je vois cette curieuse interprétation.

Si cette interprétation est à la mode, alors la même chose vaut pour
celle de RogueWave vs. Sun CC.

Si la bibliothèque livrée avec Visual C++ 6.0 n'est pas celle de

| Elle a été volontairement modifiée pour prendre en compte les
| vraies faiblesses du compilateur. Et de plus, la version accompagnant
| VC6.0 est très ancienne (pour des raisons juridiques), ce qui peut
| expliquer que par rapport à des bibliothèques C++ récente, elle puisse
| être à la traine. Mais si tu compares par exemple à celle de gcc
| version 2.x, elle est significativement en avance.

La bbbliothèque livrée avec GCC-2.x n'est pas celle de GNU. <G>.

|
| Pour plus d'info, voir par exemple,
| http://www.cuj.com/documents/s27/cuj0104sutter/sutter.htm

Oui, mais ta version est vachement colorée, comparée à (extrait du site
en question) :

[...] because of the popularity of Dinkumware Ltd.?s library as a
replacement for the older Dinkumware library shipped with
Microsoft?s compiler, we additionally tested Dinkumware?s library
on Microsoft Visual C++.

| C'est un peu vieux, mais bon, je ne connais pas de mises à jour.
|

<quote bs>
Looking at the numbers, I felt a strong urge to ask questions about
specific features. For example, which compilers (correctly) require
template<> to precede a specialization? I can get a pretty good idea
if I can ?dig? into the data to the subsection level (14.7) and I
would be even happier if I could dig to the paragraph level
(14.7[3]). It would be wonderful if vendors would publish their
detailed scores [Perennial, at least, has in fact done this. See the
Perennial's test results. ? mb]. A collection of links to such
vendor scores would be an extremely useful tool for C++ programmers
with sufficient knowledge to use the Standard. What would it take to
make test suite output a practical tool for expert C++ programmers
in addition to serving implementers?

[...]

Naturally, the test suites place a lot of emphasis on showing which
features are present and correctly implemented. In addition, I?d like
to see an increased emphasis on detecting extensions. I?d like to know
what extensions are present in an implementation as default installed,
and also which ones might still be present after throwing an ?ISO
standard? switch. For example, which compilers accept specializations
without a template<> prefix?
</quote bs>

Je voudrais savoir qui place hash_map dans std::. ;-)

<quote ark>
Similarly, suppose a test suite makes an assumption that is true of
most ? but not all ? C++ implementations. Then some implementations
may fail a bunch of tests for the wrong reason: even though they
implement correctly the feature being tested, the test makes an
inappropriate assumption for those implementations.

Let?s make this discussion more concrete: the <string> standard
header is required to declare (among other things) an operator<<
that takes an ostream as its left argument (the actual types are
more complicated than that, but the idea is right), so that
programmers can write strings onto output streams. Most
implementations meet that requirement by having <string> include
<iostream>. Implementations are permitted to work that way, but they
are not required to do so.

Now consider the following program:

// include <string> but not <iostream>
#include <string>
int main()
{
std::cout << "Hello, world!" << std::endl;
return 0;
}
</quote ark>

Note : selon cette page, GCC ne représente pas une part majeur de la
communité C++, alors toute comparaison avec GCC est inique, insidueuse
et sans intérêt ;-)

-- Gaby,

Vous avez filtré cet utilisateur ! Consultez son message

Loïc Joly writes:

[...]

| > Si la bibliothèque Dinkum utilise la deuxième construction, elle
| > est inutilisable avec d'autres compilateurs que Visual. Du moins
| > c'est ce que j'ai entendu dire. D'où ma question.
|
| La bibliothèque Dinkumware n'est pas celle livrée avec Visual C++
| 6.0.

C'est la première fois que je vois cette curieuse interprétation.

Si cette interprétation est à la mode, alors la même chose vaut pour
celle de RogueWave vs. Sun CC.

Si la bibliothèque livrée avec Visual C++ 6.0 n'est pas celle de

| Elle a été volontairement modifiée pour prendre en compte les
| vraies faiblesses du compilateur. Et de plus, la version accompagnant
| VC6.0 est très ancienne (pour des raisons juridiques), ce qui peut
| expliquer que par rapport à des bibliothèques C++ récente, elle puisse
| être à la traine. Mais si tu compares par exemple à celle de gcc
| version 2.x, elle est significativement en avance.

La bbbliothèque livrée avec GCC-2.x n'est pas celle de GNU. <G>.

|
| Pour plus d'info, voir par exemple,
| http://www.cuj.com/documents/s27/cuj0104sutter/sutter.htm

Oui, mais ta version est vachement colorée, comparée à (extrait du site
en question) :

[...] because of the popularity of Dinkumware Ltd.?s library as a
replacement for the older Dinkumware library shipped with
Microsoft?s compiler, we additionally tested Dinkumware?s library
on Microsoft Visual C++.

| C'est un peu vieux, mais bon, je ne connais pas de mises à jour.
|

<quote bs>
Looking at the numbers, I felt a strong urge to ask questions about
specific features. For example, which compilers (correctly) require
template<> to precede a specialization? I can get a pretty good idea
if I can ?dig? into the data to the subsection level (14.7) and I
would be even happier if I could dig to the paragraph level
(14.7[3]). It would be wonderful if vendors would publish their
detailed scores [Perennial, at least, has in fact done this. See the
Perennial's test results. ? mb]. A collection of links to such
vendor scores would be an extremely useful tool for C++ programmers
with sufficient knowledge to use the Standard. What would it take to
make test suite output a practical tool for expert C++ programmers
in addition to serving implementers?

[...]

Naturally, the test suites place a lot of emphasis on showing which
features are present and correctly implemented. In addition, I?d like
to see an increased emphasis on detecting extensions. I?d like to know
what extensions are present in an implementation as default installed,
and also which ones might still be present after throwing an ?ISO
standard? switch. For example, which compilers accept specializations
without a template<> prefix?
</quote bs>

Je voudrais savoir qui place hash_map dans std::. ;-)

<quote ark>
Similarly, suppose a test suite makes an assumption that is true of
most ? but not all ? C++ implementations. Then some implementations
may fail a bunch of tests for the wrong reason: even though they
implement correctly the feature being tested, the test makes an
inappropriate assumption for those implementations.

Let?s make this discussion more concrete: the <string> standard
header is required to declare (among other things) an operator<<
that takes an ostream as its left argument (the actual types are
more complicated than that, but the idea is right), so that
programmers can write strings onto output streams. Most
implementations meet that requirement by having <string> include
<iostream>. Implementations are permitted to work that way, but they
are not required to do so.

Now consider the following program:

// include <string> but not <iostream>
#include <string>
int main()
{
std::cout << "Hello, world!" << std::endl;
return 0;
}
</quote ark>

Note : selon cette page, GCC ne représente pas une part majeur de la
communité C++, alors toute comparaison avec GCC est inique, insidueuse
et sans intérêt ;-)

-- Gaby,

tib.motuelle

06/07/2004 à 09:42

Matthieu Moy wrote in message news:...

Andre Heinen writes:

for (int i=0 ; i<10 ; ++i) action();
for (int i=0 ; i<10 ; ++i) action();
Bien que ce code soit correct, il ne compilera pas avec VC++ (en
tout cas pas avec ma version): la deuxième ligne provoquera une
erreur en raison de la soi-disant redéclaration de i.

Parait-il que c'est corrigé dans VC++ 7.

Sinon, il y a la ruse de sioux :

#define for if(1) for

qui permet de rendre ça portable.

Cette forme de la macro change la signification du code suivant:

if (foo == 1)
for (int i = 0; i < 10; ++i) bar(i);
else
bar(-1);

La forme plus correcte (pas plus légale puisqu'il est interdit de
rédéfinir un mot clé, mais bon c'est un hack) inclut le else:
#define for if(0) ; else for

Bertrand.

Quel compilateur C++ pour develloper sous Linux (KDE)

10 réponses

Veuillez sélectionner un problème