Unresolved external 문제로 구글링을 해보다 나름 도움이 되는 글을 찾아서 올려 봅니다.

따로 해석은 하지 않겠습니다.

단지

__declspec(dllexport) 와 __declspec(package) 의 차이에 대하여 내용중에 나옵니다만,

Can we use the PACKAGE directive only on TObject-derived classes? 부분입니다.
.. 중략

__declspec(dllexport) can be used for plain functions, data variables, and non-VCL classes, and can be used in plain DLLs.
__declspec(dllexport) 은 일반 함수, 데이터 변수,  non-VCL class 들에 사용할 수 있고 DLL 파일에 사용될 수 있다는 내용이고,

__declspec(package) is used for VCL components, and can only be used with packages.
__declspec(package) 는 VCL Component에 대해 사용할 수 있으며 이는 package에만 사용할 수 있다는 내용..
단 builder가 C++ 로는 64bit package 를 지원하지 않아 테스트 못해봄.

위의 내용은 class 또는 함수의 export 에 대한 내용인데요..
제가 테스트 해보니까 32bit 컴파일시에는 VCL component도 _export 또는 __declspec(dllexport) 로 export 과 되더군요.
그러나 64bit 컴파일에서는 위의 규칙이 적용되는것을 봤습니다(dllexport 가 vcl 관련해서는 export가 되지 않음).

참고 하시기 바랍니다.

감사 합니다...






원문 링크 : http://stackoverflow.com/questions/2727001/how-do-i-solve-an-unresolved-external-when-using-c-builder-packages


About the other questions

Your questions are all really interesting and many of the questions are questions I my self has been looking for answers for when I started developing packages and components for C++ Builder.

Are packages reliable using C++?

Packages are a fine solution to use for C++ Builder, Both C++ Builder is built to support packages and the Pascal written VCL framework. This means that certain implementations are different in C++ Builder than other compilers. This is a necessity to keep the language compatible with its Delphi sibling. For this reason you can use packages in C++ Builder almost as easily as if using Delphi.

Is linking to the first package by adding a reference to its BPI correct?

To start with the second part of your question here, using a lib file makes your package larger simply because it is using static linking - so your guess is correct. Now back to the first part of the question, linking to a package is fine by adding a reference to its BPI. But you do need to make sure that the path variable has been set correctly as Riho suggests in his answer.

Personally I always make sure to my packages to the proper directories in your users folder, the location of this is depending on your Delphi version and operating system version. As far as I recall it is under the Document and Settings\all users\shared documents\Rad studio(version number)\Packages but I could be mistaken about that.

Can we use the PACKAGE directive only on TObject-derived classes?

The PACKAGE macro is resolved into __declspec(package), you can compare it to __declspec(dllexport). The difference between these is that package is used when declared in a package, and dllexport is used when declared in a DLL. There is a topic about this on the official embarcadero forums titled __declspec(package) vs __declspec(dllexport). The author of the original post, also asks your exact question about this, but unfortunately that part of the question is unanswered.

I have a theory however, and I must emphasize that it is nothing more than a theory. Remy Lebeau writes as a response to the question in the forum post:

__declspec(dllexport) can be used for plain functions, data variables, and non-VCL classes, and can be used in plain DLLs. __declspec(package) is used for VCL components, and can only be used with packages.

So from reading his response it seems to me that package is simply exporting the class, just like dllexport does. And since dllexport as far as I can read from his response is to be used in plain DLLs only you have to use the package for exporting (even) non VCL classes from a package.

What is interesting about all this, is that a package is essentially a DLL as far as I recall, but I must admit I can't find or remember the source of that information so take with a grain of salt.

Is splitting code into packages the best way to achieve the goal of isolating code?

Packages have some very prominent strengths when creating reusable components for the VCL. Obviously using packages limits the user to use either C++Builder or Delphi, but for components written to take advantage of the VCL framework it's an excellent choice. Properly written packages can ease the reusability of components, and I believe it is the preferred method of distributing components for the VCL.

However if your code does not take advantage of the VCL framework in any way, I would consider using an ordinary library, either static or dynamic, simply to create a more cross compiler friendly approach.

Whether there are any better approach to isolating your code, really depends on the project you are working on. I like to keep code that communicates through use of VCL classes in packages, but code that does not require use of any VCL classes in regular libraries. Keep in mind though that you can easily use VCL classes in a DLL but you need to handle special cases if you choose to export functions with VCL String classes as parameters or return values.

Any general words of advice?

I'm not the most experienced developer of packages myself, but I have found that disabling runtime linking often solves a lot of my problems, while it is somewhat trivial to fix any problems for your own code, you can often run into 3rd party components that have trouble dealing with this. Having said that, I'm not a fan of distributing my packages along with my application as is required in this case. But to be honest that is a matter of taste.

Personally I found it difficult to find some proper answers to many of my questions, when I started creating components and packages. The official helpfile is not the most informative on the matter, but looking through the VCL source code, will often give you the best answer to your question. Besides there is a few other websites that can provide help, many of the sites are targeting Delphi though, but this you have to get used to though.

Delphi Wikia has some good articles about creating components, in particular Creating Components and Creating Packages There is also BCB Journal which is one of the few C++ Builder specific sites, it has some fine articles and an acceptable forum. The Delphi pages at About.com is also a good source of information, I've found lots of good hints and nice to knows there, in particular: Creating Custom Delphi Components - Inside and Out.