struct WorkbenchHiddenDevicePrefs { UBYTE whdp_Name[0]; /* C String including NUL char */ }; /* New for V47 */ struct WorkbenchTitleFormatPrefs { TEXT wtfp_Format[0]; };
STRUCTURE WorkbenchHiddenDevicePrefs,0 UBYTE whdp_Name ; first char of C String including NULL char LABEL WorkbenchHiddenDevicePrefs_SIZEOF ;--------------------------------------------------------------------------- /* New for V46 */ ;--------------------------------------------------------------------------- STRUCTURE WorkbenchTitleFormatPrefs,0 UBYTE wtfp_Name ; first char of C String including NULL char LABEL WorkbenchTitleFormatPrefs_SIZEOF
UBYTE whdp_Name[0];
UBYTE whdp_Name;
@vojo, post #1
@Krashan, post #6
@vojo, post #7
Ok, dzięki, już rozumiem ideę takiej tablicy, chociaż wydaje mi się to niepotrzebną komplikacją że strony developera, bo jeśli w tym buforze ma być string (sądząc po komentarzach w plikach naglowkowych), to dużo czytelniejszy byłby zwykły wskaźnik na char.To nie jest niepotrzebna komplikacja, bo dzięki temu oszczędzasz 4 bajty (jakie zająłby wskaźnik), jedno adresowanie pośrednie (przy każdym dostępie) i jedną alokację pamięci. Jeżeli wielkość bufora jest znana w momencie alokacji struktury i nie zmienia się aż do dealokacji, to dobre rozwiązanie.
@Krashan, post #8
To nie jest niepotrzebna komplikacja, bo dzięki temu oszczędzasz 4 bajty (jakie zająłby wskaźnik), jedno adresowanie pośrednie (przy każdym dostępie) i jedną alokację pamięci. Jeżeli wielkość bufora jest znana w momencie alokacji struktury i nie zmienia się aż do dealokacji, to dobre rozwiązanie.
@vojo, post #9
Commodore na to nie wpadłoOczywiście, że wpadło, podobne konstrukcje w systemie trafiają się dość często, chociaż nie zawsze w publicznym API. No a gdy się trzeba zmieścić w ROM-ie, to te kilka bajtów jest ważniejsze niż czytelność kodu. Zbędne zaś alokacje pamięci szkodzą zawsze, zwłaszcza w standardowym systemowym alokatorze.
@vojo, post #9