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):

I’m a cross-platform developer, with about 17 different development environments. Most projects have a remote central team repository. git lets me cast my code out to all my local locations and effortlessly remained synced with the team repo. In addition, I can work exclusively in my local repos, as long as I need to, without touching the team repo until I’m ready to push my stuff to it. I’ve refined my process down to just the right number of branches to accomplish this. Here’s my git bliss:

First, set up a local centralized repo:

ssh me@my-central-repo-server
git clone ssh://me@the-team-repo/big-project
cd big-project
git branch daily_grind # create working branch but do NOT check it out

Next, set up a [git merge-to] command (huge THANKS to this gist):

emacs .git/config
  [alias]
    merge-to = "!gitmergeto() { export tmp_branch=`git branch | grep '* ' | tr -d '* '` && git checkout $1 && git merge $tmp_branch && git checkout $tmp_branch; unset tmp_branch; }; gitmergeto"

Now we can set up a clone in many new locations – repeat this on each dev box:

ssh me@my-laptop
git clone ssh://me@my-central-repo-server/big-project
cd big-project
git checkout -b daily_grind origin/daily_grind

This location is now a work site. Work in the daily_grind branch. Always pull before you get started working, and push when done:

ssh me@my-laptop
git pull
# work work work!
git commit -a
git push

When you are ready to share with the team, all your commits from all your dev locations will be in your central repo, in the daily_grind branch. Just merge your work with the team’s:

ssh me@my-central-repo-server
git pull # to get the team's latest
git merge daily_grind # to merge in your latest
# resolve any conflicts
git push # to push your changes to the team
git merge-to daily_grind # to push team changes to your work repo

If there were any team changes, you’ll get them in your local repos the next time you pull.

And away we go.