Pointer-Grundlagen

Die formale Definition

Die Go-Spec definiert Pointer-Typen knapp:

PointerType = "*" BaseType .
BaseType    = Type .

In Prosa: Der Typ *T ist „Pointer auf T" — egal welcher Typ T ist. Aus der Spec:

A pointer type denotes the set of all pointers to variables of a given type, called the base type of the pointer. The value of an uninitialized pointer is nil.

Drei Kernaussagen daraus, die du im Hinterkopf haben solltest:

• Pointer zeigen auf Variablen, nicht auf Werte. Nur eine Variable hat eine eindeutige Adresse. Literale, Rückgaben und nicht-adressierbare Ausdrücke haben keine — mehr dazu im Adress-Operator-Artikel.
• Pointer sind typisiert. *int und *float64 sind unterschiedliche Typen. Du kannst sie nicht implizit ineinander umwandeln. Das ist das Hauptmerkmal, das Go-Pointer von C-Pointer unterscheidet.
• Zero Value ist nil. Eine neu deklarierte Pointer-Variable ohne Initialisierung zeigt auf nichts. Sie zu dereferenzieren erzeugt einen Runtime-Panic.

Das Bild im Speicher

Bevor wir Code schreiben, kurz die Mechanik. Eine Variable belegt einen Speicherbereich; jede Speicherzelle hat eine Adresse. Ein Pointer ist nichts anderes als eine Variable, die so eine Adresse enthält.

        Speicher
+---------+----------+
| Adresse | Inhalt   |
+---------+----------+
| 0x1000  |    42    |   <-- Variable x (int)
| 0x1008  |   ...    |
| 0x1010  |  0x1000  |   <-- Variable p (*int) — enthält Adresse von x
+---------+----------+

 x := 42           // legt 42 an irgendeine Adresse
 p := &x           // p enthält die Adresse von x
 *p                // liefert den Wert an der Adresse, also 42

Die genauen Adressen interessieren dich im Alltag nie — die GC verschiebt Objekte im Heap teilweise auch zur Laufzeit, sodass die konkrete Adresse stabil bleibt, aber ihre Lage im physischen RAM sich ändern kann. Wichtig ist die Semantik: p und x zeigen auf denselben Speicher. Wer *p = 99 schreibt, ändert x.

Auf 64-Bit-Systemen ist ein Pointer 8 Byte groß — egal worauf er zeigt. *int und *[1000000]byte sind beide 8 Byte als Pointer-Variable; der Unterschied ist nur, was beim Dereferenzieren passiert.

Das erste lauffähige Beispiel

package main

import "fmt"

func main() {
    x := 42      // gewöhnliche int-Variable
    var p *int   // Pointer-Variable, momentan nil

    fmt.Println("p:", p)       // <nil>

    p = &x                      // p zeigt jetzt auf x
    fmt.Println("p:", p)       // Adresse, etwas wie 0xc000018088
    fmt.Println("*p:", *p)    // 42 — der Wert hinter dem Pointer

    *p = 99                     // schreibt durch den Pointer in x
    fmt.Println("x:", x)       // 99 — x wurde verändert
}

p: <nil>
p: 0xc000018088
*p: 42
x: 99

Die drei Schlüssel-Symbole — sie kriegen jeweils eigene Detail-Artikel, hier nur kurz:

• *T — Typ. „Pointer auf T". *int, *Config, *[]string.
• &x — Operator. Liefert die Adresse einer Variable. Aus int wird *int.
• *p — Operator. Dereferenziert einen Pointer. Aus *int wird int.

Der Sterne-Konflikt — * ist mal Typ-Konstruktor, mal Dereferenzierungs-Operator — ist gewöhnungsbedürftig, aber lesbar, sobald du dich an die Kontext-Regel gewöhnt hast: Im Typ-Kontext (Deklaration, Funktions-Signatur) baut * einen Pointer-Typ. Im Ausdrucks-Kontext (rechts vom =, in einer Rechenformel) dereferenziert er einen Pointer.

Pointer sind streng typisiert

Aus der Spec:

Two pointer types are identical if they have identical base types.

Konsequenz: Ein *int lässt sich nicht ohne Weiteres in ein *int32 oder *float64 umwandeln. Der Compiler verhindert solche Konvertierungen — du müsstest explizit unsafe.Pointer einschalten, was du in Produktiv-Code praktisch nie willst.

package main

func main() {
    var i int = 42
    var f float64

    pi := &i

    // FEHLER: cannot use pi (variable of type *int) as type *float64
    // var pf *float64 = pi

    // Auch keine implizite Umwandlung ähnlich dimensionierter Typen
    // var p32 *int32 = pi  // FEHLER

    _ = pi
    _ = f
}

Das ist ein bewusster Unterschied zu C, wo void * und Casts üblich sind. Go opfert die Flexibilität für Sicherheit: dein Compiler weiß bei jeder Pointer-Operation, welcher Typ herauskommt, und kann passende Speicher-Layouts und Methoden-Dispatch garantieren.

Eigene Pointer-Typen über Defined Types. Wer wirklich einen „neuen" Pointer-Typ braucht, definiert ihn explizit:

package main

// Ein eigener Typ — distinct von *int
type Handle *int

func use(h Handle) {
    if h != nil {
        println(*h)
    }
}

Handle und *int haben denselben Underlying-Typ, sind aber als benannte Typen unterscheidbar. In der Praxis macht man das selten — bei Stdlib-unsafe-Tricks und manchen C-Interop-Wrappern sieht man es.

Was Go-Pointer NICHT können

Drei Mechaniken, die du in C kennst und die Go bewusst weglässt:

Die Spec lässt die Beschränkungen implizit, weil die fehlenden Operationen schlicht nicht in der Grammatik vorkommen. p+1 ergibt bei einem Pointer einen Compile-Fehler:

package main

func main() {
    arr := [3]int{10, 20, 30}
    p := &arr[0]

    // FEHLER: invalid operation: p + 1 (mismatched types *int and untyped int)
    // q := p + 1

    // Korrekt: Index am Array benutzen
    q := &arr[1]
    println(*q) // 20
}

Wer durch ein Array iterieren will, nutzt range oder einen Slice — nicht Pointer-Arithmetic. Das spart eine ganze Klasse von Bugs (Buffer Overruns, Off-by-one im Pointer-Schritt) und ist nebenbei lesbarer.

Garbage Collection — ohne manuelle Freigabe

In C musst du jedem malloc ein free gegenüberstellen, sonst lekst du Speicher; oder du gibst zu früh frei und produzierst Dangling Pointers. Beides Quellen für Security-Bugs.

Go geht den anderen Weg: solange irgendeine Variable einen Pointer auf das Objekt hält (egal wie indirekt), bleibt das Objekt am Leben. Sobald niemand mehr darauf zeigt, räumt der Garbage Collector irgendwann auf. Es gibt keine free-Funktion, und du darfst dir keine ausdenken.

package main

import "fmt"

type Config struct {
    Host string
    Port int
}

func newConfig() *Config {
    return &Config{Host: "localhost", Port: 8080}
    // Das &Config{...} darf den Funktions-Frame überleben —
    // der Compiler erkennt das (Escape-Analyse) und allokiert auf dem Heap.
}

func main() {
    c := newConfig()
    fmt.Println(c.Host, c.Port)
    // c hält die einzige Referenz. Wenn main endet,
    // wird das Config-Objekt für die GC freigegeben.
}

localhost 8080

In C wäre return &Config{...} ein Klassiker für Use-after-free, weil der Stack-Frame mit dem Funktions-Return zerstört wird. Der Go-Compiler bemerkt, dass der Pointer den Frame verlässt („escaped"), und legt das Objekt deswegen auf dem Heap an. Die Mechanik kannst du dir mit go build -gcflags="-m" anzeigen lassen — sie steht detailliert im Stack-vs-Heap-Bereich der Pointer-Übersicht.

Pointer-Vergleich

Pointer sind mit == und != vergleichbar — entweder mit nil oder untereinander. Aus der Spec:

Pointer values are comparable. Two pointer values are equal if they point to the same variable or if both have value nil.

package main

import "fmt"

func main() {
    a, b := 7, 7
    p1 := &a
    p2 := &a
    p3 := &b

    fmt.Println(p1 == p2) // true  — gleiche Variable
    fmt.Println(p1 == p3) // false — verschiedene Variablen, gleicher Wert
    fmt.Println(p1 == nil) // false

    var pn *int
    fmt.Println(pn == nil) // true
}

true
false
false
true

Wichtige Unterscheidung: p1 == p3 vergleicht Adressen, nicht Werte. Auch wenn *p1 == *p3 (beide enthalten 7), sind die Pointer ungleich. Für Wertvergleich musst du dereferenzieren.

<, <=, >, >= sind auf Pointern nicht definiert. Eine Sortierung von Pointer-Werten als Adress-Reihenfolge ist nicht portabel und ergibt sowieso selten Sinn — wer sortieren will, sortiert die referenzierten Werte.

Pointer als Variablen — die zwei Erzeugungs-Wege

Es gibt zwei idiomatische Wege, einen Pointer in Go zu bekommen: per &-Operator auf einer existierenden Variable oder per new(T)-Built-in:

package main

import "fmt"

type Counter struct{ N int }

func main() {
    // (1) Adress-Operator auf bestehender Variable
    c1 := Counter{N: 0}
    p1 := &c1

    // (2) Adress-Operator auf Composite Literal (häufigster Idiom)
    p2 := &Counter{N: 0}

    // (3) new(T) — selten benutzt, weil &T{} ausdrucksstärker ist
    p3 := new(Counter)
    // p3 zeigt auf eine Counter-Instanz mit Zero Values (N == 0)

    fmt.Printf("%+v %+v %+v\n", *p1, *p2, *p3)
}

{N:0} {N:0} {N:0}

new(T) und &T{} machen praktisch dasselbe — sie allokieren eine T-Instanz mit Zero Values und geben einen Pointer darauf zurück. In der Praxis siehst du fast immer &T{...} mit Composite Literal, weil du dort die Initial-Werte gleich mitgibst. new(T) ist primär in generischem Code nützlich, wenn du nicht weißt, ob T ein Composite-Literal-Syntax hat.

unsafe.Pointer — die ausdrückliche Hintertür

Für die seltenen Fälle, in denen du tatsächlich zwischen unterschiedlichen Pointer-Typen umwandeln musst (typischerweise: C-Interop, Reflection, manuelle Memory-Layout-Tricks), existiert unsafe.Pointer. Sie ist void *-artig, gehört aber bewusst in das Paket unsafe:

package main

import (
    "fmt"
    "unsafe"
)

func main() {
    var x int64 = 0x4142434445464748
    // *int64 -> unsafe.Pointer -> *byte
    // Liest das erste Byte als Byte-Wert
    p := (*byte)(unsafe.Pointer(&x))
    fmt.Printf("%x\n", *p)
}

48

Der Output hängt von der Endianness des Systems ab — auf little-endian Intel/AMD ist das niedrigste Byte zuerst. Das demonstriert genau, warum unsafe.Pointer Plattform-abhängig wird und in normalem Code nichts zu suchen hat.

Drei harte Regeln, falls du unsafe.Pointer doch brauchst (Stdlib-Quelle, runtime, hochoptimierte Libraries):

• Die Konvertierungen sind legal, aber nicht garantiert portabel.
• Pointer-Arithmetic auf unsafe.Pointer geht nur via uintptr — und ist eine eigene Falle, weil uintptr kein Pointer ist und der GC ihn nicht trackt.
• Was im unsafe-Paket lebt, kann sich zwischen Go-Versionen ändern. Stabil ist es nur in den dokumentierten Mustern.

Im Alltag: weglassen.

Weiterführende Ressourcen

Externe Quellen

• Pointer types – Go Language Specification
• Address operators – Go Specification
• Allocation with new – Go Specification
• Effective Go: Allocation with new
• unsafe.Pointer – pkg.go.dev

Verwandte Artikel

• Pointer – Übersicht und didaktische Einführung
• & und * – Adress-Operator und Dereferenzierung im Detail
• Pointer vs. Wert – wann welche Semantik
• nil-Pointer – Zero Value, Defensive Programming
• Pointer als Parameter – Mutation, Performance, Idiomatik
• Structs – Composite Literals und Pointer-Receiver