Reprise du message précédent :
le C++ fait les deux ca tombe bien.

oui et non, du fait de certainnes de ses proprietées, des optimisation ne sont plus possibles.
 
Qui plus est, il gere pas la memoire tout seul de facon autonome sans passer par des astuces genre pointeurs intelligents.

Désolé de venir repolluer ce topic...
 
Vous avez parlé l'autre jour des transtypages automatiques en C vers le type le plus gros (ce qui est contradictoire avec d'autres langages comme le C# où ce n'est pas toujours le cas).
 
Ici, je suis en C++ (à moins que la partie du code ne soit pas encore modifiée, et du coup c'est encore du C, désolé si je me plante, je sais pas faire la différence )
 
Est-ce que j'ai le droit de faire ça ?
 

byte val1 = <une valeur>;
byte val2 = <une valeur>;
uint16 val3 = val1 * val2; // cas 1 = calculs
 
if (val3 > val1 && val2 == val2) // cas 2 = comparaison (je veux que ça se comporte comme si les variables avaient le même type)
{
 ...
}

 
=> Est-ce que val3 va prendre la valeur sur 16 bits de la multiplication de val1 et val2 sur 16 bits, ou si je vais me retrouver avec une valeur tronquée, ou pire, une exception ?
 
Voici le code en question :

Money GetTransportedGoodsIncome(uint num_pieces, uint dist, byte transit_days, CargoID cargo_type)
{
    const CargoSpec *cs = GetCargo(cargo_type);
    byte f;
    /* If playing with daylength correction, then take in account the real transit_days */
    uint16 new_transit_days = (_patches.daylength_correction) ? transit_days * _patches.daylength_multiplier : transit_days;
 
    /* Use callback to calculate cargo profit, if available */
    if (HASBIT(cs->callback_mask, CBM_CARGO_PROFIT_CALC)) {
        uint32 var18 = min(dist, 0xFFFF) | (min(num_pieces, 0xFF) << 16) | (new_transit_days << 24);
        uint16 callback = GetCargoCallback(CBID_CARGO_PROFIT_CALC, 0, var18, cs);
        if (callback != CALLBACK_FAILED) {
            int result = GB(callback, 0, 14);
 
            /* Simulate a 15 bit signed value */
            if (HASBIT(callback, 14)) result = 0x4000 - result;
 
            /* "The result should be a signed multiplier that gets multiplied
             * by the amount of cargo moved and the price factor, then gets
             * divided by 8192." */
            return result * num_pieces * _cargo_payment_rates[cargo_type] / 8192;
        }
    }
 
    /* zero the distance if it's the bank and very short transport. */
    if (_opt.landscape == LT_TEMPERATE && cs->label == 'VALU' && dist < 10)
        dist = 0;
 
    f = 255;
    if (new_transit_days > cs->transit_days[0]) {
        new_transit_days -= cs->transit_days[0];
        f -= new_transit_days;
 
        if (new_transit_days > cs->transit_days[1]) {
            new_transit_days -= cs->transit_days[1];
 
            if (f < new_transit_days) {
                f = 0;
            } else {
                f -= new_transit_days;
            }
        }
    }
    if (f < 31) f = 31;
 
    /* If playing with daylength correction, then take in account the fact we do more transports */
    int64 new_value;
    if (_patches.daylength_correction)
        new_value = BIGMULSS(dist * f * num_pieces, _cargo_payment_rates[cargo_type], 21) / _patches.daylength_multiplier;
    else
        new_value = BIGMULSS(dist * f * num_pieces, _cargo_payment_rates[cargo_type], 21);
    return new_value;
}

 
J'ai rajouté le "new_transit_days" (afin de remplacer l'ancienne valeur de "transit_days", ainsi que le "new_value";
 
_patches.daylength_multiplier est de type byte
 
Est-ce que ça va marcher comme escompter ?
 
Sinon, comment faire un transtypage implicite ?
 
uint16 val3 = (uint16)val1 * (unit16)val2; ??

D'après mes tests, y'a une couille qui flotte dans la soupe, parceque si j'active le patch, j'ai plus de revenus
 
A moins que ça ne me retroune 0, mais ça m'étonne... Avec un daylength_multiplier = 30 si les revenus sont de 30 ou plus en mode "normal", je devrais avoir 1... Mais là j'ai 0 on dirait
 
Hmmm... Etrange en fait.
 
Si je colle un daylength de 10, alors j'ai bien 90 qui devient 10 (en plus il fait ça... ha ! pigé, je suis en FF, et les FF c'est Money * 10 à l'affichage 9/10 = 1 mais 9/30 = 0
 
Bon, ben en fait je suis débile (on n'en doutait plus).
 
Pas besoin de passer par un unit16, puisque si mes journées durent 30 fois plus de temps, alors mes trajets durerons 30 fois moins de temps. Donc aucun problème pour multiplier la durée par 30...
 
A une exception près : en réalité, le jeu arrête de compter les journées lorsque la durée dépasse 255, qui correspond à la fois à la taille de byte, mais aussi au paiement minimum des transports. Du coup, je peux quand même avoir un dépassement... Corrigé simplement en collant un "min(255, val1 * val2)".
 
J'aime bien faire des posts totalement inutiles et réfléchir après la compilation -qui prend 3 plombes en plus -

Ben si t'es content

pourquoi uint16 ? tu bosses sur un 286 ?
 
reste en int tout le long, sauf quand tu lis depuis un buffer.

Comme ?
 

?

 
La surcharge des operateurs par exemple. Le compilo peut plus prevoir ses optimisation habituelles sur les operations.
 

 
malloc et free ca se pratique toujours en C++ . Pour avoir une gestion de la memoire automatique, il faut biaser.
 
Qui plus est, melanger du haut et du bas niveau dans le meme code, c'est vraiment pas conseillé.Plus on a d'outils, plus on a de chances de ne pas utiliser le bon outils. C'est ca le revers de C++ .
 
Pour les pointeurs intelligents : http://c.developpez.com/faq/cpp/?p [...] telligents

oui mais tout avoir d'automatique sans contrôle c'est pas toujours un avantage.
 
l'avantage c'est d'avoir le choix, et le C++ est pas mal pour ça.

Effectivement, ici le uint16 n'avait aucun intérêt.
A la base j'étais parti sur ce type car je pensais avoir besoin de le stocker ensuite en mémoire dans une struct donc le nombre d'occurence peut atteindre plusieurs centaines de milliers (5000 véhicules de chacun des 4 types, et pour chacun des types de cargaisons -actuellement limité à 8, mais dont la limite va sauter avec un patch à venir permettant d'utiliser de nouveaux types d'industries, donc potentiellement au moins 256 types de cargo différents puisque j'imagine que le type de cargo sera stocké dans un byte -contre actuellement 3 bits d'un flag partagé-)
 
Mais bon, finalement je suis retourné au type byte, puisque de toute façon les valeurs > 255 ne m'intéressent pas, car le jeu ne fait pas de différence dans le prix de transport des cargaisons dépassé cette valeur
 

 
Anyway De toute façon comme expliqué ici http://www.tt-forums.net/viewtopic [...] 54#p607654 et http://www.tt-forums.net/viewtopic [...] 73#p607773 mon approche est foireuse lorsqu'on a un grand coeff multiplicateur de temps :
-> Avec un temps multiplié par 30 (valeur maximale du patch que je tentais de corriger) si un véhicule met en temps normal 31 jours pour faire le trajet, alors le patch va me dire "2 jours" puisqu'il ne va incrémenter le jour que tous les 30 DayTicks. Du coup, avec mon calcul, je me retrouve avec 60 jours. Hors, entre 60 et 31 jours, l'écart de tarif peut être monstrueux, ce qui fait que le jeu se comporte vraiment très différement, et devient vraiment plus difficile. Il faudrait donc baser mon calcul non pas sur le nombre de jours, mais le nombre de ticks. Hors, après étude du code, deux choses ressortent : 1/ cela nécessiterait la réécriture de pas mal de code -trop pour moi, je suis une merde en C++, donc y'a pas moyen que je passe 10 jours à me rendre compte que je ne m'en sors pas- 2/ en plus, vu que je suis une quiche en C++, j'arrive même pas à trouver un point d'entrée pour l'appel de cette fonction : impossible de trouver où le calcul du nombre de jours de transport des cargaisons se fait... plus exactement j'ai plus ou moins trouvé, mais j'ai rien pigé, ils sont chiant à utiliser sans arrêt une fonction "DoCmd()", qui prend en paramètre un certain nombre de constantes qui font déterminer quelle fonction lancer... moi je suis paumé et j'arrive pas à suivre. Vu que mon VC++ refuse de tourner en mode débug pas à pas, je suis baisé pour trouver à coup sûr toutes les parties du code à modifier
 
Du coup le patch est mis de côté, et c'est le owner de la version "integrated" -version contenant tous les patchs intéressants candidats au tronc- qui va s'en occuper

 
Est-ce que t'es au courant que tes posts, et ta vie en général, sont aussi intéressants que la liste des ingrédients d'une boite de raviolis en conserve ?

Zapetti Cannelloni Pur Boeuf 800 g :
 
 
Sauce : eau, purée de tomate mi réduite, viande de boeuf, carottes, oignons, vin blanc, sucre, amidon transformé de maïs, huile de tournesol, sel, arômes.
 
Pâte : semoule de blé dur, eau, blanc d'oeuf.  
 
Farce : viande de boeuf, chapelure, semoule de blé dur, carottes, oignons, aromates, blanc d'oeuf, poudre de lait écrémé, fécule de manioc, sel, huile de tournesol, arômes naturels. Viande de boeuf mise en oeuvre : 13% du poids net total.

si tu veux des checked int, y a plein d'implé pour faire ça tranquillement

ça , ça peut s'arranger
 

Oui par les gens incompétents. vector,list et consoeur font leur boulot d'abstraction de manière très correct.  
 
 

 
la règle générale, c'est de conserver les types "naturels" (int/float/bool).
des fois être trop précis nuit à l'évolutitivité de l'application et aux performances.
au niveau mémoire, même si prendre des type peut être trop "larges" augmente la taille des structures et la conso de cache, c'est plus la manière de balayer et lier les structures/objets qui joue sur l'efficacité globale.  
essayer d'avoir des algos avec la complexité la plus proche du constant possible...
avoir des système d'indexation et de liaison sioux.... (ça a un coût mémoire, mais ça paut éliminer drastiquement des masses de tests dans le vent... des fois il faut pas hésiter de créer des graphes/arbres/tables aller directement à ce qui est pertinent)

L'exemple n'est pas bon.
L'opération est en fait un appel de fonction pour le cas de la surcharge d'opérateurs. Généralement, une opération impliquant une ou plusieurs opérandes de type fondamental n'est pas traduite en appel de fontion par le compilateur -- quoique ça puisse arriver.
 
 

Rarement dans le code que je lis.
 

 
Je n'irai pas contreduire les saintes écritures, par peur de finir sur le buchet.