En supposant que tu ne connaisses pas unix, tu pourrais par exemple t'inscrire sur un "freeshell", un serveur unix donnant des comptes utilisateurs gratuits. (google: unix freeshell ; il y en a des tonnes).
Sur MS-Windows, on peut utiliser PuTTY pour se connecter à un serveur distant. http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Une fois connecté, tu peux taper des commandes. En particulier, la commande man affiche la page de manuel concernant la commande ou la fonction passée en argument. Tu peux taper des commandes comme:
man man man cat man cc
Une autre solution, si tu ne veux pas investir autant (mais je te le conseille!), serait simplement d'utiliser google: manual "cat(1)"
Sur unix, les commandes utilisateurs sont dans la section 1 du manuel, d'où cat(1). Les appels systèmes dans la section 2 (ex.: open(2)), les fonctions de bibliothèque dans la section 3 (ex.: printf(3)).
READ THIS BEFORE OPENING PACKAGE: According to certain suggested versions of the Grand Unified Theory, the primary particles constituting this product may decay to nothingness within the next four hundred million years.
"Jean Pierre Daviau" <Once@WasEno.ugh> writes:
cat f.c && make f && ./f
C'est quoi cat?
man cat
En supposant que tu ne connaisses pas unix, tu pourrais par exemple
t'inscrire sur un "freeshell", un serveur unix donnant des comptes
utilisateurs gratuits. (google: unix freeshell ; il y en a des tonnes).
Sur MS-Windows, on peut utiliser PuTTY pour se connecter à un serveur
distant. http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Une fois connecté, tu peux taper des commandes. En particulier, la
commande man affiche la page de manuel concernant la commande ou la
fonction passée en argument. Tu peux taper des commandes comme:
man man
man cat
man cc
Une autre solution, si tu ne veux pas investir autant (mais je te le
conseille!), serait simplement d'utiliser google: manual "cat(1)"
Sur unix, les commandes utilisateurs sont dans la section 1 du manuel,
d'où cat(1). Les appels systèmes dans la section 2 (ex.: open(2)),
les fonctions de bibliothèque dans la section 3 (ex.: printf(3)).
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
En supposant que tu ne connaisses pas unix, tu pourrais par exemple t'inscrire sur un "freeshell", un serveur unix donnant des comptes utilisateurs gratuits. (google: unix freeshell ; il y en a des tonnes).
Sur MS-Windows, on peut utiliser PuTTY pour se connecter à un serveur distant. http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Une fois connecté, tu peux taper des commandes. En particulier, la commande man affiche la page de manuel concernant la commande ou la fonction passée en argument. Tu peux taper des commandes comme:
man man man cat man cc
Une autre solution, si tu ne veux pas investir autant (mais je te le conseille!), serait simplement d'utiliser google: manual "cat(1)"
Sur unix, les commandes utilisateurs sont dans la section 1 du manuel, d'où cat(1). Les appels systèmes dans la section 2 (ex.: open(2)), les fonctions de bibliothèque dans la section 3 (ex.: printf(3)).
READ THIS BEFORE OPENING PACKAGE: According to certain suggested versions of the Grand Unified Theory, the primary particles constituting this product may decay to nothingness within the next four hundred million years.
__func__, c'est du C99, une norme sortie il y a maintenant 8 ans.
Mon fils te dirait /sept/. Lui est né en 1998, et il insiste sur ses 8 ans, pas 9 :-)
Sinon, si on veut chipoter dans l'autre sens, __func__ est présent stable et tout (donc les implémenteurs étaient avertis) depuis les brouillons de mi-98 (FCD), donc en fait cela fait bientôt 9 ans.
Cela étant, un compilateur C souvent utilisé ces jours-ci est celui de MS, dont la dernière moûture (sortie en 2005, « Visual Studio 2005 » aka VS8 aka CL v14.0 aka Whitbey, qui vise une «meilleure» conformité aux normes, d'abord C++:1998 et dans un second temps seulement C99) ne supporte pas __func__. Rappelons que CL14 ne définit pas __STDC_VERSION__, ce qui implique seulement la conformité C90.
Depuis CLv.12 (VS7.1 "2002"), on peut utiliser à la place __FUNCTION__ (qui est candidat au support dans la norme C++). Donc, une solution peut être de rajouter
#if defined _MSC_VER && _MSC_VER>00 #define __func__ __FUNCTION__ #endif
Laid mais cela fonctionne.
J'ai lu par ailleurs que Borland avait sa propre idée sur la question, sous la forme __FUNC__... (pourquoi pas après tout). Si cela peut vous dépannez.
Vivement qu'ils alignent.
Antoine
Marc Espie écrivit dans news:eq4trn$6eo$1@biggoron.nerim.net:
__func__, c'est du C99, une norme sortie il y a maintenant 8 ans.
Mon fils te dirait /sept/.
Lui est né en 1998, et il insiste sur ses 8 ans, pas 9 :-)
Sinon, si on veut chipoter dans l'autre sens, __func__ est présent stable et
tout (donc les implémenteurs étaient avertis) depuis les brouillons de mi-98
(FCD), donc en fait cela fait bientôt 9 ans.
Cela étant, un compilateur C souvent utilisé ces jours-ci est celui de MS,
dont la dernière moûture (sortie en 2005, « Visual Studio 2005 » aka VS8 aka
CL v14.0 aka Whitbey, qui vise une «meilleure» conformité aux normes,
d'abord C++:1998 et dans un second temps seulement C99) ne supporte pas
__func__. Rappelons que CL14 ne définit pas __STDC_VERSION__, ce qui
implique seulement la conformité C90.
Depuis CLv.12 (VS7.1 "2002"), on peut utiliser à la place __FUNCTION__ (qui
est candidat au support dans la norme C++). Donc, une solution peut être de
rajouter
#if defined _MSC_VER && _MSC_VER>00
#define __func__ __FUNCTION__
#endif
Laid mais cela fonctionne.
J'ai lu par ailleurs que Borland avait sa propre idée sur la question, sous
la forme __FUNC__... (pourquoi pas après tout). Si cela peut vous dépannez.
__func__, c'est du C99, une norme sortie il y a maintenant 8 ans.
Mon fils te dirait /sept/. Lui est né en 1998, et il insiste sur ses 8 ans, pas 9 :-)
Sinon, si on veut chipoter dans l'autre sens, __func__ est présent stable et tout (donc les implémenteurs étaient avertis) depuis les brouillons de mi-98 (FCD), donc en fait cela fait bientôt 9 ans.
Cela étant, un compilateur C souvent utilisé ces jours-ci est celui de MS, dont la dernière moûture (sortie en 2005, « Visual Studio 2005 » aka VS8 aka CL v14.0 aka Whitbey, qui vise une «meilleure» conformité aux normes, d'abord C++:1998 et dans un second temps seulement C99) ne supporte pas __func__. Rappelons que CL14 ne définit pas __STDC_VERSION__, ce qui implique seulement la conformité C90.
Depuis CLv.12 (VS7.1 "2002"), on peut utiliser à la place __FUNCTION__ (qui est candidat au support dans la norme C++). Donc, une solution peut être de rajouter
#if defined _MSC_VER && _MSC_VER>00 #define __func__ __FUNCTION__ #endif
Laid mais cela fonctionne.
J'ai lu par ailleurs que Borland avait sa propre idée sur la question, sous la forme __FUNC__... (pourquoi pas après tout). Si cela peut vous dépannez.
Vivement qu'ils alignent.
Antoine
Thierry Boudet
On 2007-02-04, Marc Espie wrote:
__func__, c'est du C99, une norme sortie il y a maintenant 8 ans. Il y a des bouts de la norme qui sont coton a implementer, mais pas __func__. Tout compilo qui n'a pas encore __func__ dans ses cartons sent furieusement le sapin...
-- Ça, c'est bien du Loïc. 1 volume d'huile de foie de morue, 6 à 7 volumes d'eau, et il appelle ça du pastis. -+- AL in fmbl - Bien configurer son pastis -+-
On 2007-02-04, Marc Espie <espie@lain.home> wrote:
__func__, c'est du C99, une norme sortie il y a maintenant 8 ans.
Il y a des bouts de la norme qui sont coton a implementer, mais pas
__func__. Tout compilo qui n'a pas encore __func__ dans ses cartons
sent furieusement le sapin...
--
Ça, c'est bien du Loïc. 1 volume d'huile de foie de morue,
6 à 7 volumes d'eau, et il appelle ça du pastis.
-+- AL in fmbl - Bien configurer son pastis -+-
__func__, c'est du C99, une norme sortie il y a maintenant 8 ans. Il y a des bouts de la norme qui sont coton a implementer, mais pas __func__. Tout compilo qui n'a pas encore __func__ dans ses cartons sent furieusement le sapin...
-- Ça, c'est bien du Loïc. 1 volume d'huile de foie de morue, 6 à 7 volumes d'eau, et il appelle ça du pastis. -+- AL in fmbl - Bien configurer son pastis -+-
Antoine Leca
Thierry Boudet écrivit dans news::
On 2007-02-04, Marc Espie wrote:
__func__, c'est du C99, une norme sortie il y a maintenant 8 ans.
__LINE__ et compagnie sont des symboles « normaux » du préprocesseur, utilisables par exemple (sous réserve des règles de compatibilité de types) dans des expressions #if ou les initialisations externes etc. Dans la nuit des temps et au profond des labos Sonnerie il fut décidé que pour distinguer ces symboles des autres on utiliserait de préférence des capitales.
__func__ au contraire est une sorte de variable automatique, définie uniquement à l'intérieur d'une définition de fonction (on se demande bien ce que cela pourrait représenter ailleurs !) et inutilisable par exemple dans une expression #if (et pas seulement parce que c'est une chaîne de caractères). Suivant les mêmes conventions que ci-dessus, et aussi pour bien faire la différence avec les autres symboles « pleins de soulignés », le comité a choisi logiquement une orthographe en minuscules.
Antoine
Thierry Boudet écrivit dans news:slrneth605.as8.tth@oshima.zouh.org:
On 2007-02-04, Marc Espie wrote:
__func__, c'est du C99, une norme sortie il y a maintenant 8 ans.
__LINE__ et compagnie sont des symboles « normaux » du préprocesseur,
utilisables par exemple (sous réserve des règles de compatibilité de types)
dans des expressions #if ou les initialisations externes etc. Dans la nuit
des temps et au profond des labos Sonnerie il fut décidé que pour distinguer
ces symboles des autres on utiliserait de préférence des capitales.
__func__ au contraire est une sorte de variable automatique, définie
uniquement à l'intérieur d'une définition de fonction (on se demande bien ce
que cela pourrait représenter ailleurs !) et inutilisable par exemple dans
une expression #if (et pas seulement parce que c'est une chaîne de
caractères). Suivant les mêmes conventions que ci-dessus, et aussi pour bien
faire la différence avec les autres symboles « pleins de soulignés », le
comité a choisi logiquement une orthographe en minuscules.
__LINE__ et compagnie sont des symboles « normaux » du préprocesseur, utilisables par exemple (sous réserve des règles de compatibilité de types) dans des expressions #if ou les initialisations externes etc. Dans la nuit des temps et au profond des labos Sonnerie il fut décidé que pour distinguer ces symboles des autres on utiliserait de préférence des capitales.
__func__ au contraire est une sorte de variable automatique, définie uniquement à l'intérieur d'une définition de fonction (on se demande bien ce que cela pourrait représenter ailleurs !) et inutilisable par exemple dans une expression #if (et pas seulement parce que c'est une chaîne de caractères). Suivant les mêmes conventions que ci-dessus, et aussi pour bien faire la différence avec les autres symboles « pleins de soulignés », le comité a choisi logiquement une orthographe en minuscules.
Antoine
espie
In article , Thierry Boudet wrote:
On 2007-02-04, Marc Espie wrote:
__func__, c'est du C99, une norme sortie il y a maintenant 8 ans. Il y a des bouts de la norme qui sont coton a implementer, mais pas __func__. Tout compilo qui n'a pas encore __func__ dans ses cartons sent furieusement le sapin...
Ca rappelle que __FILE__, __LINE__ et __func__ n'ont pas exactement le meme statut. __FILE__ et __LINE__ sont entierement geres par le preprocesseur, tandis que __func__ est un identifiant reconnu du C, qui se trouve avoir comme valeur le nom de la fonction courante, ce qui, si on y reflechit, est parfaitement logique et coherent: le preprocesseur ne sait pas ce qu'est une fonction.
In article <slrneth605.as8.tth@oshima.zouh.org>,
Thierry Boudet <tth@zouh.org> wrote:
On 2007-02-04, Marc Espie <espie@lain.home> wrote:
__func__, c'est du C99, une norme sortie il y a maintenant 8 ans.
Il y a des bouts de la norme qui sont coton a implementer, mais pas
__func__. Tout compilo qui n'a pas encore __func__ dans ses cartons
sent furieusement le sapin...
Ca rappelle que __FILE__, __LINE__ et __func__ n'ont pas exactement
le meme statut. __FILE__ et __LINE__ sont entierement geres par le
preprocesseur, tandis que __func__ est un identifiant reconnu du C,
qui se trouve avoir comme valeur le nom de la fonction courante,
ce qui, si on y reflechit, est parfaitement logique et coherent:
le preprocesseur ne sait pas ce qu'est une fonction.
__func__, c'est du C99, une norme sortie il y a maintenant 8 ans. Il y a des bouts de la norme qui sont coton a implementer, mais pas __func__. Tout compilo qui n'a pas encore __func__ dans ses cartons sent furieusement le sapin...
Ca rappelle que __FILE__, __LINE__ et __func__ n'ont pas exactement le meme statut. __FILE__ et __LINE__ sont entierement geres par le preprocesseur, tandis que __func__ est un identifiant reconnu du C, qui se trouve avoir comme valeur le nom de la fonction courante, ce qui, si on y reflechit, est parfaitement logique et coherent: le preprocesseur ne sait pas ce qu'est une fonction.
Ca rappelle que __FILE__, __LINE__ et __func__ n'ont pas exactement le meme statut. __FILE__ et __LINE__ sont entierement geres par le preprocesseur, tandis que __func__ est un identifiant reconnu du C,
Et peut donc être vu, en gros, comme une chaine constante ?
qui se trouve avoir comme valeur le nom de la fonction courante, ce qui, si on y reflechit, est parfaitement logique et coherent: le preprocesseur ne sait pas ce qu'est une fonction.
Pourtant, on pourrait faire de belles craderies...
------------------------------------- int plop(int v) { printf("v = %dn", v); if (v > 5) return v; return __func__(v+1); } -------------------------------------
Ca rappelle que __FILE__, __LINE__ et __func__ n'ont pas exactement
le meme statut. __FILE__ et __LINE__ sont entierement geres par le
preprocesseur, tandis que __func__ est un identifiant reconnu du C,
Et peut donc être vu, en gros, comme une chaine constante ?
qui se trouve avoir comme valeur le nom de la fonction courante,
ce qui, si on y reflechit, est parfaitement logique et coherent:
le preprocesseur ne sait pas ce qu'est une fonction.
Pourtant, on pourrait faire de belles craderies...
-------------------------------------
int plop(int v)
{
printf("v = %dn", v);
if (v > 5)
return v;
return __func__(v+1);
}
-------------------------------------
Ca rappelle que __FILE__, __LINE__ et __func__ n'ont pas exactement le meme statut. __FILE__ et __LINE__ sont entierement geres par le preprocesseur, tandis que __func__ est un identifiant reconnu du C,
Et peut donc être vu, en gros, comme une chaine constante ?
qui se trouve avoir comme valeur le nom de la fonction courante, ce qui, si on y reflechit, est parfaitement logique et coherent: le preprocesseur ne sait pas ce qu'est une fonction.
Pourtant, on pourrait faire de belles craderies...
------------------------------------- int plop(int v) { printf("v = %dn", v); if (v > 5) return v; return __func__(v+1); } -------------------------------------
