 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Gabriel Dos Reis
Guest
|
 Posted: Fri Nov 05, 2004 4:43 pm Post subject: Re: Vider le buffer associe a stdin |
 |
|
Laurent Deniau <Laurent.Deniau (AT) cern (DOT) ch> writes:
| Quote: | Gabriel Dos Reis wrote:
Laurent Deniau <Laurent.Deniau (AT) cern (DOT) ch> writes:
| Jean-Marc Bourguet wrote:
| > Laurent Deniau <Laurent.Deniau (AT) cern (DOT) ch> writes:
| >>Une question au hasard. Vous gerez comment les exceptions dans votre
| >>code C avec tous ses pointeurs et ses mallocs (ou wrapper
| >>equivalent) si vous avez du C++ comme couche bas niveau du C?
| > Simple: si des exceptions s'echappent de la couche d'interface, il y
| > a
| > un probleme dans celles-ci. Si le code qui se met a utiliser le
| > composant directement n'est pas modifie pour intercepter les
| > exceptions possibles, il y a un probleme dans la modif.
| | Tu veux dire que toutes les methodes C++ de votre couche bas
niveau
| sont qualifiees avec throw(). A ma connaissance ce n'est pas bon pour
| les perfs sauf compilo tres efficace sur un try.
Pardon ?
(Glibc est bourré de throw() et le compilateur optimise à base de
ça).
tu veux dire que le cas particulier de throw() vide est mieux optimise
que de mettre le corps de la fonction dans un try{}catch(...){} ?
|
Si tu appelles une fonction avec throws(), tu sais qu'au site d'appel,
il n'y aura pas d'exception -- si la fonction essaie d'en lever une
(dans le corps de la fonction), il y a abort(). Donc, au site d'appel
le compilateur ne génère plus du code pour traiter les exceptions
inattendus (destruction des objets déjà construit et toussa).
Par contre si tu places l'appel explicitement dans try/catch, le
compilateur est obligé de dupliquer du code (tests et branchements)
au site d'appel -- et dans certains cas empêcher certaines
optimisations.
| Quote: |
tu peux m'en dire plus (peut-etre sur f.c.l.c++)? je suis interesse...
a+, ld.
|
--
Gabriel Dos Reis
[email]gdr (AT) cs (DOT) tamu.edu[/email]
Texas A&M University -- Department of Computer Science
301, Bright Building -- College Station, TX 77843-3112
|
|
| Back to top |
|
 |
Laurent Deniau
Guest
|
| Posted: Fri Nov 05, 2004 5:17 pm Post subject: Re: Vider le buffer associe a stdin |
|
|
Gabriel Dos Reis wrote:
| Quote: | Laurent Deniau <Laurent.Deniau (AT) cern (DOT) ch> writes:
| Gabriel Dos Reis wrote:
| > Laurent Deniau <Laurent.Deniau (AT) cern (DOT) ch> writes:
| > | Jean-Marc Bourguet wrote:
| > | > Laurent Deniau <Laurent.Deniau (AT) cern (DOT) ch> writes:
| > | >>Une question au hasard. Vous gerez comment les exceptions dans votre
| > | >>code C avec tous ses pointeurs et ses mallocs (ou wrapper
| > | >>equivalent) si vous avez du C++ comme couche bas niveau du C?
| > | > Simple: si des exceptions s'echappent de la couche d'interface, il y
| > | > a
| > | > un probleme dans celles-ci. Si le code qui se met a utiliser le
| > | > composant directement n'est pas modifie pour intercepter les
| > | > exceptions possibles, il y a un probleme dans la modif.
| > | | Tu veux dire que toutes les methodes C++ de votre couche bas
| > niveau
| > | sont qualifiees avec throw(). A ma connaissance ce n'est pas bon pour
| > | les perfs sauf compilo tres efficace sur un try.
| > Pardon ?
| > (Glibc est bourré de throw() et le compilateur optimise à base de
| > ça).
|
| tu veux dire que le cas particulier de throw() vide est mieux optimise
| que de mettre le corps de la fonction dans un try{}catch(...){} ?
Si tu appelles une fonction avec throws(), tu sais qu'au site d'appel,
il n'y aura pas d'exception -- si la fonction essaie d'en lever une
(dans le corps de la fonction), il y a abort(). Donc, au site d'appel
le compilateur ne génère plus du code pour traiter les exceptions
inattendus (destruction des objets déjà construit et toussa).
|
Je dois avouez que ton explication me melange un peu les pinceaux. Donc
je vais developper:
| Quote: | cat g.cpp
void f() throw(); |
void g() { f(); } // site d'appel, pas d'exception possible ici
| Quote: | cat f.cpp
void f() throw(); |
void f() { // site appelle', possibilite d'une exception
func_qui_peut_lever_une_exception();
}
Je pensais (selon la description du TC++PL3 14.6) que le try-catch
equivalent etait dans le corp de f() autour de l'appel de
func_qui_peut_lever_une_exception(). C'est donc la declaration de void
f() throw() dans f.cpp qui penalise l'efficacite de f() de maniere
generale (pas visible par les autres TU). Je ne pensais pas que g()
aurait egalement du code de protection autour de f() (qui pourrait
effectivement etre optimise) dans g.cpp.
D'autre part, le abort() n'est pas assure si std::unexpected()
std::terminate() sont redefinis, notament si l'utilisateur veut mapper
une exception unexpected sur une exception "expected" (TC++PL3
14.6.3.2). Alors que veux-tu dire par "il y a abort()"?
Je suis d'accord que ce dont tu parles peut s'optimiser si tout est
connu dans la meme TU (f() et g() mais pas necessairement
func_qui_peut_lever_une_exception() par exemple), mais sinon?
| Quote: | Par contre si tu places l'appel explicitement dans try/catch, le
compilateur est obligé de dupliquer du code (tests et branchements)
au site d'appel -- et dans certains cas empêcher certaines
optimisations.
|
Je ne comprends peut-etre pas ce que tu veux dire par site d'appel. Tu
fais allusion a f() ou g() dans l'exemple ci-dessus.
a+, ld.
|
|
| Back to top |
|
|
drkm
Guest
|
| Posted: Fri Nov 12, 2004 4:42 pm Post subject: Re: Vider le buffer associe a stdin |
|
|
[ X-Post f.c.l.c et f.c.l.c++, Fu2 f.c.l.c++. ]
Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
| Quote: | drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| James Kanze <james.kanze (AT) free (DOT) fr> writes:
| > Il n'y a pas, formellement, une interdiction de surcharge.
| 7.4/6 :
| At most one function with a particular name can have C language
| linkage.
oui, mais tu peux surcharger sur le linkage. Sic.
|
Je la connaissais pas, celle-là. Comment se passe la résolution de
surcharge ?
--drkm
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Fri Nov 12, 2004 7:59 pm Post subject: Re: Vider le buffer associe a stdin |
|
|
drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| Quote: | [ X-Post f.c.l.c et f.c.l.c++, Fu2 f.c.l.c++. ]
Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| James Kanze <james.kanze (AT) free (DOT) fr> writes:
| > Il n'y a pas, formellement, une interdiction de surcharge.
| 7.4/6 :
| At most one function with a particular name can have C
| language linkage.
oui, mais tu peux surcharger sur le linkage. Sic.
Je la connaissais pas, celle-là. Comment se passe la résolution de
surcharge ?
|
En fait, je pensais plutôt au fait que tu peux surcharger une fonction
extern "C" avec d'autres fonctions extern "C". Mais le surcharge sur le
linkage marche aussi, comme n'importe quel autre surcharge. (Comme j'ai
dit dans le thread, extern "C" joue sur les types.) Même, il y en a des
cas dans la norme, comme atexit.
Mais pour le petit exemple :
typedef void (*pfCpp)( void * ) ;
extern void f( void* ) ;
extern "C" {
typedef void (*pfC)( void * ) ;
extern void g( void* ) ;
}
void h( pfCpp ) ; // #1
void h( pfC ) ; // #2
h( f ) ; // appelle #1
h( g ) ; // appelle #2
Exactement comme n'importe quel autre surcharge, en fait.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|
|
| Back to top |
|
|
drkm
Guest
|
| Posted: Fri Nov 12, 2004 9:43 pm Post subject: Re: Vider le buffer associe a stdin |
|
|
James Kanze <james.kanze (AT) free (DOT) fr> writes:
| Quote: | drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
|> [ X-Post f.c.l.c et f.c.l.c++, Fu2 f.c.l.c++. ]
|> Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
|> > drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
|> > | James Kanze <james.kanze (AT) free (DOT) fr> writes:
|> > | > Il n'y a pas, formellement, une interdiction de surcharge.
|> > | 7.4/6 :
|> > | At most one function with a particular name can have C
|> > | language linkage.
|> > oui, mais tu peux surcharger sur le linkage. Sic.
|> Je la connaissais pas, celle-là. Comment se passe la résolution de
|> surcharge ?
En fait, je pensais plutôt au fait que tu peux surcharger une fonction
extern "C" avec d'autres fonctions extern "C".
|
Ce qui n'est pas permis, si ?
| Quote: | Mais le surcharge sur le
linkage marche aussi, comme n'importe quel autre surcharge. (Comme j'ai
dit dans le thread, extern "C" joue sur les types.) Même, il y en a des
cas dans la norme, comme atexit.
|
Tiens, dans ce cas, la norme donne les déclarations (18.3/3) :
extern "C" int atexit( void ( * f )( void ) ) ;
extern "C++" int atexit( void ( * f )( void ) ) ;
Est-ce équivalent à :
typedef void ( * funcType )( void ) ;
extern "C" int atexit( funcType ) ;
extern "C++" int atexit( funcType ) ;
ou à (ce que je pense) :
typedef void ( * funcType )( void ) ;
int atexit( funcType ) ;
extern "C" {
typedef void ( * cFuncType )( void ) ;
int atexit( cFuncType ) ;
}
| Quote: | Mais pour le petit exemple :
typedef void (*pfCpp)( void * ) ;
extern void f( void* ) ;
extern "C" {
typedef void (*pfC)( void * ) ;
extern void g( void* ) ;
}
void h( pfCpp ) ; // #1
void h( pfC ) ; // #2
h( f ) ; // appelle #1
h( g ) ; // appelle #2
Exactement comme n'importe quel autre surcharge, en fait.
|
Car le linkage fait partie du système de types. Ce qui me fait dire
que je me suis sans doute un peu mépris lorsque Gaby a dit que l'on
pouvait « surcharger sur le linkage ». J'ai cru qu'il parlait par
exemple de :
extern "C" void f() ;
extern "C++" void f() ;
ce qui m'amenait à la question « comment se passe la résolution de
surcharge dans ce cas ».
Mais si cela n'est pas permis, ok, il s'agit juste de ce que le
linkage fait partie du système de types, et que l'on peut donc jouer
avec dans les types des arguments, dans les surcharges. Et non que le
linkage de la fonction elle-même en permet une surcharge.
Quelle est donc la situation, à cet égard ?
Au fait, n'est-ce pas un peu bizarre de faire intervenir le linkage
dans le système de types ? Quels sont les arguments, pour ou contre ?
--drkm
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sun Nov 14, 2004 1:27 pm Post subject: Re: Vider le buffer associe a stdin |
|
|
drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| Quote: | James Kanze <james.kanze (AT) free (DOT) fr> writes:
drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
|> Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
|> > drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
|> > | James Kanze <james.kanze (AT) free (DOT) fr> writes:
|> > | > Il n'y a pas, formellement, une interdiction de surcharge.
|> > | 7.4/6 :
|> > | At most one function with a particular name can have
|> > | C language linkage.
|> > oui, mais tu peux surcharger sur le linkage. Sic.
|> Je la connaissais pas, celle-là. Comment se passe la
|> résolution de surcharge ?
En fait, je pensais plutôt au fait que tu peux surcharger une fonction
extern "C" avec d'autres fonctions extern "C".
Ce qui n'est pas permis, si ?
|
C'était évidemment une fautte de frappe. Ce que je voulais dire, c'est
que tu peux surcharger une fonction extern "C" avec d'autres fonctions
extern "C++". C'est ce que je voulais dire par « il n'y a pas
d'interdiction de surcharge » : quelque chose comme :
extern "C" void f( int ) ;
void f( double ) ;
est tout à fait légal, et la fonction extern "C" est bien surchargée.
| Quote: | Mais le surcharge
sur le linkage marche aussi, comme n'importe quel autre surcharge.
(Comme j'ai dit dans le thread, extern "C" joue sur les types.)
Même, il y en a des cas dans la norme, comme atexit.
Tiens, dans ce cas, la norme donne les déclarations (18.3/3) :
extern "C" int atexit( void ( * f )( void ) ) ;
extern "C++" int atexit( void ( * f )( void ) ) ;
Est-ce équivalent à :
typedef void ( * funcType )( void ) ;
extern "C" int atexit( funcType ) ;
extern "C++" int atexit( funcType ) ;
ou à (ce que je pense) :
typedef void ( * funcType )( void ) ;
int atexit( funcType ) ;
extern "C" {
typedef void ( * cFuncType )( void ) ;
int atexit( cFuncType ) ;
}
|
Le deuxième. En revanche, ou je ne suis pas sûr (Gaby ?) :
extern "C" void
f()
{
void (*p)() ;
}
Je crois que p a un type extern "C" aussi, mais je ne suis pas 100% sûr.
| Quote: | Mais pour le petit exemple :
typedef void (*pfCpp)( void * ) ;
extern void f( void* ) ;
extern "C" {
typedef void (*pfC)( void * ) ;
extern void g( void* ) ;
}
void h( pfCpp ) ; // #1
void h( pfC ) ; // #2
h( f ) ; // appelle #1
h( g ) ; // appelle #2
Exactement comme n'importe quel autre surcharge, en fait.
Car le linkage fait partie du système de types. Ce qui me fait
dire que je me suis sans doute un peu mépris lorsque Gaby a dit que
l'on pouvait « surcharger sur le linkage ». J'ai cru qu'il parlait
par exemple de :
extern "C" void f() ;
extern "C++" void f() ;
ce qui m'amenait à la question « comment se passe la résolution de
surcharge dans ce cas ».
Mais si cela n'est pas permis, ok, il s'agit juste de ce que le
linkage fait partie du système de types, et que l'on peut donc jouer
avec dans les types des arguments, dans les surcharges. Et non que
le linkage de la fonction elle-même en permet une surcharge.
|
Je ne crois pas que c'est permis. En tout cas, l'appel serait ambigu,
parce que la résolution du surcharge ne se fait qu'à partir des
paramètres. À une exception près :
extern "C" { typedef void (*pfC)() ; }
extern "C++" { typedef void (*pfCpp)() ; }
pfC p1 = f ; // prend la fonction « extern "C" ».
pfCpp p2 = f ; // prend la fonction « extern "C++" ».
| Quote: | Quelle est donc la situation, à cet égard ?
|
Je crois que c'est illégal, mais je suis loin d'en être sûr.
| Quote: | Au fait, n'est-ce pas un peu bizarre de faire intervenir le
linkage dans le système de types ? Quels sont les arguments, pour ou
contre ?
|
L'argument pour est clair -- on évite une certaine classe d'erreurs. Si
j'ai une fonction qui s'attend à un pointeur vers une fonction C, et par
erreur je lui passe l'adresse d'une fonction C++, c'est une erreur de
compilation, et non un comportement indéfini.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Mon Nov 22, 2004 3:16 pm Post subject: Re: Vider le buffer associe a stdin |
|
|
drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| Quote: | [ X-Post f.c.l.c et f.c.l.c++, Fu2 f.c.l.c++. ]
Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| James Kanze <james.kanze (AT) free (DOT) fr> writes:
| > Il n'y a pas, formellement, une interdiction de surcharge.
| 7.4/6 :
| At most one function with a particular name can have C language
| linkage.
oui, mais tu peux surcharger sur le linkage. Sic.
Je la connaissais pas, celle-là. Comment se passe la résolution de
surcharge ?
|
Comme dans les autres cas.
-- Gaby
|
|
| Back to top |
|
|
drkm
Guest
|
| Posted: Tue Nov 23, 2004 3:19 am Post subject: Re: Vider le buffer associe a stdin |
|
|
Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
| Quote: | drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| [ X-Post f.c.l.c et f.c.l.c++, Fu2 f.c.l.c++. ]
| Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
| > oui, mais tu peux surcharger sur le linkage. Sic.
| Je la connaissais pas, celle-là. Comment se passe la résolution de
| surcharge ?
Comme dans les autres cas.
|
C'est à dire que le linkage fait partie du système de type, et que
la résolution est faire sur les argument de la fonction ?
--drkm
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Tue Nov 23, 2004 4:38 am Post subject: Re: Vider le buffer associe a stdin |
|
|
drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| Quote: | Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| [ X-Post f.c.l.c et f.c.l.c++, Fu2 f.c.l.c++. ]
| Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
| > oui, mais tu peux surcharger sur le linkage. Sic.
| Je la connaissais pas, celle-là. Comment se passe la résolution de
| surcharge ?
Comme dans les autres cas.
C'est à dire que le linkage fait partie du système de type, et que
la résolution est faire sur les argument de la fonction ?
|
Oui -- et dans le cas où on prend implicitement l'adresse de la
fonction, le type de destination joue pour sélectionner la bonne
fonction.
-- Gaby
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Tue Nov 23, 2004 4:09 pm Post subject: Re: Vider le buffer associe a stdin |
|
|
Gabriel Dos Reis <gdr (AT) integrable-solutions (DOT) net> wrote
| Quote: | drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
| > drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| > | Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
| > | > oui, mais tu peux surcharger sur le linkage. Sic.
| > | Je la connaissais pas, celle-là. Comment se passe la
| > | résolution de surcharge ?
| > Comme dans les autres cas.
| C'est à dire que le linkage fait partie du système de type, et que
| la résolution est faire sur les argument de la fonction ?
Oui -- et dans le cas où on prend implicitement l'adresse de la
fonction, le type de destination joue pour sélectionner la bonne
fonction.
|
Aussi quand on en prend l'adresse explicitement, non ?
--
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
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Tue Nov 23, 2004 4:43 pm Post subject: Re: Vider le buffer associe a stdin |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] writes:
| Quote: | Gabriel Dos Reis <gdr (AT) integrable-solutions (DOT) net> wrote in message
news:<m3mzx9kwmq.fsf (AT) uniton (DOT) integrable-solutions.net>...
drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
| > drkm <usenet.fclcxx (AT) fgeorges (DOT) org> writes:
| > | Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> writes:
| > | > oui, mais tu peux surcharger sur le linkage. Sic.
| > | Je la connaissais pas, celle-là. Comment se passe la
| > | résolution de surcharge ?
| > Comme dans les autres cas.
| C'est à dire que le linkage fait partie du système de type, et que
| la résolution est faire sur les argument de la fonction ?
Oui -- et dans le cas où on prend implicitement l'adresse de la
fonction, le type de destination joue pour sélectionner la bonne
fonction.
Aussi quand on en prend l'adresse explicitement, non ?
|
Exact.
(J'avais une façon particulière de prendre l'adresse en tête ; ce qui
a donné lieu à cette formulation).
-- Gaby
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
