7

Here is my some code. To reduce the data size, 'id', 'knight', and 'sale_id' are not uint64_t, even though they are keys. Because 'primary_key()', 'by_knight()' and 'by_saleid()' functions convert key to uint64_t.

It works, but I wonder if it can be used like this.

//@abi table item i64
struct item {
    uint16_t id = 0;
    uint16_t code = 0;
    uint8_t knight = 0;
    uint8_t level = 0;
    uint8_t exp = 0;
    uint32_t dna = 0;
    uint32_t saleid = 0;

    uint64_t primary_key() const {
        return id;
    }

    uint64_t by_knight() const {
        return knight;
    }

    uint64_t by_saleid() const {
        return saleid;
    }

    EOSLIB_SERIALIZE(
            item,
            (id)
            (code)
            (knight)
            (level)
            (exp)
            (dna)
            (saleid)
    )
};

typedef eosio::multi_index< N(item), item,
    indexed_by< N(knight), const_mem_fun<item, uint64_t, &item::by_knight> >,
    indexed_by< N(saleid), const_mem_fun<item, uint64_t, &item::by_saleid> >
> item_table;
  • yes I think you can – Jimmy Guo Jul 12 '18 at 3:00
1

Yes, this should be possible due to implicit conversion.

It is safe to do this going from low precision to high precision, i.e. from 8-bit to 64-bit.

However, doing it in the other direction may cause data truncation if the 64-bit integer is larger than the maximum size of the 8-bit integer, leading to unexpected results.

For example, if you have 724 stored in a 64-bit integer, it is represented in binary as:

000......1011010100

If this is implicitly converted to 8-bit, the number represented in binary will be:

11010100

Which is no longer 724, but 212. This can lead to very confusing bugs, so be careful with implicit conversions!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.