Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmation C » Mon premier programme en C (35 réponse(s))

./REPRISE DU POST PRECEDENT (post n°19) Marquer comme non lu.

Benjy

Ecrit le: Mercredi 1er septembre 2004 à 22:46

Membre: Maître Ultime

Groupe: Omega staff

Messages: 1156

Membre n°91

Inscrit le 09 mars 2004

Non elle ne perd pas son sens logique!!

Le langage C y'a pas mieux!!!

./Post n°20 Marquer comme non lu.

Folco

Ecrit le: Mercredi 1er septembre 2004 à 22:50

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

oui, c'est vrai.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°21 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mercredi 1er septembre 2004 à 23:17

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

scrsave = HeapAllocPtr(3840); //adresse du buffer renvoyée dans scrsave
memcpy(scrsave, LCD_MEM, 3840); //copie de l'écran dans le buffer

ERREUR! Il faut vérifier si l'allocation a marché.

À part ça, ton code est très bien.

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°22 Marquer comme non lu.

Folco

Ecrit le: Mercredi 1er septembre 2004 à 23:52

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

oups grosse boulette alors, merci
au fait, scrsave est un pointeur, que se passe-t-il alors en cas de garbage de la RAM, ça plante? (Ce qui voudrait dire qu'il serait préférable de retenir les handles créés dans une table peut-être?)

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°23 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 2 septembre 2004 à 00:04

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Non, HeapAllocPtr verrouille (locke) automatiquement le handle, donc le pointeur reste valide.

./Post n°24 Marquer comme non lu.

Folco

Ecrit le: Jeudi 2 septembre 2004 à 00:10

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

C'est corrigé:

  if (!(scrsave = HeapAllocPtr(3840)))
  {
    ST_helpMsg ("Not enough RAM");
    return;
  }
  memcpy(scrsave, LCD_MEM, 3840);

edit: merci pour la précision, j'avais pas vu

-Edité le Jeudi 2 septembre 2004 à 00:14 par Martial Demolins-

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°25 Marquer comme non lu.

Folco

Ecrit le: Samedi 11 septembre 2004 à 21:19

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

D'ailleurs ce que j'ai écris est juste, mais gore, le jours ou ti remplacera la valeur de null par $FFFFFFFF, mon code marchera plus...

-Edité le Samedi 11 septembre 2004 à 21:22 par Martial Demolins-

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°26 Marquer comme non lu.

Kevin Kofler

Ecrit le: Dimanche 12 septembre 2004 à 00:08

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

NULL est garanti valoir 0. Standard ISO C99, paragraphe 6.3.2.3 [#3]:

       [#3] An integer constant expression with  the  value  0,  or
       such  an  expression  cast  to type void *, is called a null
       pointer   constant.55)    If  a  null  pointer  constant  is

./Post n°27 Marquer comme non lu.

Folco

Ecrit le: Dimanche 12 septembre 2004 à 18:55

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Et depuis quand TI suit cette norme ??
Le jour ou ils développernont en langage propriétaire...

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°28 Marquer comme non lu.

LionelA

Ecrit le: Dimanche 12 septembre 2004 à 19:09

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

Tu voudrais dire que TI changerait la valeur de retour de HeapAllocPtr ?
Il y aurait beaucoup trop de trucs qui marcheraient plus (y compris des trucs de chez TI) donc je ne voit absolument pas l'interêt qu'ils auraient à faire ça.
En tout cas NULL restera toujours égal à 0 (je pense que c'est une constante définie quelque part dans les fichiers de tigcc)

Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

./Post n°29 Marquer comme non lu.

geogeo

Ecrit le: Dimanche 12 septembre 2004 à 19:19

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Euh ça serait un peu débile de changer la valeur de NULL. Dans ce cas comment programmer tranquillement sans penser que chaque constante peut être changée. Là on ne s'en sort plus.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°30 Marquer comme non lu.

Folco

Ecrit le: Dimanche 12 septembre 2004 à 19:49

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

geogeo-> tout faux, si une valeur chang, il te suffit de recompiler.
(Comme quand on corrige un bug de lib statique)

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°31 Marquer comme non lu.

geogeo

Ecrit le: Dimanche 12 septembre 2004 à 20:55

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Euh oui je sais bien. Mais pense à une chose.
Tu distribue le binaire de ton programme. Et dans le cas où tu distribue les sources, il n'y a que 0.01% des utilisateurs qui vont comprendre qu'il faut recompiler le programme pour que ça focntionne sur leur plateforme si jamais il y a un changement, dans le cas contraire, ça fonctionne pas alors 'poubelle'.

Ensuite mon post avait juste l'objectif de dire que ça ne sert à rien de ce prendre la tête avec les constantes sinon on ne s'en sort plus. Suffit de changer la constante en elle même et puis basta.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°32 Marquer comme non lu.

Pollux

Ecrit le: Dimanche 12 septembre 2004 à 23:12

Membre: Vétéran

Messages: 95

Membre n°306

Inscrit le 11 juin 2004

Kevin Kofler :
NULL est garanti valoir 0. Standard ISO C99, paragraphe 6.3.2.3 [#3]:

       [#3] An integer constant expression with  the  value  0,  or
       such  an  expression  cast  to type void *, is called a null
       pointer   constant.55)    If  a  null  pointer  constant  is

Non, c'est le contraire

0 est garanti valoir NULL, mais (int)NULL ne vaut pas forcément 0... Et si x=0, (void *)x n'est pas garanti valoir NULL non plus...

(sur TI, c pas la peine de se prendre la tête avec ça, mais comme je vois que tu citais le standard pour appuyer ce que tu disais...)

./Post n°33 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 13 septembre 2004 à 05:03

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Euh, si (ptrint_t)(void*)0 est différent de 0, il y a un problème quelque part. #roll#

Et puis: 6.8.4.1 (if Statement) [#2]:

[#2] In both forms, the first substatement is executed if
the expression compares unequal to 0. In the else form, the

6.5.9 (Equality Operators) [#5]:

       [#5] Otherwise, at least one operand is a pointer.   If  one
       operand  is  a  pointer  and  the  other  is  a null pointer
       constant, the null pointer constant is converted to the type
       of the pointer.  If one operand is a pointer to an object or

Avec 6.3.2.3 [#3] qui dit que 0 est un null pointer constant, cela dit clairement que le test:
if (pointeur)
est équivalent à:
if (pointeur!=NULL)

./Post n°34 Marquer comme non lu.

Pollux

Ecrit le: Lundi 13 septembre 2004 à 10:53

Membre: Vétéran

Messages: 95

Membre n°306

Inscrit le 11 juin 2004

Kevin Kofler :
Euh, si (ptrint_t)(void*)0 est différent de 0, il y a un problème quelque part. #roll#

Ben nan, justement. Les casts pointeurs -> int et int -> pointeurs sont mal définis en C ANSI (sauf dans le cas particulier où c'est un nombre *syntaxiquement* égal à 0, auquel cas c'est aussi le pointeur nul).

Et puis: 6.8.4.1 (if Statement) [#2]:

[#2] In both forms, the first substatement is executed if
the expression compares unequal to 0. In the else form, the

Ah, mais attention : ce n'est pas parce que (ptrint_t)(void *)0 != 0 que (void *)0 != 0 ...

6.5.9 (Equality Operators) [#5]:

Avec 6.3.2.3 [#3] qui dit que 0 est un null pointer constant, cela dit clairement que le test:
if (pointeur)
est équivalent à:
if (pointeur!=NULL)

Là par contre c'est tout à fait vrai : if (pointeur) est équivalent à if (pointeur != 0) lui-même équivalent à if (pointeur != NULL) (d'ailleurs je n'utilise souvent que la première forme...)

Mais toutes tes autres conclusions sont erronées