C Interface
Base.@ccall — Macro@ccall library.function_name(argvalue1::argtype1, ...)::returntype
@ccall function_name(argvalue1::argtype1, ...)::returntype
@ccall $function_pointer(argvalue1::argtype1, ...)::returntypeRufen Sie eine Funktion in einer C-exportierten Shared Library auf, die durch library.function_name angegeben ist, wobei library eine String-Konstante oder ein Literal ist. Die Bibliothek kann weggelassen werden, in diesem Fall wird der function_name im aktuellen Prozess aufgelöst. Alternativ kann @ccall auch verwendet werden, um einen Funktionszeiger $function_pointer aufzurufen, wie er beispielsweise von dlsym zurückgegeben wird.
Jeder argvalue zu @ccall wird in den entsprechenden argtype umgewandelt, indem automatisch Aufrufe von unsafe_convert(argtype, cconvert(argtype, argvalue)) eingefügt werden. (Siehe auch die Dokumentation für unsafe_convert und cconvert für weitere Details.) In den meisten Fällen führt dies einfach zu einem Aufruf von convert(argtype, argvalue).
Beispiele
@ccall strlen(s::Cstring)::Csize_tDies ruft die C-Standardbibliotheksfunktion auf:
size_t strlen(char *)mit einer Julia-Variablen namens s. Siehe auch ccall.
Varargs werden mit der folgenden Konvention unterstützt:
@ccall printf("%s = %d"::Cstring ; "foo"::Cstring, foo::Cint)::CintDas Semikolon wird verwendet, um erforderliche Argumente (von denen mindestens eines vorhanden sein muss) von variadischen Argumenten zu trennen.
Beispiel mit einer externen Bibliothek:
# C-Signatur von g_uri_escape_string:
# char *g_uri_escape_string(const char *unescaped, const char *reserved_chars_allowed, gboolean allow_utf8);
const glib = "libglib-2.0"
@ccall glib.g_uri_escape_string(my_uri::Cstring, ":/"::Cstring, true::Cint)::CstringDas String-Literal könnte auch direkt vor dem Funktionsnamen verwendet werden, wenn gewünscht "libglib-2.0".g_uri_escape_string(...
ccall — Keywordccall((function_name, library), returntype, (argtype1, ...), argvalue1, ...)
ccall(function_name, returntype, (argtype1, ...), argvalue1, ...)
ccall(function_pointer, returntype, (argtype1, ...), argvalue1, ...)Rufen Sie eine Funktion in einer C-exportierten Shared Library auf, die durch das Tupel (function_name, library) angegeben ist, wobei jede Komponente entweder eine Zeichenkette oder ein Symbol ist. Anstelle der Angabe einer Bibliothek kann auch ein function_name-Symbol oder eine Zeichenkette verwendet werden, das im aktuellen Prozess aufgelöst wird. Alternativ kann ccall auch verwendet werden, um einen Funktionszeiger function_pointer aufzurufen, wie er beispielsweise von dlsym zurückgegeben wird.
Beachten Sie, dass das Tupel der Argumenttypen ein literales Tupel sein muss und keine Tupel-Variable oder -Ausdruck.
Jeder argvalue, der an den ccall übergeben wird, wird in den entsprechenden argtype umgewandelt, indem automatisch Aufrufe von unsafe_convert(argtype, cconvert(argtype, argvalue)) eingefügt werden. (Siehe auch die Dokumentation für unsafe_convert und cconvert für weitere Details.) In den meisten Fällen führt dies einfach zu einem Aufruf von convert(argtype, argvalue).
Core.Intrinsics.cglobal — Functioncglobal((symbol, library) [, type=Cvoid])Erhalten Sie einen Zeiger auf eine globale Variable in einer C-exportierten Shared Library, die genau wie in ccall angegeben ist. Gibt einen Ptr{Type} zurück, der standardmäßig auf Ptr{Cvoid} gesetzt ist, wenn kein Type-Argument angegeben ist. Die Werte können mit unsafe_load oder unsafe_store! gelesen oder geschrieben werden.
Base.@cfunction — Macro@cfunction(callable, Rückgabetyp, (ArgumentTypen...,)) -> Ptr{Cvoid}
@cfunction($callable, Rückgabetyp, (ArgumentTypen...,)) -> CFunctionGenerieren Sie einen C-aufrufbaren Funktionszeiger aus der Julia-Funktion callable für die angegebene Typ-Signatur. Um den Rückgabewert an einen ccall zu übergeben, verwenden Sie den Argumenttyp Ptr{Cvoid} in der Signatur.
Beachten Sie, dass das Argumenttyp-Tupel ein literales Tupel sein muss und keine Tupel-Variable oder -Ausdruck (obwohl es einen Splat-Ausdruck enthalten kann). Und dass diese Argumente zur Compile-Zeit im globalen Gültigkeitsbereich ausgewertet werden (nicht bis zur Laufzeit verschoben). Ein '$' vor dem Funktionsargument ändert dies, um stattdessen eine Laufzeit-Closure über die lokale Variable callable zu erstellen (dies wird nicht auf allen Architekturen unterstützt).
Siehe Handbuchabschnitt zu ccall und cfunction Verwendung.
Beispiele
julia> function foo(x::Int, y::Int)
return x + y
end
julia> @cfunction(foo, Int, (Int, Int))
Ptr{Cvoid} @0x000000001b82fcd0Base.CFunction — TypeCFunction-StrukturGarbage-Collection-Handle für den Rückgabewert von @cfunction, wenn das erste Argument mit '$' annotiert ist. Wie alle cfunction-Handles sollte es als Ptr{Cvoid} an ccall übergeben werden und wird am Aufrufort automatisch in den entsprechenden Typ konvertiert.
Siehe @cfunction.
Base.unsafe_convert — Functionunsafe_convert(T, x)Konvertiere x in ein C-Argument vom Typ T, wobei der Eingabewert x der Rückgabewert von cconvert(T, ...) sein muss.
In Fällen, in denen convert ein Julia-Objekt in einen Ptr umwandeln müsste, sollte diese Funktion verwendet werden, um diese Umwandlung zu definieren und durchzuführen.
Sei vorsichtig, dass eine Julia-Referenz auf x so lange existiert, wie das Ergebnis dieser Funktion verwendet wird. Dementsprechend sollte das Argument x für diese Funktion niemals ein Ausdruck sein, sondern nur ein Variablenname oder ein Feldverweis. Zum Beispiel ist x=a.b.c akzeptabel, aber x=[a,b,c] ist es nicht.
Das Präfix unsafe bei dieser Funktion weist darauf hin, dass die Verwendung des Ergebnisses dieser Funktion, nachdem das x-Argument für diese Funktion nicht mehr für das Programm zugänglich ist, zu undefiniertem Verhalten führen kann, einschließlich Programmkorruption oder Segfaults, zu einem späteren Zeitpunkt.
Siehe auch cconvert
Base.cconvert — Functioncconvert(T,x)Konvertiere x in einen Wert, der als Typ T an C-Code übergeben werden kann, typischerweise durch Aufruf von convert(T, x).
In Fällen, in denen x nicht sicher in T konvertiert werden kann, kann cconvert, im Gegensatz zu convert, ein Objekt eines Typs zurückgeben, der sich von T unterscheidet, das jedoch für unsafe_convert geeignet ist. Das Ergebnis dieser Funktion sollte gültig gehalten werden (für den GC), bis das Ergebnis von unsafe_convert nicht mehr benötigt wird. Dies kann verwendet werden, um Speicher zuzuweisen, der vom ccall verwendet wird. Wenn mehrere Objekte zugewiesen werden müssen, kann ein Tupel der Objekte als Rückgabewert verwendet werden.
Weder convert noch cconvert sollten ein Julia-Objekt nehmen und es in einen Ptr umwandeln.
Base.unsafe_load — Functionunsafe_load(p::Ptr{T}, i::Integer=1)
unsafe_load(p::Ptr{T}, order::Symbol)
unsafe_load(p::Ptr{T}, i::Integer, order::Symbol)Lädt einen Wert des Typs T von der Adresse des i-ten Elements (1-indiziert), beginnend bei p. Dies entspricht dem C-Ausdruck p[i-1]. Optional kann eine atomare Speicherreihenfolge angegeben werden.
Das Präfix unsafe bei dieser Funktion zeigt an, dass keine Validierung des Zeigers p durchgeführt wird, um sicherzustellen, dass er gültig ist. Wie in C ist der Programmierer dafür verantwortlich, sicherzustellen, dass der referenzierte Speicher nicht freigegeben oder garbage collected wird, während diese Funktion aufgerufen wird. Falsche Verwendung kann zu einem Segfault Ihres Programms führen oder fehlerhafte Antworten zurückgeben. Im Gegensatz zu C kann das Dereferenzieren eines Speicherbereichs, der als anderer Typ zugewiesen wurde, gültig sein, vorausgesetzt, die Typen sind kompatibel.
Das Argument order ist seit Julia 1.10 verfügbar.
Siehe auch: atomic
Base.unsafe_store! — Functionunsafe_store!(p::Ptr{T}, x, i::Integer=1)
unsafe_store!(p::Ptr{T}, x, order::Symbol)
unsafe_store!(p::Ptr{T}, x, i::Integer, order::Symbol)Speichert einen Wert des Typs T an der Adresse des i-ten Elements (1-indiziert), beginnend bei p. Dies entspricht dem C-Ausdruck p[i-1] = x. Optional kann eine atomare Speicherreihenfolge angegeben werden.
Das Präfix unsafe bei dieser Funktion zeigt an, dass keine Validierung des Zeigers p durchgeführt wird, um sicherzustellen, dass er gültig ist. Wie in C ist der Programmierer dafür verantwortlich, sicherzustellen, dass der referenzierte Speicher nicht freigegeben oder garbage collected wird, während diese Funktion aufgerufen wird. Falsche Verwendung kann zu einem Segfault Ihres Programms führen. Im Gegensatz zu C kann das Speichern in einem als anderem Typ zugewiesenen Speicherbereich gültig sein, vorausgesetzt, die Typen sind kompatibel.
Das Argument order ist seit Julia 1.10 verfügbar.
Siehe auch: atomic
Base.unsafe_modify! — Functionunsafe_modify!(p::Ptr{T}, op, x, [order::Symbol]) -> PairDiese führen atomar die Operationen aus, um eine Speicheradresse zu lesen und zu setzen, nachdem die Funktion op angewendet wurde. Wenn dies von der Hardware unterstützt wird (zum Beispiel atomare Inkrementierung), kann dies auf die entsprechende Hardwareanweisung optimiert werden, andernfalls wird die Ausführung ähnlich sein wie:
y = unsafe_load(p)
z = op(y, x)
unsafe_store!(p, z)
return y => zDas unsafe-Präfix bei dieser Funktion zeigt an, dass keine Validierung des Zeigers p durchgeführt wird, um sicherzustellen, dass er gültig ist. Wie in C ist der Programmierer dafür verantwortlich, sicherzustellen, dass der referenzierte Speicher nicht freigegeben oder garbage collected wird, während diese Funktion aufgerufen wird. Falsche Verwendung kann zu einem Segfault in Ihrem Programm führen.
Diese Funktion erfordert mindestens Julia 1.10.
Siehe auch: modifyproperty!, atomic
Base.unsafe_replace! — Functionunsafe_replace!(p::Ptr{T}, expected, desired,
[success_order::Symbol[, fail_order::Symbol=success_order]]) -> (; old, success::Bool)Diese führen atomar die Operationen aus, um eine Speicheradresse auf einen gegebenen Wert zu erhalten und bedingt zu setzen. Wenn von der Hardware unterstützt, kann dies auf die entsprechende Hardwareanweisung optimiert werden, andernfalls wird die Ausführung ähnlich sein wie:
y = unsafe_load(p, fail_order)
ok = y === expected
if ok
unsafe_store!(p, desired, success_order)
end
return (; old = y, success = ok)Das unsafe-Präfix bei dieser Funktion zeigt an, dass keine Validierung des Zeigers p durchgeführt wird, um sicherzustellen, dass er gültig ist. Wie in C ist der Programmierer dafür verantwortlich, sicherzustellen, dass der referenzierte Speicher nicht freigegeben oder garbage collected wird, während diese Funktion aufgerufen wird. Falsche Verwendung kann zu einem Segfault in Ihrem Programm führen.
Diese Funktion erfordert mindestens Julia 1.10.
Siehe auch: replaceproperty!, atomic
Base.unsafe_swap! — Functionunsafe_swap!(p::Ptr{T}, x, [order::Symbol])Diese führen atomar die Operationen aus, um gleichzeitig eine Speicheradresse zu lesen und zu setzen. Wenn dies von der Hardware unterstützt wird, kann es auf die entsprechende Hardwareanweisung optimiert werden, andernfalls wird die Ausführung ähnlich sein wie:
y = unsafe_load(p)
unsafe_store!(p, x)
return yDas unsafe-Präfix bei dieser Funktion zeigt an, dass keine Validierung des Zeigers p durchgeführt wird, um sicherzustellen, dass er gültig ist. Wie in C ist der Programmierer dafür verantwortlich, sicherzustellen, dass der referenzierte Speicher nicht freigegeben oder garbage collected wird, während diese Funktion aufgerufen wird. Falsche Verwendung kann zu einem Segfault in Ihrem Programm führen.
Diese Funktion erfordert mindestens Julia 1.10.
Siehe auch: swapproperty!, atomic
Base.unsafe_copyto! — Methodunsafe_copyto!(dest::Ptr{T}, src::Ptr{T}, N)Kopiere N Elemente von einem Quellzeiger zu einem Ziel, ohne Überprüfung. Die Größe eines Elements wird durch den Typ der Zeiger bestimmt.
Das unsafe Präfix dieser Funktion zeigt an, dass keine Validierung der Zeiger dest und src durchgeführt wird, um sicherzustellen, dass sie gültig sind. Falsche Verwendung kann dein Programm beschädigen oder einen Segfault verursachen, ähnlich wie in C.
Base.unsafe_copyto! — Methodunsafe_copyto!(dest::Array, do, src::Array, so, N)Kopiere N Elemente von einem Quellarray zu einem Zielarray, beginnend am linearen Index so im Quellarray und do im Zielarray (1-indiziert).
Das unsafe Präfix dieser Funktion zeigt an, dass keine Validierung durchgeführt wird, um sicherzustellen, dass N in beiden Arrays im zulässigen Bereich liegt. Falsche Verwendung kann dein Programm beschädigen oder einen Segfault verursachen, ähnlich wie in C.
Base.copyto! — Functioncopyto!(B::AbstractMatrix, ir_dest::AbstractUnitRange, jr_dest::AbstractUnitRange,
tM::AbstractChar,
M::AbstractVecOrMat, ir_src::AbstractUnitRange, jr_src::AbstractUnitRange) -> BEffizient Elemente der Matrix M nach B kopieren, abhängig vom Zeichenparameter tM, wie folgt:
tM | Ziel | Quelle |
|---|---|---|
'N' | B[ir_dest, jr_dest] | M[ir_src, jr_src] |
'T' | B[ir_dest, jr_dest] | transpose(M)[ir_src, jr_src] |
'C' | B[ir_dest, jr_dest] | adjoint(M)[ir_src, jr_src] |
Die Elemente B[ir_dest, jr_dest] werden überschrieben. Darüber hinaus müssen die Indexbereichsparameter die Bedingung length(ir_dest) == length(ir_src) und length(jr_dest) == length(jr_src) erfüllen.
Siehe auch copy_transpose! und copy_adjoint!.
copyto!(dest::AbstractMatrix, src::UniformScaling)Kopiert eine UniformScaling auf eine Matrix.
In Julia 1.0 unterstützte diese Methode nur eine quadratische Zielmatrix. Julia 1.1 fügte Unterstützung für eine rechteckige Matrix hinzu.
copyto!(dest, do, src, so, N)Kopiere N Elemente aus der Sammlung src, beginnend am linearen Index so, in das Array dest, beginnend am Index do. Gib dest zurück.
copyto!(dest::AbstractArray, src) -> destKopiere alle Elemente aus der Sammlung src in das Array dest, dessen Länge größer oder gleich der Länge n von src sein muss. Die ersten n Elemente von dest werden überschrieben, die anderen Elemente bleiben unverändert.
Das Verhalten kann unerwartet sein, wenn ein mutiertes Argument Speicher mit einem anderen Argument teilt.
Beispiele
julia> x = [1., 0., 3., 0., 5.];
julia> y = zeros(7);
julia> copyto!(y, x);
julia> y
7-element Vector{Float64}:
1.0
0.0
3.0
0.0
5.0
0.0
0.0copyto!(dest, Rdest::CartesianIndices, src, Rsrc::CartesianIndices) -> destKopiere den Block von src im Bereich von Rsrc in den Block von dest im Bereich von Rdest. Die Größen der beiden Regionen müssen übereinstimmen.
Beispiele
julia> A = zeros(5, 5);
julia> B = [1 2; 3 4];
julia> Ainds = CartesianIndices((2:3, 2:3));
julia> Binds = CartesianIndices(B);
julia> copyto!(A, Ainds, B, Binds)
5×5 Matrix{Float64}:
0.0 0.0 0.0 0.0 0.0
0.0 1.0 2.0 0.0 0.0
0.0 3.0 4.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0Base.pointer — Functionpointer(array [, index])Holen Sie sich die native Adresse eines Arrays oder Strings, optional an einem bestimmten Ort index.
Diese Funktion ist "unsicher". Seien Sie vorsichtig, um sicherzustellen, dass eine Julia-Referenz auf array existiert, solange dieser Zeiger verwendet wird. Das GC.@preserve Makro sollte verwendet werden, um das array-Argument innerhalb eines bestimmten Codeblocks vor der Garbage Collection zu schützen.
Das Aufrufen von Ref(array[, index]) ist im Allgemeinen vorzuziehen, da es die Gültigkeit garantiert.
Base.unsafe_wrap — Methodunsafe_wrap(Array, pointer::Ptr{T}, dims; own = false)Wickeln Sie ein Julia Array-Objekt um die Daten an der Adresse, die durch pointer angegeben ist, ohne eine Kopie zu erstellen. Der Zeiger-Elementtyp T bestimmt den Array-Elementtyp. dims ist entweder eine Ganzzahl (für ein 1d-Array) oder ein Tupel der Array-Dimensionen. own gibt optional an, ob Julia das Eigentum an dem Speicher übernehmen soll, indem free auf den Zeiger aufgerufen wird, wenn das Array nicht mehr referenziert wird.
Diese Funktion ist als "unsicher" gekennzeichnet, da sie abstürzt, wenn pointer keine gültige Speicheradresse für Daten der angeforderten Länge ist. Im Gegensatz zu unsafe_load und unsafe_store! ist der Programmierer auch dafür verantwortlich, sicherzustellen, dass auf die zugrunde liegenden Daten nicht über zwei Arrays mit unterschiedlichem Elementtyp zugegriffen wird, ähnlich der strengen Aliasregel in C.
Base.pointer_from_objref — Functionpointer_from_objref(x)Erhalten Sie die Speicheradresse eines Julia-Objekts als Ptr. Die Existenz des resultierenden Ptr schützt das Objekt nicht vor der Garbage Collection, daher müssen Sie sicherstellen, dass das Objekt während der gesamten Zeit, in der der Ptr verwendet wird, referenziert bleibt.
Diese Funktion darf nicht auf unveränderlichen Objekten aufgerufen werden, da diese keine stabilen Speicheradressen haben.
Siehe auch unsafe_pointer_to_objref.
Base.unsafe_pointer_to_objref — Functionunsafe_pointer_to_objref(p::Ptr)Konvertiert einen Ptr in eine Objektreferenz. Geht davon aus, dass der Zeiger auf ein gültiges, im Heap zugewiesenes Julia-Objekt verweist. Wenn dies nicht der Fall ist, führt dies zu undefiniertem Verhalten, weshalb diese Funktion als "unsicher" gilt und mit Vorsicht verwendet werden sollte.
Siehe auch pointer_from_objref.
Base.disable_sigint — Functiondisable_sigint(f::Function)Deaktiviert den Ctrl-C-Handler während der Ausführung einer Funktion im aktuellen Task, um externen Code aufzurufen, der möglicherweise Julia-Code aufruft, der nicht unterbrechungssicher ist. Soll mit der do-Block-Syntax wie folgt aufgerufen werden:
disable_sigint() do
# unterbrechungsunsicherer Code
...
endDies ist in Arbeitsthreads (Threads.threadid() != 1) nicht erforderlich, da die InterruptException nur an den Master-Thread gesendet wird. Externe Funktionen, die keinen Julia-Code oder die Julia-Laufzeit aufrufen, deaktivieren automatisch sigint während ihrer Ausführung.
Base.reenable_sigint — Functionreenable_sigint(f::Function)Reaktiviert den Ctrl-C-Handler während der Ausführung einer Funktion. Kehrt vorübergehend die Wirkung von disable_sigint um.
Base.exit_on_sigint — Functionexit_on_sigint(on::Bool)Setze das exit_on_sigint-Flag der Julia-Laufzeit. Wenn false, kann Ctrl-C (SIGINT) als InterruptException im try-Block erfasst werden. Dies ist das Standardverhalten im REPL, bei jedem Code, der über -e und -E ausgeführt wird, und in Julia-Skripten, die mit der -i-Option ausgeführt werden.
Wenn true, wird InterruptException nicht durch Ctrl-C ausgelöst. Das Ausführen von Code bei einem solchen Ereignis erfordert atexit. Dies ist das Standardverhalten in Julia-Skripten, die ohne die -i-Option ausgeführt werden.
Die Funktion exit_on_sigint erfordert mindestens Julia 1.5.
Base.systemerror — Functionsystemerror(sysfunc[, errno::Cint=Libc.errno()])
systemerror(sysfunc, iftrue::Bool)Löst einen SystemError für errno mit der beschreibenden Zeichenkette sysfunc aus, wenn iftrue true ist.
Base.windowserror — Functionwindowserror(sysfunc[, code::UInt32=Libc.GetLastError()])
windowserror(sysfunc, iftrue::Bool)Wie systemerror, aber für Windows-API-Funktionen, die GetLastError verwenden, um einen Fehlercode zurückzugeben, anstatt errno zu setzen.
Core.Ptr — TypePtr{T}Eine Speicheradresse, die auf Daten des Typs T verweist. Es gibt jedoch keine Garantie, dass der Speicher tatsächlich gültig ist oder dass er tatsächlich Daten des angegebenen Typs darstellt.
Core.Ref — TypeRef{T}Ein Objekt, das sicher auf Daten des Typs T verweist. Dieser Typ garantiert, dass er auf gültigen, in Julia zugewiesenen Speicher des richtigen Typs zeigt. Die zugrunde liegenden Daten sind vor der Freigabe durch den Garbage Collector geschützt, solange der Ref selbst referenziert wird.
In Julia werden Ref-Objekte mit [] dereferenziert (geladen oder gespeichert).
Die Erstellung eines Ref auf einen Wert x des Typs T wird normalerweise als Ref(x) geschrieben. Darüber hinaus kann für die Erstellung von Innenzeigern auf Container (wie Array oder Ptr) Ref(a, i) geschrieben werden, um eine Referenz auf das i-te Element von a zu erstellen.
Ref{T}() erstellt eine Referenz auf einen Wert des Typs T ohne Initialisierung. Für einen Bittyp T wird der Wert das sein, was derzeit im zugewiesenen Speicher vorhanden ist. Für einen Nicht-Bittyp T wird die Referenz undefiniert sein, und der Versuch, sie zu dereferenzieren, führt zu einem Fehler: "UndefRefError: Zugriff auf undefinierte Referenz".
Um zu überprüfen, ob ein Ref eine undefinierte Referenz ist, verwenden Sie isassigned(ref::RefValue). Zum Beispiel ist isassigned(Ref{T}()) false, wenn T kein Bittyp ist. Wenn T ein Bittyp ist, wird isassigned(Ref{T}()) immer true sein.
Wenn als ccall-Argument übergeben (entweder als Ptr oder Ref-Typ), wird ein Ref-Objekt in einen nativen Zeiger auf die Daten, auf die es verweist, umgewandelt. Für die meisten T oder wenn es in einen Ptr{Cvoid} umgewandelt wird, ist dies ein Zeiger auf die Objekt-Daten. Wenn T ein isbits-Typ ist, kann dieser Wert sicher verändert werden, andernfalls ist die Mutation strikt undefiniertes Verhalten.
In einem Sonderfall führt das Setzen von T = Any stattdessen zur Erstellung eines Zeigers auf die Referenz selbst, wenn es in einen Ptr{Any} umgewandelt wird (ein jl_value_t const* const*, wenn T unveränderlich ist, andernfalls ein jl_value_t *const *). Wenn es in einen Ptr{Cvoid} umgewandelt wird, gibt es weiterhin einen Zeiger auf den Datenbereich wie für jeden anderen T.
Eine C_NULL-Instanz von Ptr kann als ccall-Ref-Argument übergeben werden, um sie zu initialisieren.
Verwendung in Broadcasting
Ref wird manchmal im Broadcasting verwendet, um die referenzierten Werte als Skalar zu behandeln.
Beispiele
julia> r = Ref(5) # Erstellen Sie einen Ref mit einem Anfangswert
Base.RefValue{Int64}(5)
julia> r[] # Einen Wert aus einem Ref abrufen
5
julia> r[] = 7 # Einen neuen Wert in einen Ref speichern
7
julia> r # Der Ref enthält jetzt 7
Base.RefValue{Int64}(7)
julia> isa.(Ref([1,2,3]), [Array, Dict, Int]) # Referenzwerte während des Broadcastings als Skalar behandeln
3-element BitVector:
1
0
0
julia> Ref{Function}() # Undefinierte Referenz auf einen Nicht-Bittyp, Funktion
Base.RefValue{Function}(#undef)
julia> try
Ref{Function}()[] # Dereferenzieren einer undefinierten Referenz führt zu einem Fehler
catch e
println(e)
end
UndefRefError()
julia> Ref{Int64}()[]; # Eine Referenz auf einen Bittyp verweist auf einen unbestimmten Wert, wenn nicht angegeben
julia> isassigned(Ref{Int64}()) # Eine Referenz auf einen Bittyp ist immer zugewiesen
trueBase.isassigned — Methodisassigned(ref::RefValue) -> BoolÜberprüfen, ob die gegebene Ref mit einem Wert verknüpft ist. Dies ist immer wahr für eine Ref eines Bittyp-Objekts. Gibt false zurück, wenn die Referenz undefiniert ist.
Beispiele
julia> ref = Ref{Function}()
Base.RefValue{Function}(#undef)
julia> isassigned(ref)
false
julia> ref[] = (foobar(x) = x)
foobar (generische Funktion mit 1 Methode)
julia> isassigned(ref)
true
julia> isassigned(Ref{Int}())
trueBase.Cchar — TypeCcharEntspricht dem nativen char c-Typ.
Base.Cuchar — TypeCucharEntspricht dem nativen unsigned char c-Typ (UInt8).
Base.Cshort — TypeCshortEntspricht dem nativen signed short c-Typ (Int16).
Base.Cstring — TypeCstringEin C-ähnlicher String, der aus dem nativen Zeichentyp Cchars besteht. Cstrings sind NUL-terminiert. Für C-ähnliche Strings, die aus dem nativen breiten Zeichentyp bestehen, siehe Cwstring. Für weitere Informationen zur String-Interoperabilität mit C siehe das Handbuch.
Base.Cushort — TypeCushortEntspricht dem nativen unsigned short c-Typ (UInt16).
Base.Cint — TypeCintEntspricht dem nativen signed int c-Typ (Int32).
Base.Cuint — TypeCuintEntspricht dem nativen unsigned int c-Typ (UInt32).
Base.Clong — TypeClongEntspricht dem nativen signed long c-Typ.
Base.Culong — TypeCulongEntspricht dem nativen unsigned long c-Typ.
Base.Clonglong — TypeClonglongEntspricht dem nativen signed long long c-Typ (Int64).
Base.Culonglong — TypeCulonglongEntspricht dem nativen unsigned long long c-Typ (UInt64).
Base.Cintmax_t — TypeCintmax_tEntspricht dem nativen intmax_t c-Typ (Int64).
Base.Cuintmax_t — TypeCuintmax_tEntspricht dem nativen uintmax_t c-Typ (UInt64).
Base.Csize_t — TypeCsize_tEntspricht dem nativen size_t c-Typ (UInt).
Base.Cssize_t — TypeCssize_tEntspricht dem nativen ssize_t c-Typ.
Base.Cptrdiff_t — TypeCptrdiff_tEntspricht dem nativen ptrdiff_t c-Typ (Int).
Base.Cwchar_t — TypeCwchar_tEntspricht dem nativen wchar_t c-Typ (Int32).
Base.Cwstring — TypeCwstringEin C-ähnlicher String, der aus dem nativen Wide-Character-Typ Cwchar_ts besteht. Cwstrings sind NUL-terminiert. Für C-ähnliche Strings, die aus dem nativen Zeichentyp bestehen, siehe Cstring. Für weitere Informationen zur String-Interoperabilität mit C siehe das Handbuch.
Base.Cfloat — TypeCfloatEntspricht dem nativen float c-Typ (Float32).
Base.Cdouble — TypeCdoubleEntspricht dem nativen double c-Typ (Float64).
LLVM Interface
Core.Intrinsics.llvmcall — Functionllvmcall(fun_ir::String, returntype, Tuple{argtype1, ...}, argvalue1, ...)
llvmcall((mod_ir::String, entry_fn::String), returntype, Tuple{argtype1, ...}, argvalue1, ...)
llvmcall((mod_bc::Vector{UInt8}, entry_fn::String), returntype, Tuple{argtype1, ...}, argvalue1, ...)Rufen Sie den LLVM-Code auf, der im ersten Argument angegeben ist. Es gibt mehrere Möglichkeiten, dieses erste Argument anzugeben:
- als Literalzeichenfolge, die IR auf Funktionsebene darstellt (ähnlich einem LLVM
define-Block), wobei die Argumente als aufeinanderfolgende unbenannte SSA-Variablen (%0, %1 usw.) verfügbar sind; - als 2-Elemente-Tupel, das eine Zeichenfolge von Modul-IR und eine Zeichenfolge enthält, die den Namen der aufzurufenden Einstiegspunktfunktion darstellt;
- als 2-Elemente-Tupel, jedoch mit dem Modul, das als
Vector{UInt8}mit Bitcode bereitgestellt wird.
Beachten Sie, dass im Gegensatz zu ccall die Argumenttypen als Tupeltyp angegeben werden müssen und nicht als Tupel von Typen. Alle Typen sowie der LLVM-Code sollten als Literale und nicht als Variablen oder Ausdrücke angegeben werden (es kann erforderlich sein, @eval zu verwenden, um diese Literale zu generieren).
Opake Zeiger (geschrieben als ptr) sind im LLVM-Code nicht erlaubt.
Siehe test/llvmcall.jl für Anwendungsbeispiele.