je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win32
capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que me
conseilleriez vous ?
Merci.
On Mon, 16 Jun 2008 16:53:32 +0200, "Christian PANEL" :
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win32 capable d'être compilé sous MSC, GNU ou Borland (genre MFC)
Donc, si on résume, de telles bibliothèques sont : - wxWidgets - GTK+ + gtkmm
- peut-être WTL, que je n'ai pas regardée de près. La doc ne parle que de Visual C++. Pour les autres, on obtient des trucs assez négatifs, du style <http://lists-archives.org/mingw-users/09427-can-i-build-wtl-with-mingw.html>.
- Qt (version payante -- apparemment la version gratuite est prévue pour mingw uniquement). À noter par ailleurs : "gtkmm uses pure C++. Qt requires extensions to C++ that are parsed by the moc pre-processor." http://www.gtkmm.org/docs/gtkmm-2.4/docs/FAQ/html/index.html#id2506234
Vu le faible nombre de bibliothèques répondant à tes critères, tu peux te permettre de toutes les tester, pour décider de celle qui te convient le mieux.
D'une manière générale, j'ai la sérieuse impression qu'une bibliothèque prévue pour Windows est créée dans l'idée que le seul compilo existant est Visual C++, tandis qu'une bibliothèque créée pour Linux (puis portée sous Windows) est faite avec l'idée que rien d'autre que g++ n'existe. Quant à Borland, je ne savais même pas qu'ils s'intéressaient encore au C++. Du coup, trouver une bibliothèque (surtout une bibliothèque de gestion de fenêtres) compatible avec tous ces compilos s'avère coton :-/
On Mon, 16 Jun 2008 16:53:32 +0200, "Christian PANEL"
<c.panel@free.fr>:
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win32
capable d'être compilé sous MSC, GNU ou Borland (genre MFC)
Donc, si on résume, de telles bibliothèques sont :
- wxWidgets
- GTK+ + gtkmm
- peut-être WTL, que je n'ai pas regardée de près. La doc ne
parle que de Visual C++. Pour les autres, on obtient des trucs assez
négatifs, du style
<http://lists-archives.org/mingw-users/09427-can-i-build-wtl-with-mingw.html>.
- Qt (version payante -- apparemment la version gratuite est
prévue pour mingw uniquement).
À noter par ailleurs : "gtkmm uses pure C++. Qt requires
extensions to C++ that are parsed by the moc pre-processor."
http://www.gtkmm.org/docs/gtkmm-2.4/docs/FAQ/html/index.html#id2506234
Vu le faible nombre de bibliothèques répondant à tes critères, tu peux
te permettre de toutes les tester, pour décider de celle qui te
convient le mieux.
D'une manière générale, j'ai la sérieuse impression qu'une
bibliothèque prévue pour Windows est créée dans l'idée que le seul
compilo existant est Visual C++, tandis qu'une bibliothèque créée pour
Linux (puis portée sous Windows) est faite avec l'idée que rien
d'autre que g++ n'existe. Quant à Borland, je ne savais même pas
qu'ils s'intéressaient encore au C++.
Du coup, trouver une bibliothèque (surtout une bibliothèque de gestion
de fenêtres) compatible avec tous ces compilos s'avère coton :-/
On Mon, 16 Jun 2008 16:53:32 +0200, "Christian PANEL" :
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win32 capable d'être compilé sous MSC, GNU ou Borland (genre MFC)
Donc, si on résume, de telles bibliothèques sont : - wxWidgets - GTK+ + gtkmm
- peut-être WTL, que je n'ai pas regardée de près. La doc ne parle que de Visual C++. Pour les autres, on obtient des trucs assez négatifs, du style <http://lists-archives.org/mingw-users/09427-can-i-build-wtl-with-mingw.html>.
- Qt (version payante -- apparemment la version gratuite est prévue pour mingw uniquement). À noter par ailleurs : "gtkmm uses pure C++. Qt requires extensions to C++ that are parsed by the moc pre-processor." http://www.gtkmm.org/docs/gtkmm-2.4/docs/FAQ/html/index.html#id2506234
Vu le faible nombre de bibliothèques répondant à tes critères, tu peux te permettre de toutes les tester, pour décider de celle qui te convient le mieux.
D'une manière générale, j'ai la sérieuse impression qu'une bibliothèque prévue pour Windows est créée dans l'idée que le seul compilo existant est Visual C++, tandis qu'une bibliothèque créée pour Linux (puis portée sous Windows) est faite avec l'idée que rien d'autre que g++ n'existe. Quant à Borland, je ne savais même pas qu'ils s'intéressaient encore au C++. Du coup, trouver une bibliothèque (surtout une bibliothèque de gestion de fenêtres) compatible avec tous ces compilos s'avère coton :-/
jeremie fouche
On 18 juin, 01:30, Fabien LE LEZ wrote:
Du coup, trouver une bibliothèque (surtout une bibliothèque de gestio n de fenêtres) compatible avec tous ces compilos s'avère coton :-/
wxWidgets est OK : http://www.wxwidgets.org/about/feature2.htm, § Compiler support. Comment ça je ne suis plus objectif depuis le temps... Pour revenir un peu plus en charte, c'est pas la bibliotheque la plus / C++/, mais ça s'ameliore. -- Jérémie
On 18 juin, 01:30, Fabien LE LEZ <grams...@gramster.com> wrote:
Du coup, trouver une bibliothèque (surtout une bibliothèque de gestio n
de fenêtres) compatible avec tous ces compilos s'avère coton :-/
wxWidgets est OK : http://www.wxwidgets.org/about/feature2.htm, §
Compiler support.
Comment ça je ne suis plus objectif depuis le temps...
Pour revenir un peu plus en charte, c'est pas la bibliotheque la plus /
C++/, mais ça s'ameliore.
--
Jérémie
Du coup, trouver une bibliothèque (surtout une bibliothèque de gestio n de fenêtres) compatible avec tous ces compilos s'avère coton :-/
wxWidgets est OK : http://www.wxwidgets.org/about/feature2.htm, § Compiler support. Comment ça je ne suis plus objectif depuis le temps... Pour revenir un peu plus en charte, c'est pas la bibliotheque la plus / C++/, mais ça s'ameliore. -- Jérémie
Christian PANEL
merci à tous, c'est bien ce que je pensais. J'avais fait la même analyse que Fabien et pensais que peut être il y avait des choses qui m'avait échappé tant un bibliothèque de gestion de fenêtres me semblait être le B-A-BA incontournable. Du coup si on veut programmer sous windows, on a pas trop le choix (snif)
merci à tous, c'est bien ce que je pensais. J'avais fait la même analyse que
Fabien et pensais que peut être il y avait des choses qui m'avait échappé
tant un bibliothèque de gestion de fenêtres me semblait être le B-A-BA
incontournable. Du coup si on veut programmer sous windows, on a pas trop le
choix (snif)
merci à tous, c'est bien ce que je pensais. J'avais fait la même analyse que Fabien et pensais que peut être il y avait des choses qui m'avait échappé tant un bibliothèque de gestion de fenêtres me semblait être le B-A-BA incontournable. Du coup si on veut programmer sous windows, on a pas trop le choix (snif)
Fabien LE LEZ
On Wed, 18 Jun 2008 18:57:04 +0200, "Christian PANEL" :
Du coup si on veut programmer sous windows, on a pas trop le choix (snif)
Si tu veux programmer en C++, en étant vraiment compatible avec VC++ et g++, effectivement, tu n'as guère de choix. Pour "programmer sous Windows" en général, tu peux toutefois te restreindre à Visual Studio, auquel cas tu as le choix entre du presque-C++ (bibiothèque écrite plus ou moins en C++ mais pas vraiment compatible avec d'autres compilos), ou d'autres langages comme C#, Visual Basic ou C++CLI.
Note par ailleurs que Visual C++ est le compilateur canonique sous Windows, ce qui est moins gênant maintenant qu'il est à la fois gratuit et relativement conforme. De même, g++ est le compilateur canonique de Linux[*] ; on peut le faire tourner sous Windows (comme la plupart des programmes CLI de Linux), grâce à Cygwin (ou Mingw), mais c'est plus proche de l'émulation que d'un programme natif. Du coup, une bibliothèque compatible avec VC++ et g++ a aussi tendance à être compatible avec Windows et Linux[*]. Ou, dans l'autre sens, l'auteur d'une bibliothèque spécifique Windows a tendance à ne considérer que VC++.
[*] En fait, g++ a un rayon d'action plus important que ça : il est devenu le compilateur canonique de pas mal de versions d'Unix. Qu'en est-il de MacOSX, au fait ?
On Wed, 18 Jun 2008 18:57:04 +0200, "Christian PANEL"
<c.panel@free.fr>:
Du coup si on veut programmer sous windows, on a pas trop le
choix (snif)
Si tu veux programmer en C++, en étant vraiment compatible avec VC++
et g++, effectivement, tu n'as guère de choix.
Pour "programmer sous Windows" en général, tu peux toutefois te
restreindre à Visual Studio, auquel cas tu as le choix entre du
presque-C++ (bibiothèque écrite plus ou moins en C++ mais pas vraiment
compatible avec d'autres compilos), ou d'autres langages comme C#,
Visual Basic ou C++CLI.
Note par ailleurs que Visual C++ est le compilateur canonique sous
Windows, ce qui est moins gênant maintenant qu'il est à la fois
gratuit et relativement conforme. De même, g++ est le compilateur
canonique de Linux[*] ; on peut le faire tourner sous Windows (comme
la plupart des programmes CLI de Linux), grâce à Cygwin (ou Mingw),
mais c'est plus proche de l'émulation que d'un programme natif.
Du coup, une bibliothèque compatible avec VC++ et g++ a aussi tendance
à être compatible avec Windows et Linux[*]. Ou, dans l'autre sens,
l'auteur d'une bibliothèque spécifique Windows a tendance à ne
considérer que VC++.
[*] En fait, g++ a un rayon d'action plus important que ça : il est
devenu le compilateur canonique de pas mal de versions d'Unix. Qu'en
est-il de MacOSX, au fait ?
On Wed, 18 Jun 2008 18:57:04 +0200, "Christian PANEL" :
Du coup si on veut programmer sous windows, on a pas trop le choix (snif)
Si tu veux programmer en C++, en étant vraiment compatible avec VC++ et g++, effectivement, tu n'as guère de choix. Pour "programmer sous Windows" en général, tu peux toutefois te restreindre à Visual Studio, auquel cas tu as le choix entre du presque-C++ (bibiothèque écrite plus ou moins en C++ mais pas vraiment compatible avec d'autres compilos), ou d'autres langages comme C#, Visual Basic ou C++CLI.
Note par ailleurs que Visual C++ est le compilateur canonique sous Windows, ce qui est moins gênant maintenant qu'il est à la fois gratuit et relativement conforme. De même, g++ est le compilateur canonique de Linux[*] ; on peut le faire tourner sous Windows (comme la plupart des programmes CLI de Linux), grâce à Cygwin (ou Mingw), mais c'est plus proche de l'émulation que d'un programme natif. Du coup, une bibliothèque compatible avec VC++ et g++ a aussi tendance à être compatible avec Windows et Linux[*]. Ou, dans l'autre sens, l'auteur d'une bibliothèque spécifique Windows a tendance à ne considérer que VC++.
[*] En fait, g++ a un rayon d'action plus important que ça : il est devenu le compilateur canonique de pas mal de versions d'Unix. Qu'en est-il de MacOSX, au fait ?
Sylvain SF
Christian PANEL wrote on 18/06/2008 18:57:
merci à tous, c'est bien ce que je pensais. J'avais fait la même analyse que Fabien et pensais que peut être il y avait des choses qui m'avait échappé tant un bibliothèque de gestion de fenêtres me semblait être le B-A-BA incontournable. Du coup si on veut programmer sous windows, on a pas trop le choix (snif)
le choix de choix ? du compilo ou de la lib. d'IHM ?
coté compilo, on a en effet pas trop le choix, enfin si on ne cherche pas un compilo expérimental. coté lib. graphique, soit c'est du C/C++ et c'est compilable (ça veut pas dire linkable) avec n'importe quel compilo (y compris cross platform) soit c'est du n'importe quoi et on ne devrait pas même le compiler avec le compilo qu'il l'accompagnait.
en court, depuis le début je ne vois pas en quoi un lib. IHM serait plus compilo-dépendante que n'importe quelle autre lib.; et "compilo dépendant" sous windows, où les rares survivants ont toujours copiés au define près le compilo MS, ça fait très peu de dépendances.
Sylvain.
Christian PANEL wrote on 18/06/2008 18:57:
merci à tous, c'est bien ce que je pensais. J'avais fait la même analyse que
Fabien et pensais que peut être il y avait des choses qui m'avait échappé
tant un bibliothèque de gestion de fenêtres me semblait être le B-A-BA
incontournable. Du coup si on veut programmer sous windows, on a pas trop le
choix (snif)
le choix de choix ? du compilo ou de la lib. d'IHM ?
coté compilo, on a en effet pas trop le choix, enfin si on ne cherche
pas un compilo expérimental.
coté lib. graphique, soit c'est du C/C++ et c'est compilable (ça veut
pas dire linkable) avec n'importe quel compilo (y compris cross
platform) soit c'est du n'importe quoi et on ne devrait pas même le
compiler avec le compilo qu'il l'accompagnait.
en court, depuis le début je ne vois pas en quoi un lib. IHM serait
plus compilo-dépendante que n'importe quelle autre lib.; et "compilo
dépendant" sous windows, où les rares survivants ont toujours copiés
au define près le compilo MS, ça fait très peu de dépendances.
merci à tous, c'est bien ce que je pensais. J'avais fait la même analyse que Fabien et pensais que peut être il y avait des choses qui m'avait échappé tant un bibliothèque de gestion de fenêtres me semblait être le B-A-BA incontournable. Du coup si on veut programmer sous windows, on a pas trop le choix (snif)
le choix de choix ? du compilo ou de la lib. d'IHM ?
coté compilo, on a en effet pas trop le choix, enfin si on ne cherche pas un compilo expérimental. coté lib. graphique, soit c'est du C/C++ et c'est compilable (ça veut pas dire linkable) avec n'importe quel compilo (y compris cross platform) soit c'est du n'importe quoi et on ne devrait pas même le compiler avec le compilo qu'il l'accompagnait.
en court, depuis le début je ne vois pas en quoi un lib. IHM serait plus compilo-dépendante que n'importe quelle autre lib.; et "compilo dépendant" sous windows, où les rares survivants ont toujours copiés au define près le compilo MS, ça fait très peu de dépendances.
Sylvain.
Sylvain SF
Fabien LE LEZ wrote on 18/06/2008 19:13:
Pour "programmer sous Windows" en général, tu peux toutefois te restreindre à Visual Studio, auquel cas tu as le choix entre du presque-C++ (bibiothèque écrite plus ou moins en C++ mais pas vraiment compatible avec d'autres compilos)
tu peux expliquer ??
j'ai l'impression de lire: visual studio ne serait capable de compiler que du "plus ou moins C++", par définition "non compatible avec d'autres compilos" (qui eux sont "C++", ni "plus", ni "moins"); c'est bien ton point ? c'est un vécu ?
ou d'autres langages comme C#, Visual Basic ou C++CLI.
ou TCL/Tk, Java, voire html, mais on est sur fclc++ hein ,)
Du coup, une bibliothèque compatible avec VC++ et g++ a aussi tendance à être compatible avec Windows et Linux[*].
une lib. binaire aura tendance à être compatible avec rien du tout. une lib. source avec n'importe quel compilo non-trop-pourri.
Sylvain.
Fabien LE LEZ wrote on 18/06/2008 19:13:
Pour "programmer sous Windows" en général, tu peux toutefois te
restreindre à Visual Studio, auquel cas tu as le choix entre du
presque-C++ (bibiothèque écrite plus ou moins en C++ mais pas vraiment
compatible avec d'autres compilos)
tu peux expliquer ??
j'ai l'impression de lire: visual studio ne serait capable de compiler
que du "plus ou moins C++", par définition "non compatible avec d'autres
compilos" (qui eux sont "C++", ni "plus", ni "moins"); c'est bien ton
point ? c'est un vécu ?
ou d'autres langages comme C#, Visual Basic ou C++CLI.
ou TCL/Tk, Java, voire html, mais on est sur fclc++ hein ,)
Du coup, une bibliothèque compatible avec VC++ et g++ a aussi tendance
à être compatible avec Windows et Linux[*].
une lib. binaire aura tendance à être compatible avec rien du tout.
une lib. source avec n'importe quel compilo non-trop-pourri.
Pour "programmer sous Windows" en général, tu peux toutefois te restreindre à Visual Studio, auquel cas tu as le choix entre du presque-C++ (bibiothèque écrite plus ou moins en C++ mais pas vraiment compatible avec d'autres compilos)
tu peux expliquer ??
j'ai l'impression de lire: visual studio ne serait capable de compiler que du "plus ou moins C++", par définition "non compatible avec d'autres compilos" (qui eux sont "C++", ni "plus", ni "moins"); c'est bien ton point ? c'est un vécu ?
ou d'autres langages comme C#, Visual Basic ou C++CLI.
ou TCL/Tk, Java, voire html, mais on est sur fclc++ hein ,)
Du coup, une bibliothèque compatible avec VC++ et g++ a aussi tendance à être compatible avec Windows et Linux[*].
une lib. binaire aura tendance à être compatible avec rien du tout. une lib. source avec n'importe quel compilo non-trop-pourri.
Sylvain.
Fabien LE LEZ
On Thu, 19 Jun 2008 00:07:43 +0200, Sylvain SF :
tu peux expliquer ??
j'ai l'impression de lire: visual studio ne serait capable de compiler que du "plus ou moins C++"
Si une bibliothèque est compatible avec Visual C++ mais pas avec g++, c'est qu'elle n'est pas écrite en C++, mais en "VC++", c'est-à-dire, C++ + des extensions propriétaires.
une lib. source avec n'importe quel compilo non-trop-pourri.
Si elle est écrite en C++, oui. Si elle est écrite en C++ + des extensions spécifiques à un compilateur, elle ne sera utilisable qu'avec ce compilateur.
On Thu, 19 Jun 2008 00:07:43 +0200, Sylvain SF
<sylvain@boiteaspam.info>:
tu peux expliquer ??
j'ai l'impression de lire: visual studio ne serait capable de compiler
que du "plus ou moins C++"
Si une bibliothèque est compatible avec Visual C++ mais pas avec g++,
c'est qu'elle n'est pas écrite en C++, mais en "VC++", c'est-à-dire,
C++ + des extensions propriétaires.
une lib. source avec n'importe quel compilo non-trop-pourri.
Si elle est écrite en C++, oui. Si elle est écrite en C++ + des
extensions spécifiques à un compilateur, elle ne sera utilisable
qu'avec ce compilateur.
j'ai l'impression de lire: visual studio ne serait capable de compiler que du "plus ou moins C++"
Si une bibliothèque est compatible avec Visual C++ mais pas avec g++, c'est qu'elle n'est pas écrite en C++, mais en "VC++", c'est-à-dire, C++ + des extensions propriétaires.
une lib. source avec n'importe quel compilo non-trop-pourri.
Si elle est écrite en C++, oui. Si elle est écrite en C++ + des extensions spécifiques à un compilateur, elle ne sera utilisable qu'avec ce compilateur.
Fabien LE LEZ
On Thu, 19 Jun 2008 00:01:44 +0200, Sylvain SF :
coté lib. graphique, soit c'est du C/C++ et c'est compilable (ça veut pas dire linkable) avec n'importe quel compilo (y compris cross platform) soit c'est du n'importe quoi et on ne devrait pas même le compiler avec le compilo qu'il l'accompagnait.
Ci-dessous un exemple de code incorrect selon la norme, mais qui est parfaitement accepté par VC++ 2008, et qui a le comportement auquel le programmeur s'attendait. J'ai développé un code réel hier avec VC++, et il a fallu que je tente la compilation avec g++ pour m'apercevoir du bug. Si je n'avais pas testé le code avec g++, j'aurais bel et bien pondu du code qui fonctionne avec VC++ uniquement. Je suis d'accord avec toi, c'est du "n'importe quoi", mais on rencontre plein d'incongruités de ce genre dans du code testé avec un seul compilateur :-(
class A { public: A() {} private: A (A const&); };
class B { A a; };
B f() { return B(); }
int main() { B b= f(); }
On Thu, 19 Jun 2008 00:01:44 +0200, Sylvain SF
<sylvain@boiteaspam.info>:
coté lib. graphique, soit c'est du C/C++ et c'est compilable (ça veut
pas dire linkable) avec n'importe quel compilo (y compris cross
platform) soit c'est du n'importe quoi et on ne devrait pas même le
compiler avec le compilo qu'il l'accompagnait.
Ci-dessous un exemple de code incorrect selon la norme, mais qui est
parfaitement accepté par VC++ 2008, et qui a le comportement auquel le
programmeur s'attendait.
J'ai développé un code réel hier avec VC++, et il a fallu que je tente
la compilation avec g++ pour m'apercevoir du bug.
Si je n'avais pas testé le code avec g++, j'aurais bel et bien pondu
du code qui fonctionne avec VC++ uniquement. Je suis d'accord avec
toi, c'est du "n'importe quoi", mais on rencontre plein d'incongruités
de ce genre dans du code testé avec un seul compilateur :-(
class A
{
public:
A() {}
private:
A (A const&);
};
coté lib. graphique, soit c'est du C/C++ et c'est compilable (ça veut pas dire linkable) avec n'importe quel compilo (y compris cross platform) soit c'est du n'importe quoi et on ne devrait pas même le compiler avec le compilo qu'il l'accompagnait.
Ci-dessous un exemple de code incorrect selon la norme, mais qui est parfaitement accepté par VC++ 2008, et qui a le comportement auquel le programmeur s'attendait. J'ai développé un code réel hier avec VC++, et il a fallu que je tente la compilation avec g++ pour m'apercevoir du bug. Si je n'avais pas testé le code avec g++, j'aurais bel et bien pondu du code qui fonctionne avec VC++ uniquement. Je suis d'accord avec toi, c'est du "n'importe quoi", mais on rencontre plein d'incongruités de ce genre dans du code testé avec un seul compilateur :-(
class A { public: A() {} private: A (A const&); };
class B { A a; };
B f() { return B(); }
int main() { B b= f(); }
Fabien LE LEZ
On Thu, 19 Jun 2008 00:01:44 +0200, Sylvain SF :
en court, depuis le début je ne vois pas en quoi un lib. IHM serait plus compilo-dépendante que n'importe quelle autre lib.
Moi non plus. Le seul truc, c'est que plus une bibliothèque est grosse, plus elle a de chances de contenir du code incorrect. Et les bibliothèques d'IHM sont généralement assez grosses.
; et "compilo dépendant" sous windows, où les rares survivants ont toujours copiés au define près le compilo MS, ça fait très peu de dépendances.
Ça dépend ce que tu entends par "survivant". On trouve du code compilable sous VC++ 6, qui n'est compatible ni avec g++, ni avec Borland C++ 5.x, ni avec VC++ 2003.
On Thu, 19 Jun 2008 00:01:44 +0200, Sylvain SF
<sylvain@boiteaspam.info>:
en court, depuis le début je ne vois pas en quoi un lib. IHM serait
plus compilo-dépendante que n'importe quelle autre lib.
Moi non plus. Le seul truc, c'est que plus une bibliothèque est
grosse, plus elle a de chances de contenir du code incorrect. Et les
bibliothèques d'IHM sont généralement assez grosses.
; et "compilo
dépendant" sous windows, où les rares survivants ont toujours copiés
au define près le compilo MS, ça fait très peu de dépendances.
Ça dépend ce que tu entends par "survivant". On trouve du code
compilable sous VC++ 6, qui n'est compatible ni avec g++, ni avec
Borland C++ 5.x, ni avec VC++ 2003.
en court, depuis le début je ne vois pas en quoi un lib. IHM serait plus compilo-dépendante que n'importe quelle autre lib.
Moi non plus. Le seul truc, c'est que plus une bibliothèque est grosse, plus elle a de chances de contenir du code incorrect. Et les bibliothèques d'IHM sont généralement assez grosses.
; et "compilo dépendant" sous windows, où les rares survivants ont toujours copiés au define près le compilo MS, ça fait très peu de dépendances.
Ça dépend ce que tu entends par "survivant". On trouve du code compilable sous VC++ 6, qui n'est compatible ni avec g++, ni avec Borland C++ 5.x, ni avec VC++ 2003.
Sylvain SF
Fabien LE LEZ wrote on 19/06/2008 01:20:
Ça dépend ce que tu entends par "survivant". On trouve du code compilable sous VC++ 6, qui n'est compatible ni avec g++, ni avec Borland C++ 5.x, ni avec VC++ 2003.
vc6 et vc2003 ont en gros 5 ans d'écart non ?
si comme le PO tu partais du choix: n'importe quel compilo et n'importe quel lib. UI (mais en win32) tu choissirais exprès un compilo d'une génération et une lib. d'une autre ?
pour ma part je compilerais plutot les MFC 4.x avec VC5 ou 6 ou encore BC 5.5 et les MFC 8.x avec VC2005 ou 08.
Sylvain.
Fabien LE LEZ wrote on 19/06/2008 01:20:
Ça dépend ce que tu entends par "survivant". On trouve du code
compilable sous VC++ 6, qui n'est compatible ni avec g++, ni avec
Borland C++ 5.x, ni avec VC++ 2003.
vc6 et vc2003 ont en gros 5 ans d'écart non ?
si comme le PO tu partais du choix: n'importe quel compilo et n'importe
quel lib. UI (mais en win32) tu choissirais exprès un compilo d'une
génération et une lib. d'une autre ?
pour ma part je compilerais plutot les MFC 4.x avec VC5 ou 6 ou encore
BC 5.5 et les MFC 8.x avec VC2005 ou 08.
Ça dépend ce que tu entends par "survivant". On trouve du code compilable sous VC++ 6, qui n'est compatible ni avec g++, ni avec Borland C++ 5.x, ni avec VC++ 2003.
vc6 et vc2003 ont en gros 5 ans d'écart non ?
si comme le PO tu partais du choix: n'importe quel compilo et n'importe quel lib. UI (mais en win32) tu choissirais exprès un compilo d'une génération et une lib. d'une autre ?
pour ma part je compilerais plutot les MFC 4.x avec VC5 ou 6 ou encore BC 5.5 et les MFC 8.x avec VC2005 ou 08.
