Makefile

[invite503f25bd]

Bonsoir,

Je rencontre une difficulté technique lors de la phase de compilation d'un programme constitué de .c et .h

Je m'explique :

Je souhaiterais utiliser une variable préprocesseur, disons VAR, qui me permet :
-> dans un .h d'affecter une taille de tableau à l'intérieur d'une structure (t[VAR])
-> dans un .c de réaliser divers fin de boucles
-> dans le main.c pour initialiser un tableau

J'ai réalisé un Makefile qui compile très bien pour 1 valeur de VAR. J'utilise l'option -D de gcc pour initialiser VAR. Je fais donc :

make VAR=4
-> ici ça compile impec. Puis ensuite si je fais :
make VAR=5
-> rien ne compile alors que j'ai changé la valeur de la variable du préprocesseur.

Vous allez me dire normal, les .h et .c n'ont pas eues de modifications dans leurs codes, donc le make ce dit, inutile de recompiler, et ce malgré le changement de valeur de la variable préprocesseur.

J'espère que vous avez saisit le problème.

Si vous avez des idées pour le résoudre je suis preneur

Bonne soirée

Cordialement
-----

[pm42]

Pour régler ça avec un Makefile, il va falloir faire de la voltige.
Pourquoi vouloir recompiler à chaque fois que tu changes VAR au lieu de le passer en argument au programme, le transformer en entier et utiliser un pointeur avec un malloc ou un calloc ?

[invite503f25bd]

-> Donc je remplace mon tableau t[VAR] par *t, je récupère VAR à travers argv[1] du main, puis j'initialise "t" avec un malloc ?

-> Je n'ai jamais utilisé malloc : il sert a affecter une plage d'adresse mémoire à un tableau dont la taille n'est pas fixée d'avance, c'est bien cela ?

[pm42]

-> Donc je remplace mon tableau t[VAR] par *t, je récupère VAR à travers argv[1] du main, puis j'initialise "t" avec un malloc ?

Oui.

-> Je n'ai jamais utilisé malloc : il sert a affecter une plage d'adresse mémoire à un tableau dont la taille n'est pas fixée d'avance, c'est bien cela ?

Oui. Beaucoup de doc sur le sujet se trouve en ligne. Regarde calloc plutôt, c'est plus propre.

[A voir en vidéo sur Futura]

[inviteab0c3c8c]

Bonjour,

-> Je n'ai jamais utilisé malloc : il sert a affecter une plage d'adresse mémoire à un tableau dont la taille n'est pas fixée d'avance, c'est bien cela ?

si vous avez un compilateur C++ (ce qui semble être le cas si vous avez compilé tel quel le code que je vous avais donné précédemment), pourquoi ne pas utiliser les opérateurs new et delete, comme je l'avais d'ailleurs fait dans ledit morceau de code, pour réaliser dynamiquement une allocation mémoire ?

Allocation de tableau de taille n éléments de type T:

T* p = new T[n];
// Traitement
// ...
delete[]p;    // ne pas oublier les crochets

Allocation d'un objet de type T:

T* p = new T;
// Traitement
// ...
delete p;

D'après ce que je sais, le seul avantage d'utiliser 'malloc/free' plutôt que 'new/delete', c'est que ce premier autorise la possibilité d'une ré-allocation ('realloc') en cas de besoin de changer la taille d'un tableau "en cours de route".

[pm42]

D'après ce que je sais, le seul avantage d'utiliser 'malloc/free' plutôt que 'new/delete', c'est que ce premier autorise la possibilité d'une ré-allocation ('realloc') en cas de besoin de changer la taille d'un tableau "en cours de route".

L'autre avantage est le coté bas niveau qui fait qu'il est dispo sur presque tous les environnements, sans le "surcoùt" du C++.
Mais la syntaxe du new est plus sympa en effet.

[invite503f25bd]

Ok, merci beaucoup pour vos conseils. Je vais essayer tout ça .

Bonne journée

[inviteb9f49292]

Ok, merci beaucoup pour vos conseils. Je vais essayer tout ça .

Bonne journée

Ouais enfin le conseil du C++ je le trouve plutôt contre-productif... Tu sembles débuter, reste sur un langage à la syntaxe simple comme le C, le C++ c'est un enfer syntaxique, entre les templates, les smart pointer et maintenant les functor...

Mais la syntaxe du new est plus sympa en effet.

Pourquoi ? parce que le développeur n'a pas à savoir la taille de ce dont il a besoin ? Mouais, parfois je me demande si ce n'est pas contre-productif... Mais ça de devrait pas être un argument pour choisir entre le C et le C++ (j'ai bien compris que ce n'était pas ton intention)

[invite503f25bd]

Je fais face à une totale incompréhension. Je tente d'initialiser une matrice avec le code suivant :

 Cliquez pour afficher

#include <stdio.h>
#include <stdlib.h>

int main(int argc, const char * argv[]) {
    int NB_CASE_BOARD = 8;
    int **links = NULL;
    links = calloc(NB_CASE_BOARD, sizeof(int));
    for (int i=0; i<NB_CASE_BOARD; i++){
        links[i] = calloc(NB_CASE_BOARD, sizeof(int));
    }
    
    
    // On initialise nos contraintes
    links[0][1] = 1; links[0][7] = 1;
    links[1][0] = 1; links[1][2] = 1;
    links[2][1] = 1; links[2][3] = 1;
    links[3][2] = 1; links[3][4] = 1;
    links[4][3] = 1; links[4][5] = 1;
    links[5][4] = 1; links[5][6] = 1;
    links[6][5] = 1; links[6][7] = 1;
    links[7][6] = 1; links[7][0] = 1;
    
    for (int i=0; i<8; i++){
        for (int j=0; j<8; j++){
            printf("%d ",links[i][j]);
        }
        printf("\n");
    }

    return 0;
}

Or, la première ligne n'est pas du tout correcte : j'ai des valeurs prise au hasard dans la mémoire alors que je voudrais que ce soit : 0 1 0 0 0 0 0 1.
Le printf que j'ai en sortie est le suivant :

1063232 1 1063264 1 1063296 1 1060224 1 <------ PROBLEME ICI
1 0 1 0 0 0 0 0
0 1 0 1 0 0 0 0
0 0 1 0 1 0 0 0
0 0 0 1 0 1 0 0
0 0 0 0 1 0 1 0
0 0 0 0 0 1 0 1
1 0 0 0 0 0 1 0

Quelle est la raison de ce problème ? Comment le résoudre ?

Cordialement

[inviteab0c3c8c]

Bonjour,

Ouais enfin le conseil du C++ je le trouve plutôt contre-productif... Tu sembles débuter, reste sur un langage à la syntaxe simple comme le C, le C++ c'est un enfer syntaxique, entre les templates, les smart pointer et maintenant les functor...

tout compilateur C++, est capable de compiler une source écrite en C. Il n'est pas nécessaire de connaître tout C++ pour écrire en C++. Et pour ma part je trouve que certaines fonctionnalités de base, absentes de C, le rendent plus souple d'utilisation que le C et permettent d'écrire des programmes plus lisibles (entre autres, la possibilité de déclarer une variable, au moment où on en a besoin).

Pourquoi ? parce que le développeur n'a pas à savoir la taille de ce dont il a besoin ?

Pas seulement, et c'est un point de vue. Un autre point de vue consiste à dire que l'utilisation de 'new' évite à un programmeur en C d'utiliser l'opérateur 'sizeof'. L'utilisation de 'new' permet en outre une "vérification de type" qui peut-être bien utile, surtout pour les débutants ou les étourdis.

Par ailleurs, il est vrai que C++ a la réputation d'engendrer un surcoût en terme de performances, difficile à quantifier mais dont j'estime qu'il peut être faible compte tenu de l'efficacité des compilateurs actuels et dépend des fonctionnalités utilisées.

En ce qui me concerne, je pense que le choix du compilateur (entre C et C++) est à considérer en dernier recours, et je maintiens (sauf développement de pilotes ou situation critique en terme de performances) mon conseil en direction de C++.

Cordialement

[pm42]

Quelle est la raison de ce problème ? Comment le résoudre ?

Tu n'as pas initialisé certaines entrées je crois : links[0][0] par ex.

[inviteab0c3c8c]

    int **links = NULL;
    links = calloc(NB_CASE_BOARD, sizeof(int));

Ça compile sans même un petit warning ça ?

Sinon, rien à voir, mais vous allouez de la mémoire (calloc) sans la libérer avant de sortir de votre programme (free).

[invite503f25bd]

Tu n'as pas initialisé certaines entrées je crois : links[0][0] par ex.

Lorsque je veux initialiser links[0][0] j'ai un segfault. Est-ce normal ?

[pm42]

Sinon, rien à voir, mais vous allouez de la mémoire (calloc) sans la libérer avant de sortir de votre programme (free).

Oui mais ce n'est pas grave puisque ce sera libéré à la sortie par l'OS. Mais effectivement, ce n'est pas une bonne habitude.

Lorsque je veux initialiser links[0][0] j'ai un segfault. Est-ce normal ?

Oui. Je ne l'ai pas vu tout de suite.

Il faut faire :

    links = calloc(NB_CASE_BOARD, sizeof(int*));

Et tu avais mis un sizeof(int). Chez moi avec ça, tout marche y compris l'initialisation de 0, 0.

[inviteb9f49292]

Bonjour,

tout compilateur C++, est capable de compiler une source écrite en C. Il n'est pas nécessaire de connaître tout C++ pour écrire en C++. Et pour ma part je trouve que certaines fonctionnalités de base, absentes de C, le rendent plus souple d'utilisation que le C et permettent d'écrire des programmes plus lisibles (entre autres, la possibilité de déclarer une variable, au moment où on en a besoin).

je vais essayer de ne pas trop m'étendre sur le hors sujet, mais la possibilité de déclarer une variable n'importe où c'est dans le C depuis C89 je pense, au plus tard C99, tout comme la déclaration statique de tableau... et tout comme on ajoute des tentacules au C++, le C a évoluer... mais peut-être de manière moins tentaculaire. Et une fois compilé par un compilateur C++, du code C devient du binaire C++ beaucoup plus compliqué à déverminer...

Pas seulement, et c'est un point de vue. Un autre point de vue consiste à dire que l'utilisation de 'new' évite à un programmeur en C d'utiliser l'opérateur 'sizeof'. L'utilisation de 'new' permet en outre une "vérification de type" qui peut-être bien utile, surtout pour les débutants ou les étourdis.

OK c'est un point de vue subjectif, amha l'économie de quelques caractères à taper ne devrait pas être un critère de sélection pour un langage... Quant à la vérification du type au moment de l'allocation, admettons qu'effectivement ce soit plus safe en C++ (je n'en suis même pas sûr à cause de la dérivation), pour tout le reste, le système de typage du C++ est nettement plus casse-gueule (polymorphisme, créateur par défaut, surcharge d'opérateur...) et je ne parle même pas des nouveaux pointeurs...

Par ailleurs, il est vrai que C++ a la réputation d'engendrer un surcoût en terme de performances, difficile à quantifier mais dont j'estime qu'il peut être faible compte tenu de l'efficacité des compilateurs actuels et dépend des fonctionnalités utilisées.

Quand je déconseille un langage d'apprentissage, ce n'est pas pour des raisons de performances. Et je suis tout à fait d'accord avec ça, les perf du C++ sont de nos jours plus que correcte. Mais le C++ se trimbale surtout la réputation d'être affreusement compliqué (le nombre de tentacule), nécessitant des années de pratiques pour être efficace en se limitant à un sous ensemble du C++ (jette un oeil au google code format pour le C++ par ex)

En ce qui me concerne, je pense que le choix du compilateur (entre C et C++) est à considérer en dernier recours, et je maintiens (sauf développement de pilotes ou situation critique en terme de performances) mon conseil en direction de C++.

On ne parle pas de compilateur, on parle de langage et dans le contexte spécifique de l'apprentissage ou je maintiens mordicus qu'il ne faut pas conseiller du C++ pour apprendre la POO, et encore moins le procédural.

Désolé pour le hors-sujet