Здравствуйте, Caracrist, Вы писали:

C>вопрос: какое расширение принято давать таким файлам? Это не обычный .h файл...

я встречал такие варианты
1) .h — но в начале коммент, что это не обычный хедер (и поэтому нет стража), и как его надо юзать (такой коммент всяко полезен)
2) .inc — от include
3) .inl — от inline

You will always get what you always got
  If you always do  what you always did

Здравствуйте, VTT, Вы писали:

VTT>Что касается инклюдов в середине файла, да еще и с отсутствующим header guard, то лучше так не делать.

Вот как раз инклюды в середине файла делаются с отсутствующим header guard — потому что их by design можно включать в нескольких местах и ничего неправильного в этом нет.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Caracrist, Вы писали:

C>Мне нужно сгенерировать код во многих местах, но не только содержимое функций но и их названия...
C>не хочу использовать #define поскольку хочется чтоб он был дебагируемым.

C>вопрос: какое расширение принято давать таким файлам? Это не обычный .h файл...

Я даю расширение cpp. Потому что это не хедер (он не в голове), но содержит код на cpp.
А в один cpp можно включать другой cpp (даже если изначально он для этого не делался).
Это нормально.

Здравствуйте, Caracrist, Вы писали:

C>вопрос: какое расширение принято давать таким файлам? Это не обычный .h файл...

Какое хочешь, такое и давай. Это обычный .h файл.

C>вопрос: какое расширение принято давать таким файлам? Это не обычный .h файл...
.ic, .icp(p)

Здравствуйте, jazzer, Вы писали:

J>я встречал такие варианты
J>1) .h — но в начале коммент, что это не обычный хедер (и поэтому нет стража), и как его надо юзать (такой коммент всяко полезен)
J>2) .inc — от include
J>3) .inl — от inline

остановлюсь на .inl
спасибо!

Мне нужно сгенерировать код во многих местах, но не только содержимое функций но и их названия...
не хочу использовать #define поскольку хочется чтоб он был дебагируемым.
вынес этот код в отдельный файл:

// definesInlineCode.h
#ifndef X
#error X must be defined
#endif
inline void foo_#X()
{
//some X related code
}
#undef X

пользуюсь в разных местах вот так:

// some class
class C
{
#define X test
#include "definesInlineCode.h"
};

вопрос: какое расширение принято давать таким файлам? Это не обычный .h файл...

Здравствуйте, Kernighan, Вы писали:

K>Я даю расширение cpp. Потому что это не хедер (он не в голове), но содержит код на cpp.
K>А в один cpp можно включать другой cpp (даже если изначально он для этого не делался).
K>Это нормально.

Одна только беда — что всякие билд-системы обычно работают по расширениям. Типа из каждого .cpp надо сделать .o и потом все они объединяются в библиотеку.
А у тебя придется химичить, явно исключить этот .cpp из списка файлов на компиляцию.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Caracrist, Вы писали:

C>inline void foo_#X()
Оператор # оборачивает X в двойные кавычки, тем самым превращая его в строку. Для склеивания есть оператор ##.
Более того, оно будет работать только при раскрытии макроса, а в том виде, в каком оно представлено тут, код даже не должен собраться.
Так что (в зависимости от тела функции), тут надо либо делать полноценный макрос, либо можно обойтись шаблонной функцией.

Что касается инклюдов в середине файла, да еще и с отсутствующим header guard, то лучше так не делать.

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, Kernighan, Вы писали:

K>>Я даю расширение cpp. Потому что это не хедер (он не в голове), но содержит код на cpp.
K>>А в один cpp можно включать другой cpp (даже если изначально он для этого не делался).
K>>Это нормально.

J>Одна только беда — что всякие билд-системы обычно работают по расширениям. Типа из каждого .cpp надо сделать .o и потом все они объединяются в библиотеку.
J>А у тебя придется химичить, явно исключить этот .cpp из списка файлов на компиляцию.

Ну это проблемы бидл системы, что он такая тупая.
У меня-то исконно-посконный makefile, а он что скажешь, то и делает.

Здравствуйте, Kernighan, Вы писали:

J>>А у тебя придется химичить, явно исключить этот .cpp из списка файлов на компиляцию.

K>Ну это проблемы бидл системы, что он такая тупая.
K>У меня-то исконно-посконный makefile, а он что скажешь, то и делает.

И что, тебе там не надо специальные телодвижения совершать, вместо исконно-посконного

%.o: %.cpp
    gcc .....

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, Kernighan, Вы писали:

J>>>А у тебя придется химичить, явно исключить этот .cpp из списка файлов на компиляцию.

K>>Ну это проблемы бидл системы, что он такая тупая.
K>>У меня-то исконно-посконный makefile, а он что скажешь, то и делает.

J>И что, тебе там не надо специальные телодвижения совершать, вместо исконно-посконного
J>

J>%.o: %.cpp
J>    gcc .....
J>

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

Здравствуйте, Kernighan, Вы писали:

J>>>>А у тебя придется химичить, явно исключить этот .cpp из списка файлов на компиляцию.

K>>>Ну это проблемы бидл системы, что он такая тупая.
K>>>У меня-то исконно-посконный makefile, а он что скажешь, то и делает.

J>>И что, тебе там не надо специальные телодвижения совершать, вместо исконно-посконного
J>>

J>>%.o: %.cpp
J>>    gcc .....
J>>

K>Это называется "правило".
Спасибо, кэп

K>Но вместо него можно просто имена файлов перечислить.
Это и есть "специальные телодвижения"

K>При этом в каталоге может лежать ещё дохрена сишных файлов, которые не используются.
K>Если файлов не миллион, а десяток другой, то так даже проще.

Проще поддерживать вручную список десятка-другого файлов? Мсье знает толк

You will always get what you always got
  If you always do  what you always did