Есть набор исходников (из проекта AT91 USB Framework - Core 1.01), в каждый Сишный файл включено неск. хидеров, в частности, usb.h... Все хидеры имеют одну и ту же структуру:

#ifndef _(имя_файла)_H
#define _(имя_файла)_H
Внутри всякие объявления, и пр.,
в том числе:
#define inline _inline
.
.
.
inline unsigned int USB_GetState(const S_usb *pUsb)
{
return (*(pUsb->pState) & 0x0000FFFF);
}
.
.
.
#endif

По идее, такая структура не должна давать глюки при включении хидера в несколько файлов проекта. Но дает на этапе линковки:

udp.o(.text+0x3188):Core/usb.h:1378: multiple definition of `USB_GetState'
enumeration_example.o(.text+0x1bf4):Core/usb.h:1378: first defined here

Уже лыжи не едут! Че ему надо???

Видимо у Вас inline не инлайнится!

static inline ему надо

#define inline __inline убрать.

Это недоделка компилятора. Например в CV тоже самое. #define действует в пределах файла (по хорошему он должен действовать в пределах проекта), и _(имя_файла)_H из других файлов невиден. Поэтому возникает ошибка "пере/мульти-определения".

не понял, с чего бы это #define из h-файла должен быть виден в пределах всего проекта??

В CV может быть. А в данном случае это некорректное опрделение инлайна.

Для того чтобы хидер подключить только единожды. Как в VisualC++.

ЗЫ. В данном случае, действительно дело в инлайне. Иначе бы вылезли и другие ошибки, так как там есть и другие объявления.

Пардон, причем тут недоделки компилятора ??? Хидер каждый раз включается ОДИН раз, но в нем definition !!! ( а не declaration)
И при линковке имеем несколько нестатических функций с один и тем же именем, на что линковщик естественно матерится.
static - именно то что надо. Хотя если бы inline работал, то все было бы хорошо.. Надо в стандарт заглянуть, что-то я не думал про это

позвольте с Вами категорически не согласиться. не знаю уж, как там в visual c++, но в нормальном с++, и тем более в с это будет противоречить всей концепции языка! построенной на принципе раздельной компиляции. не вдаваясь в рассуждения о том, хорошо это или плохо, но это так, и обсуждению не подлежит.
что касается рассматриваемого вопроса, то там все понятно и люди внятно ответили - если бы inline выполнялся правильно, то не было бы никаких проблем. подозреваю даже, что это не вина компилятора, а просто автор кода напрасно изменил значение inline с помощью непонятного определения _inline

серджик_врн,

Не хочется выглядеть "к каждой бочке затычкой" и в ответ "категорически не соглашаться", создавая офтоп на пустом месте.
Приведу только кусок кода для хедера, объясняющий зачем это нужно и как это удобно применять.
Если это противоречит вашему понятию "всей концепции языка", то пора бы эту концепцию подучить
А о незнании VC программисту лучше смолчать, а не программистам тем более.

#if !defined(AFX_ENTERDLG_H__D4A31FE2_9E8C_11D8_964F_D72B7675A5C0__INCLUDED_)
#define AFX_ENTERDLG_H__D4A31FE2_9E8C_11D8_964F_D72B7675A5C0__INCLUDED_

... основной текст хедера

#endif // !defined(AFX_ENTERDLG_H__D4A31FE2_9E8C_11D8_964F_D72B7675A5C0__INCLUDED_)

Если уж на то пошло, #define это директива препроцессора и никакой области видимости она не имеет и никакой сущности в программе не отображает. Это просто способ управления процессом компиляции.

Я б сказал кому стоит подучить концепцию. Тем более VC это очень частный случай и какие нибудь Юникс-гуру могли ни разу его и не запускать
Тем более в сабже стоит - GCC