Simple reason: because it’s open source software.

Specific advantages that Scite has over Sublime, because it is OSS:

  • It runs on Pi (because, like, WE HAVE THE SOURCE)
  • With a solarized setup, it’s just as pretty
  • No NAG SCREENS OMG kill me now

Sublime is great.  Scite is better.

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

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

A new article describing my cross-platform development environment setup is now on the wiki

Updated with more detail on 2011/09/18…

I’m using the cross-platform Qt C++ library to write an app for linux, OS X, and Windows. Qt source can be compiled to a wide range of systems and devices, with two obvious omissions that are not likely to be filled any time soon: iPhone and Android. I know I am going to need client code on these devices, and I know that the client code is going to be extremely similar to the Qt client code. How do you design for this?

Applying the concept of separation of concerns, you design your classes into layers. The base layer consists of high level concept classes that perform all fundamental actions using generic data types. Then, the derived layer is used to get the job done, using the most useful and powerful lower level tools at your disposal. Push everything you can into the base layer, until you hit the limit of non-portable information and data types. It’s a beautiful way to code.

To be more specific, in my case, the base class layer will be using C++, including the STL, which gives me tons of power. I will pull in boost if even more horsepower is needed. The derived class layer for the first round of clients will be Qt-powered. The Qt library has a massive amount of real-world usefulness, supporting everything from http to video playback. I have not gotten to the iPhone and Android clients yet so the whole concept may change, but here’s my current plan. The iPhone code will be Objective C with the C++ base class layer linked in. I will attempt to incorporate the C++ base class layer into the Android code using the NDK.

Here’s a quick example of the layer approach, in this case used to quickly set up profiling using Qt’s QTime class at the lower level: (continued…)