Salut,

Je viens de me lancer dans le langage C, et je rencontre deux petit problème.

Le 1er : Je n'arrive pas à savoir ce que vaut  (short *)(int *)(((char *)1000)+4)

Le 2e : C'est un problème de syntaxe, j'aimerai limiter l'accès aux champs d'un bout de programme en C ?

Merci

Salut
 
Le 1er: 1004 (enfin un pointeur de short qui pointe sur 1004) je pense mais je ne vois pas trop l'intérêt de tout ça.
 
Le 2e: pas compris. Exemple stp

Ok, merci donc si je comprends bien le cast (int*) ne sert à rien ?
 
Pour l'exemple voila :  
 
typedef struct {
   int W, H ;
   unsigned char *rgb;
   unsigned char *mask;
} Sprite ;
 
Je veux interdire l'accès aux champ de Sprite à l'utilisateur dans la suite de prog.

Tu ne manipules que des pointeurs vers Sprite et tu n'en exposes pas la definition.  (Le C++ permet d'etre plus fin, pas le C).

Je dirais même
    (short*)(1000 + 4)
ou
    (short*) (1004)
Pour les valeurs immédiates on peut raccourcir (c'est plutôt rare des valeurs immédiates pour des pointeurs). Sur un pointeur, le cast en (char*) permet d'ajouter 4 octets au lieu de 4*sizeof(pointeur)
 

Merci pour toute vos réponse. Mais voila je n'y arrive toujours pas.
Je souhaite créer un Sprite à partir de ce code à trou pouvez-cous m'aider.  
 
code : http://petiois.free.fr/Public/sprite.c
 
Merci

Oui on peut t'aider. Pas faire le boulot.
 
Je peux avoir l'énoncé? Certaines choses éveillent ma curiosité.

Voila le sujet   http://petiois.free.fr/Public/sujet.pdf

Montre ce que tu as fait et dis où tu bloques.

j'ai fait ça pour la création du Sprite mais je ne sais pas si ca fonctionne :
 
Sprite * createSprite(int w, int h){
Sprite * newSprite;
newSprite = malloc (sizeof (Sprite));
newSprite.W -> w ;
newSprite.H -> h;
return newSprite;

L'affectation c'est "=", pas "->"
Manque aussi l'accolade fermante:} .

Tu peux pas. Tu le pourrais en C++ mais pas en C. Mais tu parles de "utilisateur"... les champs sont accessible au programmeur, pas à l'utilisateur (qui n'aura accès, lui, qu'à ton programme compilé).
 

 
J'ai pas lu le sujet ni le code. Mais si newSprite est un pointeur, alors le membre W sera adressé par newSprite->W et non newSprite.W.  
Tu voulais sans-doute écrire
newSprite->W=w ;
newSprite->H=h;
 
PS: si tu nommais ton type "t_sprite", tu pourrais mieux faire la différence entre "type" et "variable"...

Ok donc je dois plus faire un truc du genre :
 
Sprite * createSprite(int w, int h){
Sprite * newSprite;
newSprite = malloc (sizeof (Sprite));
newSprite->W=w ;
newSprite->H= h;
return newSprite;
 
??

 
Un poil plus professionnel...
 

t_sprite* createSprite(int w, int h){
    t_sprite* newSprite;
    newSprite = malloc(sizeof (t_sprite));
    if (newSprite == NULL) return NULL;
 
    newSprite->W=w ;
    newSprite->H= h;
    return newSprite;
}

ok merci

J'aimerais bien savoir où ton prof est allé chercher sa vérification de l'allocation... En tout cas quoi qu'il ait voulu faire, ça n'a pas l'air de fonctionner chez moi...
Pour ceux qui n'ont pas le sujet:

Tu n'en fais qu'un. Où vas-tu mettre tes pixels et tes informations de transparence?

Plusieurs malloc = plusieurs free... Où est la fonction destroySprite?

donc newSprite->W = w c'est faux.

je suppose que dans la fonction erreur, c'est
printf("%s\n",s) ;
et non
printf("%s\n" ) ;

je dois donc faire 3 malloc ?

On dirait bien.

Et si je fais un truc du genre est-ce bon ?
Sprite * createSprite(int w, int h){
Sprite * newSprite;
char* color;
char* transparence;
newSprite = malloc (sizeof (Sprite));
color=malloc(3*sizeof(Sprite));
transparence=malloc(Sprite));
newSprite.W -> w ;
newSprite.H -> h;
return newSprite;
 
Car si j'ai bien compris, il faut 3 octets pour définir la couleur donc il y a en tout 3*octet*sizeof(Sprite) ?

Le pointeur rgb est un tableau de pixels. En effet, il faut 3 octets pour la couleur (rouge, vert et bleu). Donc tu auras bien 3*qqchose dans ton malloc.
Par contre sa taille n'a rien à voir avec celle de la structure Sprite. Il doit simplement être capable de stocker autant de pixels qu'en contient ton image. Combien de pixels contient ton image?
 
Pour le masque, un seul octet par pixel suffit.
 
Tu n'as pas besoin de créer de nouveaux pointeurs color et transparence, tu as déjà rgb et mask dans ta structure

Ouaip. J'avais pas lu l'énoncé et j'ai juste voulu corriger "newSprite.W->w". Bah, suffit d'écrire  

newSprite->W = ((w - 1) >> 3) << 3 + 1

et c'est réglé.
 

Fuite de mémoire. Tu alloues de la mémoire et tu stockes les pointeurs associés dans des variables qui disparaissent une fois la fonction terminée. Les pointeurs sont perdus et la mémoire allouée reste allouée pour rien.
 

T'as vraiment rien pipé à l'énoncé !!! Un sprite c'est une structure permettant de gérer une image dans son intégralité. Je vois pas pourquoi rgb contiendrait 3 structures sprites (sous-entendu 3 structures permettant de gérer chacune une image !!!)
rgb est un tableau contenant 3 octets par pixel !!!
 
PS: si j'étais toi, je définirais aussi une structure rgb...
 

Ouais t'as raison. Je me demande vraiment pourquoi j'écris des trucs parfois...      

Impossible c'est un sujet pourri à trous. Il faut remplir certaines fonctions en fait...

Petiois tu veux faire ça pour rendre en cours en respectant les consignes ou faire un truc bien?

 
Ouaip, je suis en train de le regarder (et j'édite mon post précédent au fur et à mesure). Bon, c'était pas primordial de toute façon. Au lieu d'avoir une structure qui découpe elle-même ses couleurs ben faut les découper soi-même en divisant ou en multipliant par 3 selon si on lit ou si on va lire les composantes RGB. Pas catastrophique à coder...
 

A mon avis, vu cette nullité qu'il s'obstine à réécrire sans même avoir eu la politesse de lire les posts de ceux qui tentent d'apporter de la clarté dans sa mélasse, vaut mieux qu'il se contente de répondre pile-poil à l'énoncé...

newSprite->W = ((w - 1) >> 3) << 3 + 1

Ah bon?

Cest pas beau à voir mais j'avais fait
w + ((8-w%8) % 8)

Bon je n'ai pas cherché mieux j'ai rempli les fonctions vite fait pour que ça m'affiche les sprites.

Sve@r tu as une idée pour la vérif du prof? Il regarde à l'indice -1 pour trouver la taille du tableau (je pense...) ? Mais je n'ai jamais vu quelqu'un faire ça, ça ne fonctionne pas chez moi (architecture?) et si c'est bien ça, pourquoi encadrer la valeur avec des inégalités?

Je trouve que ça sent fort le prof qui lance le programme et regarde le résultat sans vérifier le code... Ça ne lui prendrait pas plus de temps de regarder comment est allouée la mémoire.

Erreur de ma part. J'ai tapé de tête en croyant que le décalage avait la même priorité que la multiplication.
Bon, pour le fun, voici la bonne opération que j'aurais dû écrire
(((w - 1) >> 3) + 1) << 3
 

Non, j'aime bien aussi. C'est juste pour se faire plaisir quoi.
 

Tu veux parler de

int sz = ((int *)(spr))[-1] ;
   if((sz<16)||(sz>50)) erreur("Allocation" ) ;
   sz = ((int *)(spr->rgb))[-1] ;
   if((sz<2300)||(sz>2400)) erreur("Allocation RGB" ) ;
   sz = ((int *)(spr->mask))[-1] ;
   if((sz<96)||(sz>130)) erreur("Allocation mask" ) ;

Incompréhensible. On dirait que lui-aussi il se fait plaisir. Mais comme tu dis c'est probablement lié à l'architecture de sa machine. Autrement dit, ce qu'il a écrit c'est tout sauf portable. En plus, je me demande la tronche qu'aura sa variable "sz" si malloc a renvoyé NULL...
 

 
Bah oui. Il alloue son sprite et remplit les pointeurs à null. Ensuite il alloue les pointeurs internes et si une des allocations se passe mal, alors il appelle freeSprite() qui se charge de libérer les pointeurs internes qui ne sont pas à null. C'est sûr qu'avec un prof pareil, Petiois a du soucis à se faire...

En effet.
 

C'est bien ce que je pensais.
Ça doit servir à expliquer aux élèves ce qu'il ne faut pas faire, c'est volontaire.  
 
 

 
On est d'accord.

Et en plus, si jamais il y a un pb interne, il appelle "erreur()" qui fait un exit brutos. Sortir proprement il connait ça le prof ??? Bah c'est pas la peine. On a qu'à laisser zindow gérer le caca...

Ah ok j'ai compris, merci ptitchep.
 
 
 

Et pour ta gouverne Sve@r, je prends le temps de lire tous les posts. C'est juste que je ne pige pas tout en C sinon je ne viendrais pas poser des question sur ce topic !!

 
J'ai déjà entendu parler de ça, des archis sur lesquelles des informations sont stockées à l'indice -1.
D'ailleurs si je ne me trompe pas, les std::vector du C++ stockent aussi des infos à l'indice -1 auxquelles ils ne faut généralement surtout pas toucher. Mais je n'ai jamais approfondi la question pour pouvoir vous en dire plus.

Mouais, ça pue la bidouille...
En tout cas pas mal de ses étudiants doivent pleurer devant le pc parce qu'ils ne passent pas la première question...

La preuve que non puisque t'as réécrit un truc que je t'avais corrigé. Et ça, c'est incontournable.  
 

Ah oui, j'oubliais l'excuse facile du "je pige pas tout"   . Me dit pas qu'on te fait faire du travail avec des structures sans t'avoir expliqué la différence entre "->" et ".". Et me dit pas qu'on t'a jamais informé qu'une affectation se faisait via l'opérateur "="...
 

Le Pascal fait ça aussi. Il stocke la taille allouée dans la case mémoire située juste avant la variable allouée. Ptet que le prof vient du Pascal...

 
Le Pascal ne fait pas ca plus que le C.  En C comme en Pascal, c'est l'utilisation d'un detail d'implementation vraisemblablement meme pas documente pour l'implementation utilisee.

Tu te trompes

Putain Joel, on t'a jamais dit d'être cool avec les gens?

je suis cool, j'ai pas dit "tu te trompes boulard"  

 
  Elle vaut son pesant de cacahuète cette fonction :
 

struct tbl {
   int t[256][256][256] ;
};
 
void drawPoint(int x, int y, int r, int g, int b){
   static struct tbl *t=NULL ;
   if(!t){
      t=malloc(sizeof(struct tbl)) ;
      memset(t, 0, sizeof(struct tbl));
   }
   XColor color ;
   color.red = r<<8 ;
   color.green = g<<8 ;
   color.blue = b<<8 ;
   if(!(t->t[r][g][b])) {
      XAllocColor(display, colormap, &color) ;
      t->t[r][g][b] = color.pixel ;
   }
   XSetForeground(display, gc, t->t[r][g][b]) ;
   XDrawPoint(display, window, gc, x, y) ;
}

 
Il alloue une colormap de 64Mo   . Ils sont au courant tes profs que c'est juste en 8bits que t'a besoin d'une colormap ? Ce n'est qu'un cas d'école certes, mais tout de même.
 
 

Vous croyez qu'on a fait peur à Petiois à force de dire que son prof est nul ou bien qu'il a réussi son exercice?

 
Peux-tu m'expliquer le comportement suivant alors :  
 
Attention code vraiment crado pour mettre en évidence le comportement des vectors.
 

 
Provoque l'envoi d'un SIGABRT lors de la désallocation du vector. Par contre si l'on ne touche pas à l'indice -1 (même en modifiant le -2 ou le size+1) le programme s'exécute et se termine correctement.
Donc on peut toucher à tous les indices sans provoquer de problème (enfin faut le dire vite) sauf l'indice -1.

tu ecrases simplement le pointeur de fin du vector qui est stockée à coté du pointeur de début. Aucun rapport avec stocker des trucs en v[-1].
 
RTFM

 
Là Petiois a maintenant vraiment de quoi avoir peur. Je pense même que c'est susceptible de le dégoûter du C