Серый список

[zHz00]

В dll-ке была переменная "тип устройства". Она принимала одно из значений, описанных #define'ами (да, анахронизм, но привычно). В основной программе эта переменная получалась и иногда анализировалась через switch. Фактически применялись 1-2 типа устройства. Тут понадобилось включить третий, давно забытый тип. И всё работать перестало.

ОКАЗАЛОСЬ, что список констант в длл-ке и в основной программе имеют разную нумерацию. А раньше всё работало, потому что номера используемых устройств случайно (!) совпадали с теми константами switch, которые делают нужные действия.

Comments

[Гость]

Прости, если ляпну ерунду — с dll'ками работал давно и в Delphi, не помню уже вообще ничегошеньки.

Разве для того, чтобы юзать что-то из dll, не нужно инклюдить хедер с декларациями её функций? Если да, то почему тогда не вынести #define'ы в хедер и не юзать полученные константы и в библиотеке, и в программе?

-- Minoru

[zHz00]

У нас динамическая подгрузка отдельных функций DLL через GetProcAddress, поэтому вместо прототипов функций, описываются типы УКАЗАТЕЛЕЙ НА ФУНКЦИИ, поэтому прямо инклюдить хедер не выйдет. Сделать отдельный хедер с константами -- можно. Но мы так не делаем.

[Knows Ajed]

Вау... снова без WAAAGH не обошлось, видать.

[Гость]

> описываются типы УКАЗАТЕЛЕЙ НА ФУНКЦИИ

Капсом можно и не писать, не такая уж страшная и сногсшибательная концепция ☺ Описываются указатели, я так понял, прямо в программе, а не в хедере, который с dll'кой идёт? Зачем же вы так?

-- Minoru

[zHz00]

Minoru -- концепция указателя сама по себе страшная и сногсшибательная -- я не шучу. А уж указатель на функцию это ещё круче.

В хедере длл-ки указаны прототипы функций. А в программе описаны указатели. Можно было бы описать типы указателей в хедере длл-ки в дополнение к самим функциям. Почему так не сделано -- я не знаю. Делали ещё до меня.

[Гость]

> концепция указателя сама по себе страшная и сногсшибательная -- я не шучу

Это на тебя работа со студентами влияет; впрочем, я сейчас уже не уверен, что это влияние — дурное.

Про функции — это мы что-то от темы ушли. Забъем.

> Сделать отдельный хедер с константами -- можно. Но мы так не делаем.

А почему?

-- Minoru

[zHz00]

>>А почему?

У нас уже есть отдельный хедер с константами на всю программу. Поэтому нужные константы для длл-ки включены в него. Если действовать согласно тому, что ты пишешь, нужны будут два файла с константами, один из которых состоит всего из 5-6 констант. Но это не главная проблема. Главная -- репозиторий. Если в проекте присутствуют файлы из другого репозитория, то придётся устраивать жёсткую привязку относительного расположения папок рабочих копий разных проектов. Хотя они и имеют отношение друг к другу. Вообще, на эту тему следует подумать. Но геморроя это точно добавит. Как в крупных компаниях делают общий хедер на несколько проектов, которые расположены в разных репозиториях?

[Гость]

В моём понимании, по-хорошему следует вместе с библиотекой всегда поставлять хедер, описывающий всё, что должны знать о библиотеке её пользователи. В вашем случае это упомянутые 5-6 констант, а также описания функций (в вашем случае скорее даже typedef'ы для указателей на оные).

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

1) отказ от отдельных репозиториев. Так делает Facebook. Они писали какой-то пост про преимущества и недостатки такого подхода, загугли, если интересны детали. Кроме Фейсбука так, похоже, никто не делает ☺

2) в основном репозитории создаётся директория с копиями всех зависимостей, а система сборки настраивается так, чтобы пользоваться этими копиями. Таким образом решается проблема путей к зависимостям — они всегда одинаковы. Сами копии при этом в основном репозитории не хранятся; мы либо: а) обучаем систему сборки подтягивать их перед непосредственно компиляцией (так делает утилита rebar для Erlang, например), либо б) пользуемся Git submodules (грубо говоря, это такой способ включить в свой репозиторий другую репу, представив её в виде директории). В обоих случаях можно заодно зафорсить версию, то есть подтягивать конкретный релиз зависимости (rebar это делает автоматически на основании файлика с названиями и версиями зависимостей; с submodules придётся вручную объяснить гиту, что теперь ты хочешь чекаутить другую версию).

-- Minoru

[Knows Ajed]

zHz00, ну, к примеру, если бы где-нибудь в машине около моста заиграла Ave Maria, можно было бы бить тревогу. Ведь это не то, что ожидается, когда идёшь под мостом в темноте. К тому же, изящно сочеталось бы с аналогичными событиями, которые ты описывал.