@mateusz_s, post #29

typedef union _tPixel {
  struct {
    UBYTE Pad;
    UBYTE R;
    UBYTE G;
    UBYTE B;
  };
  ULONG Value; 
} tPixel;

• Odpowiedz

@teh_KaiN, post #31

typedef struct _RGB { UBYTE Alpha, Red, Green, Blue; } RGB;

RGB data[5], yellow = { 0xff, 0xff, 0xff, 0x00 };
RGB *dest, *src = &data[0];

*dest++ = *src;
*dest++ = yellow;

• Odpowiedz

@Artur Jarosik, post #30

• Odpowiedz

@teh_KaiN, post #31

• Odpowiedz

@mateusz_s, post #34

• Odpowiedz

@Hexmage960, post #35

• Odpowiedz

@teh_KaiN, post #36

union
{
	struct { UBYTE r, g, b; } rgb;
	ULONG value;
};

• Odpowiedz

@Hexmage960, post #37

• Odpowiedz

@Hexmage960, post #37

• Odpowiedz

@michal_zukowski, post #39

• Odpowiedz

@Hexmage960, post #40

• Odpowiedz

@stefkos, post #41

union attrib
{
	UWORD cost;
	ULONG weight;
};

union attrib *attr;

enum
{
	COST,
	WEIGHT
};

switch (type)
{
	case COST: printf("Cena samochodu: %d\n", attr->cost); break;
	case WEIGHT: printf("Waga samochodu: %ld\n", attr->weight); break;
}

• Odpowiedz

@Hexmage960, post #35

• Odpowiedz

@Hexmage960, post #37

• Odpowiedz

@Hexmage960, post #42

• Odpowiedz

@orila, post #45

Zgodziłbym się z tym, gdyby operacja przypisania była możliwa:

union Color
{
    struct RGB { UBYTE a, r, g, b; } rgb;
    ULONG val;
};

union Color color = 0x01020304;

Co jak unia ma trzy lub więcej składowych?

Jeżeli chcemy osiągnąć efekt szybkiego zapisu 32-bitowego z zachowaniem cech struktury, bezpieczniej jest skorzystać z kopiowania struktury i zostawić kompilatorowi optymalizację:

struct RGB *mem, value = *mem++;

Sprawdziłem i pod VC++ przerabia to na dwa polecenia asemblera na 32-bitowym słowie (DWORD) - jeden odczytuje do rejestru, drugi zapisuje.

W przypadku gdy zrzutujemy na wskaźnik do ULONG - uzyskamy coś podobnego jak kopiowanie struktury, ale jest mniej bezpieczne. W przypadku kopiowania struktury RGB, mamy pewność, że dane zostaną skopiowane właściwie niezależnie od rozmiaru struktury.

Możemy też trzymać piksele w ULONG i porobić makra Red(c), Green(c), Blue(c), Alpha(c), jeżeli znamy format pikseli, ale to chyba mniej wygodne.

Ostatnia aktualizacja: 12.03.2021 21:03:27 przez Hexmage960

• Odpowiedz

@Hexmage960, post #46

• Odpowiedz

@orila, post #47

OK, unia może mieć nawet kilka składowych o identycznych typach, wskaźniki albo zagnieżdżone struktury.

Przyszedł mi dziś do głowy przykład: Unia przechowuje dokładnie jedną figurę.

Te struktury są niekompatybilne i nadal uważam, że w unii można korzystać tylko z jednej składowej równocześnie.

Co do zapisu w rejestrach sprzętowych to OK, ale podejrzewam że i tutaj składowe się wykluczają. Jeśli mają jakieś części wspólne (np. właśnie typ zawartości unii) to i tak wyprowadzamy je poza unię.

union Figura
{
	struct Prostokat { int a, b; } *p;
	struct Trojkat { int a, h; } *t;
	struct Okrag { int r; } *o;
};

long pole(int typ, union Figura *f)
{
	if (typ == PROSTOKAT)
		return(f->p->a * f->p->b);
	else if (typ == TROJKAT)
		return(f->t->a * f->t->h * 0.5);
	else if (typ == OKRAG)
		return(PI * f->o->r * f->o->r);
	return 0;
}

Ostatnia aktualizacja: 12.03.2021 21:57:33 przez Hexmage960

• Odpowiedz

@Hexmage960, post #48

• Odpowiedz

@orila, post #49

OK, zgoda. Rzeczywiście zetknąłem się całkiem niedawno z taką unią o nazwie REGS.

http://www.delorie.com/djgpp/doc/libc/libc_486.html

I wygląda na to, że masz rację co do takiego zastosowania unii. Ciekawym jak to się przekłada na format pikseli, ale pewnie dokładnie w taki sam sposób (4 bajty/1 długie słowo).

Ostatnia aktualizacja: 12.03.2021 22:28:17 przez Hexmage960

• Odpowiedz

@Hexmage960, post #48

• Odpowiedz

@Artur Jarosik, post #30

• Odpowiedz

@mateusz_s, post #52

• Odpowiedz

@Artur Jarosik, post #53

• Odpowiedz

@mateusz_s, post #54

• Odpowiedz

@mateusz_s, post #55

• Odpowiedz

@michal_zukowski, post #56

• Odpowiedz