Как я решаю неразрешенное внешнее при использовании Разработчика C++ пакеты?

Неразрешенное внешнее

Неразрешенное внешнее значение в вашем случае, похоже, связано с тем, что компилятор не может найти путь к данным пакета. Вы должны выяснить, если:

• Путь существует в списке путей поиска компилятора.
• Пакет существует в каталоге пакетов по умолчанию.

Если одно из них истинно, проблема не в пути. Однако, как отмечает Рихо , это наиболее вероятная причина проблемы. В вики-странице документации Embarcadero говорится следующее о неразрешенной внешней ошибке:

Именованный символ упоминается в данном модуле, но не определен нигде в наборе объектных файлов и библиотек. включены в ссылку. Убедитесь, что символ написан правильно.

Вы обычно увидите эту ошибку компоновщиком для символов C или C ++, если произойдет одно из следующих событий:

• Вы неправильно сопоставили объявления символа __ pascal и __ cdecl ] типы в разных исходных файлах.
• Вы пропустили имя объектного файла, который нужен вашей программе. Вам необходимо вручную добавить все необходимые пакеты в список «Требуется».
• Вы не сделали ссылку в библиотеке эмуляции.

Если вы связываете код C ++ с модулями C, возможно, вы забыли заключить внешние объявления C в extern «C».

У вас также может быть несовпадение регистра между двумя символами.

Источник: Неразрешенный внешний «символ», на который имеется ссылка из «модуля» .

Поскольку, судя по измененным именам классов, это не случай неправильного написания. Вы также заявляете, что добавили пакет в список требований, поэтому мы также исключаем это. Поскольку вы не связываетесь с модулями C, мы также можем опустить эту часть. Значит, это указывает на проблемы с каталогом.

О других вопросах

Все ваши вопросы действительно интересны, и многие из них - это вопросы, на которые я сам искал ответы, когда начинал разрабатывать пакеты и компоненты для C ++ Builder.

Надежны ли пакеты при использовании C ++?

Пакеты - прекрасное решение для использования в C ++ Builder, C ++ Builder создан для поддержки пакетов и VCL-фреймворка, написанного на языке Pascal. Это означает, что некоторые реализации в C ++ Builder отличаются от других компиляторов. Это необходимо для того, чтобы язык был совместим с его родным братом Delphi. По этой причине вы можете использовать пакеты в C ++ Builder почти так же легко, как при использовании Delphi.

Правильно ли связываться с первым пакетом путем добавления ссылки на его BPI?

Начнем со второй части вашего вопроса: использование файла lib увеличивает размер вашего пакета просто потому, что он использует статическое связывание - так что ваш предположение верное.Теперь вернемся к первой части вопроса. Можно установить ссылку на пакет, добавив ссылку на его BPI. Но вам нужно убедиться, что переменная пути установлена ​​правильно, как предлагает Рихо в своем ответе.

Лично я всегда убеждаюсь, что мои пакеты находятся в правильных каталогах в вашей папке пользователей, расположение которых зависит от вашей версии Delphi и версии операционной системы. Насколько я помню, он находится в папке Document and Settings \ all users \ shared documents \ Rad studio (номер версии) \ Packages, но я могу ошибаться в этом.

Можно ли использовать директиву PACKAGE только для классов, производных от TObject ?

Макрос PACKAGE преобразован в __ declspec (package) , вы можете сравнить его с __ declspec (dllexport) . Разница между ними в том, что package используется при объявлении в пакете, а dllexport используется при объявлении в DLL. На официальном форуме embarcadero есть тема под названием __ declspec (package) vs __declspec (dllexport) . Автор исходного сообщения также задает ваш точный вопрос по этому поводу, но, к сожалению, эта часть вопроса остается без ответа.

Однако у меня есть теория, и я должен подчеркнуть, что это не более чем теория. Реми Лебо пишет в ответ на вопрос в сообщении на форуме:

__ declspec (dllexport) может использоваться для простых функций, переменных данных и классов, не относящихся к VCL, и может использоваться в простых библиотеках DLL.__declspec (package) используется для компонентов VCL и может использоваться только с пакетами.

Итак, читая его ответ, мне кажется, что пакет просто экспортирует класс, как это делает dllexport. И поскольку dllexport, насколько я могу понять из его ответа, должен использоваться в простых библиотеках DLL, только вам нужно использовать пакет для экспорта (даже) классов, отличных от VCL, из пакета.

Что интересно во всем этом, так это то, что, насколько я помню, пакет по сути является DLL, но я должен признать, что не могу найти или запомнить источник этой информации, так что относитесь к нему с недоверием.

Является ли разделение кода на пакеты лучшим способом достижения цели изоляции кода?

Пакеты обладают некоторыми очень сильными сторонами при создании повторно используемых компонентов для VCL. Очевидно, что использование пакетов ограничивает пользователя использованием C ++ Builder или Delphi, но для компонентов, написанных с использованием преимуществ инфраструктуры VCL, это отличный выбор. Правильно написанные пакеты могут облегчить повторное использование компонентов, и я считаю, что это предпочтительный метод распространения компонентов для VCL.

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

Есть ли лучший подход к изоляции вашего кода, это действительно зависит от проекта, над которым вы работаете. Мне нравится хранить код, который обменивается данными с помощью классов VCL в пакетах, но код, который не требует использования каких-либо классов VCL в обычных библиотеках. Однако имейте в виду, что вы можете легко использовать классы VCL в DLL, но вам нужно обрабатывать особые случаи, если вы решите экспортировать функции с классами VCL String в качестве параметров или возвращаемых значений.

Какие-нибудь общие советы?

Я сам не самый опытный разработчик пакетов, но обнаружил, что отключение связывания во время выполнения часто решает множество моих проблем, в то время как исправить любые проблемы для ваш собственный код, вы часто можете столкнуться со сторонними компонентами, которые не могут справиться с этим. Сказав это, я не поклонник распространения моих пакетов вместе с моим приложением, как это требуется в данном случае. Но если честно, это дело вкуса.

Лично мне было трудно найти какие-то правильные ответы на многие из моих вопросов, когда я начал создавать компоненты и пакеты. Официальный файл справки не самый информативный по этому вопросу, но просмотр исходного кода VCL часто дает вам лучший ответ на ваш вопрос. Кроме того, есть несколько других веб-сайтов, которые могут предоставить помощь, хотя многие из них нацелены на Delphi, но к этому вам нужно привыкнуть.

В Delphi Wikia есть несколько хороших статей о создании компонентов, в частности Создание компонентов и Создание пакетов Также есть BCB Journal , который является одним из немногих C ++ Конкретные сайты Builder, у него есть несколько хороших статей и приемлемый форум. Страницы Delphi на сайте About.com также являются хорошим источником информации, я нашел там много хороших советов и приятно знать, в частности: Создание пользовательских компонентов Delphi - внутри и снаружи .