3

I'm not exactly new to C++ but I've never managed to get my head around Libraries.

I would like to split my networking, graphics and input class sets out of my main executable so that I can update them individually rather then sending out a recompiled version of all the code as a single executable.

Is this possible and how do I do this cross platform? (E.g. the process will work on Windows, Linux and Mac)

James
  • 2,609
  • 3
  • 20
  • 27
  • 4
    It's possible, most people do it when they first discover it's possible, and in the end it simply complicates the build, distribution and debugging process. Unless you're talking about a very large system with very good tracking of and handling of different library versions, just make one executable and save yourself some headaches. – Erik Mar 08 '11 at 15:26
  • 2
    @Erik: Depends on the environment. When you find yourself copying/sharing code between several products then it might be time to split your shared code into one or several libraries. DRY :-) – DarkDust Mar 08 '11 at 15:33
  • @DarkDust: I've found the opposite to be true, due to all the headaches from version conflicts. Bandwidth is cheap. time isn't :) – Erik Mar 08 '11 at 15:36
  • Word of warning there is a significant amount of work in making something cross platform. Also don't let a Mac user catch you calling it "Max" they are very sentimental :P – AJG85 Mar 08 '11 at 15:44
  • @AJG85, Typo :P Thanks for the warning but I very much needs to be. – James Mar 08 '11 at 15:47
  • @James definitely check out QT to ease your cross platform needs wxWidgets is a good runner up and if GUI is not a main focus boost will give you a huge leg up. Your input will probably be closely coupled your main executable but network and graphics layers are prime candidates for a .dll or .so or whatever Mac uses for shared libraries. – AJG85 Mar 08 '11 at 17:19
  • I myself also would prefer split-parallel existence of stuff for the sake of overview from the developers perspective I can understant that. @Erik : beautiful overviewable timeless code is *elegant and gives fulfillment*. Bandwith use and time will not give that feeling always. That must be the reason why millions of people enjoy extremely unefficient slow but highly fullfilling hobbies like fishing, post stamp collecting and other time consuming but very enriching hobbies although admitted thats way too boring for me. (I like to make fine pencil drawings for hours on end on an A5 page :D – Sam Mar 30 '11 at 01:51

4 Answers4

4

As @Armen said in the simplest of terms, one of the requirements here is a library that works as cross-platform as possible/needed. Qt is the obvious choice for this. There are others like wxWidgets that achieve the same thing and the choice is up to you.

The second thing is that all the "upgradeable" libraries need to conform to binary compatibility (something which Qt pledges to do for every major version, don't know about wxWidgets).

Third and probably the "yeah, duh!" part: you need to build these as shared libraries and link these shared libraries.

These three points should allow you to replace the libraries without rebuilding the executable file itself and keep that as small as possible. The way of upgrading will be different across platforms though (linux: automatic through repositories, Mac and Windows manually or through your own updating software, perhaps macports for Mac?)

rubenvb
  • 74,642
  • 33
  • 187
  • 332
  • 1
    Also,you can use Qt plugin mechanism to provide smaller components which you can upgrade and redistribute without a brand new program. – Dat Chu Mar 08 '11 at 15:36
  • It's hard to call Qt a "C++ library" given that it can't be compiled by an... erm... C++ compiler. – Billy ONeal Mar 08 '11 at 15:50
  • @Billy: all stupidity aside, if you don't like the aspect of Qt being a "C++ library", call it a "C++ framework". Lot's of GNU programs and libraries also can't be compiled by a C compiler, as they need loads of helper utilities (a prime example: GCC, which uses at the least flex and bison, yacc). IMHO, moc is a lot smaller and still generates pure C++ code in the end. Agreed, Qt and the STL have their significant differences, but Qt is very much templated and object oriented and c++0x-like memory managed (see e.g. Qt's smart pointers). – rubenvb Mar 08 '11 at 15:57
  • @rubenvb: I don't see what the STL has to do with this conversation. My point with Qt is not that it's a bad library or framework, but that calling it a C++ library is a bit of a stretch. Nobody calls Flex or Bison C libraries. That doesn't mean they're not useful. But if someone's asking for a C or C++ solution to the problem you should be upfront about the fact that Qt requires the extra preprocessing step. – Billy ONeal Mar 08 '11 at 15:59
  • @Billy: ok, you're talking only about moc? Every major build system has support for these things, it's not a problem as much as it is a feature. With regards to the Flex/Bison analogue: they aren't C libraries, no, but they are non-compiler C things needed to build some projects. Same goes for Qt's moc, except that any Qt development environment also has moc built-in. If you can't see my point, then I propose we agree to disagree. – rubenvb Mar 08 '11 at 16:35
  • @rubenvb: If it cannot be compiled according to the C++ standard, then I don't see how it can be called C++. Yes, Flex and Bison are non-compiler C things. Qt is the same. Any "Flex development environment" comes with flex built in too. That doesn't mean it's okay for someone to pass off a flex program as a C library. – Billy ONeal Mar 08 '11 at 16:40
2

Yes, use Qt

Armen Tsirunyan
  • 130,161
  • 59
  • 324
  • 434
1

Two libraries that I swear by, that you may want to look at

SDL:
http://www.libsdl.org/
tut:
http://lazyfoo.net/SDL_tutorials/index.php

SFML:
http://www.sfml-dev.org/
tut:
http://www.sfml-dev.org/tutorials/1.6/

Both graphics/networking/audio libraries!

ultifinitus
  • 1,813
  • 2
  • 19
  • 32
0

Really, this doesn't make sense. You're going to have to recompile the binary when you move it to another platform in any case, because different platforms use different hardware and use different binary formats. There's no reason not to just link in your "platform specific" code into the same binary.

Cross platform at the source level does make sense, however.

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
  • 2
    I don't think you understand what the OP is asking; he's clearly talking about a set of source-cross-platform libraries (is there any other kind of cross-platform?--> no) to be able to split up distribution and binary upgrades. – rubenvb Mar 08 '11 at 16:57