Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Quel compilateur C++ pour develloper sous Linux (KDE)

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

56 réponses
Avatar
Socrate
Je suis actuellement sous XP
Je passe sous linux, mandrake + précisément, et je cherche un bon
compilateur


merci d'avance
Signaler un problème avec ce contenu

6 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
2 3 4 5 6
Avatar
kanze
Andre Heinen wrote in message
news:...
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.


Je sais. C'est ce que moi, j'ai voulu dire. L'implémentation d'une
bibliothèque standard contiendra forcément du code qui dépend de
l'implémentation. Si tu régardes dans l'implémentation de la
bibliothèque de g++, par exemple, je suis sûr que tu trouveras du code
qui est différent pour Windows que pour Unix. (Pense, par exemple, à la
gestion de mode binary dans filebuf.)

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.


Et alors ? Jusqu'ici, je n'ai jamais eu un problème avec ceci.

Je ne sais pas pourquoi tout le monde en parle autant. Si c'était le
plus grand problème de VC++, ça serait formidable.

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.


Et si la bibliothèque ne comporte aucune fonction avec deux boucles for,
l'une derrière l'autre ? Ou si elle en contient, elle utilise des noms
de variables différentes ?

Il y avait des problèmes avec VC++ 5.0. La version de la bibliothèque
Dinkumware qui était livrée avec ce compilateur avait supprimé toutes
les membres templatés, par exemple. Ce qui n'était pas le cas pour la
version de la bibliothèque qu'il livre pour le compilateur Comeau sous
Linux.

--
James Kanze GABI Software http://www.gabi-soft.fr
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


Avatar
Andre Heinen
On 6 Jul 2004 03:04:40 -0700, wrote:

L'implémentation d'une
bibliothèque standard contiendra forcément du code qui dépend de
l'implémentation. Si tu régardes dans l'implémentation de la
bibliothèque de g++, par exemple, je suis sûr que tu trouveras du code
qui est différent pour Windows que pour Unix. (Pense, par exemple, à la
gestion de mode binary dans filebuf.)


Naïvement, je me disais qu'une implémentation de la bibliothèque
standard pouvait être portable et "correcte". Auquel cas elle
aurait dû pouvoir fonctionner avec n'importe quel compilateur
"suffisamment correct".

D'après ta réponse, je comprends que ce n'est pas le cas.

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.


Et alors ? Jusqu'ici, je n'ai jamais eu un problème avec ceci.


Moi non plus.

Je ne sais pas pourquoi tout le monde en parle autant. Si c'était le
plus grand problème de VC++, ça serait formidable.


C'est juste le premier exemple qui m'est venu à l'esprit pour
essayer d'expliquer pourquoi je craignais que la Dinkum ne pose
des problèmes.

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


Avatar
Gabriel Dos Reis
writes:

| Andre Heinen wrote in message
| news:...
| > 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.
|
| Je sais. C'est ce que moi, j'ai voulu dire. L'implémentation d'une
| bibliothèque standard contiendra forcément du code qui dépend de
| l'implémentation.

Mais ce ne sont pas tous les composants qui contiennent du code
non-standard ou sont obligés d'inclure du code non-standard.
vector<T> n'est pas obligé d'être écrit en C++ non-standard.

Je trouve l'argument fallacieux. Un composant peut se trouver dans la
bibliothèque standard non pas parce qu'il requiert du code
non-standard. Mais simplement parce que c'est pratique et ce serait
bien si tout le monde utilisait la même chose. Les containers, les
algorithmes, les itérateurs ne requierent pas du code non-standard.
Les classes d'hiérarchie d'exception non plus.

-- Gaby
Avatar
kanze
Andre Heinen wrote in message
news:...

On 6 Jul 2004 03:04:40 -0700, wrote:

L'implémentation d'une bibliothèque standard contiendra forcément du
code qui dépend de l'implémentation. Si tu régardes dans
l'implémentation de la bibliothèque de g++, par exemple, je suis sûr
que tu trouveras du code qui est différent pour Windows que pour
Unix. (Pense, par exemple, à la gestion de mode binary dans filebuf.)


Naïvement, je me disais qu'une implémentation de la bibliothèque
standard pouvait être portable et "correcte". Auquel cas elle aurait
dû pouvoir fonctionner avec n'importe quel compilateur "suffisamment
correct".

D'après ta réponse, je comprends que ce n'est pas le cas.


En général, non. Il y a des choses dans la bibliothèque qui peuvent être
implémentée en C++ standard -- std::vector, par exemple. Mais même là,
un des avantages de les mettre dans la norme, c'est que le compilateur
peut « savoir » ce qu'ils font, et optimiser mieux -- si j'écris quelque
chose comme :

void f( std::string const& ) ;

f( "texte" )

par exemple, un bon compilateur va simplement généré une chaîne
préconstruite dans la mémoire, et la passer à la fonction, de façon à ce
que le temps d'execution du constructeur de la chaîne soit 0. (Pour
l'instant, évidemment, on n'y est pas encore. Les implémenteurs des
compilateurs ont déjà trop à faire pour implémenter tout le langage.)

Disons que le fait qu'une fonctionalité généralement utile ne soit pas
implémentable dans le cadre du langage standard est une raison
suffisante pour qu'elle fasse partie de la norme. Mais que ce n'est pas
la seule raison possible -- indépendamment des histoires d'optimisation,
quelque chose comme string ou vector sont si générale, et vont
apparaître dans tant d'interfaces, qu'il faut qu'ils soient normalisés
aussi, même si leur implémentation en C++ standard ne pose pas de
problèmes particuliers.

Enfin, tout ce que j'ai voulu dire, c'est qu'une implémentation de la
bibliothèque va dépendre de l'implémentation générale du compilateur.
Pas à chaque ligne de code, évidemment, et même pas dans chaque
fonction. Mais il y aurait bien du code qu'il faut changer selon la
plate-forme.

--
James Kanze GABI Software http://www.gabi-soft.fr
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


Avatar
kanze
Gabriel Dos Reis wrote in message
news:...
writes:

| Andre Heinen wrote in message
| news:...
| > 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.

| Je sais. C'est ce que moi, j'ai voulu dire. L'implémentation d'une
| bibliothèque standard contiendra forcément du code qui dépend de
| l'implémentation.

Mais ce ne sont pas tous les composants qui contiennent du code
non-standard ou sont obligés d'inclure du code non-standard. vector<T>
n'est pas obligé d'être écrit en C++ non-standard.

Je trouve l'argument fallacieux. Un composant peut se trouver dans la
bibliothèque standard non pas parce qu'il requiert du code
non-standard. Mais simplement parce que c'est pratique et ce serait
bien si tout le monde utilisait la même chose. Les containers, les
algorithmes, les itérateurs ne requierent pas du code non-standard.
Les classes d'hiérarchie d'exception non plus.


Est-ce que ça t'arrive à lire les messages auxquels tu réponds ? Tout ce
que j'ai dit, c'est qu'une implémentation de la bibliothèque standard
contiendrait forcément du code qui dépend de l'implémentation. Je n'ai
pas dit que tout le code dans la bibliothèque doit dépendre de
l'implémentation. Même dans le cas de quelque chose comme filebuf, il y
aurait probablement 80-90% du code qui est portable (toute la gestion
des buffers, par exemple).

Le fait qu'une fonctionalité est généralement utile, et qu'elle ne peut
pas être implémentée de façon portable, est un argument de poids pour sa
normalisation, pour que les aspects propres à l'implémentation soit le
problème de l'implémentation, et non du programmeur lambda. Mais c'est
loin d'être le seul argument possible pour la normalisation de quelque
chose. (Encore qu'il y a des minimalistes qui diraient... Mais ils n'ont
pas beaucoup d'influence sur l'évolution de C++.)

--
James Kanze GABI Software http://www.gabi-soft.fr
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

Avatar
Gabriel Dos Reis
writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:
|
| > | Andre Heinen wrote in message
| > | news:...
| > | > 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.
|
| > | Je sais. C'est ce que moi, j'ai voulu dire. L'implémentation d'une
| > | bibliothèque standard contiendra forcément du code qui dépend de
| > | l'implémentation.
|
| > Mais ce ne sont pas tous les composants qui contiennent du code
| > non-standard ou sont obligés d'inclure du code non-standard. vector<T>
| > n'est pas obligé d'être écrit en C++ non-standard.
|
| > Je trouve l'argument fallacieux. Un composant peut se trouver dans la
| > bibliothèque standard non pas parce qu'il requiert du code
| > non-standard. Mais simplement parce que c'est pratique et ce serait
| > bien si tout le monde utilisait la même chose. Les containers, les
| > algorithmes, les itérateurs ne requierent pas du code non-standard.
| > Les classes d'hiérarchie d'exception non plus.
|
| Est-ce que ça t'arrive à lire les messages auxquels tu réponds ? Tout ce

Par une extraordinaire coincidence, c'est ce que j'ai fait.

-- Gaby
2 3 4 5 6