квалификатор register

А почему бы и нет? register - это просто совет компилятору, который он вправе проигнорировать, особенно если видит, что дальше ты берёшь указатель на неё.

Собственно, ты чего добиться хочешь? Может это и отступление от стандарта, но к проблемам не приведёт совершенно точно.

у меня не компилирует:

$ cat tst.c  
main()
{
    register i;

    (void)&i;
}

$ gcc -O0 -ansi -pedantic tst.c 
tst.c: In function 'main':
tst.c:5: error: address of register variable 'i' requested

$ gcc --version                  
gcc (GCC) 4.1.2 20060628 prerelease (NetBSD nb2 20060711)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> А почему бы и нет? register - это просто совет компилятору, который он вправе проигнорировать

стандарт запрещает:

The operand of the unary & operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit- field and is not declared with the register storage-class specifier.

Ну, я не спорю, но в чём проблема-то?

> Ну, я не спорю, но в чём проблема-то?

у меня проблемы нет, я register никогда не использую:)

но я знаю людей готовых тут же привести кого угодно к void за нарушение стандартов

суть требования о том что запрещено брать адрес у register переменной -- видимо в том что с одной стороны: требование чтобы компилятор просматривал весь код и если берется адрес не размещал в регистре -- это требование слишком жесткое для маленьких и быстрых компиляторов. А с другой стороны: если не требовать просматривать весь код, то получится что одни компиляторы успешно скомпилируют код на который будет ругаться другой компилятор -- это тоже нехорошо. Лучше однозначно запретить

Ну, warning тут не помешал бы, конечно...

Именно warning тут и появляется, даже без -pedantic:

> cat 1.c
int main(void)
{
        register int n;
        int m;

        m = (int)&n;

        return m;
}
> gcc 1.c
1.c: In function `main':
1.c:6: warning: address of register variable `n' requested
> gcc -pedantic-errors 1.c
1.c: In function `main':
1.c:6: error: address of register variable `n' requested
> gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
> 

я объявлял только одну переменную register, так что компилятор не может ее проигноировать. Я правильно понял,что если я беру адрес от переменной объявленной с квалификатором register,то компилятор не размещает ее на регистрах?варнинг у меня выводится даже без всяких педантик и анси,но тем не менее программа успешно компилируется и выводит адрес.

> Я правильно понял

Да, конечно.

> Именно warning тут и появляется, даже без -pedantic: gcc version 3.4.6

в 4-й ветке это пофиксили

А вот в C++ это совершенно валидный код.

а как реализуется в С++ взятие адреса от переменной размещенной на регистрах?

> а как реализуется в С++ взятие адреса от переменной размещенной на регистрах?

Так же как и везде - никак. :) Просто квалификатор register в данном случае игнорируется. Собственно, как и положено с ним поступать в любом случае.

"Собственно, как и положено с ним поступать в любом случае."

прошу прощение за мое тупоумие, так что объявляй переменную с квалификатором register ,а GCC мое пожелание в ЛЮБОМ случае игнорирует(как в С так и в С++)?

Я за конкретный компилятор сказать не могу, но ты сам подумай, что есть квалификатор register? Это подсказка компилятору в области, в которой он лучше тебя разбирается - в оптимизации. Это атавизм, тяжёлое наследие царского режима, это есть времён, когда оптимизация в C-компиляторах была в зачаточном состоянии. Любой современный компилятор и без тебя разберётся, что держать в регистрах и когда.

Постольку поскольку это никак не влияет на логику выполняемой программы, компилятор безусловно может это проигнорировать, если ему это покажется целесообразным. И никакой стандарт ему в этом не помешает, если тесты будут работать точно так же, но быстрее.