C++ des boîtes et C++ des forums

On 19 Jul 2004 03:16:16 -0700, vc.spam@free.fr (Vince44):

Actuellement je suis ammené à faire de + en + de

C/C++

En cinq caractères, tu as décrit une bonne partie du problème : il est
très difficile de programmer sous Windows en C++, car tout a été fait
pour des programmeurs C.

ce qui m'emmerde profondément.

Je te comprends. La partie la plus chiante du travail du programmeur
C++ est de faire des wrappers pour des bibliothèques C (pas uniquement
l'API Win32).

Pourquoi éxiste-t-il 873 redéfinition d'un entier 32 bit?

Un des problèmes du C++ est que "typedef" se comporte un peu comme
"#define" : il ne déclare pas un nouveau type, mais un nouveau nom
pour le même type.

Du coup, si tu veux un type "identifiant de fichier", de 32 bits, et
que tu écris
typedef unsigned long IdentifiantDeFichier;

le compilo sera incapable de faire la différence entre
"IdentifiantDeFichier" et "unsigned long". Absence bizarre de typage
fort...

Les programmeur de chez MS sont payés au #define?

M'en parle pas...
Cela dit, on travaille là avec des méthodes mises au point au début de
Windows, et jamais changées depuis.

Pourquoi dans VC++ on doit choisir entre CString qui
est non portable, et "char *" qui est légèrement primitif !

Parce que std::string est très récent.
Du coup, avant qu'il arrive dans le standard, tout le monde a eu le
temps de faire sa propre version non portable.

Regarde le constructeur de fstream() pour voir ;-)

De plus, comme std::string est un template (basic_string <char,
quelque chose d'autre>), peu de compilateurs le supportent vraiment,
i.e. avec des messages d'erreurs clairs. Et du coup, même wxWidgets
définit sa propre classe wxString, non-template ! ~_~

On devrait disposer avec chaque
environnement C++ d'un bibliothèque portable reprenant au minimum les
fonctions des packages java.lang et java.util de java...

N'oublie pas que Java est un langage relativement simple et récent,
fait quasiment d'un seul coup par Sun. C++ est un langage plus ancien,
basé sur C, langage populaire mais ne convenant pas du tout à la
tâche, et fait de petits bouts rajoutés.

N'oulie pas aussi que plein de programmeurs C se croient capables de
bien programmer en C++.

Comment faire du C++ propre et portable (GUI portable en option) en
alternative à VC++. Ou, comment et avec quoi bossez-vous? Quel IDE,
quel compilo et surtout quelle(s) bibliothèque(s) pour remplacer les
MFC?

Pour l'instant, je programme avec OWL et Borland C++ 5.02.
Je garde OWL pour les projets commencés avec, mais compte passer à
wxWidgets pour les prochains projets.
Quand au compilo, je suis habitué à l'IDE de BC++ 5.02, mais je
virerais tout ça dès que j'en aurais assez marre du mauvais support
des templates...

vc.spam@free.fr (Vince44) writes:

Pourquoi dans VC++ on doit choisir entre CString qui
est non portable, et "char *" qui est légèrement primitif!!! (J'ai
une idée de la réponse...). On devrait disposer avec chaque
environnement C++ d'un bibliothèque portable reprenant au minimum les
fonctions des packages java.lang et java.util de java...

Il y en a quand même un bon morceau dans la STL :

http://www.sgi.com/tech/stl/

(en particulier std::string, pas parfait mais à peu près portable)

--
Matthieu

Vince44 wrote:

Bonjour à tous,

Actuellement je suis ammené à faire de + en + de C/C++ ce qui
m'emmerde profondément. ça n'est pas que je n'aime pas C++, mais
fesant pas mal de Java, je ne supporte pas les absurdités de la
programmation C/C++ sous Windows. Pourquoi éxiste-t-il 873
redéfinition d'un entier 32 bit???

Le poids de l'historique ?

Les programmeur de chez MS sont
payés au #define? Pourquoi dans VC++ on doit choisir entre CString qui
est non portable, et "char *" qui est légèrement primitif!!! (J'ai
une idée de la réponse...).

Idem :(

On devrait disposer avec chaque
environnement C++ d'un bibliothèque portable reprenant au minimum les
fonctions des packages java.lang et java.util de java...

Comme je ne sais pas ce qu'il y a là dedans...

Comment faire du C++ propre et portable (GUI portable en option) en
alternative à VC++. Ou, comment et avec quoi bossez-vous? Quel IDE,
quel compilo et surtout quelle(s) bibliothèque(s) pour remplacer les
MFC?

En terme de compilo ou de bibliothèque standard, VC++, dans sa dernière
version en particulier, et d'un très bon niveau. Si vous connaissez, je
vous déconseilles donc d'abandonner.

Par contre, les MFC, je suis d'accord pour dire qu'elle sont vraiment
pas bonne. Au boulot, on utilise QT pour faire du code portable (et même
parfois porté ;)). C'est plutôt bien fait, et agréable à utiliser. C'est
du C++ classique (ils veulent depuis longtemps une compatibilité même
avec des compilos peu à jour). WxWidgets est aussi souvent cité.

Le tout à l'echelle d'une PME et sans obliger tous mes collègues
à migrer avec moi (même si certains me suivraient bien volontier). Je
sais, je suis très éxigeant, mais bon, je viens de java ;-)

Pour ce qui d'une migration en douceur, il y a côté QT des passerelles
QT/ActiveX dans les deux sens. De même qu'il existe des bindings (dans
QT, et probablement dans WxWidgets) pour d'autres langages, type python.

Au passage, je suis bien intéressé par des bons livres

Pas de problèmes, y'en a plein....

(de préférence
en français,

Bin, si, problème, finalement... ;)

mais pas obligatoirement) sur la bonne programmation
(C/)C++... Mais j'imagine qu'en faisant qq recherches je trouverais la
réponse dans les archives... (si vous avez un lien vers un post
intressant...)

Dans la FAQ par exemple
(http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/), mais ça
n'a pas été remis à jour récemment. Il manque principalement à mon goût
"The C++ standard library" (Jossutis) et "C++ template, the complete
guide" de Vandevoorde et Jossutis (appel du pied à Gaby).

--
Loïc

On Mon, 19 Jul 2004 21:57:31 +0200, Loïc Joly
<loic.actarus.joly@wanadoo.fr>:

[...] QT [...]
WxWidgets est aussi souvent cité.

J'ai d'ailleurs l'impression qu'ils se ressemblent beaucoup : à chaque
fois que quelqu'un donne des arguments en faveur de QT, ils valent
aussi pour wxWidgets :-)

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

On 19 Jul 2004 03:16:16 -0700, vc.spam@free.fr (Vince44):

Actuellement je suis ammené à faire de + en + de

C/C++

En cinq caractères, tu as décrit une bonne partie du problème : il est
très difficile de programmer sous Windows en C++, car tout a été fait
pour des programmeurs C.

ce qui m'emmerde profondément.

Je te comprends. La partie la plus chiante du travail du programmeur
C++ est de faire des wrappers pour des bibliothèques C (pas uniquement
l'API Win32).
Je préfèrerais faire des wrapper, actuellement on utilise les biblio

C, du coup c'est plus rapide mais j'ai l'imprésion de pisser dans la
mer que l'on va devoir vider à la petite cuillière...

Pourquoi éxiste-t-il 873 redéfinition d'un entier 32 bit?

Un des problèmes du C++ est que "typedef" se comporte un peu comme
"#define" : il ne déclare pas un nouveau type, mais un nouveau nom
pour le même type.

Du coup, si tu veux un type "identifiant de fichier", de 32 bits, et
que tu écris
typedef unsigned long IdentifiantDeFichier;

le compilo sera incapable de faire la différence entre
"IdentifiantDeFichier" et "unsigned long". Absence bizarre de typage
fort...
Et bien ça promet, on a pas fini d'en chier... Ceux à qui on interdira

le #define ne manquerons pas de reprendre leurs mauvaises habitudes
avec le typedef...

Les programmeur de chez MS sont payés au #define?

M'en parle pas...
Cela dit, on travaille là avec des méthodes mises au point au début de
Windows, et jamais changées depuis.
Que ça soit vieux c'est une chose, que ça n'évolue pas ça en est une

autre...

Pourquoi dans VC++ on doit choisir entre CString qui
est non portable, et "char *" qui est légèrement primitif !

Parce que std::string est très récent.
Du coup, avant qu'il arrive dans le standard, tout le monde a eu le
temps de faire sa propre version non portable.
Ben non, pas nous :-) Nous on fait du TChar... Au moins on aura pas

travaillé pour rien...

Regarde le constructeur de fstream() pour voir ;-)

De plus, comme std::string est un template (basic_string <char,
quelque chose d'autre>), peu de compilateurs le supportent vraiment,
i.e. avec des messages d'erreurs clairs. Et du coup, même wxWidgets
définit sa propre classe wxString, non-template ! ~_~
Et là c'est le drame...

On devrait disposer avec chaque
environnement C++ d'un bibliothèque portable reprenant au minimum les
fonctions des packages java.lang et java.util de java...

N'oublie pas que Java est un langage relativement simple et récent,
fait quasiment d'un seul coup par Sun. C++ est un langage plus ancien,
basé sur C, langage populaire mais ne convenant pas du tout à la
tâche, et fait de petits bouts rajoutés.
Je n'oubli pas, je veux bien comprendre que C++ soit agé, mais il ne

me semble pas que le problème soit C++... Il me semble que c'est
surtout ce qui se fait autour. ça me donne l'impréssion que C++ est
une vitrine plus présentable que C, mais seulement une vitrine. Je ne
nie pas l'existence de C++ dans l'industrie, simplement si il faut
faire du C dès qu'on veut du portable ou du proche système on tape
dans le C... Je me demande si il ne manque pas un leader dans le
process d'évolution du langage C++: quelqu'un qui aurait dit à MS &
cie "démerdez-vous pour inclure la STDLib et écrire des wrappers pour
vos API, vous avez 5 ans." Moi j'aimerais bien voir "deprecated" en
face de toutes les fonctions C dans la MSDN... D'ailleurs je me
demande si ils ont écrit des wrappers pour C#, dans ce cas ça
signifirait qu'on ne les aura jamais pour C++. C++ serait la
génération sacrifiée...

N'oulie pas aussi que plein de programmeurs C se croient capables de
bien programmer en C++.
Je ne l'oubli pas, et c'est précisément pour ne pas les réjoindre que

je fais cette démarche... personnelement j'ai plutôt une culture
objet, mais actuellement en C/C++ je suis obligé de la mettre de
côté...

Comment faire du C++ propre et portable (GUI portable en option) en
alternative à VC++. Ou, comment et avec quoi bossez-vous? Quel IDE,
quel compilo et surtout quelle(s) bibliothèque(s) pour remplacer les
MFC?

Pour l'instant, je programme avec OWL et Borland C++ 5.02.
Je garde OWL pour les projets commencés avec, mais compte passer à
wxWidgets pour les prochains projets.
Quand au compilo, je suis habitué à l'IDE de BC++ 5.02, mais je
virerais tout ça dès que j'en aurais assez marre du mauvais support
des templates...

Merci pour tout, même si je suis un peu déçu. J'avoue que m'embarquer
dans du borland ne m'inspire pas vraiment, j'aurait préféré un truc
plus portable. Par exemple eclipse + stl + compilo "propre"
multiplate-forme (gcc? dispo sous windows?). Quand on discutait
C++/Java les gens étaient plus enthousiastes sur les possibilités de
dev propres et portables avec C++. Sans remettre en cause le language,
il semblerait que s'outiller correctement ne soit pas si simple, en
tout cas à mille lieues de ce qui est offert en Java...

Merci.

Comme tu as l'air de mettre tous les langages dans le même panier, je
vais tenter de remettre les pendules à l'heure -- en somme, un message
3699 plus que 42.

C# et Java ont beaucoup en commun : chacun est un langage (AMHA) moins
riche que le C++, fait par une seule entreprise qui contrôle presque
tout et fournit en même temps une bibliothèque assez complète ; nombre
très réduit d'éditeurs de compilateurs ("compilateur" étant bien sûr à
prendre au sens large).

C n'est pas très différent sur ce plan : s'il a évolué depuis K&R, il
n'évolue plus beaucoup maintenant. Il y a énormément de compilateurs
différents, mais tous ont eu le temps de se mettre à la page.
De plus, la communication entre deux applications (ou une application
et une API) est très simple, puisqu'il suffit d'exporter une table de
fonctions [nom => adresse], sans problème de surcharge, de namespaces,
de classes, etc.

C++, au contraire, est un langage très riche et qui évolue encore
beaucoup. Du coup, les compilateurs ont du mal à se mettre à la page
et à implémenter rapidement toutes les fonctionnalités[*].
D'autant que C++, s'il vient avec une bibliothèque standard (elle
aussi en constante évolution), ne fournit quasiment pas de fonctions
d'accès au système (en particulier, il ne fournit rien pour les
interfaces graphiques).
Du coup, on est obligé d'utiliser des bibliothèques externes.
Ces bibliothèques externes, au moment de leur création, utilisent les
fonctionnalités bien implémentées sur les compilateurs disponibles à
cette date. Puisque pas mal de ces bibliothèques (wxWidgets, MFC, OWL)
ont été créées avant que std::string soit commun, chacune a implémenté
sa propre classe "chaîne de caractères", avec plus ou moins de
bonheur.

En prime, pas mal de bibliothèques (Zlib par exemple) sont écrites en
C -- j'avoue n'avoir pas bien compris pourquoi. On se retrouve donc à
passer pas mal de temps à faire des wrappers pour ces bibliothèques --
voire à carrément les utiliser telles quelles, et à mélanger du C et
du C++ dans le programme principal. Et quand tu dois, dans un même
.cpp, mélanger des char*, des std::string et des wxString, c'est là
que le bordel commence...

Du coup, la programmation en C++ donne l'impression d'être un
assemblage de plein de trucs différents, venant de provenances
différentes...

Note que tu as raison sur un point : Microsoft va sans aucun doute
favoriser son langage, le C#, au détriment des langages sur lequel il
n'a aucun contrôle (C++ notamment).


[*] on en est où, avec "export", au fait ? ;-)

Fabien LE LEZ wrote:

J'ai d'ailleurs l'impression qu'ils se ressemblent beaucoup : à chaque
fois que quelqu'un donne des arguments en faveur de QT, ils valent
aussi pour wxWidgets :-)

Ils se ressemblent pas mal effectivement (C++, API indépendante de la
plate-forme etc...), mais ont des philosophies différentes :
- Qt est commercial : entreprise qui developpe, une licence payante
(petite exception : il existe une version GPL pour certains OS, mais pas
Widows), mais un developpement plus poussé (plus de fonctionnalités)
- WxWidgets est non commercial : un licence plus permissive (LGPL),
permettant de faire ce qu'on veut de son programme pour un cout nul,
mais un developpement moins abouti.

En prime, pas mal de bibliothèques (Zlib par exemple) sont écrites en
C -- j'avoue n'avoir pas bien compris pourquoi. On se retrouve donc à
passer pas mal de temps à faire des wrappers pour ces bibliothèques --
voire à carrément les utiliser telles quelles, et à mélanger du C et
du C++ dans le programme principal. Et quand tu dois, dans un même
.cpp, mélanger des char*, des std::string et des wxString, c'est là
que le bordel commence...

Du coup, la programmation en C++ donne l'impression d'être un
assemblage de plein de trucs différents, venant de provenances
différentes...

Note que tu as raison sur un point : Microsoft va sans aucun doute
favoriser son langage, le C#, au détriment des langages sur lequel il
n'a aucun contrôle (C++ notamment).

Il me semble qu'il y aurait moins de librairies écrites en C, et plus
écrites en C++ si le format binaire des .LIB était standardisé...

J'ai un certain nombre d'outils, libs et DLLs écrites en C++, mais je suis
obligé de me coltiner une interface externe en C si je veux être a peu près
certain d'avoir mon code compatible avec tous mes utilisateurs.

Mike (vite une ABI standard !)

On Tue, 20 Jul 2004 18:07:53 +0200, "Mickael Pointier"
<mpointier@edengames.moc>:

Il me semble qu'il y aurait moins de librairies écrites en C, et plus
écrites en C++ si le format binaire des .LIB était standardisé...

Mouais... la quasi-totalité des bibliothèques écrites en C que
j'utilise sont fournies sous forme de sources (parfois assez chiants à
compiler, d'ailleurs), rarement sous forme précompilée (.lib/.a). Du
coup, l'argument ne tient pas.


--
;-)

On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome
<jerome.martinez@aenlever-orangefrance.com.invalid>:

- Qt est commercial : entreprise qui developpe

Au fait, si jamais l'entreprise qui développe fait faillite, le
développement pourra-t-il continuer ?


--
;-)