Des questions en tout genre !

[QG]

Bonjour,

1) J'ai entendu dire que ceci était incorrect :

Code:


#include <stdlib.h>

int
main (void)
{
  char string[] = "abcdef";
  size_t const i = 1;

  /* Il est dit que l'on a pas le droit d'utiliser un indice declare avec le qualificateur 'const' */
  string[i] = 'x';

  return EXIT_SUCCESS;
}


C'est vrai ? Parce que j'ai beau configurer gcc n'importe comment, il m'indique aucun warning/erreur !

2) Dans ta FAQ, à la question 'J'aimerais savoir où je pourrais trouver la liste complète des caractères spéciaux tels que \n ou \t.'

Si j'ai bien compris, '\u' et '\U' sont des caractères spéciaux ajoutées par la norme C99 ?

Je pense que j'aurai encore d'autres questions plus tard
Merci d'avance ! (:

[-ed-]

Bonjour,

1) J'ai entendu dire que ceci était incorrect :

Code:


#include <stdlib.h>

int
main (void)
{
  char string[] = "abcdef";
  size_t const i = 1;

  /* Il est dit que l'on a pas le droit d'utiliser un indice declare avec le qualificateur 'const' */
  string[i] = 'x';

  return EXIT_SUCCESS;
}


C'est vrai ? Parce que j'ai beau configurer gcc n'importe comment, il m'indique aucun warning/erreur !

Il est clair que dans ce code précisément, i peut être 'const'. Mais dans un code plus évolué où i serait utilisé véritablement comme un indice variable (dans une boucle for, par exemple), il ne pourrait évidemment pas être 'const', car à l'évidence, i++ ne passerait pas...

2) Dans ta FAQ, à la question 'J'aimerais savoir où je pourrais trouver la liste complète des caractères spéciaux tels que \n ou \t.'

Si j'ai bien compris, '\u' et '\U' sont des caractères spéciaux ajoutées par la norme C99 ?

C'est possible, j'avoue ne pas savoir de quoi il s'agit ... En tout cas, ils n'existent pas dans C90.

.

[QG]

Il est clair que dans ce code précisément, i peut être 'const'.

Merci !

Bon, comme promis, j'ai de nouvelles questions (j'en aurai toujours je crois ) !

1) J'ai jeté un œil à ton fichier 'bits.h' (cette page : http://www.bien-programmer.fr/clib.htm ) et je vois écrit :

Code:


#ifdef __cplusplus
extern "C"
{
#endif

/* ... */

#ifdef __cplusplus
}
#endif



J'ai entendu dire que ça servait à faire en sorte que le compilateur C++ proprement dit décore les symboles des fonctions à la manière du C (et non du C++) ? Je ne sais pas si ça sert uniquement à ça... Tu pourrais m'en dire plus ?

2) Sur ta vidéo ici à 4:55 :

https://www.youtube.com/watch?v=4PJmKEwJyPo

Tu dis qu'il faut inclure 'hello.h' en premier... Que si on inclut 'stdio.h' en premier, il risque de masquer les manques...

Je comprends pas trop, tu aurai un exemple s'il te plaît ? :)


3) On dit souvent qu'utiliser les variables globales complique la maintenance du programme source, le rend incompréhensible et rend le les modules dépendant...

Mais qu'en est-il des variables structurées globales ? Il faut les éviter le plus possibles, comme les variables ?

Merci d'avance encore !

[-ed-]

1) J'ai jeté un œil à ton fichier 'bits.h' (cette page : http://www.bien-programmer.fr/clib.htm ) et je vois écrit :

Code:


#ifdef __cplusplus
extern "C"
{
#endif

/* ... */

#ifdef __cplusplus
}
#endif



J'ai entendu dire que ça servait à faire en sorte que le compilateur C++ proprement dit décore les symboles des fonctions à la manière du C (et non du C++) ? Je ne sais pas si ça sert uniquement à ça... Tu pourrais m'en dire plus ?

Oui, c'est ça. En fait, ce mécanisme permet d'utiliser des bibliothèques C dans une environnement C++. En effet, dans la pratique, le code de bibliothèque n'est pas recompilé à chaque utilisation. Il est fait à chaque modification de la bibliothèque, ce qui est rare. Une fois que c'est fait, le code est stable et seule l'interface (le .h) est compilé à chaque fois. Or si on ne prend pas garde à mettre extern "C" en C++ (et uniquement en C++, car c'est une instruction inconnue du C), les prototypes des fonctions déclarés dans le .h seront 'enrichis' à la manière C++, donc différent de ce qui a été défini dans la bibliothèque. Résultat, l'éditeur de lien de s'y retrouve pas. Par exemple, il cherche mafonction_@xxx() alors que dans la bibliothèque C, il s'appelle mafonction().

2) Sur ta vidéo ici à 4:55 :

https://www.youtube.com/watch?v=4PJmKEwJyPo

Tu dis qu'il faut inclure 'hello.h' en premier... Que si on inclut 'stdio.h' en premier, il risque de masquer les manques...

Je comprends pas trop, tu aurais un exemple s'il te plaît ? :)

Pour bien comprendre ce problème, il fait avoir peu d'expérience en programmation modulaire... Ca risque de faire des tonnes d'explications alors que c'est très simple et assez évident ...

En gros, le but est de vérifier que le .h contient bien tout ce qui est nécessaire à son utilisation et que donc son utilisation sera simple, sans qu'il soit nécessaire de rajouter un .h en plus dans le fichier utilisateur.

Un exemple bien connu est une extension de <stdlib.h> contenue dans les implémentation du C de Borland (BC++ 3.1, par exemple).

Il a été ajouté par Borland une macro qui fait :

Code:

#define randomize() srand((unsigned)time(NULL))

or cette macro utilise 2 fonctions standards qui sont rand() déclarée dans <stdlib.h>, et time() déclarée dans <time.h>

Lors de l'utilisation, on a donc :

Code:


#include <stdlib.h>

int main (void)
{
  randomize();

  return 0;
}


ce qui génère un warning car time() n'est pas déclaré. Pour être correct, il faut écrire, par exemple :

Code:


#include <stdlib.h>
#include <time.h>

int main (void)
{
  randomize();

  return 0;
}


Alors que si <time.h> avait été inclus dans le <stdlib.h> de Borland (au moins en mode étendu), la question aurait été réglée définitivement de manière 'invisible', et le premier code aurait fonctionné directement.

Mes recommandations ont pour but d'éliminer ce genre d'erreur, car on les détecte à la compilation de l'implémentation.

3) On dit souvent qu'utiliser les variables globales complique la maintenance du programme source, le rend incompréhensible et rend les modules dépendant...

Mais qu'en est-il des variables structurées globales ? Il faut les éviter le plus possibles, comme les variables ?

Si on parle bien de variables à portée globale, c'est légèrement moins catastrophique, mais c'est quand même à éviter. C'est un problème de portée. L'accès global en écriture est très risqué. On a aucun contrôle, on ne sait pas qui fait quoi, on a pas de certitudes sur qui modifie les données ...

De plus, si on doit gérer une deuxième instance du même type de données, il faut doubler les fonctions. Et si on doit en gérer 10, 100, 1000, on va écrire dix, cent, mille fois la fonction ? C'est absurde, non ? Regarder comment est fait 'FILE'. On a une structure de données 'opaque' et un jeu de fonction avec lequel on créée l'espace de données (fopen()), on le gère (fread(), fwrite() etc.) et on le détruit (fclose()) C'est le bon-sens même. Ce mécanisme est à la base de la 'bonne programmation'.

Lire ceci : http://www.bien-programmer.fr/tad.php

[QG]

Bonjour,

Alors que si <time.h> avait été inclus dans le <stdlib.h> de Borland (au moins en mode étendu), la question aurait été réglée définitivement de manière 'invisible', et le premier code aurait fonctionné directement.

D'accord maisi ici on peut très bien inclure 'time.h' ou 'stdlib.h' en premier ou en dernier, ça n'a pas de rapport avec le masquage des manques, non ?

Je pense avoir d'autres questions plus tard, encore !

Merci d'avance !

[-ed-]

Non, c'est OK. Dans l'ordre que tu veux.

[Contenu sponsorisé]