J'apprends le C avec K&R et Deitel&Deitel et C the Complete Reference.
Aucun des trois ne cite LPSTR.
Ce que je dis c'est qu'il doit bien y avoir un livre dans lequel on peut apprendre le C avec LPSTR mentionné quelque part.
winnt.h.
merci
JPD
"AMcD®" a écrit dans le message de news: 422e589a$0$15714$
Jean Pierre Daviau wrote:
J'ai l'impression que ça ne répond pas à ma question.
*LPSTR
Error E2349 environ.c 10: Nonportable pointer conversion in function main
Sérieux...
LPSTR c'est un type fondamental de Windows. Tu l'as défini dans winnt.h.
Je crains qu'il ne te faille apprendre d'abord le C, puis ensuite à programmer sous Windows... J'ai la nette impression que tu mélanges un peu tout.
-- AMcD®
http://arnold.mcdonald.free.fr/
AMcD®
Jean Pierre Daviau wrote:
J'apprends le C avec K&R et Deitel&Deitel et C the Complete Reference.
Aucun des trois ne cite LPSTR.
Évidemment, ce n'est pas un type C pur, c'est un type Windows. Un type défini par typedef comme je t'ai indiqué ailleurs.
Ce que je dis c'est qu'il doit bien y avoir un livre dans lequel on peut apprendre le C avec LPSTR mentionné quelque part.
Je ne crois pas. On apprends d'abord le C, ensuite à programmer sous Windows en C. Les deux sont distincts car tu peux programmer sous Unix en C, sous OS X en C, etc. Ne confonds pas langage et système d'exploitation.
-- AMcD®
http://arnold.mcdonald.free.fr/
Jean Pierre Daviau wrote:
J'apprends le C avec K&R et Deitel&Deitel et C the Complete Reference.
Aucun des trois ne cite LPSTR.
Évidemment, ce n'est pas un type C pur, c'est un type Windows. Un type
défini par typedef comme je t'ai indiqué ailleurs.
Ce que je dis c'est qu'il doit bien y avoir un livre dans lequel on
peut apprendre le C avec LPSTR mentionné quelque part.
Je ne crois pas. On apprends d'abord le C, ensuite à programmer sous Windows
en C. Les deux sont distincts car tu peux programmer sous Unix en C, sous OS
X en C, etc. Ne confonds pas langage et système d'exploitation.
J'apprends le C avec K&R et Deitel&Deitel et C the Complete Reference.
Aucun des trois ne cite LPSTR.
Évidemment, ce n'est pas un type C pur, c'est un type Windows. Un type défini par typedef comme je t'ai indiqué ailleurs.
Ce que je dis c'est qu'il doit bien y avoir un livre dans lequel on peut apprendre le C avec LPSTR mentionné quelque part.
Je ne crois pas. On apprends d'abord le C, ensuite à programmer sous Windows en C. Les deux sont distincts car tu peux programmer sous Unix en C, sous OS X en C, etc. Ne confonds pas langage et système d'exploitation.
"Pierre Maurette" a écrit dans le message de news: 422ee735$0$23414$
AMcD® a écrit :
Jean Pierre Daviau wrote:
:-) scusez moi mais
LPSTR
j'ai pas vu dans K&R
JPD
S'il n'y a que ça...
typedef CHAR *LPSTR, *PSTR;
et: typedef char CHAR;
et surtout pas: #define LPSTR char*
;-)
-- Pierre
Stephane Legras-Decussy
AMcD® a écrit dans le message : 422ee6ed$0$12548$
Évidemment, ce n'est pas un type C pur, c'est un type Windows. Un type défini par typedef comme je t'ai indiqué ailleurs.
à ce propos, je commence à bien m'amuser à devellopper en win32, cela pose t-il un probleme de ne pas se coltiner les types à la c** de microsoft, et de preferer de loin un bon vieux char* ?
de meme quel est l'"interet des WORD, qu'est-ce qui ne va pas avec les int et les long ?
(bien sûr les typedef objet HWND, HPEN, HBITMAP... sont utiles)
AMcD® <arnold.mcdonald@free.fr> a écrit dans le message :
422ee6ed$0$12548$636a15ce@news.free.fr...
Évidemment, ce n'est pas un type C pur, c'est un type Windows. Un type
défini par typedef comme je t'ai indiqué ailleurs.
à ce propos, je commence à bien m'amuser à devellopper
en win32, cela pose t-il un probleme de ne pas se coltiner les types
à la c** de microsoft, et de preferer de loin un bon vieux char* ?
de meme quel est l'"interet des WORD, qu'est-ce qui ne va pas avec
les int et les long ?
(bien sûr les typedef objet HWND, HPEN, HBITMAP... sont utiles)
Évidemment, ce n'est pas un type C pur, c'est un type Windows. Un type défini par typedef comme je t'ai indiqué ailleurs.
à ce propos, je commence à bien m'amuser à devellopper en win32, cela pose t-il un probleme de ne pas se coltiner les types à la c** de microsoft, et de preferer de loin un bon vieux char* ?
de meme quel est l'"interet des WORD, qu'est-ce qui ne va pas avec les int et les long ?
(bien sûr les typedef objet HWND, HPEN, HBITMAP... sont utiles)
AMcD®
Stephane Legras-Decussy wrote:
à ce propos, je commence à bien m'amuser à devellopper en win32, cela pose t-il un probleme de ne pas se coltiner les types à la c** de microsoft, et de preferer de loin un bon vieux char* ?
Ben aujourd'hui on fait de l'Unicode. Donc, si tu restes avec des char, tu risques d'être qu'ANSI :-).
de meme quel est l'"interet des WORD, qu'est-ce qui ne va pas avec les int et les long ?
Les int n'ont pas de taille fixe suivant les architectures. 2, 4 octets. Le word, c'est 2 BYTE, donc 16 bits.
(bien sûr les typedef objet HWND, HPEN, HBITMAP... sont utiles).
Barf, fait de l'ASM, tu n'utilises que les types 8, 16, 32, 48 et 64 bits. Tu peux quasi tout afire avec ces 5 types ;-).
-- AMcD®
http://arnold.mcdonald.free.fr/
Stephane Legras-Decussy wrote:
à ce propos, je commence à bien m'amuser à devellopper
en win32, cela pose t-il un probleme de ne pas se coltiner les types
à la c** de microsoft, et de preferer de loin un bon vieux char* ?
Ben aujourd'hui on fait de l'Unicode. Donc, si tu restes avec des char, tu
risques d'être qu'ANSI :-).
de meme quel est l'"interet des WORD, qu'est-ce qui ne va pas avec
les int et les long ?
Les int n'ont pas de taille fixe suivant les architectures. 2, 4 octets. Le
word, c'est 2 BYTE, donc 16 bits.
(bien sûr les typedef objet HWND, HPEN, HBITMAP... sont utiles).
Barf, fait de l'ASM, tu n'utilises que les types 8, 16, 32, 48 et 64 bits.
Tu peux quasi tout afire avec ces 5 types ;-).
à ce propos, je commence à bien m'amuser à devellopper en win32, cela pose t-il un probleme de ne pas se coltiner les types à la c** de microsoft, et de preferer de loin un bon vieux char* ?
Ben aujourd'hui on fait de l'Unicode. Donc, si tu restes avec des char, tu risques d'être qu'ANSI :-).
de meme quel est l'"interet des WORD, qu'est-ce qui ne va pas avec les int et les long ?
Les int n'ont pas de taille fixe suivant les architectures. 2, 4 octets. Le word, c'est 2 BYTE, donc 16 bits.
(bien sûr les typedef objet HWND, HPEN, HBITMAP... sont utiles).
Barf, fait de l'ASM, tu n'utilises que les types 8, 16, 32, 48 et 64 bits. Tu peux quasi tout afire avec ces 5 types ;-).
-- AMcD®
http://arnold.mcdonald.free.fr/
Dominique Vaufreydaz
Bonjour,
Barf, fait de l'ASM, tu n'utilises que les types 8, 16, 32, 48 et 64 bits. Tu peux quasi tout afire avec ces 5 types ;-).
D'ailleurs, c'est ce que fait ton compilateur !
Doms.
Bonjour,
Barf, fait de l'ASM, tu n'utilises que les types 8, 16, 32, 48 et 64
bits. Tu peux quasi tout afire avec ces 5 types ;-).
Barf, fait de l'ASM, tu n'utilises que les types 8, 16, 32, 48 et 64 bits. Tu peux quasi tout afire avec ces 5 types ;-).
D'ailleurs, c'est ce que fait ton compilateur !
Doms.
Patrick Philippot
Bonjour,
Stephane Legras-Decussy wrote:
cela pose t-il un probleme de ne pas se coltiner les types à la c** de microsoft, et de preferer de loin un bon vieux char* ?
Oui.
1. Les types standardisés de Microsoft ont permis d'assurer la compatibilité ascendante VC++ (au détail près) depuis VC++ 1.0 16-bit (1993). Pour des types à la c.. , je trouve ça pas mal. Un programme C/C++ écrit il y a 12 ans en respectant les conventions de type MS peut être repris aujourd'hui pratiquement sans modif. Tout le monde ne peut pas en dire autant.
2. Comme cela a été précisé, UNICODE devient progressivement la norme et est le seul jeu de cracatères reconnu par le système en interne. Les nouvelles technologies de développement et en particulier .Net ne connaissent également qu'UNICODE. Donc il serait fort opportun dans votre code d'utiliser TCHAR.H et les fonctions de manipulation chaines de la famille _tcsxxxx (par exemple _tcscpy au lieu de strcpy, etc). Faites la distinction claire entre un char et un octet (ah, les kilotonnes de code qu'il faut passer en revue à cause d'une approche non stricte du typage).
3. L'utilisation de ces types facilite la migration vers .Net.
4. L'utilisation de ces types facilite le travail du compilateur et la recherche d'erreur. Par exemple, je peux toujours utiliser un int à la place d'un handle ou affecter un octet à un char. Si j'utilise des types plus précis, le compilateur m'enverra les warnings adéquats.
bon vieux char:
Tout est dans le mot "vieux" :-) . Et pas aussi bon que ça vu les problèmes de traduction que ce choix finalement calamiteux et typiquement nombriliste de nos amis états-uniens a engendrés depuis des années.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Bonjour,
Stephane Legras-Decussy wrote:
cela pose t-il un probleme de ne pas se coltiner les types
à la c** de microsoft, et de preferer de loin un bon vieux char* ?
Oui.
1. Les types standardisés de Microsoft ont permis d'assurer la
compatibilité ascendante VC++ (au détail près) depuis VC++ 1.0 16-bit
(1993). Pour des types à la c.. , je trouve ça pas mal. Un programme
C/C++ écrit il y a 12 ans en respectant les conventions de type MS peut
être repris aujourd'hui pratiquement sans modif. Tout le monde ne peut
pas en dire autant.
2. Comme cela a été précisé, UNICODE devient progressivement la norme et
est le seul jeu de cracatères reconnu par le système en interne. Les
nouvelles technologies de développement et en particulier .Net ne
connaissent également qu'UNICODE. Donc il serait fort opportun dans
votre code d'utiliser TCHAR.H et les fonctions de manipulation chaines
de la famille _tcsxxxx (par exemple _tcscpy au lieu de strcpy, etc).
Faites la distinction claire entre un char et un octet (ah, les
kilotonnes de code qu'il faut passer en revue à cause d'une approche non
stricte du typage).
3. L'utilisation de ces types facilite la migration vers .Net.
4. L'utilisation de ces types facilite le travail du compilateur et la
recherche d'erreur. Par exemple, je peux toujours utiliser un int à la
place d'un handle ou affecter un octet à un char. Si j'utilise des types
plus précis, le compilateur m'enverra les warnings adéquats.
bon vieux char:
Tout est dans le mot "vieux" :-) . Et pas aussi bon que ça vu les
problèmes de traduction que ce choix finalement calamiteux et
typiquement nombriliste de nos amis états-uniens a engendrés depuis des
années.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
cela pose t-il un probleme de ne pas se coltiner les types à la c** de microsoft, et de preferer de loin un bon vieux char* ?
Oui.
1. Les types standardisés de Microsoft ont permis d'assurer la compatibilité ascendante VC++ (au détail près) depuis VC++ 1.0 16-bit (1993). Pour des types à la c.. , je trouve ça pas mal. Un programme C/C++ écrit il y a 12 ans en respectant les conventions de type MS peut être repris aujourd'hui pratiquement sans modif. Tout le monde ne peut pas en dire autant.
2. Comme cela a été précisé, UNICODE devient progressivement la norme et est le seul jeu de cracatères reconnu par le système en interne. Les nouvelles technologies de développement et en particulier .Net ne connaissent également qu'UNICODE. Donc il serait fort opportun dans votre code d'utiliser TCHAR.H et les fonctions de manipulation chaines de la famille _tcsxxxx (par exemple _tcscpy au lieu de strcpy, etc). Faites la distinction claire entre un char et un octet (ah, les kilotonnes de code qu'il faut passer en revue à cause d'une approche non stricte du typage).
3. L'utilisation de ces types facilite la migration vers .Net.
4. L'utilisation de ces types facilite le travail du compilateur et la recherche d'erreur. Par exemple, je peux toujours utiliser un int à la place d'un handle ou affecter un octet à un char. Si j'utilise des types plus précis, le compilateur m'enverra les warnings adéquats.
bon vieux char:
Tout est dans le mot "vieux" :-) . Et pas aussi bon que ça vu les problèmes de traduction que ce choix finalement calamiteux et typiquement nombriliste de nos amis états-uniens a engendrés depuis des années.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Stephane Legras-Decussy
Patrick Philippot a écrit dans le message : d0rqqq$oee$
Donc il serait fort opportun dans votre code d'utiliser TCHAR.H et les fonctions de manipulation chaines de la famille _tcsxxxx (par exemple _tcscpy au lieu de strcpy, etc).
ok j'ignorais ce TCHAR, je vais explorer...
je n'avais jamais songer à unicodiser mes trucs...
Faites la distinction claire entre un char et un octet (ah, les kilotonnes de code qu'il faut passer en revue à cause d'une approche non stricte du typage).
ça c'est bon, pas de probleme de distinction depuis longtemps... c'est comme la distinction entre les bytes et les octets...
merçi pour votre réponse :-)
Patrick Philippot <patrick.philippot@mainsoft.xx.fr> a écrit dans le message
: d0rqqq$oee$1@biggoron.nerim.net...
Donc il serait fort opportun dans
votre code d'utiliser TCHAR.H et les fonctions de manipulation chaines
de la famille _tcsxxxx (par exemple _tcscpy au lieu de strcpy, etc).
ok j'ignorais ce TCHAR, je vais explorer...
je n'avais jamais songer à unicodiser mes trucs...
Faites la distinction claire entre un char et un octet (ah, les
kilotonnes de code qu'il faut passer en revue à cause d'une approche non
stricte du typage).
ça c'est bon, pas de probleme de distinction depuis longtemps...
c'est comme la distinction entre les bytes et les octets...
Patrick Philippot a écrit dans le message : d0rqqq$oee$
Donc il serait fort opportun dans votre code d'utiliser TCHAR.H et les fonctions de manipulation chaines de la famille _tcsxxxx (par exemple _tcscpy au lieu de strcpy, etc).
ok j'ignorais ce TCHAR, je vais explorer...
je n'avais jamais songer à unicodiser mes trucs...
Faites la distinction claire entre un char et un octet (ah, les kilotonnes de code qu'il faut passer en revue à cause d'une approche non stricte du typage).
ça c'est bon, pas de probleme de distinction depuis longtemps... c'est comme la distinction entre les bytes et les octets...
