I really like the “fast” C++11 types, that give best performance for a guaranteed minimum bit width. Use them when you know a variable will not exceed the maximum value of that bit width, but does not have to be a precise bit width in memory or elsewhere.

Pick specific-width fields whenever data is shared with other processes and components and you want a guarantee of its bit width.

And when using pointer size and array indices you should use types defined for those specific situations.

FAST types:


    int_fast8_t
    int_fast16_t                fastest signed integer type with width of
    int_fast32_t                at least 8, 16, 32 and 64 bits respectively
    int_fast64_t

    uint_fast8_t
    uint_fast16_t               fastest unsigned integer type with width of
    uint_fast32_t               at least 8, 16, 32 and 64 bits respectively
    uint_fast64_t

SMALL types:


    int_least8_t
    int_least16_t               smallest signed integer type with width of
    int_least32_t               at least 8, 16, 32 and 64 bits respectively
    int_least64_t

    uint_least8_t
    uint_least16_t		smallest unsigned integer type with width of
    uint_least32_t		at least 8, 16, 32 and 64 bits respectively
    uint_least64_t

EXACT types:


    int8_t                      signed integer type with width of
    int16_t                     exactly 8, 16, 32 and 64 bits respectively
    int32_t                     with no padding bits and using 2's complement for negative values
    int64_t                     (provided only if the implementation directly supports the type)

    uint8_t                     unsigned integer type with width of
    uint16_t                    exactly 8, 16, 32 and 64 bits respectively
    uint32_t                    (provided only if the implementation directly supports the type)
    uint64_t

SPECIFIC-USE types:


    intptr_t                    integer type capable of holding a pointer
    uintptr_t                   unsigned integer type capable of holding a pointer 
    size_t                      unsigned integer type capable of holding an array index (same size as uintptr_t)

Pretty much SAY BYE BYE TO [int]! 🙂 …or when going across OSes and 32/64bit platforms you will be playing with this matrix of fun (originally from here):

image2

here are all the confusing mostly-incomplete zip file solutions:

  • zlib THE lib; only does ONE file, knows nothing about .zip containers; gz uses zlib, works on ONE file (the tar file, hence .tar.gz)
  • miniz some google code HACKERY that does exactly what i want (.zip handling in one header file) but DOES NOT WORK – erp, yes it does, id10t
  • minizip a zlib-bundled addon package that allows for working with .zip files
  • boost you can bake zlib into boost but again, it knows nothing about .zip files, MOTHER FRACK
  • libzip ANOTHER library, supposedly handles .zip files – REQUIRES ZLIB DOH, might as well use minizip

In the end, miniz made it pretty easy (once I used it correctly). Remember, a .zip file is a container of compressed files, doh.

That was fun! 🙂

This problem turned out to be due to the very long relative paths that Visual Studio created to the gsoap-generated files. (continued…)

c++11 containers
sorted_vector use when doing lots of unsorted insertions and maintaining constant sort would be expensive
map sorted binary search tree; always sorted by key; you can walk through in sorted order
multimap same as map but allows dupe keys; need for this should be pretty rare
unordered_map hashmap; always sorted by key; additional bucket required for hash collisions; no defined order when walking through
unordered_multimap same as map but allows dupe keys; dupes are obviously in the same bucket, and you can walk just the dupes if needed
set
multiset
unordered_set
unordered_multiset
sets are just like maps, except the key is embedded in the object, great idea
but… they are ruined by the constraint that contained items must be const
but… then redeemed by mutable
You can use mutable on the variable that are not part of the key to remove the const!
This changes the constness of the object from binary (completely const) to logical (constness is defined by the developer)
so… set is an excellent way to achieve both encapsulation and logical const

Final note: using object pointers is the ultimate solution.
The entire object can be dereferenced and accessed then without const issues.
Two requirements: you must make sure yourself that you do not change the key values;
you must create sort functors that dereference the pointers to sort using object contents if needed
(the default sorting will be by pointer address).
The arguably biggest advantage, as a result, is that you can create multiple sets
to reference the same group of objects with different sort funtors to create multiple indices.
OH YEAH! 🙂

I am loving cross-platform development with Qt, it’s robust and logical and leads to amazing native desktop apps. Before getting started, I expected that there would be lots of platform-specific hackery required, and going cross-platform would slow down the end product by 20-30%. But Qt is so reliable, and well-laid-out, and provides so much more than just lowest-common-denominator functionality, that I’m finding it to be much faster than, e.g., developing a desktop app with C# or Java.

Another reason it is giving me leverage: [n] compilers are better than one. (continued…)