Take a look at boost's Numeric Conversion library. I think you'll need to define an overflow policy that truncates the source value to the target's legal range (but I haven't tried it). In all, it may take more code than your example above, but should be more robust if your requirements change.

A static_cast is not safer than implicit conversion. However, you might have read that a static_cast is safer than a C cast. That's because it only allows "reasonable" casts. Some examples of a reasonable cast would be between numeric types, void * to some other pointer, base class ptr to derived class ptr. For example:

class Base {};
class D1 : public Base {};
class D11 {};
...
Base *ptr_to_Base(...); // Get from somewhere.
D11 *p = (D11 *) ptr_to_Base; // No compiler error! I need new eyeglasses!
D11 *p2 = static_cast<D11 *>(ptr_to_Base); // This gives you a compiler error.

Note that a static_cast can still allow bad casts, just not "unreasonable" ones:

class D2 : public Base {};
...
Base *b = new D2;
D1 *p3 = static_cast<D1 *>(b); // Wrong, but allowed by compiler.

Unfortunately, no such function exists in the C++ standard library. That leaves a few options:

Option #1: boost::numeric_cast

If you have access to Boost, then boost::numeric_cast should do exactly what you want. It will perform a conversion between two numeric types unless the conversion would go outside the range of the target type. In such cases, a boost::numeric::bad_numeric_cast exception is thrown.

Option #2: gsl::narrow()

Alternatively, gsl::narrow is a good option. I'd consider it preferable to Boost if you are OK with bringing GSL into your project.

Option #3: Roll your own.

If you were curious about implementing your own conversion, you can take a look at The C++ Programming Language 4th Edition by Bjarne Stroustrup (ISBN 978-0321563842).

In Chapter 11.5, he defines a narrow_cast as such:

template<class Target, class Source>
Target narrow_cast(Source v)
{
   auto r = static_cast<Target>(v); // convert the value to the target type
   if (static_cast<Source>(r)!=v)
      throw runtime_error("narrow_cast<>() failed");
   return r;
}

This implementation is quite bare and doesn't go quite as far as Boost's does, but could conceivably be modified to suit your needs.

When you do

static_cast<int>(s1.size()) - s2.size()

You convert s1.size() to a int and then when you subtract s2.size() from it that int is promoted to the same type as s2.size() and then it is subtracted. This means you still have unsigned integer subtraction and since that can't ever be negative it will wrap around to a larger number. It is no different from doing s1.size() - s2.size().

You have the same thing with

static_cast<int>(s1.size() - s2.size())

With the added bonus of possible signed integer overflow which is undefined behavior. You are still doing unsigned integer subtraction so if s1 is smaller than s2 than you wrap around to a large number.

What you need to do is convert both s1.size() and s2.size() to a signed integer type to get singed integer subtraction. That could look like

static_cast<ptrdiff_t>(s1.size())  - static_cast<ptrdiff_t>(s2.size())

And now you will actually get a negative number if s1.size() is less than s2.size().

It should be noted that all of this can be avoided by using less than operator. Your function can be rewritten to be

bool isShorter(const string &s1, const string &s2)
{
    return s1.size() < s2.size();
}

which, IMHO, is much easier to read and understand.

There's gsl::narrow

narrow // narrow<T>(x) is static_cast<T>(x) if static_cast<T>(x) == x or it throws narrowing_error

You must cast to function pointer types (not function types)

thread t1(static_cast<void (*)()>(&hello));
                           ^^^

A function type (eg. void()) is a type that denotes a function by its parameters and return types. However there can be no variables of these types in the program (except function themselves, these are lvalues of function types). However, there can be references to functions or pointers to functions, of which you want to use the latter.

When you don't try to make variables (or temporary objects) of function type (eg. you typedef a function type, or use it as a template parameter), its use is OK. std::function<void()> only uses the parameter to specify its parameters and return type, so its designers decided to use this sleek syntax. Internally, it doesn't try to make variables with that type.

First, understand that those lines are not equivalent.

int* anInt = (int*)aFloat; // is equivalent to

int* anInt = reinterpret_cast<int*>(aFloat); 

What is happening here is that the programmer is asking the compiler to do whatever it can to make the cast.

The difference is important because using static_cast will only ask for a base type that is "safe" to convert to, where reinterpret_cast will convert to anything, possibly by just mapping the wanted memory layout over the memory of the given object.

So, as the "filter" is not the same, using a specific cast is more clear and safe than using the C cast. If you rely on the compiler (or runtime implementation if you use dynamic_cast) to tell you where you did something wrong, by avoid using C cast and reinterepret_cast.

Now that this is more clear, there is another thing: static_cast, reinterpret_cast, const_cast and dynamic_cast are easier to search for.

And the ultimate point: they are ugly. That's wanted. Potentially buggy code, code smells, obvious "tricks" that might generate bugs, are easier to track when it's associated with ugly look. Bad code should be ugly.

That's "by design". And that allows the developer to know where he could have done things better (by totally avoiding casts, if not really needed) and where it's fine but it's "documented" in the code by "marking" it as ugly.

A secondary reason for introducing the new-style cast was that C-style casts are very hard to spot in a program. For example, you can't conveniently search for casts using an ordinary editor or word processor. This near-invisibility of C-style casts is especially unfortunate because they are so potentially damaging. An ugly operation should have an ugly syntactic form. That observation was part of the reason for choosing the syntax for the new-style casts. A further reason was for the new-style casts to match the template notation, so that programmers can write their own casts, especially run-time checked casts.

Maybe, because static_cast is so ugly and so relatively hard to type, you're more likely to think twice before using one? That would be good, because casts really are mostly avoidable in modern C++.

Source: Bjarne Stroustrup (C++ creator)

It's possible to make that work, but not via overloading static_cast<>(). You do so by overloading the typecast operator:

class Square
{
public:
    Square(int side) : side(side) {}
    operator int() const { return side * side; } // overloaded typecast operator
private:
    int side;
};

// ...

// Compiler calls Square::operator int() to convert aSquare into an int
cout << static_cast<int>(aSquare) <<endl;

Beware that overloaded typecast operators more often than not tend to do more harm than good. They make lots of nonsensical implicit cast operations possible. When you read this code snippet below, do you think "a is going to get the area of s"?

Square aSquare;
int a = aSquare; // What the heck does this do?

I certainly don't. This makes way more sense and is much more readable:

Square aSquare;
int a = aSquare.GetArea();

Not to mention that typically you want to be able to access other information about Square, like GetSide() or GetApothem() or GetPerimeter() or whatever. operator int() obviously can return only one int, and you can't have multiple operator int()s as members of a class.

Here's another situation where the operator int() makes code that compiles yet makes no sense whatsoever:

Square s;
if(s > 42) {} // Huh?!

What does it mean for a Square to be greater than 42? It's nonsense, but with the operator int() the code above will compile as Shape is now convertible to an int which can be compared to another int with a value 4.

So don't write typecast operators like that. In fact if you're overloading typecast operators you may want to think twice about what you're doing. There's actually only a few cases where overloading the typecast operator is useful in modern C++ (e.g. the safe bool idiom).

You can only use static_cast if the type you cast and the one you cast to are related, or when the compiler knows how to perform that cast.

Cannot convert Rat to double without a conversion operator

Tells you that there is no conversion operator for Rat that allows the compiler to cast it to double.

A conversion operator would look this way:

struct Rat {
 // …
 operator double() const { 
    // … perform a conversion to double …
 }
 // …
}

Depending on if you want to allow implicit conversion or not, you need to add explicit in front of operator.

Without explicit you can write:

double x = Rat(2,3);

With explicit you need a cast:

double x = static_cast<double>(Rat(2,3));

Normally explicit is preferred, to avoid accidental casts.

This will do it:

#include <iostream>
using namespace std;

struct C{int n;};
struct A{int n;};
struct B : A, C{};

int main()
{
    B b;
    B* pb = &b;
    cout << static_cast<C*>(pb) << "\n";
    cout << reinterpret_cast<C*>(pb);
}

Note the differences in the two addresses.

I've built some multiple inheritance here, and have put an explicit member in the base classes, in order to circumvent possible optimisation of empty base classes to size zero.

See https://ideone.com/QLvBku