I am asking this here because I think my last question was more than one question so creating another question seemed appropriate. However, you can close it if it does not adhere to the SO policies.
In this comment on my last question , I was given a nice advice by Michael Aaron Safyan (at least I liked it):
Once you feel somewhat comfortable in the language, then I would recommend taking a look at Google Code and seeing if there are any C++ projects that are in need of some help.
I am going to be developing on XCode on Mac. My question is that do I have to take that into consideration when developing for C++ projects. Is environment consideration project based or can a generic OS/Env be used like Mac/Xcode or Ubuntu/Anjuta?
Thanks.
In theory, no; in practice, yes.
For core algorithms, the environment wouldn't matter.
For UI, the platform matters termendously.
Unfortunately, UI drives most applications. Usually, the core algorithms are trivial.
Even in the rare cases where UI doesn't matter, you would still have the problem of common libraries.
When it comes to C++ development there are two major camps: MSVC, and gcc. Porting a project between them is not always easy, so since Xcode is gcc-based as long as you stick to gcc projects (typical filenames to look for are configure and Makefile) you should not have a problem.
If a project has been ported, or is portable, to your platform of choice, of course you can work on it.
But if a project is specific to a certain platform, and that's not your chosen one (e.g., a Windows application), you will have a hard time working on that project as you cannot compile the source, let alone have a test run.
Of course, today there are many virtualization solutions available that allow you to run a different OS in a virtual machine. In my opinion, though, that just adds another layer of problems, especially for a novice programmer.
Related
I am familiar with QT/gtk+ libs under linux. I've just roughly had a look at available c++ frameworks like Reason and Platinum. Does anyone have any experience working with any of them? Are they any good, should I consider learning them? I am not a big fan of frameworks though.
Keep using Qt or gtk+.
They're very good, and you already know them.
I am not a fan of frameworks either, which is maybe why I haven't heard of those you mention. Having said that, check out POCO. Looks much better than Qt or gtk+ to me if you don't need GUI.
I worked on a project that had to run on multiple platforms (Linux, Windows, Windows CE). We used WxWidgets for the UI. The libraries and the tools weren't perfect. But it compiled and ran on all the platforms without any issues.
The platform is completely open source, so you have the benefits therein.
In the end, I was glad we used it as apposed to porting the UI layer multiple times.
boost asio: the framework for those who are not framework fans ;-). (and this question still lacked a boost answer)
I've started working a little bit with Platinum C++. The documentation is really lacking. That said, you can get some things off the ground relatively quickly. What I worry about is investing deeper into it and finding bugs without support or that it gets dropped as a project (or never really adopted) -- it is version 1.0.0.4
I sounds like you are practiced in keeping the general application mechanics independent and abstracted from one another. It may be worth writing your own small 'framework' and plugging in functionality from other projects with a small wrapper - particularly boost, as mentioned above. This is the direction I am going.
What are the best practices on writing a cross platform library in C++?
My development environment is Eclipse CDT on Linux, but my library should have the possibility to compile natively on Windows either (from Visual C++ for example).
Thanks.
To some extent, this is going to depend on exactly what your library is meant to accomplish.
If you were developing a GUI application, for instance, you would want to focus on using a well-tested cross-platform framework such as wxWidgets.
If your library depends primarily on File IO, you would want to make sure you use an existing well-tested cross-platform filesystem abstraction library such as Boost Filesystem.
If your library is none of the above (i.e. there are no existing well-tested cross-platform frameworks for you to use), your best bet is to make sure you adhere to standard C++ as much as possible (this means don't #include <linux.h> or <windows.h>, for instance). When that isn't possible (i.e. your library reads raw sound data from a microphone), you'll want to make sure the implementation details for a given platform are sufficiently abstracted away so that you minimize the work involved in porting your library to another platform.
To my knowledge, there are a few things you can do:
You can divide the platform specific code into different namespaces.
You can use the PIMPL idiom to hide platform specific code.
You can use macros do know what code to compile (in this case the code will be platform specific). Check this link for more information.
Test your library in multiple environments.
Depending on what you are doing it might be good to use libraries such as Boost because it is not specific to a platform. The downside (or possibly the good side) is that you will force the use of the libraries you included.
Couple of suggestions from my practical experience:
1) Make sure of regular compilation of sources in your targeted platforms. Don't wait till the end. This'd help point to errors early. Use a continuous build system -- it makes life a lot easier.
2) Never use platform specific headers. Not even for writing native code -- for all you know some stuff in a windows header might expect some string which was ABC in XP but got changed to ABC.12 in Win7.
3) Use ideas from STL and BOOST and then build on top of them. Never consider these to be a panacea for problems though -- STL is easy to ship with your code but BOOST is not.
4) Do not use compiler specific constructs like __STDCALL. This is asking for hell.
5) The same code when compiled with similar compiler options in g++ and cl might result in different behavior. Please have a copy of your compiler manual very handy.
Anytime I work on something like this I try and build it in the different environments that I want to be supported. Similarly if you were making a web page and you wanted to make sure it worked in IE, Firefox, and Chrome you'd test it in all three of those browsers. Test it in the different environments you want to support, and you'll know what systems you can safely say it works for.
question as stated is bit abstract.but you can give QT a consideration
It's really just as simple as "don't using anything platform specific". The wealth of freely available tools availalble these days makes writing cross-platform code in C++ a snap. For those rare but occasional cases where you really do need to use platform specific APIs, just be sure to separate them out via #defines or, better in my opinion, distinct .cpp files for each platform.
There are many alternatives for cross platform libraries but my personal preferences are:
GUI: Qt
OS abstraction (though Qt does a great job of this all by itself): Boost
Cross-platform Makefiles: CMake
The last one, CMake, has been a tremendous help for me over the last few years for keeping my build environment sane while doing dual-development on Windows & Linux. It has a rather steep learning curve but once it's up and running, it works exceptionally well.
You mean besides continuous integration and testing on target platforms? Or besides using design to abstract away the implementation details?
No, can't think of anything.
I am writing a small C++ program for fun and for extending my C++ skill. Since its scope is relatively small, I also planning to try out cross-platform development by making this program support both Windows and Linux.
I reckon my C++ proficiency is sitting somewhere between casual and intermediate level: OO, a bit of templates and design patterns, used STL before and trying to look into it more in details, ... However, while coding this little program, I find that the deeper I dig into C++, the more pain I feel, especially when I come to understanding and dealing with differences between different platform's/vendor's implementation.
The use of cross-platform frameworks like Qt, ACE, Boost seems help to speed up development a lot thus make life easier, but I worry if this will beat my purpose. Can somebody give some advice if there is any "best practice" for doing C++ cross-platform development? Thanks.
Can somebody give some advice if there is any "best practice" for doing C++ cross-platform development?
There are three things:
Write your own code so that it's portable
Wrap platform-specific APIs behind an abstraction/insulation/utility layer
Choose cross-platform libraries
You can choose option #2 and/or #3.
Advantages of #3 over #2 tend to be things like, "It's already written, debugged, and supported"; and the disadvantages are like, "I have to learn it, I might have to pay for it, I can't necessarily support it myself, and it may not do exactly what I want."
Developers will often prefer option #3 instead of #2, especially if it's free open source (which all three of the libraries that you cited are).
http://blog.backblaze.com/2008/12/15/10-rules-for-how-to-write-cross-platform-code/
Should provide more detail to the answers already given.
Also I suggest using existing libraries that abstract endianness, data type sizes and differences. The following should be considered before starting your cross-platform project.
GUI
Qt
XVT
wxWidgets
General Libraries/frameworks
STL (Incorporated in most platform libraries already)
Boost
Game Development
SDL
Cocos2d-x
Use gcc. It's available on both Windows and Linux and the libraries and language syntax is identical on both platforms.
For cross platform GUI applications, Qt is a good idea. There is no getting away from having a dependency on a GUI framework if you are trying to achieve platform independence.
Unless you are doing GUI stuff cross platform isn't a big problem.
There are some small issues to do with filesystems ( different / \ separators, allowed characters in filenames etc) but these are at the application level rather than the c++.
Doing major applications gets more complex, you need to handle help, file locations an possibly security and user info in a cross platform way. For simple algorithm type programming there isn't a problem.
Qt is mainly a GUI library, although it has extra cross platform filesystems stuff. STL, Boost, ACE are cross platform but that isn't there main point.
Use them! Seriously. The only reason you may not want to use them is if you plan on working in an environment where they're not available. But, given their cross-platform nature, that's not likely.
You will find that the benefit you get from using them is immense, even if they weren't cross-platform. The "best practice" you speak of is to be able to deliver your "product" as quicly and easily as possible.
I once answered a question from someone who stated he didn't want to use GUI libraries at a level above Xlib. If he'd actually ever used Xlib, he'd know the pain we'd all felt when forced to code at such a low level of abstraction. This makes about as much sense as wanting to code in assembler because C/C++?Python/Perl/everthting-else is simply a higher-level abstarction.
this answers are really good and you can make a list for find where is the beginning. but i think you should read some articles about "porting application".not relevant with cross-platform development but this can give you very large perspective about cross platform development. In cross-platform developing, one of more importing thing is memory issues like "endian" (byte order- byte order can show differences for tehnologies or platforms)
use boost. they take care of cross-platform stuff for you.
boost::filesystem is a great example
i think you can learn a lot from using ACE or equivalent libraries. they will boost your understanding of c++ and design patterns. i think this is the best thing you can do to improve your coding skills.
If your are really interested in making your code as cross-platform as possible, use as many compilers as possible. If you are using Windows and Linux, use VC and gcc, at the minimum. This will ensure that you don't use complier specific features, and that you don't rely on system specific behavior. Use more compilers (Intel, IBM, etc) and OSs (OS X, Solaris) if you have access to them.
You can try using U++ > http://www.ultimatepp.org/index.html
I was asking my team to port our vc6 application to vc2005, they are ready to allot sometime to do the same.Now they need to know what is the advantage of porting.
I don't thing they really understand what does it mean to adhere to standard compliance.
Help me list out the advantage to do the porting.
Problem I am facing are
1)No debugging support for standard containers
2)Not able to use boost libraries
3)We use lot of query generation but use CString format function that is not type safe
4)Much time is spent on trouble shooting vc6 problems like having >>
vector<vector<int>>
with out space between >>
Advantages:
More standards compliant compiler. This is a good thing because it will make it easier to port to another platform (if you ever want to do that). It also means you can look things up in the standard rather than in microsoft's documentation. In the end you will have to upgrade your compiler at some point in the feature. The sooner you do it, the less work it will be.
Not supported by MS. The new SDK doesn't work. 64-bit doesn't work. And I don't think they're still fixing bugs either.
Nicer IDE. Personally, I really prefer tabs to MDI. I also think that it's much easier to configure Visual Studio (create custom shortcuts, menu bars, etc.). Of course that's subjective. Check out an express edition and see if you agree.
Better plugin support. Some plugins aren't available for VC6.
Disadvantages:
Time it takes to port. This very much depends on what kind of code you have. If your code heavily uses non-standards compliant VC6 features, it might take some time. As Andrew said, if you're maintaining an old legacy project, it might not be worth it.
Worse Performance. If you're developing on really old computers, Visual Studio may be too slow.
Cost I just had a quick look and Visual Studio licenses seem to be a bit more expensive than VC6's.
Why VC2005? If you are going to invest the time (and testing!) to upgrade from VC6, why not target VC2008?
If you're maintaining a legacy project then there may be no advantage in porting. Simply converting projects and fixing up compiler problems could take weeks of time and introduce instability.
If you're actively developing a product then the main advantage is that you'll no longer be using a product that's over eight years old - which is clearly a good thing.
More recent versions of the Windows SDK don't work with VC6 - if you want to use the latest Windows features, you'll need a more recent compiler.
The later compilers are said to be more standards conforming. I'm sorry I can't be more specific. I do know that VC6 generates lots of compiler warnings just for using standard template classes.
If you use any external libraries that are compiled with a later compiler, you'll need to use something compatible.
Prepare for something of a harsh transition - the IDE's are more different than they should be.
To ensure complete compatibility of the application with different versions of the base platform. And to rectify any errors found thereby so as to give enough freedom to end user to use his own version of the base platform.
I'm not saying you shouldn't convert, but to take your specific points:
1)No debugging support for standard
containers
I debug code using standard containers with VC++ 6 all the time. What's your problem here?
2)Not able to use boost libraries
True. You may find you can use some of the simpler stuff.
3)Much time is spent on trouble
shooting vc6 problems like having >>
[can't get SO to stop mangling this, nb]
with out space between >>
Um, that is a syntax error (at least in the version of C++ understood by VC++6) and will be flagged as such. If your team is spending "much time" on this sort of thing, you need another team.
Edit:
3)We use lot of query generation but
use CString format function that is
not type safe
It will be equally type-unsafe under VS2005. I don't see why this is a reason for porting. If you want type safety use the standard C++ I/O mechanisms.
If your team can't see any advantage and you are unable to explain any advantage, why are you asking them to do this?
Sounds like you are porting just for the sake of it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Pros. and cons? how long do you use it? What about jambi?
I have been using Qt for several years now for commercial development and have been very happy with it.
One of the nice things with Qt is that it provides a large set of libraries as well as the GUI stuff (eg XML parsing, threads, networking), all in a consistent style and all multi-platform. This means we rarely need to use other libraries, though we do use boost for some things.
Another very important factor for us was internationalization. In a previous, MFC based application we had to maintain 2 localized versions, for the two languages we support. In our Qt based app we just have the one version.
The Qt translation system, using linguist is easy to use and makes supporting multiple languages easy (of course you still have to translate the strings which is a lot of work!)
The GUI layout system where the widgets resize themselves according to a layout makes everything much easier. In different languages the length of the strings are different. With fixed size widgets (like MFC) each dialog needs to be adjusted for each language, otherwise parts of labels get cut off. With Qt they resize themselves. Of course, there are cases when it does not work exactly right but it still makes everything much easier.
QString does everything in Unicode and handles the conversions from different codecs very easily.
One thing that has been very valuable is the access to the source, although e this is certainly not unique to Qt. On several occasions the ability to check the Qt source has explained some strange behaviour or given a clue how to achieve something.
We have found a few bugs in Qt, some of which have been fixed after reporting to Trolltech. In other cases they have suggested a work around. These have all been fairly obscure and not had a major impact on our development.
One of the main downsides to Qt would be the lack of 3rd party libraries for use in commercial applications. However, Qt is fairly complete so for us it has not been a big problem, though that will depend on which type of application you are developing.
I have not used Jambi either.
I've used Qt on a couple of projects I did in c++ on several platforms over a period of seven years. I think it works pretty well and definitely was quicker for me to develop a decent GUI app on the Mac than plodding through a language I didn't know (Objective-C) at the time.
I think the signal/slot mechanism is a bit funky but isn't horrible. Once you're use it for a bit, it's not a show stopper. The connection stuff is easy to bungle up (or at least it was) and it's always good to check the return on those because your app will go merrily on its way and not tell you that it didn't work.
I've never used jambi.
Here are some of my Pros and Cons with Qt:
Pros:
Cross-platform
I know this one is always used, but after going back and forth between Windows and Linux with Qt, it's amazing how little I have to do to get up and running. I think this is helped by the fact I only use Vim with Qt Designer.
QMake
This is one of my favorite aspects of Qt. After doing work in wxWidgets, FLTK, etc., I get so tired of messing around with different build systems and I don't want to manually create my makefiles. I currently use CMake on anything other than Qt right now, but I think I'm slowly moving even Qt over to CMake. However it's just so easy to get going with QMake.
QTestLib
I looked at a couple other C++ unit testing frameworks and when I created my tests using QTestLib, it felt very similar to NUnit(C#) and within minutes I had several passing tests. I also noticed that it would be very easy to create my own continuous integration environment.
Closest to Java and .Net in productivity
The biggest thing I hear/read people say about C++ is, "I can be more productive with Java or .Net". From personal experience I can get a prototype of an application running in Qt using Vim and Qt Designer, before Eclipse or Visual Studio even load. I also get a very similar set of libraries in Qt that I have in .Net or Java and if it's not there I can leverage the existing C++ code out there.
Cons:
Price
This is the biggest factor I can think of right now. However, the cost is worth every cent, um if I knew how many cents I had to save up without making a call to a sales rep. I purchased a license back in the day when they had their small business discount and it was worth it then, I would've paid three times as much and I think that's the current price.
Develop anywhere with commercial license
I would love to be able to develop on any platform, but build and sell for another platform. For example, develop on Linux, then build and deploy on Windows if you just have the Windows commercial license. From what I know, you can only develop and build a commercial application on the platform you have a license for.
Vendor lock-in
Well sort of, this is more of a personal con. I don't like being tied to a specific vendor because I get side tracked by the company direction and product direction. TrollTech was purchased by Nokia, is this good or bad I don't know, but a company that size can do evil things.
I think I'm done for now :). Oh, I haven't used Jambi but I'm really interested in doing a couple prototype projects to find out how easy it is to use a plugin developed in C++ with Jambi. Especially using Jambi as a web interface with C++ plugins.
To be honest I haven't read much on it, so it may be impossible or very easy.
I used Qt in a previous job. I'd only had the absolute briefest of contact with Qt several years prior to that, so I was pretty much a Qt newb.
When I started I was told to choose my language and environment, but cross-platform support was desirable. I tried Qt and Java, and even gave C# a go just for the heck of it. I gave myself two days to evaluate each option.
Maybe I was slightly biased with my history as a C++ developer, but after spending time on each option Qt was the only one that showed any hints at being useful without a long learning curve.
The documentation provided with Qt and the example applications made it very easy for an experienced developer but Qt beginner to get up and running very quickly. I had UI prototype/mockups of the end application done by the end of my trial period. With Java/Eclipse, Java/SunStudio and C#/VS.net I had trouble getting anything nontrivial happening in that time.
Signals/slots took some getting used to, but it wasn't too bad, and I wrote some simple wrappers to assert when connections failed to stop silly typos from stopping the app. from working.
The other thing I liked is that Qt had almost everything I needed. You name it - storage, networking, GUI, threading, containers - Qt has a class to deal with it. Which IMHO is important because mixing libraries can sometimes cause problems.
Having the source code to Qt was a big plus, one for just plain interest's sake, but also it allowed me to compile Qt using the compiler and settings of my choosing, including a debug version for use during development.
I also found Trolltech's support to be fairly good. I raised a couple of bugs on Qt, one of which was fixed and released whilst I was still working on the project (only a 6 month job).
The only negative I can recall was the difficulty in debugging Qt objects (using VS) - there is a Qt plugin for VS that can examine Qt objects but I was using the free version of VS and plugins don't work for it. But that wasn't Qt's fault.
I haven't used jambi so can't comment.
On C++ your only other alternatives are MFC and wxWidgets.
QT / wxWidgets is largely a personal preference. I do think QT is a clean design with good documentation.
QT costs about one month of developer salary if you aren't using it for GPL.
I have been using Qt for over two years now.
Things I like on Qt are:
Easy GUI programming (compared to
MFC), Qt Designer
Nice container classes
Nice graphics scene framework
Excellent documentation with useful examples
Translation support
Good technical support
I can highly recommend the Qt Developer Days. If you have a chance to take part, then do it! Lots of nice and very interesting talks there.
Qt is a very nice library, but it has an expensive per-seat developer license, so it's not always useful for all projects.
Don't use it, however...
Pro:
QT has an optional 3 phase layout, where as WX only allows for 2 currently (I believe they plan to do 3 phase, just have not worked it in yet).
One of the bigger problems with using layouts is static text and wrapping. WX asks how big is your min width/height and portions out the screen, QT has option to say how wide do you want, how high do you need to be if your X wide. This allows you to express the flow of a page much better.