Une petite question sur les fonctions en C : depuis quand peut-on en C
imbriquer la définition d'une fonction à l'intérieur d'une autre ?
Je fais du C depuis plusieurs années et je suis tombé récemment sur un
truc du genre :
#include <stdio.h>
void main()
{
int i;
int f (int x)
{
return x * 3;
}
for (i = 0; i < 100; i++) printf ("%d = %d\n", i, f(i));
}
Ca peut-être assez pratique, pour ne pas polluer le code avec des
fonctions qui ne servent que dans une fonction donnée.
Je faisais des trucs du style en Pascal il y a bien longtemps, et je
savais que c'était autorisé en C++, mais je n'aurais jamais eu la
curiosité de le tester en C.
Pour info, ce code a été testé sous Linux avec gcc 4.1.2
Que ce soit une extension, peut-être, je ne me suis jam ais penché sur ce problème. En revanche, je ne connais pas de comp ilo qui refuse les fonctions imbriquées. gcc 2.7 l'autorisait d éjà, DEC C aussi, le compilo Sun n'est pas gêné... Aurais-tu des exemples ? Je pose la question parce que pour une histoire de lisibilit é, j'utilise ça dans quelques programmes et je n'ai jamais eu un utilisateur qui soit venu râler parce que la biblioth èque en question refusait de compiler...
Turbo C n'a jamais supporté cette extension. Je pense que Microsoft C non plus, ainsi que Visual Studio etc.
On 1 août, 10:22, JKB <j...@koenigsberg.invalid> wrote:
Que ce soit une extension, peut-être, je ne me suis jam ais penché
sur ce problème. En revanche, je ne connais pas de comp ilo qui
refuse les fonctions imbriquées. gcc 2.7 l'autorisait d éjà, DEC C
aussi, le compilo Sun n'est pas gêné... Aurais-tu des exemples ? Je
pose la question parce que pour une histoire de lisibilit é,
j'utilise ça dans quelques programmes et je n'ai jamais eu un
utilisateur qui soit venu râler parce que la biblioth èque en
question refusait de compiler...
Turbo C n'a jamais supporté cette extension. Je pense que Microsoft C
non plus, ainsi que Visual Studio etc.
Que ce soit une extension, peut-être, je ne me suis jam ais penché sur ce problème. En revanche, je ne connais pas de comp ilo qui refuse les fonctions imbriquées. gcc 2.7 l'autorisait d éjà, DEC C aussi, le compilo Sun n'est pas gêné... Aurais-tu des exemples ? Je pose la question parce que pour une histoire de lisibilit é, j'utilise ça dans quelques programmes et je n'ai jamais eu un utilisateur qui soit venu râler parce que la biblioth èque en question refusait de compiler...
Turbo C n'a jamais supporté cette extension. Je pense que Microsoft C non plus, ainsi que Visual Studio etc.
-ed-
On 2 août, 02:08, Gabriel Dos Reis wrote:
(Marc Espie) writes:
| Outre le fait que les systemes modernes n'ont plus la pile en executabl e, | c'est quand meme de la generation de code au vol, ce qui sur tous les | processeurs decents (c'est-a-dire pas intel et ses cradouilleries) | necessite d'invalider des lignes de caches... donc pas du tout terrible | en performance (sur intel, il y a de la logique dans le processeur pour | invalider les lignes en question automatiquement dans ce contexte, ca | n'empeche pas que c'est pas trop bon en perfs, un peu comme le fait d'a cceder | a de la memoire pas alignee fonctionne, mais rame un peu). | | "la solution" serait sans doute similaire a celle utilisee pour les | gestionnaires de signaux: a savoir parametrer un peu plus le bout de co de | genere au vol, de facon a ne plus avoir a le generer au vol, et quitte | a se taper un petit bout d'indirection supplementaire, a finalement | appeler du code standard, qui ne foutra pas le bordel dans le cache...
C++0x autorise des lambdas avec possibilité de capture de variable locales par référence. Le tout est réecrit comme si on avait une cl asse qui surcharge l'operateur d'appel de fonction, les variables capturées étant données membres. Pas besoin de pile/tas éxécutable.
Est-ce qu'une fonction imbriquée définie avec 'static' devient permanente, donc pointable par un pointeur de fonction ?
Non, je rigole ...
On 2 août, 02:08, Gabriel Dos Reis <g...@cse.tamu.edu> wrote:
es...@lain.home (Marc Espie) writes:
| Outre le fait que les systemes modernes n'ont plus la pile en executabl e,
| c'est quand meme de la generation de code au vol, ce qui sur tous les
| processeurs decents (c'est-a-dire pas intel et ses cradouilleries)
| necessite d'invalider des lignes de caches... donc pas du tout terrible
| en performance (sur intel, il y a de la logique dans le processeur pour
| invalider les lignes en question automatiquement dans ce contexte, ca
| n'empeche pas que c'est pas trop bon en perfs, un peu comme le fait d'a cceder
| a de la memoire pas alignee fonctionne, mais rame un peu).
|
| "la solution" serait sans doute similaire a celle utilisee pour les
| gestionnaires de signaux: a savoir parametrer un peu plus le bout de co de
| genere au vol, de facon a ne plus avoir a le generer au vol, et quitte
| a se taper un petit bout d'indirection supplementaire, a finalement
| appeler du code standard, qui ne foutra pas le bordel dans le cache...
C++0x autorise des lambdas avec possibilité de capture de variable
locales par référence. Le tout est réecrit comme si on avait une cl asse
qui surcharge l'operateur d'appel de fonction, les variables capturées
étant données membres. Pas besoin de pile/tas éxécutable.
Est-ce qu'une fonction imbriquée définie avec 'static' devient
permanente, donc pointable par un pointeur de fonction ?
| Outre le fait que les systemes modernes n'ont plus la pile en executabl e, | c'est quand meme de la generation de code au vol, ce qui sur tous les | processeurs decents (c'est-a-dire pas intel et ses cradouilleries) | necessite d'invalider des lignes de caches... donc pas du tout terrible | en performance (sur intel, il y a de la logique dans le processeur pour | invalider les lignes en question automatiquement dans ce contexte, ca | n'empeche pas que c'est pas trop bon en perfs, un peu comme le fait d'a cceder | a de la memoire pas alignee fonctionne, mais rame un peu). | | "la solution" serait sans doute similaire a celle utilisee pour les | gestionnaires de signaux: a savoir parametrer un peu plus le bout de co de | genere au vol, de facon a ne plus avoir a le generer au vol, et quitte | a se taper un petit bout d'indirection supplementaire, a finalement | appeler du code standard, qui ne foutra pas le bordel dans le cache...
C++0x autorise des lambdas avec possibilité de capture de variable locales par référence. Le tout est réecrit comme si on avait une cl asse qui surcharge l'operateur d'appel de fonction, les variables capturées étant données membres. Pas besoin de pile/tas éxécutable.
Est-ce qu'une fonction imbriquée définie avec 'static' devient permanente, donc pointable par un pointeur de fonction ?
Non, je rigole ...
Tonton Th
On 08/02/2010 10:55 AM, -ed- wrote:
Est-ce qu'une fonction imbriquée définie avec 'static' devient permanente, donc pointable par un pointeur de fonction ?
Ne donne pas de mauvaises idées aux gens...
Non, je rigole ...
Je ne suis qu'à demi rassuré :)
-- : ils sont tout de même assez fort chez Ms : si je n'en veux pas il me le refile de force : et si j'en veux 1 il m'en refile 3 : - Remy, fcold - c'est beau le commerce
On 08/02/2010 10:55 AM, -ed- wrote:
Est-ce qu'une fonction imbriquée définie avec 'static' devient
permanente, donc pointable par un pointeur de fonction ?
Ne donne pas de mauvaises idées aux gens...
Non, je rigole ...
Je ne suis qu'à demi rassuré :)
--
: ils sont tout de même assez fort chez Ms
: si je n'en veux pas il me le refile de force
: et si j'en veux 1 il m'en refile 3
: - Remy, fcold - c'est beau le commerce
Est-ce qu'une fonction imbriquée définie avec 'static' devient permanente, donc pointable par un pointeur de fonction ?
Ne donne pas de mauvaises idées aux gens...
Non, je rigole ...
Je ne suis qu'à demi rassuré :)
-- : ils sont tout de même assez fort chez Ms : si je n'en veux pas il me le refile de force : et si j'en veux 1 il m'en refile 3 : - Remy, fcold - c'est beau le commerce
JKB
Le Mon, 02 Aug 2010 12:06:11 +0200, Tonton Th écrivait :
On 08/02/2010 10:55 AM, -ed- wrote:
Est-ce qu'une fonction imbriquée définie avec 'static' devient permanente, donc pointable par un pointeur de fonction ?
Ne donne pas de mauvaises idées aux gens...
Non, je rigole ...
Je ne suis qu'à demi rassuré :)
Pourquoi ? ;-)
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 02 Aug 2010 12:06:11 +0200,
Tonton Th <tth@la.bas.invalid> écrivait :
On 08/02/2010 10:55 AM, -ed- wrote:
Est-ce qu'une fonction imbriquée définie avec 'static' devient
permanente, donc pointable par un pointeur de fonction ?
Ne donne pas de mauvaises idées aux gens...
Non, je rigole ...
Je ne suis qu'à demi rassuré :)
Pourquoi ? ;-)
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 02 Aug 2010 12:06:11 +0200, Tonton Th écrivait :
On 08/02/2010 10:55 AM, -ed- wrote:
Est-ce qu'une fonction imbriquée définie avec 'static' devient permanente, donc pointable par un pointeur de fonction ?
Ne donne pas de mauvaises idées aux gens...
Non, je rigole ...
Je ne suis qu'à demi rassuré :)
Pourquoi ? ;-)
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Le Sat, 31 Jul 2010 23:05:56 +0000 (UTC), Marc Espie écrivait : > In article <4c54a520$0$16565$, > Alain BARTHE wrote: >>Bonsoir, >> >>Une petite question sur les fonctions en C : depuis quand peut-on en C >>imbriquer la définition d'une fonction à l'intérieur d'une autre ? > > C'est une extension specifique a gcc. > > Ca pose d'eventuels problemes. C'est implemente avec une technique appelee > "trampolines", qui necessite dans pas mal de cas de rendre la pile executable, > ce qui la rend nettement plus sensible aux attaques de type buffer-overflow...
Que ce soit une extension, peut-être, je ne me suis jamais penché sur ce problème. En revanche, je ne connais pas de compilo qui refuse les fonctions imbriquées. gcc 2.7 l'autorisait déjà, DEC C aussi, le compilo Sun n'est pas gêné... Aurais-tu des exemples ?
De la doc de gcc:
$ cat nested.c double foo (double a, double b) { double square (double z) { return z * z; }
return square (a) + square (b); }
En passant, Sun n'accepte pas chez moi:
$ cc -V cc: Sun C 5.9 SunOS_sparc Patch 124867-12 2009/11/22 usage: cc [ options] files. Use 'cc -flags' for details $ cc -c nested.c "nested.c", line 3: syntax error before or at: { "nested.c", line 5: warning: old-style declaration or incorrect type for: square "nested.c", line 5: identifier redeclared: square current : function() returning int previous: function(double) returning double : "nested.c", line 3 "nested.c", line 5: syntax error before or at: + "nested.c", line 5: warning: function prototype parameters must have types "nested.c", line 5: warning: old-style declaration or incorrect type for: square "nested.c", line 6: syntax error before or at: } cc: acomp failed for nested.c
Et si je ne me trompe pas, il n'y a rien dans la doc de Sun cc qui indique que c'est disponible avec une option (j'ai regarde -features et fait une recherche sur nested qui n'a trouve que des choses relatives a openmp)
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
JKB <jkb@koenigsberg.invalid> writes:
Le Sat, 31 Jul 2010 23:05:56 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
> In article <4c54a520$0$16565$426a74cc@news.free.fr>,
> Alain BARTHE <alain.barthe.65@free.fr> wrote:
>>Bonsoir,
>>
>>Une petite question sur les fonctions en C : depuis quand peut-on en C
>>imbriquer la définition d'une fonction à l'intérieur d'une autre ?
>
> C'est une extension specifique a gcc.
>
> Ca pose d'eventuels problemes. C'est implemente avec une technique appelee
> "trampolines", qui necessite dans pas mal de cas de rendre la pile executable,
> ce qui la rend nettement plus sensible aux attaques de type buffer-overflow...
Que ce soit une extension, peut-être, je ne me suis jamais penché
sur ce problème. En revanche, je ne connais pas de compilo qui
refuse les fonctions imbriquées. gcc 2.7 l'autorisait déjà, DEC C
aussi, le compilo Sun n'est pas gêné... Aurais-tu des exemples ?
De la doc de gcc:
$ cat nested.c
double foo (double a, double b)
{
double square (double z) { return z * z; }
return square (a) + square (b);
}
En passant, Sun n'accepte pas chez moi:
$ cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-12 2009/11/22
usage: cc [ options] files. Use 'cc -flags' for details
$ cc -c nested.c
"nested.c", line 3: syntax error before or at: {
"nested.c", line 5: warning: old-style declaration or incorrect type for: square
"nested.c", line 5: identifier redeclared: square
current : function() returning int
previous: function(double) returning double : "nested.c", line 3
"nested.c", line 5: syntax error before or at: +
"nested.c", line 5: warning: function prototype parameters must have types
"nested.c", line 5: warning: old-style declaration or incorrect type for: square
"nested.c", line 6: syntax error before or at: }
cc: acomp failed for nested.c
Et si je ne me trompe pas, il n'y a rien dans la doc de Sun cc qui indique
que c'est disponible avec une option (j'ai regarde -features et fait une
recherche sur nested qui n'a trouve que des choses relatives a openmp)
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Le Sat, 31 Jul 2010 23:05:56 +0000 (UTC), Marc Espie écrivait : > In article <4c54a520$0$16565$, > Alain BARTHE wrote: >>Bonsoir, >> >>Une petite question sur les fonctions en C : depuis quand peut-on en C >>imbriquer la définition d'une fonction à l'intérieur d'une autre ? > > C'est une extension specifique a gcc. > > Ca pose d'eventuels problemes. C'est implemente avec une technique appelee > "trampolines", qui necessite dans pas mal de cas de rendre la pile executable, > ce qui la rend nettement plus sensible aux attaques de type buffer-overflow...
Que ce soit une extension, peut-être, je ne me suis jamais penché sur ce problème. En revanche, je ne connais pas de compilo qui refuse les fonctions imbriquées. gcc 2.7 l'autorisait déjà, DEC C aussi, le compilo Sun n'est pas gêné... Aurais-tu des exemples ?
De la doc de gcc:
$ cat nested.c double foo (double a, double b) { double square (double z) { return z * z; }
return square (a) + square (b); }
En passant, Sun n'accepte pas chez moi:
$ cc -V cc: Sun C 5.9 SunOS_sparc Patch 124867-12 2009/11/22 usage: cc [ options] files. Use 'cc -flags' for details $ cc -c nested.c "nested.c", line 3: syntax error before or at: { "nested.c", line 5: warning: old-style declaration or incorrect type for: square "nested.c", line 5: identifier redeclared: square current : function() returning int previous: function(double) returning double : "nested.c", line 3 "nested.c", line 5: syntax error before or at: + "nested.c", line 5: warning: function prototype parameters must have types "nested.c", line 5: warning: old-style declaration or incorrect type for: square "nested.c", line 6: syntax error before or at: } cc: acomp failed for nested.c
Et si je ne me trompe pas, il n'y a rien dans la doc de Sun cc qui indique que c'est disponible avec une option (j'ai regarde -features et fait une recherche sur nested qui n'a trouve que des choses relatives a openmp)
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
JKB
Le 02 Aug 2010 12:52:17 +0200, Jean-Marc Bourguet écrivait :
JKB writes:
Le Sat, 31 Jul 2010 23:05:56 +0000 (UTC), Marc Espie écrivait : > In article <4c54a520$0$16565$, > Alain BARTHE wrote: >>Bonsoir, >> >>Une petite question sur les fonctions en C : depuis quand peut-on en C >>imbriquer la définition d'une fonction à l'intérieur d'une autre ? > > C'est une extension specifique a gcc. > > Ca pose d'eventuels problemes. C'est implemente avec une technique appelee > "trampolines", qui necessite dans pas mal de cas de rendre la pile executable, > ce qui la rend nettement plus sensible aux attaques de type buffer-overflow...
Que ce soit une extension, peut-être, je ne me suis jamais penché sur ce problème. En revanche, je ne connais pas de compilo qui refuse les fonctions imbriquées. gcc 2.7 l'autorisait déjà, DEC C aussi, le compilo Sun n'est pas gêné... Aurais-tu des exemples ?
De la doc de gcc:
$ cat nested.c double foo (double a, double b) { double square (double z) { return z * z; }
return square (a) + square (b); }
En passant, Sun n'accepte pas chez moi:
$ cc -V cc: Sun C 5.9 SunOS_sparc Patch 124867-12 2009/11/22 usage: cc [ options] files. Use 'cc -flags' for details $ cc -c nested.c "nested.c", line 3: syntax error before or at: { "nested.c", line 5: warning: old-style declaration or incorrect type for: square "nested.c", line 5: identifier redeclared: square current : function() returning int previous: function(double) returning double : "nested.c", line 3 "nested.c", line 5: syntax error before or at: + "nested.c", line 5: warning: function prototype parameters must have types "nested.c", line 5: warning: old-style declaration or incorrect type for: square "nested.c", line 6: syntax error before or at: } cc: acomp failed for nested.c
Et si je ne me trompe pas, il n'y a rien dans la doc de Sun cc qui indique que c'est disponible avec une option (j'ai regarde -features et fait une recherche sur nested qui n'a trouve que des choses relatives a openmp)
La question est maintenant de savoir pourquoi je ne me suis pas encore fait engueuler par les gens qui utilisent SunStudio...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Le 02 Aug 2010 12:52:17 +0200,
Jean-Marc Bourguet <jm@bourguet.org> écrivait :
JKB <jkb@koenigsberg.invalid> writes:
Le Sat, 31 Jul 2010 23:05:56 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
> In article <4c54a520$0$16565$426a74cc@news.free.fr>,
> Alain BARTHE <alain.barthe.65@free.fr> wrote:
>>Bonsoir,
>>
>>Une petite question sur les fonctions en C : depuis quand peut-on en C
>>imbriquer la définition d'une fonction à l'intérieur d'une autre ?
>
> C'est une extension specifique a gcc.
>
> Ca pose d'eventuels problemes. C'est implemente avec une technique appelee
> "trampolines", qui necessite dans pas mal de cas de rendre la pile executable,
> ce qui la rend nettement plus sensible aux attaques de type buffer-overflow...
Que ce soit une extension, peut-être, je ne me suis jamais penché
sur ce problème. En revanche, je ne connais pas de compilo qui
refuse les fonctions imbriquées. gcc 2.7 l'autorisait déjà, DEC C
aussi, le compilo Sun n'est pas gêné... Aurais-tu des exemples ?
De la doc de gcc:
$ cat nested.c
double foo (double a, double b)
{
double square (double z) { return z * z; }
return square (a) + square (b);
}
En passant, Sun n'accepte pas chez moi:
$ cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-12 2009/11/22
usage: cc [ options] files. Use 'cc -flags' for details
$ cc -c nested.c
"nested.c", line 3: syntax error before or at: {
"nested.c", line 5: warning: old-style declaration or incorrect type for: square
"nested.c", line 5: identifier redeclared: square
current : function() returning int
previous: function(double) returning double : "nested.c", line 3
"nested.c", line 5: syntax error before or at: +
"nested.c", line 5: warning: function prototype parameters must have types
"nested.c", line 5: warning: old-style declaration or incorrect type for: square
"nested.c", line 6: syntax error before or at: }
cc: acomp failed for nested.c
Et si je ne me trompe pas, il n'y a rien dans la doc de Sun cc qui indique
que c'est disponible avec une option (j'ai regarde -features et fait une
recherche sur nested qui n'a trouve que des choses relatives a openmp)
La question est maintenant de savoir pourquoi je ne me suis pas
encore fait engueuler par les gens qui utilisent SunStudio...
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Le 02 Aug 2010 12:52:17 +0200, Jean-Marc Bourguet écrivait :
JKB writes:
Le Sat, 31 Jul 2010 23:05:56 +0000 (UTC), Marc Espie écrivait : > In article <4c54a520$0$16565$, > Alain BARTHE wrote: >>Bonsoir, >> >>Une petite question sur les fonctions en C : depuis quand peut-on en C >>imbriquer la définition d'une fonction à l'intérieur d'une autre ? > > C'est une extension specifique a gcc. > > Ca pose d'eventuels problemes. C'est implemente avec une technique appelee > "trampolines", qui necessite dans pas mal de cas de rendre la pile executable, > ce qui la rend nettement plus sensible aux attaques de type buffer-overflow...
Que ce soit une extension, peut-être, je ne me suis jamais penché sur ce problème. En revanche, je ne connais pas de compilo qui refuse les fonctions imbriquées. gcc 2.7 l'autorisait déjà, DEC C aussi, le compilo Sun n'est pas gêné... Aurais-tu des exemples ?
De la doc de gcc:
$ cat nested.c double foo (double a, double b) { double square (double z) { return z * z; }
return square (a) + square (b); }
En passant, Sun n'accepte pas chez moi:
$ cc -V cc: Sun C 5.9 SunOS_sparc Patch 124867-12 2009/11/22 usage: cc [ options] files. Use 'cc -flags' for details $ cc -c nested.c "nested.c", line 3: syntax error before or at: { "nested.c", line 5: warning: old-style declaration or incorrect type for: square "nested.c", line 5: identifier redeclared: square current : function() returning int previous: function(double) returning double : "nested.c", line 3 "nested.c", line 5: syntax error before or at: + "nested.c", line 5: warning: function prototype parameters must have types "nested.c", line 5: warning: old-style declaration or incorrect type for: square "nested.c", line 6: syntax error before or at: } cc: acomp failed for nested.c
Et si je ne me trompe pas, il n'y a rien dans la doc de Sun cc qui indique que c'est disponible avec une option (j'ai regarde -features et fait une recherche sur nested qui n'a trouve que des choses relatives a openmp)
La question est maintenant de savoir pourquoi je ne me suis pas encore fait engueuler par les gens qui utilisent SunStudio...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Antoine Leca
JKB écrivit :
La question est maintenant de savoir pourquoi je ne me suis pas encore fait engueuler par les gens qui utilisent SunStudio...
C++ ? Code non compilé à cause d'un #ifndef OPTIMISATION ?
Antoine
JKB écrivit :
La question est maintenant de savoir pourquoi je ne me suis pas
encore fait engueuler par les gens qui utilisent SunStudio...
C++ ? Code non compilé à cause d'un #ifndef OPTIMISATION ?
La question est maintenant de savoir pourquoi je ne me suis pas encore fait engueuler par les gens qui utilisent SunStudio...
C++ ? Code non compilé à cause d'un #ifndef OPTIMISATION ?
Antoine
JKB
Le Mon, 02 Aug 2010 13:41:16 +0200, Antoine Leca écrivait :
JKB écrivit :
La question est maintenant de savoir pourquoi je ne me suis pas encore fait engueuler par les gens qui utilisent SunStudio...
C++ ? Code non compilé à cause d'un #ifndef OPTIMISATION ?
Absolument pas. Code compilé _et_ fonctionnel.
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 02 Aug 2010 13:41:16 +0200,
Antoine Leca <root@localhost.invalid> écrivait :
JKB écrivit :
La question est maintenant de savoir pourquoi je ne me suis pas
encore fait engueuler par les gens qui utilisent SunStudio...
C++ ? Code non compilé à cause d'un #ifndef OPTIMISATION ?
Absolument pas. Code compilé _et_ fonctionnel.
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 02 Aug 2010 13:41:16 +0200, Antoine Leca écrivait :
JKB écrivit :
La question est maintenant de savoir pourquoi je ne me suis pas encore fait engueuler par les gens qui utilisent SunStudio...
C++ ? Code non compilé à cause d'un #ifndef OPTIMISATION ?
Absolument pas. Code compilé _et_ fonctionnel.
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Antoine Leca
JKB écrivit :
Le Mon, 02 Aug 2010 13:41:16 +0200, Antoine Leca écrivait :
JKB écrivit :
La question est maintenant de savoir pourquoi je ne me suis pas encore fait engueuler par les gens qui utilisent SunStudio...
C++ ? Code non compilé à cause d'un #ifndef OPTIMISATION ?
Absolument pas. Code compilé _et_ fonctionnel.
Euh ? Si d'un côté on te reporte que le compilo MachinBiniou n'a pas la fonctionnalité, tu ne peux pas être assuré que *ce* compilateur accepte ton code et que de plus le code fonctionne comme tu l'as prévu : cela supposerait que tu disposes toi-même du compilo en question, et là je ne comprends plus ta remarque sur les engueulades... (tu ne vas t'engueuler toi-même ;-) )
J'ai eu une fois un effet un peu similaire : j'avais trois compilateurs qui se mélangeaient les uns aux autres, et pour des tests je ne voulais pas que GCC soit utilisé... et je ne comprenais pas pourquoi j'obtenais les mêmes résultats "avec" ou "sans" GCC :-( En fait ce qui se passait c'est que dans le processus de compilation (qui était trop compliqué et pas assez surveillé), d'abord le chemin menant à gcc était rajouté à l'insu de mon plein gré (à cause de binutils), ensuite la valeur de $CC était « oublié » dans un sous-sous-shell, et enfin autoconf préfère gcc à cc/c89, à ma surprise (sur le coup). Au final, le code « intéressant » était quand même compilé par GCC, et une fois lié avec le frontal (pour une fois, mort aux ABI compatibles ;-)) on obtenait positivement le même programme... Je ne pense pas que ton problème se ramène à un truc aussi alambiqué (et surtout aussi mal foutu que mon machin), mais je crois que tant que tu n'as pas mis les mains sur l'instance de ton projet compilé avec MachinBiniou, tu ne peux pas être sûr.
Antoine
JKB écrivit :
Le Mon, 02 Aug 2010 13:41:16 +0200,
Antoine Leca <root@localhost.invalid> écrivait :
JKB écrivit :
La question est maintenant de savoir pourquoi je ne me suis pas
encore fait engueuler par les gens qui utilisent SunStudio...
C++ ? Code non compilé à cause d'un #ifndef OPTIMISATION ?
Absolument pas. Code compilé _et_ fonctionnel.
Euh ? Si d'un côté on te reporte que le compilo MachinBiniou n'a pas la
fonctionnalité, tu ne peux pas être assuré que *ce* compilateur accepte
ton code et que de plus le code fonctionne comme tu l'as prévu : cela
supposerait que tu disposes toi-même du compilo en question, et là je ne
comprends plus ta remarque sur les engueulades... (tu ne vas t'engueuler
toi-même ;-) )
J'ai eu une fois un effet un peu similaire : j'avais trois compilateurs
qui se mélangeaient les uns aux autres, et pour des tests je ne voulais
pas que GCC soit utilisé... et je ne comprenais pas pourquoi j'obtenais
les mêmes résultats "avec" ou "sans" GCC :-( En fait ce qui se passait
c'est que dans le processus de compilation (qui était trop compliqué et
pas assez surveillé), d'abord le chemin menant à gcc était rajouté à
l'insu de mon plein gré (à cause de binutils), ensuite la valeur de $CC
était « oublié » dans un sous-sous-shell, et enfin autoconf préfère gcc
à cc/c89, à ma surprise (sur le coup). Au final, le code « intéressant »
était quand même compilé par GCC, et une fois lié avec le frontal (pour
une fois, mort aux ABI compatibles ;-)) on obtenait positivement le même
programme...
Je ne pense pas que ton problème se ramène à un truc aussi alambiqué (et
surtout aussi mal foutu que mon machin), mais je crois que tant que tu
n'as pas mis les mains sur l'instance de ton projet compilé avec
MachinBiniou, tu ne peux pas être sûr.
Le Mon, 02 Aug 2010 13:41:16 +0200, Antoine Leca écrivait :
JKB écrivit :
La question est maintenant de savoir pourquoi je ne me suis pas encore fait engueuler par les gens qui utilisent SunStudio...
C++ ? Code non compilé à cause d'un #ifndef OPTIMISATION ?
Absolument pas. Code compilé _et_ fonctionnel.
Euh ? Si d'un côté on te reporte que le compilo MachinBiniou n'a pas la fonctionnalité, tu ne peux pas être assuré que *ce* compilateur accepte ton code et que de plus le code fonctionne comme tu l'as prévu : cela supposerait que tu disposes toi-même du compilo en question, et là je ne comprends plus ta remarque sur les engueulades... (tu ne vas t'engueuler toi-même ;-) )
J'ai eu une fois un effet un peu similaire : j'avais trois compilateurs qui se mélangeaient les uns aux autres, et pour des tests je ne voulais pas que GCC soit utilisé... et je ne comprenais pas pourquoi j'obtenais les mêmes résultats "avec" ou "sans" GCC :-( En fait ce qui se passait c'est que dans le processus de compilation (qui était trop compliqué et pas assez surveillé), d'abord le chemin menant à gcc était rajouté à l'insu de mon plein gré (à cause de binutils), ensuite la valeur de $CC était « oublié » dans un sous-sous-shell, et enfin autoconf préfère gcc à cc/c89, à ma surprise (sur le coup). Au final, le code « intéressant » était quand même compilé par GCC, et une fois lié avec le frontal (pour une fois, mort aux ABI compatibles ;-)) on obtenait positivement le même programme... Je ne pense pas que ton problème se ramène à un truc aussi alambiqué (et surtout aussi mal foutu que mon machin), mais je crois que tant que tu n'as pas mis les mains sur l'instance de ton projet compilé avec MachinBiniou, tu ne peux pas être sûr.
