Après, C99 n'avait pas forcément bonne presse (je ne suis plus trop ça). En fait, certaines parties de la norme C99 ne sont pas implantées par les compilateurs courants, et je ne sais si cette fonctionnalité en fait partie.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Le 23-07-2010, Rémi BERTHOLET <r.bertholet@gmail.com> a écrit :
Mais je voudrais faire quelque chose comme cela :
MaFonction({0,0});
Après, C99 n'avait pas forcément bonne presse (je ne
suis plus trop ça). En fait, certaines parties de la norme
C99 ne sont pas implantées par les compilateurs courants,
et je ne sais si cette fonctionnalité en fait partie.
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Après, C99 n'avait pas forcément bonne presse (je ne suis plus trop ça). En fait, certaines parties de la norme C99 ne sont pas implantées par les compilateurs courants, et je ne sais si cette fonctionnalité en fait partie.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Antoine Leca
Marc Boyer écrivit :
Après, C99 n'avait pas forcément bonne presse (je ne suis plus trop ça). En fait, certaines parties de la norme C99 ne sont pas implantées par les compilateurs courants, et je ne sais si cette fonctionnalité en fait partie.
Celle fonctionnalité-là est plutôt bien accueillie. Mais c'est une invention du comité (par d'existant auparavant), donc il faut effectivement un compilo « récent » (= dont le développement s'est poursuivi dans les 8 dernières années).
Antoine
Marc Boyer écrivit :
Après, C99 n'avait pas forcément bonne presse (je ne
suis plus trop ça). En fait, certaines parties de la norme
C99 ne sont pas implantées par les compilateurs courants,
et je ne sais si cette fonctionnalité en fait partie.
Celle fonctionnalité-là est plutôt bien accueillie.
Mais c'est une invention du comité (par d'existant auparavant), donc il
faut effectivement un compilo « récent » (= dont le développement s'est
poursuivi dans les 8 dernières années).
Après, C99 n'avait pas forcément bonne presse (je ne suis plus trop ça). En fait, certaines parties de la norme C99 ne sont pas implantées par les compilateurs courants, et je ne sais si cette fonctionnalité en fait partie.
Celle fonctionnalité-là est plutôt bien accueillie. Mais c'est une invention du comité (par d'existant auparavant), donc il faut effectivement un compilo « récent » (= dont le développement s'est poursuivi dans les 8 dernières années).
C'est un des trucs dont je ne vois pas trop l'interet. Ca ne fait que rajouter de la syntaxe pas tres utile a un langage qui est deja bloated.
Je ne suis pas non plus fan des initialiseurs a la con.... ca aurait bien plus simple d'autoriser les operateurs d'affectation classiques un peu partout, y compris pour fixer des valeurs initiales de variables en dehors d'une fonction, plutot que d'inventer encore un bout de syntaxe bizarroide.
Et a cote, on n'a toujours pas les parametres anonymes comme en C++, et on est oblige d'utiliser des extensions cretines genre attribute((unused)) pour faire taire le compilo... tssss
In article <i2btoe$mu7$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
C'est un des trucs dont je ne vois pas trop l'interet. Ca ne fait que
rajouter de la syntaxe pas tres utile a un langage qui est deja bloated.
Je ne suis pas non plus fan des initialiseurs a la con.... ca aurait bien
plus simple d'autoriser les operateurs d'affectation classiques un peu
partout, y compris pour fixer des valeurs initiales de variables en dehors
d'une fonction, plutot que d'inventer encore un bout de syntaxe bizarroide.
Et a cote, on n'a toujours pas les parametres anonymes comme en C++, et
on est oblige d'utiliser des extensions cretines genre attribute((unused))
pour faire taire le compilo... tssss
C'est un des trucs dont je ne vois pas trop l'interet. Ca ne fait que rajouter de la syntaxe pas tres utile a un langage qui est deja bloated.
Je ne suis pas non plus fan des initialiseurs a la con.... ca aurait bien plus simple d'autoriser les operateurs d'affectation classiques un peu partout, y compris pour fixer des valeurs initiales de variables en dehors d'une fonction, plutot que d'inventer encore un bout de syntaxe bizarroide.
Et a cote, on n'a toujours pas les parametres anonymes comme en C++, et on est oblige d'utiliser des extensions cretines genre attribute((unused)) pour faire taire le compilo... tssss
Samuel DEVULDER
Rémi BERTHOLET a écrit :
Je peux appeler ma fonction en faisant : struct MaStructure data = {0,0}; MaFonction(data);
Mais je voudrais faire quelque chose comme cela : MaFonction({0,0});
Existe t'il une syntaxe en C pour le faire ?
Vu que ta fonction ne retourne rien, je propose ceci:
#define MaFonctionAux1(init) do { struct MaStructure data = init; MaFonction(data); } while(0)
Après les macros, c'est pas toujours bien vu. De plus je ne vois pas trop ce pourquois tu veux à tout prix passer des accolades. Tu pourrais aussi bien avoir:
void MaFonctionAux2(int x, int y) { struct MaStructure data = {x, y}; MaFonction(data); }
Globalement il n'y a pas grande utilité à ces fonctions/macros auxiliaires. Eventuellement passer par Aux1 (la macro) est de pouvoir nommer les champs ".x=" et ".y=" et donc de ne pas se préoccuper de savoir si x est le 1er ou le 2eme paramètre:
MaFonctionAux1({.y=1, .x=2});
Ca peut faciliter la relecture du code surtout si la fonction prend 5 entiers qu'ils vaut mieux distinguer. Mais encore là perso c'est rare que je passe des constantes comme ca. Si une constante a un sémantique précise, alors j'utilise plutôt une vars locale (const) ou un define qui défini que 1 est la valeur d'init de y et 2 celle d'init de x:
#define INIT_X 2 #define INIT_Y 1
MaFonctionAux2(INIT_X, INIT_Y);
sam.
Rémi BERTHOLET a écrit :
Je peux appeler ma fonction en faisant :
struct MaStructure data = {0,0};
MaFonction(data);
Mais je voudrais faire quelque chose comme cela :
MaFonction({0,0});
Existe t'il une syntaxe en C pour le faire ?
Vu que ta fonction ne retourne rien, je propose ceci:
#define MaFonctionAux1(init)
do {
struct MaStructure data = init;
MaFonction(data);
} while(0)
Après les macros, c'est pas toujours bien vu. De plus je ne vois pas
trop ce pourquois tu veux à tout prix passer des accolades. Tu pourrais
aussi bien avoir:
void MaFonctionAux2(int x, int y) {
struct MaStructure data = {x, y};
MaFonction(data);
}
Globalement il n'y a pas grande utilité à ces fonctions/macros
auxiliaires. Eventuellement passer par Aux1 (la macro) est de pouvoir
nommer les champs ".x=" et ".y=" et donc de ne pas se préoccuper de
savoir si x est le 1er ou le 2eme paramètre:
MaFonctionAux1({.y=1, .x=2});
Ca peut faciliter la relecture du code surtout si la fonction prend 5
entiers qu'ils vaut mieux distinguer. Mais encore là perso c'est rare
que je passe des constantes comme ca. Si une constante a un sémantique
précise, alors j'utilise plutôt une vars locale (const) ou un define qui
défini que 1 est la valeur d'init de y et 2 celle d'init de x:
Je peux appeler ma fonction en faisant : struct MaStructure data = {0,0}; MaFonction(data);
Mais je voudrais faire quelque chose comme cela : MaFonction({0,0});
Existe t'il une syntaxe en C pour le faire ?
Vu que ta fonction ne retourne rien, je propose ceci:
#define MaFonctionAux1(init) do { struct MaStructure data = init; MaFonction(data); } while(0)
Après les macros, c'est pas toujours bien vu. De plus je ne vois pas trop ce pourquois tu veux à tout prix passer des accolades. Tu pourrais aussi bien avoir:
void MaFonctionAux2(int x, int y) { struct MaStructure data = {x, y}; MaFonction(data); }
Globalement il n'y a pas grande utilité à ces fonctions/macros auxiliaires. Eventuellement passer par Aux1 (la macro) est de pouvoir nommer les champs ".x=" et ".y=" et donc de ne pas se préoccuper de savoir si x est le 1er ou le 2eme paramètre:
MaFonctionAux1({.y=1, .x=2});
Ca peut faciliter la relecture du code surtout si la fonction prend 5 entiers qu'ils vaut mieux distinguer. Mais encore là perso c'est rare que je passe des constantes comme ca. Si une constante a un sémantique précise, alors j'utilise plutôt une vars locale (const) ou un define qui défini que 1 est la valeur d'init de y et 2 celle d'init de x:
#define INIT_X 2 #define INIT_Y 1
MaFonctionAux2(INIT_X, INIT_Y);
sam.
Antoine Leca
Marc Espie écrivit :
In article <i2btoe$mu7$, Antoine Leca wrote:
Mais c'est une invention du comité (par d'existant auparavant), donc il faut effectivement un compilo « récent » (= dont le développement s'est poursuivi dans les 8 dernières années).
C'est un des trucs dont je ne vois pas trop l'interet.
J'y voit deux intérêts : - initialiser des matrices creuses, et plus généralement les tableaux de manière plus limpide qu'avec les règles du K&R de complémentation par des valeurs nulles ; - s'affranchir de la dépendance à l'ordre de déclaration des membres dans les initialisations de structures, ce qui devrait dans la pratique éviter les séries d'initialisations pour passer d'un objet à un autre.
on est oblige d'utiliser des extensions cretines genre attribute((unused)) pour faire taire le compilo... tssss
Mauvais compilateur, changer de compilateur ? :^)
Antoine
Marc Espie écrivit :
In article <i2btoe$mu7$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
Mais c'est une invention du comité (par d'existant auparavant), donc il
faut effectivement un compilo « récent » (= dont le développement s'est
poursuivi dans les 8 dernières années).
C'est un des trucs dont je ne vois pas trop l'interet.
J'y voit deux intérêts :
- initialiser des matrices creuses, et plus généralement les tableaux
de manière plus limpide qu'avec les règles du K&R de complémentation par
des valeurs nulles ;
- s'affranchir de la dépendance à l'ordre de déclaration des membres
dans les initialisations de structures, ce qui devrait dans la pratique
éviter les séries d'initialisations pour passer d'un objet à un autre.
on est oblige d'utiliser des extensions cretines genre attribute((unused))
pour faire taire le compilo... tssss
Mais c'est une invention du comité (par d'existant auparavant), donc il faut effectivement un compilo « récent » (= dont le développement s'est poursuivi dans les 8 dernières années).
C'est un des trucs dont je ne vois pas trop l'interet.
J'y voit deux intérêts : - initialiser des matrices creuses, et plus généralement les tableaux de manière plus limpide qu'avec les règles du K&R de complémentation par des valeurs nulles ; - s'affranchir de la dépendance à l'ordre de déclaration des membres dans les initialisations de structures, ce qui devrait dans la pratique éviter les séries d'initialisations pour passer d'un objet à un autre.
on est oblige d'utiliser des extensions cretines genre attribute((unused)) pour faire taire le compilo... tssss
Mauvais compilateur, changer de compilateur ? :^)
Antoine
espie
In article <i2jd1s$m13$, Antoine Leca wrote:
Marc Espie écrivit :
In article <i2btoe$mu7$, Antoine Leca wrote:
Mais c'est une invention du comité (par d'existant auparavant), donc il faut effectivement un compilo « récent » (= dont le développement s'est poursuivi dans les 8 dernières années).
C'est un des trucs dont je ne vois pas trop l'interet.
J'y voit deux intérêts : - initialiser des matrices creuses, et plus généralement les tableaux de manière plus limpide qu'avec les règles du K&R de complémentation par des valeurs nulles ; - s'affranchir de la dépendance à l'ordre de déclaration des membres dans les initialisations de structures, ce qui devrait dans la pratique éviter les séries d'initialisations pour passer d'un objet à un autre.
Je suis toujours pas pour. Je ne vois ce qui interdisait d'ecrire les choses classiquement, genre
struct S s;
s.a = valeur; s.b = autre; ...
et de rajouter comme regle que les premieres affectations peuvent etre vus comme une initialisation, en particulier, pas besoin de passer par la case des zeros partout si le compilo peut optimiser.
Typiquement, par rapport a un nombre croissant d'optimisations tres agressives permises ces derniers temps (les histoires d'alias), par rapport a de la semantique peu claire et controversee (restrict), ou par rapport a des modifs incompatibles avec le C89 (long long et printf), ou des modifs de fond du langage (les tableaux de taille choisie a l'execution), je pense que c'est une modification relativement triviale de la semantique du langage, sans impact reel sur les programmes existants. Ca avait meme l'immense avantage de rendre plus rapide et efficace des programmes qui utilisaient deja ce genre de construction... et tout compilo decent doit de toutes facons savoir deja optimiser ce genre de choses dans les cas ou c'est une construction legale.
Enfin bon... C a enormement grossi depuis C89. Il y a quelques bonnes idees, mais pas mal de trucs casse-gueules, peu intuitifs, et qui rendent le langage plus difficile a maitriser pour les debutants...
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop l'implication des grosses boites comme microsoft sur certains aspects de la norme (l'extreme grotesquitude des fonctions de gestion de chaine introduites pour la prochaine revision du standard, par exemple)....
In article <i2jd1s$m13$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
Marc Espie écrivit :
In article <i2btoe$mu7$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
Mais c'est une invention du comité (par d'existant auparavant), donc il
faut effectivement un compilo « récent » (= dont le développement s'est
poursuivi dans les 8 dernières années).
C'est un des trucs dont je ne vois pas trop l'interet.
J'y voit deux intérêts :
- initialiser des matrices creuses, et plus généralement les tableaux
de manière plus limpide qu'avec les règles du K&R de complémentation par
des valeurs nulles ;
- s'affranchir de la dépendance à l'ordre de déclaration des membres
dans les initialisations de structures, ce qui devrait dans la pratique
éviter les séries d'initialisations pour passer d'un objet à un autre.
Je suis toujours pas pour. Je ne vois ce qui interdisait d'ecrire les choses
classiquement, genre
struct S s;
s.a = valeur;
s.b = autre;
...
et de rajouter comme regle que les premieres affectations peuvent etre
vus comme une initialisation, en particulier, pas besoin de passer par la
case des zeros partout si le compilo peut optimiser.
Typiquement, par rapport a un nombre croissant d'optimisations tres agressives
permises ces derniers temps (les histoires d'alias), par rapport a de la
semantique peu claire et controversee (restrict), ou par rapport a des modifs
incompatibles avec le C89 (long long et printf), ou des modifs de fond du
langage (les tableaux de taille choisie a l'execution), je pense que
c'est une modification relativement triviale de la semantique du langage,
sans impact reel sur les programmes existants. Ca avait meme l'immense
avantage de rendre plus rapide et efficace des programmes qui utilisaient
deja ce genre de construction... et tout compilo decent doit de toutes
facons savoir deja optimiser ce genre de choses dans les cas ou c'est une
construction legale.
Enfin bon... C a enormement grossi depuis C89. Il y a quelques bonnes
idees, mais pas mal de trucs casse-gueules, peu intuitifs, et qui rendent
le langage plus difficile a maitriser pour les debutants...
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop
l'implication des grosses boites comme microsoft sur certains aspects
de la norme (l'extreme grotesquitude des fonctions de gestion de chaine
introduites pour la prochaine revision du standard, par exemple)....
Mais c'est une invention du comité (par d'existant auparavant), donc il faut effectivement un compilo « récent » (= dont le développement s'est poursuivi dans les 8 dernières années).
C'est un des trucs dont je ne vois pas trop l'interet.
J'y voit deux intérêts : - initialiser des matrices creuses, et plus généralement les tableaux de manière plus limpide qu'avec les règles du K&R de complémentation par des valeurs nulles ; - s'affranchir de la dépendance à l'ordre de déclaration des membres dans les initialisations de structures, ce qui devrait dans la pratique éviter les séries d'initialisations pour passer d'un objet à un autre.
Je suis toujours pas pour. Je ne vois ce qui interdisait d'ecrire les choses classiquement, genre
struct S s;
s.a = valeur; s.b = autre; ...
et de rajouter comme regle que les premieres affectations peuvent etre vus comme une initialisation, en particulier, pas besoin de passer par la case des zeros partout si le compilo peut optimiser.
Typiquement, par rapport a un nombre croissant d'optimisations tres agressives permises ces derniers temps (les histoires d'alias), par rapport a de la semantique peu claire et controversee (restrict), ou par rapport a des modifs incompatibles avec le C89 (long long et printf), ou des modifs de fond du langage (les tableaux de taille choisie a l'execution), je pense que c'est une modification relativement triviale de la semantique du langage, sans impact reel sur les programmes existants. Ca avait meme l'immense avantage de rendre plus rapide et efficace des programmes qui utilisaient deja ce genre de construction... et tout compilo decent doit de toutes facons savoir deja optimiser ce genre de choses dans les cas ou c'est une construction legale.
Enfin bon... C a enormement grossi depuis C89. Il y a quelques bonnes idees, mais pas mal de trucs casse-gueules, peu intuitifs, et qui rendent le langage plus difficile a maitriser pour les debutants...
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop l'implication des grosses boites comme microsoft sur certains aspects de la norme (l'extreme grotesquitude des fonctions de gestion de chaine introduites pour la prochaine revision du standard, par exemple)....
Tonton Th
On 07/26/2010 12:39 PM, Marc Espie wrote:
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop l'implication des grosses boites comme microsoft sur certains aspects de la norme (l'extreme grotesquitude des fonctions de gestion de chaine introduites pour la prochaine revision du standard, par exemple)....
Tu est mauvaise langue :) Tu peux faire tourner quelques référénces sur ce complôt et ces grotesquitudes ?
On 07/26/2010 12:39 PM, Marc Espie wrote:
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop
l'implication des grosses boites comme microsoft sur certains aspects
de la norme (l'extreme grotesquitude des fonctions de gestion de chaine
introduites pour la prochaine revision du standard, par exemple)....
Tu est mauvaise langue :) Tu peux faire tourner quelques
référénces sur ce complôt et ces grotesquitudes ?
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop l'implication des grosses boites comme microsoft sur certains aspects de la norme (l'extreme grotesquitude des fonctions de gestion de chaine introduites pour la prochaine revision du standard, par exemple)....
Tu est mauvaise langue :) Tu peux faire tourner quelques référénces sur ce complôt et ces grotesquitudes ?
espie
In article <4c4d6987$0$29846$, Tonton Th wrote:
On 07/26/2010 12:39 PM, Marc Espie wrote:
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop l'implication des grosses boites comme microsoft sur certains aspects de la norme (l'extreme grotesquitude des fonctions de gestion de chaine introduites pour la prochaine revision du standard, par exemple)....
Tu est mauvaise langue :) Tu peux faire tourner quelques référénces sur ce complôt et ces grotesquitudes ?
Cherche strcpy_s sur google, tu auras tout ce qu'il faut pour te faire ta propre opinion.
In article <4c4d6987$0$29846$426a74cc@news.free.fr>,
Tonton Th <tth@la.bas.invalid> wrote:
On 07/26/2010 12:39 PM, Marc Espie wrote:
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop
l'implication des grosses boites comme microsoft sur certains aspects
de la norme (l'extreme grotesquitude des fonctions de gestion de chaine
introduites pour la prochaine revision du standard, par exemple)....
Tu est mauvaise langue :) Tu peux faire tourner quelques
référénces sur ce complôt et ces grotesquitudes ?
Cherche strcpy_s sur google, tu auras tout ce qu'il faut pour te faire
ta propre opinion.
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop l'implication des grosses boites comme microsoft sur certains aspects de la norme (l'extreme grotesquitude des fonctions de gestion de chaine introduites pour la prochaine revision du standard, par exemple)....
Tu est mauvaise langue :) Tu peux faire tourner quelques référénces sur ce complôt et ces grotesquitudes ?
Cherche strcpy_s sur google, tu auras tout ce qu'il faut pour te faire ta propre opinion.
Richard
Le 26/07/2010 13:06, Marc Espie a écrit :
In article<4c4d6987$0$29846$, Tonton Th wrote:
On 07/26/2010 12:39 PM, Marc Espie wrote:
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop l'implication des grosses boites comme microsoft sur certains aspects de la norme (l'extreme grotesquitude des fonctions de gestion de chaine introduites pour la prochaine revision du standard, par exemple)....
Tu est mauvaise langue :) Tu peux faire tourner quelques référénces sur ce complôt et ces grotesquitudes ?
Cherche strcpy_s sur google, tu auras tout ce qu'il faut pour te faire ta propre opinion.
D'un autre côté Microsoft n'a toujours pas implémenté grand chose de la norme C99 dans visual C++. Donc c'est difficile de leur trouver une implication dans les standards du C.
-- Richard
Le 26/07/2010 13:06, Marc Espie a écrit :
In article<4c4d6987$0$29846$426a74cc@news.free.fr>,
Tonton Th<tth@la.bas.invalid> wrote:
On 07/26/2010 12:39 PM, Marc Espie wrote:
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop
l'implication des grosses boites comme microsoft sur certains aspects
de la norme (l'extreme grotesquitude des fonctions de gestion de chaine
introduites pour la prochaine revision du standard, par exemple)....
Tu est mauvaise langue :) Tu peux faire tourner quelques
référénces sur ce complôt et ces grotesquitudes ?
Cherche strcpy_s sur google, tu auras tout ce qu'il faut pour te faire
ta propre opinion.
D'un autre côté Microsoft n'a toujours pas implémenté grand chose de la
norme C99 dans visual C++. Donc c'est difficile de leur trouver une
implication dans les standards du C.
si j'etais mauvaise langue, je dirais bien qu'on sent un peu trop l'implication des grosses boites comme microsoft sur certains aspects de la norme (l'extreme grotesquitude des fonctions de gestion de chaine introduites pour la prochaine revision du standard, par exemple)....
Tu est mauvaise langue :) Tu peux faire tourner quelques référénces sur ce complôt et ces grotesquitudes ?
Cherche strcpy_s sur google, tu auras tout ce qu'il faut pour te faire ta propre opinion.
D'un autre côté Microsoft n'a toujours pas implémenté grand chose de la norme C99 dans visual C++. Donc c'est difficile de leur trouver une implication dans les standards du C.
