Selection aléatoire conditionelle (:D) - Page 2

Oui je connais alloca, mais le problème aurait été le même qu'avec un malloc "normal" : allouer / désallouer plusieurs fois la mémoire par frame aurait sans doute considérablement ralenti. Finalement même si la méthode avec une seule allocation est un peu plus couteuse en RAM, elle devrait être plus rapide.

256 element ?

256 pointeurs ?

sa fait pas 256Octets mais 256 * sizeof(int) !

attention !

bah si ce sont des pointeurs...

Non non, 256 elements (char)
Et puis de toute façon même si ça avait été des pointeurs, c'est 256 * sizeof(*char) et non pas 256 * sizeof(int), un int fait 2 octets sur Ti

et oui la taille d'un poiteur = sizeof(int)

quand tu fait

void *MonPtr

tu allou la taille d'un int en mémoire pour stoquer le ptr (sur un PC ou une TI : 4Octets)

et oui c'est comme sa, sinon tu aurait plein de pbms...
d'ailleur c pour sa que les int posent des pbms sur TIGCC... il devrait etre 32bits et pas 16bits...

Vertyos :
Non non, 256 elements (char)
Et puis de toute façon même si ça avait été des pointeurs, c'est 256 * sizeof(*char) et non pas 256 * sizeof(int), un int fait 2 octets sur Ti

256 * sizeof(*char)

risque pas de marcher sa sertait plutot

256 * sizeof(char) ou alors 256 * sizeof(char*)

et le fait que les int sur TIGCC fassent 16bits est une grossierre erreur...

Vertyos
: Oui je connais alloca, mais le problème aurait été le même qu'avec un malloc "normal" : allouer / désallouer plusieurs fois la mémoire par frame aurait sans doute considérablement ralenti. Finalement même si la méthode avec une seule allocation est un peu plus couteuse en RAM, elle devrait être plus rapide.

Justement avec alloca tu n'a pas ce problème. alloca fait de l'allocation sur la pile, ce qui est extrêmement rapide (il suffit de décrementer sp).

godzil
: d'ailleur c pour sa que les int posent des pbms sur TIGCC... il devrait etre 32bits et pas 16bits...

Euuuuuh non Un int n'est pas forcement sur 32-bits. Le standard ne l'a jamais imposé. Beaucoup de personnes pensent comme toi et écrivent du code non-portable à cause de ça.

Heu ué n'importe koi *char

Mais la doc de tigcc précise que, sans switch rajouté, char < short = int < long, donc int = 2 octets logiquement
(et donc 256 * sizeof(int) != 256 * sizeof(char*))

Nitro > *vraiment* rapide ? Parceque 256 octets c'est pas grand chose, donc les laisser alloués en permanence c'est pas très genant.

nitro
:

godzil
: d'ailleur c pour sa que les int posent des pbms sur TIGCC... il devrait etre 32bits et pas 16bits...

Euuuuuh non Un int n'est pas forcement sur 32-bits. Le standard ne l'a jamais imposé. Beaucoup de personnes pensent comme toi et écrivent du code non-portable à cause de ça.

La logique du C veux qu'un int soit egal a la taille d'un poiteur sur une processeur particulier.
Que je sache un pointeur sur le 68000 fait 32bits, donc l'int devrait faire 32bits et pas 16bits...

Si tu programmait en C sur une machine 8 bit ton int serait de 8 bits

C'est peut-être pas logique mais il n'empeche que...

il n'empeche qu'il ne faut de tte pas utiliser les int avec TIGCC dans la version "standard"..

Oué enfin pas de pb de ce coté là j'en utilise jamais. Mais c'est HS, d'une parcequ'il aurait fallu faire 256 * 4, d'une autre parceque de toute façon c'est un tableau de char et pas de pointeurs

met quand meme

malloc(256 * sizeof(char) on sait jamais

Bon si tu veux chipoter tu peux dire que le bus d'adresse fait 24 bits aussi

lol des fois que la taille du char change en cours de route
mais ça aussi, pour la lisibilité, je ne transforme pas en * 1

godzil :
La logique du C veux qu'un int soit egal a la taille d'un poiteur sur une processeur particulier. Que je sache un pointeur sur le 68000 fait 32bits, donc l'int devrait faire 32bits et pas 16bits...

La logique du C pour moi c'est le standard ISO/IEC 9899:1999 (appelé C99).
Dans ce document, paragraphe 6.2.5, il est écrit :
A "plain" int object has the natural size suggested by the architecture of the execution environment
Et sur 68k, il est plus intelligent de prendre 16-Bit parce que c'est la taille du bus de donnée.

Vertyos
: Oui je connais alloca, mais le problème aurait été le même qu'avec un malloc "normal" : allouer / désallouer plusieurs fois la mémoire par frame aurait sans doute considérablement ralenti.

L'allocation avec un alloca se fait en une seule instruction 68k.

godzil :
et oui la taille d'un poiteur = sizeof(int)
quand tu fait
void *MonPtr tu allou la taille d'un int en mémoire pour stoquer le ptr (sur un PC ou une TI : 4Octets)

Non, la taille d'un pointeur n'est pas forcément celle de int!

d'ailleur c pour sa que les int posent des pbms sur TIGCC... il devrait etre 32bits et pas 16bits...

Non, parce que l'ABI de la plateforme (AMS) dit que ce sont 16 bits. (Ils font aussi 16 bits avec TI-FlashStudio.) Le switch -mlong pose des tas de problèmes avec printf etc.

godzil
: et le fait que les int sur TIGCC fassent 16bits est une grossierre erreur...

Non, parce que c'est ce qu'utilise AMS.

nitro
:

godzil
: d'ailleur c pour sa que les int posent des pbms sur TIGCC... il devrait etre 32bits et pas 16bits...

Euuuuuh non Un int n'est pas forcement sur 32-bits. Le standard ne l'a jamais imposé. Beaucoup de personnes pensent comme toi et écrivent du code non-portable à cause de ça.

En effet. À la limite, on peut utiliser long ou size_t si on a besoin de transtyper un pointeur en un entier, ça passe presque partout (même s'il n'est pas garanti que ça fonctionne là non plus!), mais int est clairement insuffisant, et pas seulement avec TIGCC.

godzil :
La logique du C veux qu'un int soit egal a la taille d'un poiteur sur une processeur particulier. Que je sache un pointeur sur le 68000 fait 32bits, donc l'int devrait faire 32bits et pas 16bits...

La logique du C veut que size_t soit égal à la taille d'un pointeur, sauf dans des cas particuliers (AMS pourrait en être un, vu que les objets sont limités à 65520 octets par la limite de taille des handles alors que les adresses sont sur 32 bits, mais TI a préféré le choix le plus logique, qui est sizeof(size_t)==sizeof(void *)). Nulle part n'est-il dit qu'un size_t doit obligatoirement être un unsigned int. Dans TIGCC (et TI-FlashStudio), c'est un unsigned long, et c'est parfaitement raisonnable.

Si tu programmait en C sur une machine 8 bit ton int serait de 8 bits

Non, le standard C99 interdit explicitement les int de 8 bits. C'est 16 bits minimum pour short et int. 32 bits minimum pour long, 64 pour long long. Cf. paragraphe 5.2.4.2.1.

(kevin passe sont temps a lire de la doc ou quoi ? )

L'histoire des tailles minimales a été discutée sur la mailing list de GCC.

dsl j'evite de m'abonner au mailing qui explose une boite en 5min chrono....

Je ne suis pas abonné non plus, je lis les archives online.

Une variante de la méthode de geogeo:
avecu un premier for th comptes le nombre d'élément valides dans la liste, puis tu fais un rand sur ce nombre et tu accèdes au n-ième élément en partant du début. C'est la même chose sans créer de liste secondaire quoi.

Ca ne fonctionnera pas si les éléments valide sont dispersé dans la liste.

Une variante de la méthode de geogeo: avecu un premier for th comptes le nombre d'élément valides dans la liste, puis tu fais un rand sur ce nombre et tu accèdes au n-ième élément en partant du début. C'est la même chose sans créer de liste secondaire quoi.

c'est tres lent

geogeo> si, ça fonctionnera.

Et oui par contre, c'est plus lent que d'avoir une deuxième liste.

Il y a aussi une autre méthode pour éviter de créer une listes, effectue un trie rapide et un rand sur la liste.

int items=0;
int i;

for (i=0;i<10;i++)
{
if (strchr (LstItem[i],"A"!=0) LstItem[items++]=LstItem[i];
}

Puis un rand sur la liste avec items pour indiquer la fin.

Un tri, laisse tomber, c'est encore plus lent que tout le reste...
[edit]: non en fait, ce n'est pas si lent.

le tri tu pourrait l'effectuer a chaque insertion dans la liste pas 4x par frames..

Non parce que l'ordre doit changer à chaque fois.