[C] Функцию превратить в макрос

Код от профана:

#define MGC(var) \
*var, *var=next(*var)

Возвращает новое значение, а мне нужно старое.

Замените запятую после *var на точку с запятой :)

Но все-таки, по-моему, inline-функция намного лучше. И чем она вам не нравится - не понимаю (тем более, что если компилятор вставит ее именно как inline, получится намного лучше непредсказуемого дырявого макроса, который я вам нарисовал).

> который я вам нарисовал

ничего ты не нарисовал, он делает не тоже самое, что приведённая функция.

А что должно значить выражение «*var;»? Ничего не меняется.

А функция не нравится тем, что не доверяю я inline'у. То ли он есть у компилятора, то ли нету.

Там, где компилятор решит не инлайнить - инлайнить и не надо.

gcc'шные хаки... Возможно, конечно, но еще менее стандартно, чем inline :(

Придется, наверно, делать head глобальной.

> А функция не нравится тем, что не доверяю я inline'у. То ли он есть у компилятора, то ли нету.

Если компилятор не выполнит inline, то именно это не скажется на скорости вашего кода не как. Значит он ничего неоптимизует совсем

Я не смогу написать

void *p = mm_get_chunk(pool);

У меня тут счет на такты идет...

И я говорил еще и о том, что не все могут поддерживать inline.

> И я говорил еще и о том, что не все могут поддерживать inline.

Самые простые компиляторы обязаны вставлять inline. Более сложные могут отказать в этом, если это не выгодно.

Компиляторы, за небольшим исключением, вообще не обязаны понимать слово «inline», ибо не соответствуют C99.

>А return и вовсе делает что-то неожиданное.

Ой, бред написал, извиняюсь

> А функция не нравится тем, что не доверяю я inline'у. То ли он есть у компилятора, то ли нету.

У меня тут счет на такты идет...

Вы пытаетесь считать такты, не имея на руках конкретного компилятора и конкретной целевой железяки. Ок. А почему вы решили, что у компилятора именно с inline-ами будет плохо? Вдруг он кроме iniline-а еще чего-нибудь не умеет? Не умеет разворачивать циклы, например? Не умеет делать выравнивание? Вдруг он будет вообще не-оптимизирующим? Почему именно вокруг какой-то одной фичи вы устраиваете пляску?

> Компиляторы, за небольшим исключением, вообще не обязаны понимать слово «inline»

Де-факто, трудно найти компилятор, который не понимал бы.

>А функция не нравится тем, что не доверяю я inline'у. То ли он есть у компилятора, то ли нету.

Поставь для функции атрибут always_inline(gcc). Для других компиляторов что-то подобное тоже наверняка есть.

А что ты делаешь с возвратом ф-ии? Если ты её присваиваешь вот так,
foo=mm_get_chunk(bar), то
можно попробовать как-нибудь так
#define MM_GET_CHUNK(dest,pool) dest=*pool; *dest=next(dest);
(с точностью до разыменования указателей).

Ещё один вариант - завести переменную отдельно в охватывающем блоке, а потом что-нибудь вроде
#define MM_GET_CHUNK(temp_var,pool) \
(temp_var=*pool, *pool=next(*pool), temp_var)
если я правильно помню смысл операции «запятая».

>А почему вы решили, что у компилятора именно с inline-ами будет плохо? Вдруг он кроме iniline-а еще чего-нибудь не умеет? Не умеет разворачивать циклы, например? Не умеет делать выравнивание? Вдруг он будет вообще не-оптимизирующим?

Беглый взгляд на багзиллу gcc позволяет сказать, что для конкрентной версии компилятора в чём-то он может быть и прав :)

> Беглый взгляд на багзиллу gcc позволяет сказать ...

... позволяет сказать, что поведение компилятора совершенно непредсказуемо, и грабли могут быть абсолютно в любом месте. inline ничем не выделяется в этом плане.

Я пишу библиотеку из полутора функций. Мои требования - скорость и соответствие стандарту. По обоим пунктам смущает inline. Никаких других оптимизаций здесь не нужно, критичная область - три приведенные строки. Ясно, что вызов функции сожрет еще примерно столько же. Не хотелось выходить за рамки C89, чтобы ни в каких условиях не иметь проблем с компиляцией.

Де-факто, трудно найти компилятор, который не понимал бы.

Это радует. Вероятно, придется оставить как есть.

можно попробовать как-нибудь так

Да, думал об этом, просто использовать будет не так удобно. Хотя это и самый правильный для макроса вариант.

завести переменную отдельно в охватывающем блоке

Тоже вариант, и тоже неудобный :(

Если функция не реентерабельна, можно завести одну глобальную переменную на весь мир. Если и это не вариант, то, по-моему, на этом варианты заканчиваются.

> Не хотелось выходить за рамки C89, чтобы ни в каких условиях не иметь проблем с компиляцией.

ИМХО, самое важное для встраивания функции - чтобы компилятору было видно тело функции к тому моменту, когда функция вызывается. Этого можно достигнуть путём размещения тела функции в h-файле.

Если этот h-файл заинклудят в нескольких разных c-файлах, то на этапе линковки возникнет проблема: реализация функции оказалась в нескольких разных o-файлах, и линковщик не знает, какую из реализаций выбрать.

Проблему устраняет слово inline. Однако на экзотических компиляторах этого слова может не быть. За то есть слово, находящееся в C89, тоже позволяющее проблему устранить: static.

Так что наиболее портабельное решение - сделать зависящий от компилятора макрос, который выбирает между inline и static. Либо между inline-функцией в h-файле и обычной функцией в c-файле.

> Так что наиболее портабельное решение - сделать зависящий от компилятора макрос, который выбирает между inline и static.

static не повредит всегда делать и реализацию сразу в хедере, если функция нужна в нескольких файлах. А inline и always_inline дописывать, если повезло.