Qques questions, base du C - Page 1

Bon. Voilà ttes les questions que je me pose sur le C et auquelles je n'ai pas trouvé de réponses. Si qqun peut éclairer ma lanterne...

1)
Quelle est la différence entre les short, char et long à part qu'ils sont 'codés sur X bytes' ? Quand on crée par exemple un écran virtuel, pourquoi est-ce un char et non autre chose ? Le mot 'char' me fait pense à 'chaine de caractère'. J'ai tout faux ?

2)
Comment ça marche pour mettre dans une variable soit un nombre soit une chaine de caractère ? Il faut faire ça sur un char, un short, un long ? Que signifie l''écriture :
char variable[]='hello world' ? Qu'est-ce que ce tableau dont on indique pas la longueur ???

3)
A quoi correspond l'écriture "bonjour"+2 ? En basic c'est une erreur mais en C on ne dirait pas... Il y a aussi celle-la :
unsigned char *type = HeapDeref(entry->handle)
*(unsigned short*)(type+4) (de obza_fazer)
Elle sert à renvoyer la longeur X d'une variable pic, mais à quoi correspond l'addition dans cette expression ???

Voilà... Je pense que c'est tout, merci à ceux qui peuvent me répondre.

P.S : Squale, pkoi ne pas commencer ton tuto par des bases comme ça, qui changent beaucoup par rapport au ti-basic ? Ce n'est qu'une proposition bien sûr

1a) La différence c'est la taille => donc la valeur maximale que la variable peut stocker.
1b) Pour au moins une raison pratique. La taille de la mémoire vidéo est de 3840 octets. Un tableau de char est composé d'éléments de 1 octet chacun. Donc pour déclarer le buffer il vaut mieux écrire char Buffer[3840] plutôt que short Buffer[3840/2] (un élément de type short tient sur 2 octets).

2a) Un nombre : Variable= 123456;
Une chaîne : strcpy(Tableau, "chaîne")
2b) oui c'est un tableau de caractères que l'on initialise et qui prend la taille de la chaîne !

3a) L'expression "bonjour"+2 est un pointeur sur le troisième caractère (octet) du tableau "bonjour". L'analyseur lexical d'un compilateur C considère les chaînes comme des tableaux de type char, voilà pourquoi des écritures aussi bizarres sont possibles.
3b) Avec la première ligne, type pointe sur le début du fichier. Seconde ligne :
type+4 est parfaitement équivalent à &type[4]. Cette expression est un pointeur sur le 5ième octet du fichier... Qui contient la longueur de l'image !
(unsigned short*) est un transtypage (les anglophones disent un cast). Cela "transforme" (type+4) (pointeur sur un octet), en un pointeur sur 2 octets (car la longueur du pic tient sur 2 octets). L'étoile placée avant sert enfin à lire le contenu pointé par ce pointeur... la longueur !
[edit]Edité par Thibaut le 03-01-2002 à 16:56:27[/edit]

Gé-ni-al !
En un post tu réponds clairement à tout, merci bcp !

Tu peux aller voir mon modeste cours au sujet des pointeurs ici : http://www.ti-fr.org/~prog/index.php3?do=c/tuto/pointeurs [edit]correction : quand TI-fr sera complètement remis en place [/edit]
[edit]Edité par Thibaut le 03-01-2002 à 16:53:20[/edit]

héhé, cassé

A la place de ce commentaire tu aurais pu répondre à Bob64, gugusg

on dirai que tu lu a déjà tout dit et je ne connait pas encore le C, dsl

Apprend c'est mieux que l'ASM !
[edit]Edité par Thibaut le 03-01-2002 à 16:59:07[/edit]

ben pour l'instant je me contente de l'asm
et comme mon projet est 100% asm, eh ben ..... ca attendra

>Thibaut: Apprend c'est mieux que l'ASM !

Non, l'assembleur est mieux, à une condition près: que ça soit de l'assembleur _nostub. (Les programmes deviennent en général plus petits et plus rapides.) Mais le C permet quand-même de programmer plus rapidement, avec un risque de bogues plus faible (mais pas inexistant!), et il y a d'excellents programmes en C (TI-Chess, TI-Mahjongg, ...).

> Kevin : arf
Bob64 : vas lire ce fichier il est interessant : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Ah ouais en effet c assez interessant... Merci !
(un pti coup d'impression et hop : qq pages à lire en français )

Bob64: vas dans la partie programmation de ti-fr ya pas mal de truc...

KK: que la programmation asm soit en nostub ou non ne change rien du tout, c'est toujours aussi interessant...
Et puis entre dire si l'asm est mieux ou moins bien que le C, c'est une question de choix... vouloir etre plus pres du processeur ou avoir un certain recul et facilite le developement d'algo...

Perso j'adore l'asm, mais je suis bien oblige de me mettre au C, car c'est le language universel ... Et le C est aussi interessant, mais sur d'autre points...

>TiMad: KK: que la programmation asm soit en nostub ou non ne change rien du tout, c'est toujours aussi interessant...

Le problème, ce n'est pas si c'est intéressant ou non, mais si c'est utile ou non...
Autre chose, s'il vous plaît n'utilisez pas l'adresse en $c8 pour déterminer le modèle de la calculatrice dans de nouveaux programmes, il y a de fortes chances que ça donnera TI-89 sur les Voyage 200. Utilisez plutôt la variable ScrRect.

Il va falloir adopter des conventions

De toute façon, il faudra déjà recompiler tous les programmes en niveaux de gris en C pour HW3, parce que les routines de niveaux de gris des dernières versions de TIGCCLIB veulent traîter les HW3 comme des HW1. (J'ai découvert cela aujourd'hui. Au moins, Sebastian compte le corriger dès maintenant.)
[edit]Edité par Kevin Kofler le 07-01-2002 à 21:10:47[/edit]

Bon tant que j'y suis... Je vais quand même pas créer 1 nouveau topic pr ça :

Comment on met en "mode" degrées ? Les fonctions trigos de TIGCC utilisent les radians, mais la j'aurais besoin d'utiliser les degrés... comment on s'y prends ?

#define sin(x) (sin((x)*(PI/180.)))
#define cos(x) (cos((x)*(PI/180.)))
#define tan(x) (tan((x)*(PI/180.)))
#define asin(x) (asin((x))*(180./PI))
#define acos(x) (acos((x))*(180./PI))
#define atan(x) (atan((x))*(180./PI))

(C'est pratique, les #defines circulaires en C.)

Ah oui en effet c assez simple, mais j'aurais pas trouvé tt seul... Merci !

Et en Azur

les #define circulaire, c vrai que c pratique, mais au bout d'un moment, si on reprend le source plus tard, on comprend plus rien

C quand même con qu'on puisse pas directement utiliser les degrés comme en basic

je préfère pas pouvoir utiliser les degrés, et avoir des progs rapides que le contraire !!!!
Et puis, si c'est pour faire des progs de maths, mieux vaut en général utiliser le BASIC (qui est plus simple pr ces progs)

Bah c pas pr faire un truc de maths, c pr 1 algo que je ve intergrer à un de mes programmes.

Bon vous allez peut-être vous poser des questions du genre "à koi ça va lui servir ?"

Et bah j'ai déjà l'impression que mon algo il est LEEEEEEEEENT et qu'il existe bcp mieux, mais je préfere essayer de le terminer et qu'il marche tel quel pour ensuite demander comment j'aurais du le faire pour qu'il soit rapide.

Par contre si vs trouvez à quoi ça me sert, ça veut dire que je ne suis pas trop loin de la bonne solution et donc dans ce cas là, tant mieux

normalement, on optimises l'algo à mort avant de le coder...
Ensuite, si c encore trop lent, on change d'algo...

enfin, normalement (je fais po trop comme ça : j'ai ma façon de coder, voila pourquoi je bosse généralement seul sur mes projets )

Bah en fait j'aimerais bien être tombé sur un assez bon algo du 1er coup, mais rien n'est moins sur...
Et puis je veux voir si il marche de toute façon...

Ensuite je demanderais surement des conseils pour le refaire entièrement en + rapide.

OK.

>>De toute façon, il faudra déjà recompiler tous les programmes en niveaux de gris en C pour HW3
tu veux dire tous les progs utilisant les lib statiques, ça n'a pas de raport ac le C
et si vous av pas les sources ?
alors qu'avec les lib dyn, pas de pb

ceci dit (juste pour te taquinner), c vrai que c un pb chiant..
je compatis
[edit]Edité par Pen^2 le 08-01-2002 à 18:35:48[/edit]

Bon ça marche pas mon truc
Encore qq essais et je m'avoue vaincu