rhhhhhhhaaaaaaaaaaaaaa #mad# #vtff# - Page 3

et même, rien ne garanti que les autres n'ont pas le même défaut... donc faudrait demander un audit externe... qui coutera des thunes et dont les conclusions ne sront peut être pas assez tranchées pour servir un dossier de poursuite contre un (ex) employé

N'empêche, des fois je me dis que le blocage des routes par les camionneurs ne serait vraiment, vraiment rien comparé à un blocage des infrastructures par les informaticiens...

d'autant qu'au lieu de créer des bouchons ça ferait un blackout en domino... on a eu un bel exemple avec skype y'a quelques jours...

Godzil (./60) :
Meme en connaissant, ça peux ne pas etre délibéré certaines construction. Et de toute maniere si tu dev dans ton coin quoi qu'il en soit tu fait forcement un peu ce genre de choses, volontairement ou non

Non, il existe des "normes" de codage (syntaxe), de nomage de variable (notation hongroise, voir chez Microsoft) etc... Il suffit de suivre un minimum de bon sens et tu peux assez facilement pondre un truc structuré, commenté et documenté (même si ça ne plait pas à tout le monde)

Kochise

Kochise, tu ne doit pas travailler dans le monde reel c'est tout simple

CSkinProgress
(
  LPCTSTR  i_poStrMessage,
  int      i_nUpper       = 100,
  int      i_nProgress    = cSPT_PERCENT,
  int      i_nPane        = 0,
  int      i_nSize        = 200,
  CBitmap* i_poBitmap     = NULL
#ifdef dCSP_SLIDERBAR_METHOD
 ,BOOL     i_bReverse     = false
#endif // dCSP_SLIDERBAR_METHOD

);

C'est quand même bien abusé ton paramètre conditionnel

Godzil (./65) :
Kochise, tu ne doit pas travailler dans le monde reel c'est tout simple

Non, je suis développeur chez les Bisounours, de sacré déconneurs ces peluches sur patte, et une sacré descente (de rein ?) avec ça...

Kochise

squalyl (./66) :
C'est quand même bien abusé ton paramètre conditionnel

Ouais, j'ai depuis encore fait évoluer mon "style" de programmation, c'est un peu plus propre (et encore plus structuré). J'aime bien pouvoir "désactiver" des parties de code inutiles, plutôt que de laisser du code mort (ça vient surtout de mon expérience dans l'embarqué)

Mon crédo c'est surtout : une ligne par commande (aaaah, l'assembleur), ça permet de...
- comparer très simplement deux codes sources (les différences deviennent des lignes uniques)
- pouvoir localiser un bug très simplement (sur les debuggeur qui travaillent qu'à la ligne)
- pouvoir désactiver une ligne/commande sans tout le reste derrière
- pouvoir documenter ligne par ligne (par exemple ici, paramètre par paramètre)
- d'afficher une structure hiérarchique du code, même les IF sont indentés de façon arborescente
- etc...

Kochise

pas envie de discuter des heures de ça, mais utiliser des pratiques de l'embarqué dans le non-embarqué c'est bien, sauf quand c'est inutile.

Ton truc à base de paramètres conditionnels n'est pas un style mais une connerie. En particulier ça empêche d'utiliser une version précompilée de ton bordel. Surtout qu'à bien faire, les #ifdef, tu les as mis au milieu. tout ça pour éviter quoi? 4 octets de pile? mets ton ifdef dans ton implémentation, mais pitié, pas dans l'interface

c'est le genre de truc qui mérite sincèrement des coups de trifouet.

Yeeaaaahhhhhsssss...

• Kochise descend son pantalon

Si je l'avais laissé dans l'interface, suivant la version précompilée, le gars aurait pas compris pourquoi ça marche ou pas. Ici l'interface colle à la version précompilée. J'ai hésité à faire comme tu as dit, mais ça aurait pu mener à une DLL-hell...

Kochise

un paramètre inutile documenté comme "may not be taken into account if..." c'est pas la mort non plus

(#kochifesses# )

Bon oui, hein, je t'ais dit que depuis (2003) je me suis un peu amélioré

Kochise

hmmm? ah j'avais point vu la date

(sinon t'avais bcp de dents à cette époque )

Moi je dis que ça se justifie ce qu'il fait, mais ça dépend des cas. Evidemment le mieux est de travailler avec un langage qui n'impose pas ça grâce à l'héritage (il aurait alors créé la classe qui a ou non la fonctionnalité au runtime grâce à une fabrique). Mais dans des plate-formes où l'allocation statique est avantageuse, on peut imaginer des trucs du style:

struct base_t {
    s32 x, y;
    u8 pad[56];
};

struct pluscomplexe_t {
    s32 x, y;
    s32 specifique;
    u8 pad[52];
};

struct base_t liste[256];

C'est plus sale, mais ça se justifie. Evidemment c'est largement plus rapide qu'une allocation dynamique et ne parlons même pas d'un garbage collector, mais il y a une certaine précaution dont il faudrait faire preuve avant de juger que la solution plus haut, "du temps où on savait coder", est vraiment préférable.

Euh, dans ce cas là, tu fais une union...

(Oui mais je ne suis plus totalement certain de tête de la syntaxe et j'ai pas envie d'ouvrir mon IDE pour tester
Encore que de mémoire l'union n'est pas forcément une bonne solution pour ça... tu fais comment si tu veux avoir des "classes" qui puissent elles-mêmes hériter d'une sous-classe, et si tu veux avoir plusieurs sous classes d'une classe de base?)

(aucune idée, je fais pas de C++ )

C'est du C ça

Y'a pas de classes en C

Brunni (./76) :
(Oui mais je ne suis plus totalement certain de tête de la syntaxe et j'ai pas envie d'ouvrir mon IDE pour tester

struct base_t {
    union{
    s32 x, y;
    }
    u8 pad[64];
};

struct pluscomplexe_t {
    union{
    s32 x, y;
    s32 specifique;
    }
    struct base_t pad; // ou "u8 pad[64];" ducoup
};

struct base_t liste[256];

Comme ça...

Kochise

Oui voilà merci. Enfin un tel code reste facilement considérable comme moche, surtout par rapport aux standards actuels, mais il peut se justifier dans certains cas, quoi.

Euh je vois pas pourquoi vous vous prenez la tête... suffit de créer une seule structure qui contient les membres communs à toute les variantes, plus une union qui contient tous les membres/sous-structures qui diffèrent.

Justement non, puisque dans l'union tous les membres (ici x, y et specifique) sont à la même place. Donc de fait les éléments qui diffèrents écrasent les éléments communs... Oui, parce que l'exemple donné plus haut est faux

Kochise

(vous pouvez continuer à poster ici pour discuter, mais seulement à condition d'ajouter des smileys , , et )

Hein ? S'ils sont écrasés, c'est qu'ils ne sont plus communs, par définition...

ne faisait pas partie de la liste !

Kochise (./80) :

Brunni (./76) :
(Oui mais je ne suis plus totalement certain de tête de la syntaxe et j'ai pas envie d'ouvrir mon IDE pour tester

struct base_t {
    union{
    s32 x, y;
    }
    u8 pad[64];
};

struct pluscomplexe_t {
    union{
    s32 x, y;
    s32 specifique;
    }
    struct base_t pad; // ou "u8 pad[64];" ducoup
};

struct base_t liste[256];

Comme ça...

Kochise

c'est quoi ce code

Kochise (./83) :
Justement non, puisque dans l'union tous les membres (ici x, y et specifique) sont à la même place. Donc de fait les éléments qui diffèrents écrasent les éléments communs... Oui, parce que l'exemple donné plus haut est faux

Kochise

ouf, pendant quelques posts tu m'as fait peur

Zerosquare (./85) :
Hein ? S'ils sont écrasés, c'est qu'ils ne sont plus communs, par définition...

En fait il faut écrire :

struct pt_t { 
    int x, y; // Pas au même emplacement mémoire
}; 

struct base_t { 
    union {
    struct pt_t pt; // Au même...
    char pad[64]; // ...emplacement mémoire
    };
}; 
 
struct pluscomplexe_t {
    union {
      struct { // Au même...
      struct pt_t pt;
      int specifique; 
      };
    struct base_t base; // ...emplacement mémoire
    };
}; 

struct base_t liste[256];

Ah oui, et , , et ) <- Il en fait bien parti...

Kochise

Non, celui-là est intégré à ma phrase. Le "et" est avant le dernier élément

Falait pas écrire [: o )] puisque [: o] donne d'où le )

Kochise