kolejność zmiennych podczas kompilacji

Witam
Mam takie pytanie,powiedzmy że mam taki oto kod(oczywiście to jest tylko przykład):

 
int a;
char b;
signed int c;
long int d;
char e;
int f;

Zawsze myślałem że kompilator umieszcza zmienne w pamięci w kolejności według deklaracji,a tu podglądałem debuggerem i wyszło, że np b jest przed a a d po f, itp.
Jak zmusić kompilator, zmienne były umieszczone w pamięci według kolejności ich deklaracji ?
I odpada pomysł np z strukturami, tylko chodzi o to czy jest jakaś dyrektyrwa bądź opcja kompilatora.
Dodam że używam kompilatora Watcom 1.9

Zmienne lokalne w ogóle nie muszą znajdować się w pamięci. Może być np. użyty rejestr procesora, jeżeli optymalizator uzna, że tak będzie lepiej. W związku z tym, nie należy polegać na lokalizacji zmiennych lokalnych na stosie.

Dlaczego nie chcesz skorzystać ze struktury i po co ci to w ogóle?

I odpada pomysł np z strukturami, tylko chodzi o to czy jest jakaś dyrektyrwa bądź opcja kompilatora.
wyłączenie wszelkiej optymalizacji kodu, a w przypadku watcoma dodatkowo zmiana konwencji wywołania funkcji z "register" na "stack", powinny dać taki efekt - ale to jest złe rozwiązanie.

kazurkazur napisał(a):

Jak zmusić kompilator, zmienne były umieszczone w pamięci według kolejności ich deklaracji ?
Język C++ nie oferuje takiego ficzera.

Język C++ nie oferuje takiego ficzera.
Hmm...

static struct
{
  int a;
  char b;
  signed int c;
  long int d;
  char e;
  int f;
} g;

int main()
{
  int &a = g.a;
  char &b = g.b;
  signed int &c = g.c;
  long int &d = g.d;
  char &e = g.e;
  int &f = g.f;
// włala.
}

@Azarien

I odpada pomysł np z strukturami, tylko chodzi o to czy jest jakaś dyrektyrwa bądź opcja kompilatora.

Zapomniałem dodać, że chodzi mi o zmienne globalne a nie lokalne.

Myślę,że dyrektywa będzie rozwiązaniem bardziej eleganckim, poza tym chciałbym lepiej poznać kompilator.

Azarien napisał(a):

Język C++ nie oferuje takiego ficzera.
Hmm...

static struct
{
  int a;
  char b;
  signed int c;
  long int d;
  char e;
  int f;
} g;

int main()
{
  int &a = g.a;
  char &b = g.b;
  signed int &c = g.c;
  long int &d = g.d;
  char &e = g.e;
  int &f = g.f;
// włala.
}

Heh, dobrze wiesz, że to nie to samo :) O ile cytat jest wyrwany z kontekstu o tyle chodzi o zmienne lokalne.

Idąc za twoim przykładem, jeszcze lepiej, jakby g było zmienną lokalną, wtedy osiągniemy pełny efekt (będą wołane konstruktory/destruktory jeśli użyć by złożonych obiektów).

Swoją drogą ciekawym byłaby poniższa konstrukcja a'la anonymous struct (oczywiście jest ona błędna):

void func() {
    struct {
        int a;
        char b;
        signed int c;
        long int d;
        char e;
        int f;
    };
};

kazurkazur napisał(a):

Zapomniałem dodać, że chodzi mi o zmienne globalne a nie lokalne.
Jedyną gwarancją kolejności jest wpakowanie zmiennych do struktury. Kompilator, jeśli w ogóle zdecyduje się umieścić strukturę w pamięci, ma obowiązek ułożyć zmienne w takiej kolejności w jakiej zostały one zadeklarowane. Ale może również dołożyć dodatkowe odstępy między nimi (zawsze identyczne w obrębie tej samej struktury). Dodatkowo jeśli struktura nie dziedziczy po niczym to adresem całej struktury jest adres pierwszego składnika tj. nie może wstawić odstępu na samym początku struktury. Tyle jeśli chodzi o standard C++.

Zapomniałem dodać, że chodzi mi o zmienne globalne a nie lokalne.

Może lepiej wyjaśnij, do czego ci to potrzebne.

Cokolwiek chcesz zrobić, prawdopodobnie zły pomysł. A jeśli już musisz - użyj struktury.

Kompilator nie ma obowiązku układać sobie zmiennych w programie w jakiś konkretny sposób. Na przykład taki kod:

const char *a = "asdfghjk";
char b[] = "qwertyui";
char c[10];

int main()
{
    puts(a);
    puts(b);
    puts(c);
}

Deklaruje trzy zmienne, które (w pliku PE na Windowsie) powinny pójść do zupełnie innych sekcji:

• a jest wskaźnikiem w sekcji danych R/W (.data w przypadku gcc), wskazuje na początek napisu przechowywanego w sekcji danych read-only (.rdata na gcc).
• b jest napisem przechowywanym w całości w sekcji R/W (.data w przypadku gcc)
• c jest napisem (tzn. tablicą charów) niezainicjalizowanym, przechowywanym w sekcji danych niezainicjalizowanych (.bss na gcc)
  Nie ma szans żeby to znalazło się koło siebie w pamięci.

Dowód, tak to wygląda po kompilacji:

mov     eax, off_402000
mov     [esp+10h+var_10], eax
call    puts
mov     [esp+10h+var_10], offset aQwertyui ; "qwertyui"
call    puts
mov     [esp+10h+var_10], offset unk_405068
call    puts

Powiedzmy że poprawne rozwiązanie:

struct stupid_hack
{
	const char *a;
	char b[8];
	char c[10];
} awful_hack = { "asdfghjk", "qweryui" };

int main()
{
    puts(awful_hack.a);
    puts(awful_hack.b);
    puts(awful_hack.c);
}