There are a few reasons for putting code in a DYNAMIC link library (linked at runtime) versus statically linked into the application (the same applies to all operating systems that support runtime linkage no matter what they call the runtime linked modules):
1) You need to be able to replace the version of the DYNAMIC library code without rebuilding anything else or 2) You have multiple executables (A) (B) and (C) (for example) that will all use the same DYNAMIC library code and you are hard-up for memory such that you only want the DYNAMIC library code loaded once and used by all requestors in order to save memory. or both. Note that there is a third reason for using a dynamic (runtime) linked library and that is that it provides something that you want all comers to be able to use the same way. Examples of this include the interfaces to the operating system and its platform libraries themselves which are always dynamically linked (this is the primary job of the program loader after all), and code which is "near to" such status such as widely used utility routines (such as zlib, X, etc). You may use item (1) for example so that your application uses SQLite3 in a DLL. Without making any change to your application at all, you can change the version of SQLite3 being used simply by changing the SQLite3.DLL. This works well provided that the API contract does not change between versions of the DLL and that you are dependent on that API contract, not on the implementation details of the contract "under the hood" -- if it does (ie, you are version/implementation dependent) then you are in what is known as "DLL Hell" because your application is not actually dependent on the SQLite3 API, it is dependent on a certain VERSION of the SQLite3.DLL. Mutatis mutandis to any DLL providing any API. You may use item (2) for example so that your application uses a standard facility in a way that is compatible with item (1) in order to save loading the code into every process. An example of this is the language/subsystem runtime libraries. Since there may be many thousands of these executables running concurrently -- such as every single process requiring the use of the platform "C" library. Rather than statically link the several megabytes of runtime into each and every executable (and loading A COPY of the same code with each executable), the library is only loaded ONCE and each process MAPS the loaded module into its own virtual address space thus perhaps saving gigabytes or terabytes of memory by only actually loading one copy of the code which everyone uses. Putting something into a DLL "just cuz you can" is not a good reason for putting code in a DLL and unless you require the capabilities provided by (1) or (2) and are absolutely sure that you are dependent on the API contract and not the implementation contract, putting code in a DLL is almost always a bad idea. It may be "cute" and "what the jonses are doing", but it serves no useful purpose other than add complication for complication sake. That is to say that if you have to change anything other than just "copying over" the DLL to change the implementation of the API functionality that DLL provides to your application, then using a DLL was the wrong thing to do. So, the only one who can answer your question is you by your knowledge of how your application works. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of John Smith >Sent: Monday, 21 January, 2019 03:16 >To: SQLite mailing list >Subject: [sqlite] Building SQLite DLL with Visual Studio 2015 > >Hi, > > >I need to build a data-layer DLL for a large project. > >My project is 64-bit built with Visual-Studio 2015. > >I want to ask about what would be the preferred way to build SQLite: > >1. Build SQLite code as a separate DLL and use it from my data-layer >DLL, > >2. Use the ready-built binary of 64-bit SQLite DLL for Windows >(sqlite-dll-win64-x64-3260000.zip), > >3. Or, build my data-layer code with SQLite code as a single DLL. > >Thanks in advanced, > >John > > >_______________________________________________ >sqlite-users mailing list >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
