[c] как в макрос передать макрос?

apl13

$ cat twc.c

#define TWICE(x) x, x

#define FOUR_TIMES(x) TWICE(TWICE(x

#define SIXTEEN_TIMES(x) FOUR_TIMES(FOUR_TIMES(x



char a[] = {SIXTEEN_TIMES('a')};



$ gcc -E twc.c

# 1 "twc.c"

# 1 "<built-in>"

# 1 "<command line>"

# 1 "twc.c"









char a[] = {twc.c:5:30: macro "TWICE" passed 4 arguments, but takes just 1

TWICE, TWICE};

Неохота четыре раза писать TWICE там, где можно два раза написать FOUR_TIMES. :crazy:

vall

zurg:/tmp$ cat 1.c 

#define TWICE(x) x, x

#define FOUR_TIMES(x) TWICE(x TWICE(x)

#define EIGHT_TIMERS(x) FOUR_TIMES(x FOUR_TIMES(x)

#define SIXTEEN_TIMES(x) EIGHT_TIMERS(x EIGHT_TIMERS(x)





char a[] = {SIXTEEN_TIMES('a')};

zurg:/tmp$ gcc -E 1.c

# 1 "1.c"

# 1 "<built-in>"

# 1 "<command-line>"

# 1 "1.c"

char a[] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a'};

apl13

Да это понятно, раньше я так и делал.
Дело в том, что для определения SIXTY_FIVE_THOUSAND_FIVE_HUNDRED_THIRTY_SIX_TIMES потребуется шестнадцать шагов - а могло бы пять...

vall

char a[] = {[0 ... 65535] = 'a'};

apl13

char a[] = {[0 ... 65535] = 'a'};
Гы. :ooo:
Это в каком стандарте появилось?
(gcc 3 проглотил, да. Я от него не ждал.)

vall

хз. может c99, а может гнутое расширение.

Vlad77



#define TWICE(x...) x, x

#define FOUR_TIMES(x) TWICE(TWICE(x

#define SIXTEEN_TIMES(x) FOUR_TIMES(FOUR_TIMES(x

char a[] = {SIXTEEN_TIMES('a')};

localhost ~/test $ gcc -E macro.c
# 1 "macro.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "macro.c"
char a[] = {'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a'};

apl13

Ох, блин! :ooo: А когда появились variadic marcros?

apl13

А.
Variable-argument macros were introduced in the ISO/IEC 9899:1999 (C99) revision of the C Programming Language standard in 1999.
Ну, короче, тоже новомодная хрень.

Vlad77

Ох, блин! :ooo: А когда появились variadic marcros?
Рекомендую к изучению: http://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html
а также окрестные
PS или ты вообще про variadic marcros? Давным-давно уже в gcc.

pitrik2

Ну, короче, тоже новомодная хрень.
99 год, прошлый век, 10 лет тому назад
это новомодная хрень?

Vlad77

Ты знаешь учебник, покрывающий С99, с уровнем признания K&R?

vall

iso9899-c99.pdf там не такие уж и большие изменения.

elenangel

а Fillchar(a,sizeof(a'a') на сях отсутствует или это уже не модно?

Dasar

а Fillchar(a,sizeof(a'a') на сях отсутствует или это уже не модно?
это будет выполнено во время исполнения, а всё предыдущее было при компиляции

apl13

Ты memset, что ли, имеешь в виду? Я привык вычисления делать на этапе инициализации. int main {FILE *f = fopen("filename.ext", "r"); unsigned char a[4] = {'\0'}; size_t nread = (f ? fread(a, sizeof(char 4, f) : 0); long result = (long)a[0] << 24 + (long)a[1] << 16 + (long)a[2] << 8 + (long)a[3]; return printf("%d\n", result) * fclose(f);}

vall

с другой стороны memset быстрее чем чтение с диска

Dasar

с другой стороны memset быстрее чем чтение с диска
это проще одних махом решить через обработку проги exe-packer-ом.

vall

тогда страницы кода не будут шарится между экземплярами

tokuchu

это проще одних махом решить через обработку проги exe-packer-ом.
Который при распаковке тоже сделает не быстрее, чем memset? :)

vall

не, это будет специальный пакер который сделает memset

elenangel

memset,
да, я именно его имел ввиду, но не мог вспомнить.

elenangel

опять вечная дилемма: что экономить - такты или байты?
мне кажется что в данном случае лучше потратить примерно 16384 такта (на 32-разрядной машине чем 64к памяти (целых четыре страницы шестнадцать страниц!)
в идеале оно должно соптимизироваться во что-то вроде
 


   mov ecx, 16384

   mov edi, offset a

   mov eax, 'aaaa'

   rep stosd

upd
и да, в случае очень большого куска заливаемой памяти возможно будет распараллелить этот процесс на пару-четверку ядер =)

vall

64к памяти (целых четыре страницы!)
orly?

Andbar

в идеале оно должно соптимизироваться во что-то вроде
не факт, что на современных cpu это не самый оптимальный вариант (это было быстро для старых поколений процессоров). Плюс, такты непонятно откуда взяты.
Правда и memset на старых компиляторах (когда-то супер-популярной для многих проектов 6й студии, да и у 7й, вроде, тоже) реализован крайне неэффективно.

Dasar

Который при распаковке тоже сделает не быстрее, чем memset?
скорее unpacker будет быстрее, потому что распаковывать будет последовательно, а memset-ы будут вызывать неупорядоченные обращения к памяти.
+ заодно и другие участки(код, строки и т.д.) тоже будут сжаты, а не только этот кусок.

Dasar

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

tokuchu

но код сейчас обычно маленький, по сравнению с данными, и много параллельных копий редко запускается, что могло дать выигрышь по скорости последующих запусков
Дело не только в скорости запусков. Да и отношение код/данные смотря на что смотреть. Для популярных на данной системе библиотек очень полезно будет если они будут шариться.

agaaaa

Имхо, в данном случае ваши макросы неоправданно снижают читаемость кода.

elenangel

виноват, протупил. не 4, а 16 страниц по 4к каждая.

Serab

читаемость кода
Чувак, это DizziDen, ему похуй, он просто получает fun :D

Ivan8209

>> читаемость кода
> Чувак, это DizziDen
У человека, собирающегося писать обработку звука на хаскеле,
свои воззрения на читаемость кода.
---
...Я работаю антинаучным аферистом...

agaaaa

Имхо, ему их следует поменять.
Обработку звука на хаскеле, подозреваю, тоже можно неплохо написать.
http://shootout.alioth.debian.org/u64q/benchmark.php?test=ma...
Вот тут видно, что хаскель всего в 2 раза менее оптимальный код выдаёт, чем GCC С++, к которому лично у меня уже выработалось стойкое отвращение.

tokuchu

Имхо, в данном случае ваши макросы неоправданно снижают читаемость кода.
Ну я за memset голосую, если что. :)

Ivan8209

Кстати, прочитай про m4. Тебе понравится.
---
ZZZZYU. Ты его не слушай, он тебя, куда хочешь, сагитирует!
hruid. Да, это он может.

apl13

У человека, собирающегося писать обработку звука на хаскеле,
свои воззрения на читаемость кода.
Это технологии будущего, между прочим, ибо компьютер, способный исполнить код синтезатора на хаскеле за разумное время, раньше чем через тридцать лет не появится. :umnik:
ЗЫ. На самом деле, хаскель в этом вопросе по производительности не сильно хуже сей, просто там есть нюансы, которые меня смущают, а всем остальным.

vall

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

apl13

Вообще-то, не так уж это и удивительно.
Оставить комментарий
Имя или ник:
Комментарий: