Jaki jest wynik NULL + int?

#define BUFFER_OFFSET(i) ((char *)NULL + (i))

Technicznie wynik tej operacji jest niezdefiniowany , A makro faktycznie jest błędne. Pozwól mi wyjaśnić:

C definiuje (A C++ podąża za nim), że wskaźniki mogą być rzucane na liczby całkowite, czyli typu uintptr_t, i że jeśli liczba całkowita uzyskana w ten sposób, rzucana z powrotem do oryginalnego typu wskaźnika, z którego pochodzi, da oryginalny wskaźnik.

Wtedy jest arytmetyka wskaźnikowa, co oznacza, że jeśli mam dwa wskaźniki wskazujące ten sam obiekt, mogę wziąć różnica między nimi, wynikająca z liczby całkowitej (typu ptrdiff_t), a liczbą całkowitą dodaną lub odejmowaną do jednego z oryginalnych wskaźników, daje drugą. Definiuje się również, że przez dodanie 1 do wskaźnika, zostanie wyświetlony wskaźnik do następnego elementu indeksowanego obiektu. Również różnica dwóch uintptr_t, podzielonych przez sizeof(type pointed to) wskaźników tego samego obiektu musi być równa odejmowanym wskaźnikom. I wreszcie, wartości {[2] } mogą być dowolne. Mogą to być nieprzezroczyste uchwyty też. Nie muszą być adresami (choć większość implementacji robi to w ten sposób, bo to ma sens).

Teraz możemy spojrzeć na niesławny wskaźnik null. C definiuje wskaźnik, który jest przypisany do for od typu uintptr_u wartość 0 jako nieprawidłowy wskaźnik. zauważ, że w Twoim kodzie źródłowym jest zawsze 0. Po stronie zaplecza, w skompilowanym programie, wartość binarna używana do reprezentacji maszyny może być czymś zupełnie innym! Zazwyczaj jest to nie, ale może być. C++ jest tym samym, ale C++ nie pozwala na tak Ukryte odlewania niż C, więc trzeba rzucić 0 jawnie do void*. Również dlatego, że wskaźnik null nie odnosi się do obiektu i dlatego nie ma dereferenced size wskaźnik arytmetyka jest niezdefiniowana dla wskaźnika null . Wskaźnik null odnoszący się do żadnego obiektu oznacza również, że nie ma definicji sensownego rzucania go do wpisanego wskaźnika.

Więc jeśli to wszystko jest nieokreślone, dlaczego to makro mimo wszystko działa? Ponieważ większość implementacji (czyli kompilatorów) jest wyjątkowo łatwowierna, a programiści leniwi w najwyższym stopniu. Wartość całkowita wskaźnika w większości implementacji jest tylko wartością samego wskaźnika po stronie zaplecza. Więc wskaźnik null jest w rzeczywistości 0. I chociaż arytmetyka wskaźnika na wskaźniku null nie jest sprawdzana, większość kompilatorów po cichu ją zaakceptuje, jeśli wskaźnik ma przypisany typ, nawet jeśli nie ma to sensu. char jest typem "wielkości jednostkowej" C, jeśli chcesz to powiedzieć. Tak więc arytmetyka wskaźnika na cast jest jak artihmetic na adresach po stronie zaplecza.

Mówiąc krótko, po prostu nie ma sensu próbować magii wskaźników z zamierzonym rezultatem, aby być przesunięciem po stronie języka C, to po prostu nie działa w ten sposób.

Cofnijmy się na chwilę i przypomnijmy sobie, co tak naprawdę staramy się zrobić: pierwotny problem polegał na tym, że funkcje gl…Pointer przyjmują wskaźnik jako parametr danych, ale dla wierzchołków Obiekty buforujące chcemy określić offset bajtowy w naszych danych, który jest liczbą. Do kompilatora C funkcja przyjmuje wskaźnik (nieprzezroczystą rzecz, jak się dowiedzieliśmy). Poprawnym rozwiązaniem byłoby wprowadzenie nowych funkcji, szczególnie do użytku z VBOs (powiedzmy gl…Offset – myślę, że zamierzam je wprowadzić). Zamiast tego to, co zostało zdefiniowane przez OpenGL, jest exploitem działania kompilatorów. Wskaźniki i ich ekwiwalent integer są zaimplementowane jako te same wartości binarne reprezentacja przez większość kompilatorów. Musimy więc sprawić, że kompilator wywoła te gl…Pointer funkcje z naszym numerem zamiast wskaźnika.

Więc technicznie jedyną rzeczą, którą musimy zrobić, to powiedzieć kompilatorowi " tak, Wiem, że uważasz, że ta zmienna a jest liczbą całkowitą, i masz rację, a ta funkcja glVertexPointer pobiera tylko void* dla jej parametru danych. Ale zgadnij co: ta liczba całkowita została uzyskana z void*", przez rzucenie jej na (void*), a następnie trzymanie kciuków, że kompilator jest właściwie tak głupio przekazać wartość całkowitą do glVertexPointer.

typedef void (*TFPTR_VertexOffset)(GLint, GLenum, GLsizei, uintptr_t);
TFPTR_VertexOffset myglVertexOffset = (TFPTR_VertexOffset)glVertexPointer;

Teraz możesz używać myglVertexOffset bez robienia głupich rzutów, a parametr offset zostanie przekazany do funkcji, bez niebezpieczeństwa, że kompilator może z nim zadzierać. Jest to również metoda, której używam w moim programy.

To nie jest "NULL + int", to jest "NULL cast to the type 'pointer to char'", a następnie zwiększa ten wskaźnik o i.

I tak, to może być zastąpione przez funkcję - ale jeśli nie wiesz, co ona robi, to dlaczego cię to obchodzi? Najpierw zrozum, co ona robi, potem zastanów się, czy byłaby lepsza jako funkcja.

Dane atrybutów wierzchołków OpenGL są przypisywane przez tę samą funkcję (glVertexAttribPointer) jako wskaźniki w pamięci lub offsety znajdujące się w buforze wierzchołków w zależności od kontekstu.

Makro BUFFER_OFFSET() wydaje się konwertować offset bajtów całkowitych na wskaźnik, aby umożliwić kompilatorowi bezpieczne przekazanie go jako argument wskaźnika. "(Char*)NULL+i " wyraża tę konwersję przez wskaźnik-arytmetykę; wynik powinien być tym samym wzorem bitowym, zakładając sizeof (char)= = 1, bez którego to makro by się nie powiodło.

struct MyVertex { float pos[3]; u8 color[4]; }
// general purpose Macro to find the byte offset of a structure member as an 'int'

#define OFFSET(TYPE, MEMBER) ( (int)&((TYPE*)0)->MEMBER)

// assuming a VBO holding an array of 'MyVertex', 
// specify that color data is held at an offset 12 bytes from the VBO start, for every vertex.
glVertexAttribPointer(
  colorIndex,4, GL_UNSIGNED_BYTE, GL_TRUE,
  sizeof(MyVertex), 
  (GLvoid*) OFFSET(MyVertex, color) // recast offset as pointer 
);