Simple reason: because it’s open source software.
Specific advantages that Scite has over Sublime, because it is OSS:
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):
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…)
