Bonjour,
Je recherche un exemple d'implémentation qui, conformément à ce que semble
autoriser la norme, ne définirait aucune fonction main (ou WinMain, ou
autre).
J'imagine qu'une telle implémentation génèrerait un code de prologue qui
lancerait les constructeurs d'une ou plusieurs classes, dont une nommée par
exemple Application.
Si j'ai bien compris, C++Builder6 pourrait fournir cet exemple, s'il
"cachait", ou plutôt ne créait pas, et donc rendait non-éditable le fichier
NomDuProjet.cpp (macro d'instanciation de la fiche principale du projet +
WinMain()).
De toutes façons, il faut bien que, sous Windows, le lieur fournisse en fin
de compte un point d'entrée conforme au prototype WinMain() ....
Ce n'est pas pour un devoir (j'ai un peu passé l'âge), mais c'est quand même
pour un travail de rédactiion.
Bonne messe, Cordialement,
Pierre
| IL manque juste cruellement des alternatives libres, histoire de ne pas se | retrouver a dependre sans faire expres d'un gcc'ism.
Open C++ ou LLVM?
-- Gaby
kanze
(Marc Espie) wrote in message news:<br51bp$24p4$...
Cote libstdc++, comme James l'a souligne, la bibliotheque est fortement dependante de l'OS sous-jacent quant aux aspects normalisation (et les gens de GCC ne tiennent pas a en prendre la responsabilite, sauf erreur de ma part).
Non seulement l'OS, dans la plupart des cas, mais aussi toute la bibliothèque standard C. Je crois que c'est facultatif maintenant, mais quand je génère gcc pour Solaris, il utilise le libc et le libm de Solaris. Et ce libc et ce libm comprenent non seulement l'API de l'OS, mais toutes les fonctions de la norme C. Donc, par exemple, la version de printf que j'ai est la version étendue des Open Systems, et non celle de la norme C.
Par exemple, la gestion du multithreading, chere a James, est fortement dependante des capacites de la libc sous-jacente.
Oui et non. Le multithreading, en soi, ne relève pas de la norme ; la question hosted ou non n'y a donc pas d'importance. Et l'API des threads se trouve en libpthread, non en libc. En revanche, évidemment, les garanties de thread safety en ce qui concerne la bibliothèque standard C (printf, etc.) sont bien celles de la bibliothèque Solaris.
Dans le passe, g++ faisait fortement ami-ami avec la glibc (et donc, impossible d'avoir des entrees-sorties thread-safe sur un autre systeme). Je n'ai pas encore eu le temps de me plonger dans le re-design complet que constitue la libstdc++-v3. J'en espere beaucoup (trop ?).
(accessoirement, je ne sais pas si ce post est hors-sujet ou pas. Le theme en est essentiellement `les aspects portabilite et normalisation de g++'. Je ne vois pas trop ou en discuter a part ici)
La question sur l'utilisation de C++ pour écrire un OS citait g++, mais en fait, le problème se pose plus généralement en ce qui concerne C++ ; quoiqu'en dise la norme, par exemple, si tu écris un OS de type Posix en C++, tu ne peux pas utiliser operator new dans l'implémentation de brk:-). Selon les contextes, il y aurait aussi des fois où tu ne peux pas compter sur l'initialisation (y compris les initialisations statiques ou à zéro) des variables statiques, et probablement pas les exceptions ni la RTTI non plus -- en fait, tout où le généré risque d'avoir besoin des objets statiques préinitialisés. (Mais tout dépend de l'implémentation -- les POD const avec initialisation pûrement statique pourrait marcher même dans les cas où les autres initialisations ne marchent pas, par exemple.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
espie@tetto.gentiane.org (Marc Espie) wrote in message
news:<br51bp$24p4$2@biggoron.nerim.net>...
Cote libstdc++, comme James l'a souligne, la bibliotheque est
fortement dependante de l'OS sous-jacent quant aux aspects
normalisation (et les gens de GCC ne tiennent pas a en prendre la
responsabilite, sauf erreur de ma part).
Non seulement l'OS, dans la plupart des cas, mais aussi toute la
bibliothèque standard C. Je crois que c'est facultatif maintenant, mais
quand je génère gcc pour Solaris, il utilise le libc et le libm de
Solaris. Et ce libc et ce libm comprenent non seulement l'API de l'OS,
mais toutes les fonctions de la norme C. Donc, par exemple, la version
de printf que j'ai est la version étendue des Open Systems, et non celle
de la norme C.
Par exemple, la gestion du multithreading, chere a James, est
fortement dependante des capacites de la libc sous-jacente.
Oui et non. Le multithreading, en soi, ne relève pas de la norme ; la
question hosted ou non n'y a donc pas d'importance. Et l'API des threads
se trouve en libpthread, non en libc. En revanche, évidemment, les
garanties de thread safety en ce qui concerne la bibliothèque standard C
(printf, etc.) sont bien celles de la bibliothèque Solaris.
Dans le passe, g++ faisait fortement ami-ami avec la glibc (et donc,
impossible d'avoir des entrees-sorties thread-safe sur un autre
systeme). Je n'ai pas encore eu le temps de me plonger dans le
re-design complet que constitue la libstdc++-v3. J'en espere beaucoup
(trop ?).
(accessoirement, je ne sais pas si ce post est hors-sujet ou pas. Le
theme en est essentiellement `les aspects portabilite et normalisation
de g++'. Je ne vois pas trop ou en discuter a part ici)
La question sur l'utilisation de C++ pour écrire un OS citait g++, mais
en fait, le problème se pose plus généralement en ce qui concerne C++ ;
quoiqu'en dise la norme, par exemple, si tu écris un OS de type Posix en
C++, tu ne peux pas utiliser operator new dans l'implémentation de
brk:-). Selon les contextes, il y aurait aussi des fois où tu ne peux
pas compter sur l'initialisation (y compris les initialisations
statiques ou à zéro) des variables statiques, et probablement pas les
exceptions ni la RTTI non plus -- en fait, tout où le généré risque
d'avoir besoin des objets statiques préinitialisés. (Mais tout dépend de
l'implémentation -- les POD const avec initialisation pûrement statique
pourrait marcher même dans les cas où les autres initialisations ne
marchent pas, par exemple.)
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
(Marc Espie) wrote in message news:<br51bp$24p4$...
Cote libstdc++, comme James l'a souligne, la bibliotheque est fortement dependante de l'OS sous-jacent quant aux aspects normalisation (et les gens de GCC ne tiennent pas a en prendre la responsabilite, sauf erreur de ma part).
Non seulement l'OS, dans la plupart des cas, mais aussi toute la bibliothèque standard C. Je crois que c'est facultatif maintenant, mais quand je génère gcc pour Solaris, il utilise le libc et le libm de Solaris. Et ce libc et ce libm comprenent non seulement l'API de l'OS, mais toutes les fonctions de la norme C. Donc, par exemple, la version de printf que j'ai est la version étendue des Open Systems, et non celle de la norme C.
Par exemple, la gestion du multithreading, chere a James, est fortement dependante des capacites de la libc sous-jacente.
Oui et non. Le multithreading, en soi, ne relève pas de la norme ; la question hosted ou non n'y a donc pas d'importance. Et l'API des threads se trouve en libpthread, non en libc. En revanche, évidemment, les garanties de thread safety en ce qui concerne la bibliothèque standard C (printf, etc.) sont bien celles de la bibliothèque Solaris.
Dans le passe, g++ faisait fortement ami-ami avec la glibc (et donc, impossible d'avoir des entrees-sorties thread-safe sur un autre systeme). Je n'ai pas encore eu le temps de me plonger dans le re-design complet que constitue la libstdc++-v3. J'en espere beaucoup (trop ?).
(accessoirement, je ne sais pas si ce post est hors-sujet ou pas. Le theme en est essentiellement `les aspects portabilite et normalisation de g++'. Je ne vois pas trop ou en discuter a part ici)
La question sur l'utilisation de C++ pour écrire un OS citait g++, mais en fait, le problème se pose plus généralement en ce qui concerne C++ ; quoiqu'en dise la norme, par exemple, si tu écris un OS de type Posix en C++, tu ne peux pas utiliser operator new dans l'implémentation de brk:-). Selon les contextes, il y aurait aussi des fois où tu ne peux pas compter sur l'initialisation (y compris les initialisations statiques ou à zéro) des variables statiques, et probablement pas les exceptions ni la RTTI non plus -- en fait, tout où le généré risque d'avoir besoin des objets statiques préinitialisés. (Mais tout dépend de l'implémentation -- les POD const avec initialisation pûrement statique pourrait marcher même dans les cas où les autres initialisations ne marchent pas, par exemple.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
DINH Viêt Hoà
Donc, par exemple, la version de printf que j'ai est la version étendue des Open Systems, et non celle de la norme C.
quelles sont les extensions des Open Systems par rapport à printf() ?
Selon les contextes, il y aurait aussi des fois où tu ne peux pas compter sur l'initialisation (y compris les initialisations statiques ou à zéro) des variables statiques, et probablement pas les exceptions ni la RTTI non plus -- en fait, tout où le généré risque d'avoir besoin des objets statiques préinitialisés. (Mais tout dépend de l'implémentation -- les POD const avec initialisation pûrement statique pourrait marcher même dans les cas où les autres initialisations ne marchent pas, par exemple.)
effectivement, on aurait un new avec un petit peu de contraintes.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Donc, par exemple, la version de printf que j'ai est la version
étendue des Open Systems, et non celle de la norme C.
quelles sont les extensions des Open Systems par rapport à printf() ?
Selon les contextes, il y aurait aussi des fois où tu ne peux
pas compter sur l'initialisation (y compris les initialisations
statiques ou à zéro) des variables statiques, et probablement pas les
exceptions ni la RTTI non plus -- en fait, tout où le généré risque
d'avoir besoin des objets statiques préinitialisés. (Mais tout dépend de
l'implémentation -- les POD const avec initialisation pûrement statique
pourrait marcher même dans les cas où les autres initialisations ne
marchent pas, par exemple.)
effectivement, on aurait un new avec un petit peu de contraintes.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Donc, par exemple, la version de printf que j'ai est la version étendue des Open Systems, et non celle de la norme C.
quelles sont les extensions des Open Systems par rapport à printf() ?
Selon les contextes, il y aurait aussi des fois où tu ne peux pas compter sur l'initialisation (y compris les initialisations statiques ou à zéro) des variables statiques, et probablement pas les exceptions ni la RTTI non plus -- en fait, tout où le généré risque d'avoir besoin des objets statiques préinitialisés. (Mais tout dépend de l'implémentation -- les POD const avec initialisation pûrement statique pourrait marcher même dans les cas où les autres initialisations ne marchent pas, par exemple.)
effectivement, on aurait un new avec un petit peu de contraintes.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Gabriel Dos Reis
writes:
| | > Donc, par exemple, la version de printf que j'ai est la version | > étendue des Open Systems, et non celle de la norme C. | | quelles sont les extensions des Open Systems par rapport à printf() ? | | > Selon les contextes, il y aurait aussi des fois où tu ne peux | > pas compter sur l'initialisation (y compris les initialisations | > statiques ou à zéro) des variables statiques, et probablement pas les | > exceptions ni la RTTI non plus -- en fait, tout où le généré risque | > d'avoir besoin des objets statiques préinitialisés. (Mais tout dépend de | > l'implémentation -- les POD const avec initialisation pûrement statique | > pourrait marcher même dans les cas où les autres initialisations ne | > marchent pas, par exemple.) | | effectivement, on aurait un new avec un petit peu de contraintes.
La norme définit deux fonctions ::operator new. Une qui peut lever des exceptions, comme dans
|
| > Donc, par exemple, la version de printf que j'ai est la version
| > étendue des Open Systems, et non celle de la norme C.
|
| quelles sont les extensions des Open Systems par rapport à printf() ?
|
| > Selon les contextes, il y aurait aussi des fois où tu ne peux
| > pas compter sur l'initialisation (y compris les initialisations
| > statiques ou à zéro) des variables statiques, et probablement pas les
| > exceptions ni la RTTI non plus -- en fait, tout où le généré risque
| > d'avoir besoin des objets statiques préinitialisés. (Mais tout dépend de
| > l'implémentation -- les POD const avec initialisation pûrement statique
| > pourrait marcher même dans les cas où les autres initialisations ne
| > marchent pas, par exemple.)
|
| effectivement, on aurait un new avec un petit peu de contraintes.
La norme définit deux fonctions ::operator new. Une qui peut lever des
exceptions, comme dans
| | > Donc, par exemple, la version de printf que j'ai est la version | > étendue des Open Systems, et non celle de la norme C. | | quelles sont les extensions des Open Systems par rapport à printf() ? | | > Selon les contextes, il y aurait aussi des fois où tu ne peux | > pas compter sur l'initialisation (y compris les initialisations | > statiques ou à zéro) des variables statiques, et probablement pas les | > exceptions ni la RTTI non plus -- en fait, tout où le généré risque | > d'avoir besoin des objets statiques préinitialisés. (Mais tout dépend de | > l'implémentation -- les POD const avec initialisation pûrement statique | > pourrait marcher même dans les cas où les autres initialisations ne | > marchent pas, par exemple.) | | effectivement, on aurait un new avec un petit peu de contraintes.
La norme définit deux fonctions ::operator new. Une qui peut lever des exceptions, comme dans
Donc, par exemple, la version de printf que j'ai est la version étendue des Open Systems, et non celle de la norme C.
quelles sont les extensions des Open Systems par rapport à printf() ?
Des paramètres positionnels. Du genre :
printf( "%2$d %1$sn", maChaine, monInt ) ;
C'est pratique pour l'internationalisation, quand par exemple l'ordre des mots est différent dans les deux langues.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote in message
news:<etPan.3fd6ee53.303f0e86.7971@homer>...
Donc, par exemple, la version de printf que j'ai est la version
étendue des Open Systems, et non celle de la norme C.
quelles sont les extensions des Open Systems par rapport à printf() ?
Des paramètres positionnels. Du genre :
printf( "%2$d %1$sn", maChaine, monInt ) ;
C'est pratique pour l'internationalisation, quand par exemple l'ordre
des mots est différent dans les deux langues.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Donc, par exemple, la version de printf que j'ai est la version étendue des Open Systems, et non celle de la norme C.
quelles sont les extensions des Open Systems par rapport à printf() ?
Des paramètres positionnels. Du genre :
printf( "%2$d %1$sn", maChaine, monInt ) ;
C'est pratique pour l'internationalisation, quand par exemple l'ordre des mots est différent dans les deux langues.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
espie
In article , wrote:
DINH Viêt Hoà wrote in message news:...
Donc, par exemple, la version de printf que j'ai est la version étendue des Open Systems, et non celle de la norme C.
quelles sont les extensions des Open Systems par rapport à printf() ?
Des paramètres positionnels. Du genre :
printf( "%2$d %1$sn", maChaine, monInt ) ;
C'est pratique pour l'internationalisation, quand par exemple l'ordre des mots est différent dans les deux langues.
Et c'est relativement genant, parce que c'est le seul bout de printf
qui est delicat a implementer sans allocation memoire, et c'est aussi le seul qui rend printf et consorts inutilisable depuis un gestionnaire de signaux sans precaution particuliere...
In article <d6652001.0312100841.4d31705c@posting.google.com>,
<kanze@gabi-soft.fr> wrote:
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote in message
news:<etPan.3fd6ee53.303f0e86.7971@homer>...
Donc, par exemple, la version de printf que j'ai est la version
étendue des Open Systems, et non celle de la norme C.
quelles sont les extensions des Open Systems par rapport à printf() ?
Des paramètres positionnels. Du genre :
printf( "%2$d %1$sn", maChaine, monInt ) ;
C'est pratique pour l'internationalisation, quand par exemple l'ordre
des mots est différent dans les deux langues.
Et c'est relativement genant, parce que c'est le seul bout de printf
qui est delicat a implementer sans allocation memoire, et c'est aussi
le seul qui rend printf et consorts inutilisable depuis un gestionnaire
de signaux sans precaution particuliere...
Donc, par exemple, la version de printf que j'ai est la version étendue des Open Systems, et non celle de la norme C.
quelles sont les extensions des Open Systems par rapport à printf() ?
Des paramètres positionnels. Du genre :
printf( "%2$d %1$sn", maChaine, monInt ) ;
C'est pratique pour l'internationalisation, quand par exemple l'ordre des mots est différent dans les deux langues.
Et c'est relativement genant, parce que c'est le seul bout de printf
qui est delicat a implementer sans allocation memoire, et c'est aussi le seul qui rend printf et consorts inutilisable depuis un gestionnaire de signaux sans precaution particuliere...
