0

I'm writing a small program that I want to be able to link with other programs. I also intend to run it from a command line interface, and maybe later with a GUI interface.

How could distribution and reuse flexibility be hurt by linking my program as a static or dynamic library?

Distribute it as a library and

  • Dynamically link for GUI and command line interfaces
  • Statically link for a stand alone binary
Improve this question

4 Answers 4

Reset to default
1

If you're wondering whether to link statically or dynamically you have to first determine how your application will be used.

Dynamic linking is less resource intensive, so this is a good option if your application will be used by many other processes. Dynamic linking also allows you to propagate bug fixes without having to reship things. Static linking is good for small applications running in limited environments, because they have larger resource footprints.

However, static libraries may be easier to deploy, since there are the application won't have file dependencies like will dynamically linked libraries.

To summarise, it really all depends what you want your code to be used for, how, by whom, and in what environment. Also, the statically linked option gives you a slight performance increase at startup (but for all practical purposes that is negligible).

I would suggest for most scenarios you go with linking dynamically.

Hope this answers the question. If you need more information, there are plenty of resources on the differences between static and dynamic linking and the advantages/disadvantages of both.

Happy coding!

Improve this answer
3
  • 2
    Dynamic linking is less resource intensive. You need to clarify your statement. For which resource is it less intensive, and why? Because from what you write, I think you're confusing the benefit of the saved disk space that you can get from dynamic (thus possibly shared) libraries with the memory footprint of the process. The dynamic library will still be loaded into that process image, so that doesn't necessarily save you much. Also, this depends a bit on your target platform. Commented Jun 7, 2013 at 7:23
  • 1
    I'd suggest for most scenarios (that OP seems likely to encounter at this stage) to use static linking. You can still decouple your code into libraries, and avoid bloating your software or entering shared lib hell. Commented Jun 7, 2013 at 7:28
  • You are 100% correct haylem. Yes I was referring to disk space savings if this library is shared. I should have clarified that. Thanks for the comment. Commented Jun 7, 2013 at 8:33
0

I know this is a bit late in the day, but thought I would throw my tuppence in: In regards to which is best it really is a very subjective matter, depending greatly on what functionality, security, availability and security you require: With dynamic linking, for example:

  • save memory: multiple programs can access your DLL functionality simultaneously
  • Independence: any language that can access a DLL can utilise the functionality you have loving crafted
  • versioning/locale: you can make locale or version specific dlls or even a single dll which can contain version/locale specifics, without worrying about changes to the program, the dll will do it all for you (well onceyou have put in the work to start with...Nothing is free:)
  • save disk space: one DLL on disk can serve throughout a system
  • upgrade ease: you can upgrade a whole set of functionality with a simple DLL change

With static linking you can:

  • ensure your program Always has the functions available within the SLL
  • ahem optimally use your disk space: well, the executable will be bigger, however, chances are that by trading off some disk space you will have a much(variable amount of much-ness) faster program
  • distribution: much easier as you will have reduced or non-extant dependencies, so no extra files to include, just to achieve some functionality. The executable will contain all the SLL code and that's it, all you will need are any resources you want to include seperately from an SLL.
  • security: if everything your program needs is statically linked then your exe will be that bit harder to hack or crack, although nothing can stop a truly determined security breacher, size and complexity can often dissuade amateurs and tinkerers. Obviously obfuscation helps too.

There are other reasons too, but as an initial breakdown of the pros of each I thought this may help anyone else looking at the question.

Improve this answer
-3

I would write it as a library (eg, DLL or JAR) and write the console app to talk to it. That way in the future you could write a GUI for it.

Or for more flexibility you could write it as a web service and talk to it that way.

Improve this answer
1
  • 1
    His question, if I understand it correctly, is whether static or dynamic linking is more appropriate. Commented Jun 7, 2013 at 2:14
-3

If your "program" has two different processes you can use a named pipe.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.