Les types énumérés et les booléens _sont_ des entiers, tu n'y peux rien.
Super ! Donc vrai + rouge = 6 ! La classe. Merci.
batyann811
Nicolas George a écrit :
Les types énumérés et les booléens _sont_ des entiers, tu n'y peux rien.
Ce sont des entiers en C dans un vrai langage ce sont juste des types scalaires. Les entiers aussi sont des types scalaires mais en aucun cas les types énumérés et le type booléen ne sont des entiers.
Nicolas George a écrit :
Les types énumérés et les booléens _sont_ des entiers, tu n'y peux rien.
Ce sont des entiers en C dans un vrai langage ce sont juste des types
scalaires. Les entiers aussi sont des types scalaires mais en aucun cas
les types énumérés et le type booléen ne sont des entiers.
Les types énumérés et les booléens _sont_ des entiers, tu n'y peux rien.
Ce sont des entiers en C dans un vrai langage ce sont juste des types scalaires. Les entiers aussi sont des types scalaires mais en aucun cas les types énumérés et le type booléen ne sont des entiers.
debug this fifo
batyann811 wrote:
les types énumérés et le type booléen ne sont des entiers.
le booleen non entier, c'est pour la logique floue.
batyann811 wrote:
les types énumérés et le type booléen ne sont des entiers.
le booleen non entier, c'est pour la logique floue.
On Thu, 26 Nov 2009 13:57:17 +0100, batyann811 wrote:
Des histoires de bonnes femmes, à tous les coups. :-)
C'est vrai que si GC veut dire Gros Cul...
Si le tampon déborde par le cul c'est qu'il faut relire la page de man afférante,
-- Doug713705
Yliur
> > Tu te rends compte de ce que tu es capable d'écrire ? Je te > rappelle que Java est un langage à GC, ce n'est pas ce qui empêche > les fuites mémoire partout, parce qu'en général, il faut > déréférencer les objets pour que le GC récupère la mémoire (et au > prix d'une consommation de ressources sans aucune mesure). > > Bref, le GC, c'est une rustine pour les gens qui ne savent > pas programmer (ou qui utilisent la mémoire comme des gorets). >
je n'ai jamais vu de fuite mémoire ou plutôt je ne l'ai jamais rencontrée avec du code java
Les cas où il faut "déréferencer" des variables sont en effet assez rares en Java. C'est juste quand la variable est référencée dans un endroit "annexe", par exemple elle est stockée dans une table de hachage (indexation). Et encore, l'utilisation de références faibles permet de ne pas s'occuper de ça dans ce cas.
en java si cela n'a pas changé, le code s'exécute par défaut dans le thread de l'interface graphique, c'est moyen je trouve
Ben il s'agit uniquement du code en réaction aux événements utilisateurs (quand il clique sur un bouton par exemple). Et ça peut être ça que tu veux, pour éviter que l'utilisateur puisse cliquer s ur plusieurs boutons "en même temps" (c'est-à-dire que le code exécut é en réaction aux clics s'exécute en parallèle). Si le traitement déclenché est long et que tu veux l'exécuter dans un autre fil d'exécution, il faut effectivement créer toi-même le nouveau fil.
> > Tu te rends compte de ce que tu es capable d'écrire ? Je te
> rappelle que Java est un langage à GC, ce n'est pas ce qui empêche
> les fuites mémoire partout, parce qu'en général, il faut
> déréférencer les objets pour que le GC récupère la mémoire (et au
> prix d'une consommation de ressources sans aucune mesure).
>
> Bref, le GC, c'est une rustine pour les gens qui ne savent
> pas programmer (ou qui utilisent la mémoire comme des gorets).
>
je n'ai jamais vu de fuite mémoire ou plutôt
je ne l'ai jamais rencontrée avec du code java
Les cas où il faut "déréferencer" des variables sont en effet assez
rares en Java. C'est juste quand la variable est référencée dans un
endroit "annexe", par exemple elle est stockée dans une table de
hachage (indexation). Et encore, l'utilisation de références
faibles permet de ne pas s'occuper de ça dans ce cas.
en java si cela n'a pas changé, le code s'exécute par défaut dans le
thread de l'interface graphique, c'est moyen je trouve
Ben il s'agit uniquement du code en réaction aux événements
utilisateurs (quand il clique sur un bouton par exemple). Et ça peut
être ça que tu veux, pour éviter que l'utilisateur puisse cliquer s ur
plusieurs boutons "en même temps" (c'est-à-dire que le code exécut é
en réaction aux clics s'exécute en parallèle). Si le traitement
déclenché est long et que tu veux l'exécuter dans un autre fil
d'exécution, il faut effectivement créer toi-même le nouveau fil.
> > Tu te rends compte de ce que tu es capable d'écrire ? Je te > rappelle que Java est un langage à GC, ce n'est pas ce qui empêche > les fuites mémoire partout, parce qu'en général, il faut > déréférencer les objets pour que le GC récupère la mémoire (et au > prix d'une consommation de ressources sans aucune mesure). > > Bref, le GC, c'est une rustine pour les gens qui ne savent > pas programmer (ou qui utilisent la mémoire comme des gorets). >
je n'ai jamais vu de fuite mémoire ou plutôt je ne l'ai jamais rencontrée avec du code java
Les cas où il faut "déréferencer" des variables sont en effet assez rares en Java. C'est juste quand la variable est référencée dans un endroit "annexe", par exemple elle est stockée dans une table de hachage (indexation). Et encore, l'utilisation de références faibles permet de ne pas s'occuper de ça dans ce cas.
en java si cela n'a pas changé, le code s'exécute par défaut dans le thread de l'interface graphique, c'est moyen je trouve
Ben il s'agit uniquement du code en réaction aux événements utilisateurs (quand il clique sur un bouton par exemple). Et ça peut être ça que tu veux, pour éviter que l'utilisateur puisse cliquer s ur plusieurs boutons "en même temps" (c'est-à-dire que le code exécut é en réaction aux clics s'exécute en parallèle). Si le traitement déclenché est long et que tu veux l'exécuter dans un autre fil d'exécution, il faut effectivement créer toi-même le nouveau fil.
Yliur
> > > Certainement pas. Le C n'est pas un assembleur évolué. Un > assembleur évolué, ce serait Macro32 de VMS. Ce n'est pas un > assembleur évolué parce qu'il ne permet l'accès à un paquet de > structures de contrôle, parce qu'il ne garantit pas l'exécution > dans un ordre donné, ni l'atomicité, ni d'ailleurs rien d'autre qui > est faisable en assembleur. C'est même pour cela qu'au fond des OS, > il y a quasiment toujours des routines écrites directement en > assembleur !
Allez si ça peut te faire plaisir je vais dire que c'est un assembleur++
++assembleur, il faut l'améliorer avant de l'utiliser.
> >
> Certainement pas. Le C n'est pas un assembleur évolué. Un
> assembleur évolué, ce serait Macro32 de VMS. Ce n'est pas un
> assembleur évolué parce qu'il ne permet l'accès à un paquet de
> structures de contrôle, parce qu'il ne garantit pas l'exécution
> dans un ordre donné, ni l'atomicité, ni d'ailleurs rien d'autre qui
> est faisable en assembleur. C'est même pour cela qu'au fond des OS,
> il y a quasiment toujours des routines écrites directement en
> assembleur !
Allez si ça peut te faire plaisir je vais dire que c'est un
assembleur++
++assembleur, il faut l'améliorer avant de l'utiliser.
> > > Certainement pas. Le C n'est pas un assembleur évolué. Un > assembleur évolué, ce serait Macro32 de VMS. Ce n'est pas un > assembleur évolué parce qu'il ne permet l'accès à un paquet de > structures de contrôle, parce qu'il ne garantit pas l'exécution > dans un ordre donné, ni l'atomicité, ni d'ailleurs rien d'autre qui > est faisable en assembleur. C'est même pour cela qu'au fond des OS, > il y a quasiment toujours des routines écrites directement en > assembleur !
Allez si ça peut te faire plaisir je vais dire que c'est un assembleur++
++assembleur, il faut l'améliorer avant de l'utiliser.
Yliur
Le Thu, 26 Nov 2009 14:05:48 +0100 batyann811 a écrit :
debug this fifo a écrit : > batyann811 wrote: >> >> Pour moi les 2 principaux défauts du C c'est >> 1 - Typage pas assez strict (pas de booléen, pas d'enum, pas de >> type > ^^^^^^^^^^ > fud detected...
Non non. Je suis sérieux je ne considère pas les enums du C comme un vrai type énuméré.
Si on est un peu strict/méchant, il n'y a pas non plus de tableaux ni de caractères en C. Il y a bien des éléments de syntaxe pour gérer des tableaux ou des caractères, mais c'est pour faire semblant : - un "tableau" c'est juste un pointeur, ce qui fait qu'il faut noter à côté sa taille. - un "caractère" c'est juste un octet, on ne peut pas faire de correspondance non ambiguë avec un caractère parce que l'encodage n'est pas spécifié.
Le Thu, 26 Nov 2009 14:05:48 +0100
batyann811 <batyann811@invalid.fre> a écrit :
debug this fifo a écrit :
> batyann811 wrote:
>>
>> Pour moi les 2 principaux défauts du C c'est
>> 1 - Typage pas assez strict (pas de booléen, pas d'enum, pas de
>> type
> ^^^^^^^^^^
> fud detected...
Non non. Je suis sérieux je ne considère pas les enums du C comme un
vrai type énuméré.
Si on est un peu strict/méchant, il n'y a pas non plus de tableaux ni
de caractères en C. Il y a bien des éléments de syntaxe pour gérer
des tableaux ou des caractères, mais c'est pour faire semblant :
- un "tableau" c'est juste un pointeur, ce qui fait qu'il faut
noter à côté sa taille.
- un "caractère" c'est juste un octet, on ne peut pas faire de
correspondance non ambiguë avec un caractère parce que l'encodage
n'est pas spécifié.
Le Thu, 26 Nov 2009 14:05:48 +0100 batyann811 a écrit :
debug this fifo a écrit : > batyann811 wrote: >> >> Pour moi les 2 principaux défauts du C c'est >> 1 - Typage pas assez strict (pas de booléen, pas d'enum, pas de >> type > ^^^^^^^^^^ > fud detected...
Non non. Je suis sérieux je ne considère pas les enums du C comme un vrai type énuméré.
Si on est un peu strict/méchant, il n'y a pas non plus de tableaux ni de caractères en C. Il y a bien des éléments de syntaxe pour gérer des tableaux ou des caractères, mais c'est pour faire semblant : - un "tableau" c'est juste un pointeur, ce qui fait qu'il faut noter à côté sa taille. - un "caractère" c'est juste un octet, on ne peut pas faire de correspondance non ambiguë avec un caractère parce que l'encodage n'est pas spécifié.
doug713705
On Thu, 26 Nov 2009 14:53:53 +0100, debug this fifo wrote:
les types énumérés et le type booléen ne sont des entiers.
le booleen non entier, c'est pour la logique floue.
if (bool == 0.5){ printf "ptet bin qu'oui, ptet ben qu'non" }else{ printf "vous n'etes pas Normand." }
-- Doug713705
On Thu, 26 Nov 2009 14:53:53 +0100, debug this fifo wrote:
les types énumérés et le type booléen ne sont des entiers.
le booleen non entier, c'est pour la logique floue.
if (bool == 0.5){
printf "ptet bin qu'oui, ptet ben qu'non"
}else{
printf "vous n'etes pas Normand."
}
On Thu, 26 Nov 2009 14:53:53 +0100, debug this fifo wrote:
les types énumérés et le type booléen ne sont des entiers.
le booleen non entier, c'est pour la logique floue.
if (bool == 0.5){ printf "ptet bin qu'oui, ptet ben qu'non" }else{ printf "vous n'etes pas Normand." }
-- Doug713705
Nicolas George
batyann811 , dans le message <4b0e86cf$0$923$, a écrit :
Ce sont des entiers en C dans un vrai langage ce sont juste des types scalaires. Les entiers aussi sont des types scalaires mais en aucun cas les types énumérés et le type booléen ne sont des entiers.
C'est fondamentalement la même chose.
batyann811 , dans le message <4b0e86cf$0$923$ba4acef3@news.orange.fr>, a
écrit :
Ce sont des entiers en C dans un vrai langage ce sont juste des types
scalaires. Les entiers aussi sont des types scalaires mais en aucun cas
les types énumérés et le type booléen ne sont des entiers.
batyann811 , dans le message <4b0e86cf$0$923$, a écrit :
Ce sont des entiers en C dans un vrai langage ce sont juste des types scalaires. Les entiers aussi sont des types scalaires mais en aucun cas les types énumérés et le type booléen ne sont des entiers.
