Wollt nur mal wissen, ob das geht (UB oder nicht):

struct Context
{
	OVERLAPPED overlapped;
	unsigned int type;
};

OVERLAPPED* g_overlapped;

void Set(OVERLAPPED* overlapped)
{
	g_overlapped = overlapped;
}

void Get(OVERLAPPED** overlapped)
{
	*overlapped = g_overlapped;
}

int main()
{
	{
		Context* context = new Context;

		cout << context << endl; // 00345268

		Set((OVERLAPPED*)context);
	}

	{
		Context* context;

		Get((OVERLAPPED**)&context); // Diese Casterei ist angeblich Blödsinn, funktioniert aber! Ich bekomme also wieder die richtige Adresse (Visual Studio 2008)

		cout << context << endl; // 00345268 identisch
	}
}

Es wird 2x die selbe Adresse ausgegeben. Hintergrund ist, dass ich GetQueuedCompletionStatus richtig benutzen möchte. Aber bin mir nicht ganz sicher, ob das so OK ist.
Man könnte Set() mit zB. WSARecv() vergleichen und Get() mit GetQueuedCompletionStatus().

Wie kommst du darauf, dass es Blödsinn sein soll? (klar casting sollte man vermeiden, wenn möglich, aber oftmals in Verbindung mit anderen API's ist man gezwungen die zu benutzen; insbesondere bei der WinAPI).

Zunächst gings um ein vererbtes OVERLAPPED, dann aber um einen Member.

The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an
object type, or a pointer to a function type and the result is an lvalue referring to the object or function to
which the expression points.

Das verletzt du mit der dereferenzierung, weil der Ausdruck, den du dereferenzierst nicht auf ein Objekt des Typen zeigt, sondern auf etwas anderes (in dem Falle wieder ein Zeiger).

Wenn du es so machst, wie hustbaer zeigt, dann bist du da allerdings auf der sicheren Seite. Der cast nach Context ist dann wieder sicher Ok.

Wahrscheinlich wird deine Variante schon meistens gehen, aber es ist halt trotzdem nicht sicher.
Dass die Dereferenzierung nicht erlaubt ist macht auch Sinn, weil ein Zeiger ist nie gefährlich bis er einmal benutzt wird und dazu muss er immer dereferenziert werden und dann muss der Typ stimmen, sonst hast du den Salat.

Das ist laut Standard nicht OK.
Dass es mit den meisten Implementierungen trotzdem funktionieren wird, ist eine andere Sache. Es gibt auch einige APIs die sich darauf verlassen dass soetwas funktioniert, z.B. die COM Funktionen unter Windows (CoCreateInstance, IUnknown::QueryInterface uvm.). Nur deswegen muss man es ja nicht nachmachen.

Warum es nicht OK ist: Zeiger auf unterschiedliche Typen können unterschiedlich aussehen.

Stell dir eine C++ Implementierung für eine 32 Bit CPU vor, die nur 32 Bit Worte einzeln adressieren kann. (BTW: So eine CPU kann dann, trotz beschränkung auf 32 Bit, 16 BG RAM adressieren.)
Wie soll jetzt ein Zeiger auf ein "char" aussehen? Nun, laut C++ Standard ist es OK wenn ein "char" 32 Bit hat, also könnte eine C++ Implementierung einfach definieren: char, short und int haben alle 32 Bit - und die Sache wäre geritzt.
Bloss verschwendet das ziemlich viel Speicher. Also verwendet die C++ Implementierung 8 Bit grosse chars, und verwendet zwei 32 Bit Wörter für char Zeiger: ein Wort für die Adresse des 32 Bit Wortes in dem sich der "char" befindet, und noch ein Wort für die Nummer des "char" in diesem Wort (0-3).

Ebenso sind dann Zeiger auf short 2 Worte gross, bzw. auch Zeiger auf alle Typen deren Alignment kleiner 4 Byte ist. Also ggf. auch Structs oder Klassen.

Angenommen OVERLAPPED wäre 2 Byte gross. Ein OVERLAPPED Zeiger würde dann aus 2 Worten bestehen.
Context enthält nun aber zusätzlich zu einem OVERLAPPED Member noch einen int. Nehmen wir an der int hat die üblichen 4 Byte, dann braucht ein "Context" min. 6 Byte. Sagen wir weiter die C++ Implementierung definiert dass alles was zwischen 5 und 7 Byte gross ist, mit Padding auf 8 Byte "aufgewüllt" wird. sizeof(Context) ist also 8, und alignof(Context) wäre sagen wir 4.
Und schwupps, ein "Zeiger auf Context" braucht nur mehr aus einem Wort zu bestehen (da alignof(Context) ja 4 ist, muss das 2. Wort immer 0 sein, und kann daher weggelassen werden).

Resultat: ein "Zeiger auf OVERLAPPED" (T*) und ein "Zeiger auf Context" (U*) sehen im Speicher ganz unterschiedlich aus. Daher kann man auch nicht einen T** in einen U** casten, und erwarten, dass dabei etwas sinnvolles rauskommt. Das wäre wie einen std::vector<char>* in einen std::string* zu casten.

Also: Für POD-Structs (und auch nur für die) ist garantiert, dass die Speicheradresse des gesamten Structs und die seines ersten Members identisch sind - padding kommt nicht am Anfang eines structs. Dieser Umstand wird in C gern genutzt, um objektorientierte Vererbung per pointer punning nachzustellen - genau das, was du da vorhast. Im Standard:

ISO/IEC 14882:2003 9.2 (17) schrieb:

A pointer to a POD-struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa. [Note: There might therefore be unnamed padding within a POD-struct object, but not at its beginning, as necessary to achieve appropriate alignment. ]

Natürlich musst du aber wie ein Adler darauf achten, dass du diesen Zeiger, wenn du ihn zurückcastest, nicht in einen Typ zurückcastest, der mit dem gespeicherten nicht Layout-kompatibel ist. Layout-Kompatibilität definiert wie folgt:

ISO/IEC 14482:2003 9.2 (14-16) schrieb:

14 Two POD-struct (clause 9) types are layout-compatible if they have the same number of nonstatic data members, and corresponding nonstatic data members (in order) have layout-compatible types (3.9).

15 Two POD-union (clause 9) types are layout-compatible if they have the same number of nonstatic data members, and corresponding nonstatic data members (in any order) have layout-compatible types (3.9).

16 If a POD-union contains two or more POD-structs that share a common initial sequence, and if the POD-union object currently contains one of these POD-structs, it is permitted to inspect the common initial part of any of them. Two POD-structs share a common initial sequence if corresponding members have layout-compatible types (and, for bit-fields, the same widths) for a sequence of one or more initial members.

Und als ob das noch nicht fummelig genug wäre, gibt es strict-aliasing-Regeln nach 3.10 (15):

ISO/IEC 14882:2003 3.10 (15) schrieb:

If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined ⁴⁸⁾:

— the dynamic type of the object,
— a cv-qualified version of the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,
— an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union),
— a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
— a char or unsigned char type.

⁴⁸⁾ The intent of this list is to specify those circumstances in which an object may or may not be aliased.

Das ist für den Optimierer wichtig. Beispielsweise darf der in einer Funktion der Form

void foo(bar *p, baz *q) {
  // ...
}

mit zwei POD-Typen bar und baz davon ausgehen, dass p und q nicht auf das gleiche Objekt zeigen. Das kann in Verbindung mit type punning, wenn man nicht sehr vorsichtig ist, zu sehr langen und frustrierenden Debugging-Sessions führen.

Insgesamt bedeutet das beispielsweise:

struct foo {
  OVERLAPPED o;
  int x;
};

struct bar {
  OVERLAPPED o;
  short x;
};

// ...

foo f;
OVERLAPPED *p = reinterpret_cast<OVERLAPPED*>(&f);
bar *q = reinterpret_cast<bar*>(p);

q->o; // Undefiniert!

// Aber:
union baz { foo f; bar b; } *r = reinterpret_cast<baz*>(p);

r->b.o; // OK
r->b.x; // Undefiniert!

bar *s = &r->b;
s->o; // Undefiniert!

foo *t = &r->f;
t->o; // OK

Das ganze ist natürlich ein Wespennest, dass man am besten durch eine vernünftige Klassenhierarchie vollständig umgeht. Spricht etwas dagegen, einen Zeiger auf eine Basisklasse zu speichern und damit zu arbeiten? Dann kriegst du später auch keine Probleme damit, den Kram wieder zu löschen - momentan habe ich Schwierigkeiten zu sehen, wie du g_overlapped in definierter Weise wieder loswerden willst.

Context* context;
Get((OVERLAPPED**)&context);

Warum macht man sowas?

Context* context;
Get(&((OVERLAPPED*)context));

Das wäre doch genau das, was man oben erreichen will, nur dass das Verhalten
definiert ist.

Oder sehe ich das falsch?

So ganz verstehe ich es derzeit leider noch nicht. Besonders die Beispiele von @seldon ...

Da ich eh nur mit Windows arbeite, könnte ich es dann doch so stehen lassen.

@?????
error C2102: '&' requires l-value

int* answer_to_the_universe = &42;

Wird nicht funktionieren, du musst 42 in einer Variablen Speichern.

Context* context;
Get((OVERLAPPED**)&context);

Das ist laut Standard nicht OK.
Dass es mit den meisten Implementierungen trotzdem funktionieren wird, ist eine andere Sache. Es gibt auch einige APIs die sich darauf verlassen dass soetwas funktioniert, z.B. die COM Funktionen unter Windows (CoCreateInstance, IUnknown::QueryInterface uvm.).

So, ich muss mich hier mal selbst korrigieren.
CoCreateInstance etc. sind vollkommen OK, so lange man sie richtig verwendet.
OK:

void* isv = 0;
HRESULT hr = CoCreateInstance(...., &isv);
ISomething* is = static_cast<ISomething*>(isv);

Nicht OK:

ISomething* is = 0;
HRESULT hr = CoCreateInstance(...., reinterpret_cast<void**>(&is));

Die API an sich ist also in Ordnung, nur die Art wie sie meistens verwendet wird nicht.

Interessieren würde mich, ob es mit VS2008 definiert ist.

Wieso willst du es unbedingt so lassen? Schreib es um, so dass du kein undefiniertes Verhalten verwenden musst, anstatt dir den Kopf darüber zu zerbrechen ob eine bestimmte Implementierung das Verhalten definiert.

void* isv = 0;
HRESULT hr = CoCreateInstance(...., &isv);
ISomething* is = static_cast<ISomething*>(isv);

Wer Schreibarbeit sparen will, benutzt einen kleinen Proxy:

template<typename T>
class APIfy
{
public:
    APIFy(T*& p) : p_( p ), v_( p ) {}
    ~APIFy() { p_ = static_cast< T* >( v_ ); }
    void** operator() { return &v_; }
private:
    void operator=(APIfy&);
    T*& p_;
    void* v_;
};
template <typename T>
APIfy<T> apify(T*& p) { return APIfy<T>( p ); }

...

ISomething* is = 0;
HRESULT hr = CoCreateInstance(...., apify(is));

Vorteil hier, dass man ggf. bereits vorhandenen Code durch einfaches Suchen&Ersetzen korrigieren kann.