I know Wt is the most stable of them, but it's a bit uncomfortable to use.
CppCMS sounds good but how stable is it? How secure is it?
I have encountered C++ Server Pages as well but there's nothing about their security in there.
Has anyone had some experience with any of those libraries and can enlight me?
First of all, several differences:
Wt is GUI like framework, it is quite far from traditional web development. So, if you
want to develop a code as if it was GUI it is for you.
CppCMS is traditional MVC framework optimized for performance, it has many features like template engines, forms processing, i18n support, sessions, efficient caching and so on, support of various web server APIs: FastCGI, SCGI and CGI. If you come for Django world, you would find yourself at home.
I'm less familiar with the third project, but it feels more like PHP -- you put the
C++ code inside templates and has no clear separation of View and Controller.
Stability, I can tell only about CppCMS, it is stable, and there are applications running
it 7/24, the authors blog and the Wiki with documentation of CppCMS are written in CppCMS.
So, there shouldn't be major critical bugs.
Disclosure: I'm developer of CppCMS.
I am the developper of libapache2-mod-raii and I am very disappointed we did not recommend this library for production work... Cause I do ! :)
I also like to point out that the project page is also available in English.
On the other hand, I do not agree with Steve about the fact that servlets are not compiled on the fly, as they are !
Otherwise, on the lacks of prefork support is not my point of view, although I was looking on the issue.
On a side note, I used mod_raii a while ago to rapidly port some parts of an existing C++ application on the web.
It takes exactly the same approach than JSP, with the whole compilation part delegated to the Apache module.
I cannot recommend it for production use, since I don't have much experience in it, but it is definitely something worth playing around with, and I didn't have any issue at the time.
It lacks some features like the support of a preforked apache, but has all the needed core features.
Answer from 2018:
I am running on limited hardware resources, so C++ is the first thing I think of. I made a decision by looking at this benchmark of web frameworks. cutelyst (a Qt derivative) and Wt dominate the top spots. They are all non-libre. So, I looked into treefrog. Right after its first and only tutorial, it is apparent that it uses qmake from Qt and thus Qt's LGPL applies.
I reluctantly go with CppCMS at the bottom of the list, as ffead has too many errors and poco is not a fullstack framework.
Diving into the tutorials, CppCMS is way ahead of treefrog when it comes to documentations. The first several tutorials are easy to follow. However when I start encountering problems, help is almost non-existent. I can't imagine how it would be like going with treefrog to get something done. Lack of documentations (and good ones) is the reason why I dumped it in the first place.
I almost dumped CppCMS also due to a serious roadblock. A tiny community cannot offer much help. Got Laravel (a very popular PHP framework) installed and about to test something. Then, the CppCMS issue seemed resolvable and I am back to it. Guess I am about to get stuffs done with CppCMS but its constraints are showing.
The incident got me thinking, and I look back at the benchmark, allowing Java and PHP to be there. I need some alternatives in case things don't work out. Lo and behold, the top three spots are occupied by Java frameworks. Laravel may not be the fastest, but it is really hot right now. Plus, I can call my C++ executables from PHP codes.
According to this discussion: if you use Qt with dynamic linking, it seems that you do not have to disclose your code if you use Qt with dynamic linking. This has to be researched, and Qt cannot be mastered within a single day. I suppose that makes cutelyst a possible choice again, IF AND ONLY IF you can do dynamic linking, and do all your things that way. I am just not a fan Qt's legal minefield and jumping hoops.
Through all this, I have a different look towards Java. Will still do Laravel because of all the rage, and I am now open to things other than C++.
Related
I have read a few articles in the cross-platform tag. However, as I'm starting a fresh application (mostly a terminal/console app), I'm wondering about the easiest way to make it cross-platform (i.e. working for Linux, Mac OS X, and Windows). I have thought about the following:
adding various macro/tags in my code to build different binary executables for each operating system
use Qt platform to develop a cross-functional app (although the GUI and platform component would add more development time as I'm not familiar with Qt)
Your thoughts? Thanks in advance for your contribution!
Edit: Sounds like there are a lot of popular responses on Java and Qt. What are the tradeoffs between these two while we're at it?
Do not go the first way. You'll encounter a lot of problems that are already solved for you by numerous tools.
Qt is an excellent choice if you definitely want C++. In fact, it will speed up development even if you aren't familiar with it, as it has excellent documentation and is easy to use. The good part about it is that it isn't just a GUI framework, but also networking, XML, I/O and lots of other stuff you'll probably need.
If not necessary C++, I'd go with Java. C++ is far too low level language for most applications. Debugging memory management and corrupt stacks can be a nightmare.
To your edited question:
The obvious one: Java has garbage collection, C++ doesn't. It means no memory leaks in Java (unless you count possible bugs in JVM), no need to worry about dangling pointers and such.
Another obvious one: it is extremely easy to use platform-dependent code in C++ using #ifdefs. In Java it is a real pain. There is JNI but it isn't easy to use at all.
Java has very extensive support of exceptions. While C++ has exceptions too, Qt doesn't use them, and some things that generate exceptions in Java will leave you with corrupt memory and crashes in C++ (think buffer overflows).
"Write once, run everywhere." Recompiling C++ program for many platforms can be daunting. Java programs don't need to be recompiled.
It is open to debate, but I think Java has more extensive and well-defined library. The abstraction level is generally higher, the interfaces are cleaner. And it supports more useful things, like XML schemas and such. I can't think of a feature that is present in Qt, but absent in Java. Maybe multimedia or something, I'm not sure.
Both languages are very fast nowadays, so performance is usually not an issue, but Java can be a real memory hog. Not extremely important on modern hardware too, but still.
The least obvious one: C++ can be more portable than Java. One example is FreeBSD OS which had very poor support for Java some time ago (don't know if it is still the case). C++/Qt works perfectly there. If you plan on supporting a wide range of Unix systems, C++ may be a better choice.
Use Java. As much bashing as it gets/used to get, it's the best thing to get stuff working across any platform. Sure, you will still need to handle external OS related functions you may be using, but it's much better than using anything else.
Apart from Java, there are a few things you can run on the JVM - JRuby, Jython, Scala come to mind.
You could also write with the scripting languages directly( Ruby, Python, etc ).
C/C++ is best left for applications that demand complete memory control and high controllability.
I'd go with the QT (or some other framework) option. If you went with the first you'd find it considerably harder. After all, you have to know what to put into the various conditionally compiled sections for all the platforms you're targeting.
I would suggest using a technology designed for cross-platform application development. Here are two technologies I know of that -- as long as you read the documentation and use the features properly -- you can build the application to run on all 3 platforms:
Java
XULRunner (Mozilla's Development Platform)
Of course, there is always the web. I mostly use web applications not just for their portability, but also because they run on my Windows PC, my Ubuntu computer, and my Mac.
We mainly build web applications because the web is the future. Local applications are viewed in my organization as mostly outdated, unless there is of course some feature or technology the web doesn't yet support that holds that application back from being fully web-based.
I would also suggest Github's electron which allows to build cross platform desktop applications using NodeJs and the Google's Chromium. The only drawback for this method is that an electron application run much slower than a native C++ application due to the abstraction layers between Javascript and native C++.
If you're making a console app, you should be able to use the same source for all three platforms if you stick to the functions defined in the POSIX libraries. Setting up your build environment is the most complicated part, especially if you want to be able to build for multiple platforms out of the same source tree.
I'd say if you really want to use C++, QT is the easiest way for cross-platform application, I found myself using QT when I need an UI even though QT has a large set of library which makes pretty much everything easier in C++.
If you don't want to use QT then you need a good design and a lot of abstraction to make cross-platfform application.
However I'm using more and more Python bindinq to QT for medium size application.
If you are working on a console application and you know a bit of python, you might find Python scripting much more comfortable than C++. It keeps the time comsuming stuff away to be able to focus on your application.
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.
STL/Boost cover all the low level stuff.
But what about the higher level concepts?
Windows: We have multiple windowing libs
KDE(Qt)
Gnome
Motif(C but written in OO style)
MS Windows
etc
But is anybody working on a unified standard for windowing?
Something that wrapped all the above would be acceptable. (even if it only accessed the common stuff it would be a starting point).
Networking:
There are a couple out there (including the Boost low level stuff).
But is there anybody working on a Service based network layer?
All the other stuff that Java/C# have in their standard libraries.
The stuff that makes it simpler for a beginner to jump in and say Wow done and it works everywhere (nearly).
Anyway. Here hoping there are some cool projects out there.
Edit
Maybe there is not one.
But if there are a couple that could be bundled together as a starting point (and potentially modified over time (where is that deprecated keyword)) into a nice consolidated whole.
Note: Windows is just a small part of what I am looking for. The Java/C# languages consolidate a lot more under the hood than just the GUI. What would be a good set of libraries to get all the functionality in one place.
There are too big differences between platforms to get a definitive C++ standard for GUI programming. I think Qt is about as close as you will get in the forseeable future. wxWidgets is another popular choise, but as I understand it, they are using less modern c++ features.
As for networking, I think you are being kind of vague. If you mean web services over HTTP, I would have a look at Pion.
Well it is almost 2010 and C++ almost has threads.
I'll probably get slammed for this but C++ moves too slow - to its own detriment and its user base. I readily acknowledge the difficulty of the technical and political issues involved but that's still the dirty reality of it. The language can't build in higher level concepts when it takes 5-10 years to agree on and implement the building blocks.
The reasons for this have endlessly debated but the sad truth is that C++ has relegated itself to a niche language. I like C++ but I look at the progress C#, Java, and even Python and Ruby have made over the last 5 years and I increasingly question whether C++ is worth the effort.
The Poco C++ project aims to deliver all that you ask, except for Windowing:
The POCO C++ Libraries aim to be for
network-centric, cross-platform C++
software development what Apple's
Cocoa is for Mac development, or Ruby
on Rails is for Web development — a
powerful, yet easy to use platform to
build your applications upon.
Qt might be the only framework complete enough to be what you suggest.
I guess there's some kind of keyword lookup driving the advertising here because I'm seeing a REALbasic ad, which is what I generally use for cross-platform GUI's nowadays.
I have spent a lot of time over the last 15 years working in C++ GUI's including retailing my own portability layer for CodeWarrior PowerPlant and working on the two Macintosh-based GUI code generators, including adding Windows generation to AppMaker. I've worked with wxWidgets, mainly wxPython. So, my opinion on difficulties in cross-platform GUI is fairly well-qualified :-)
Cross-platform GUI frameworks are hard to the point of nearly impossible without significant compromise - the issues come down to subtle matters of behavior which generally bother users at a level where some of them can't quantify but know that the application doesn't feel right. This is a lot harder to fix than just rendering native controls.
I started using REALbasic because their framework does a better job of getting the feel right than anything else I'd tried (I didn't get into Qt because of the expensive commercial license).
The reason it has taken so long for things to evolve is nothing to do with the C++ world moving slowly, it's just an intractable problem. The very best cross-platform Java apps do some stuff conditionally for OS/X and it is still screamingly obvious to an experienced user that they are not a native Mac app, although some are very usable and come pretty close to looking native - Oxygen XML editor and DeltaWalker are two of my favourites.
I don't think it is achievable to make a really comprehensive portable GUI library. Operating systems are just too different. Can you imagine a GUI library that would cover everything from iPhone to Windows 7 and wouldn't feel wierd on any of them?
A Boost gui library comes up occasionally.
The general opinion seems to be that the problems is too wide (are you targeting cellphones, FPS games or CAD workstations) and that it is too much work - Qt/wxWidgets has taken 10years.
see http://lists.boost.org/Archives/boost/2005/09/94453.php for a discussion.
It would have been nice because GUI usually means cross platform and threads, so all the GUI toolkits have invented their own cross platform,filesystem and thread classes. On the other hand if a standard GUI had been introduced in C++ it would probably look like TK !
What's so great about standardization ? Sure, if novice coders want to download one SDK to build portable apps, let them download Qt (or something similar) and forever remain within it's fine walled environment. But it'd be a tragedy if the C++ world revolved around that one library and boost and POCO and wxWidgets and clutter and blitz++ and eigen and and 101 other wonderful things (yes, gtkmm and ACE even) were stifled at birth because the gatekeepers of The Standard Library didn't see fit to admit them.
Diversity is good I think (although when dealing with it, it helps to have a good package manager; I've spent hours setting up build dependencies on Windows which just needed a few seconds of apt-getting on Debian).
ACE is great for concurrent communication and networking.
For cross platform windowing, there's wxWidgets. (formerly wxWindows).
Only everybody and his brother, but hardly any of them actually get anywhere.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
At the moment, our application uses the Trident Win32 component, but we want to move away from that for a few reasons, chief among them being our desire to go cross-platform.
We're looking at WebKit and Gecko, but I'd love to get some feedback before I make a decision. Here are some of the most important requirements:
It should be relatively fast, with a small footprint. Ideally, we would be able to trim away anything we don't need without too much effort.
Decent documentation is important. I don't anticipate needing to do anything too unusual with it, but you never know.
We're using C++, and would like to work with a well-designed object-oriented architecture, if possible.
Cross-platform is a must, and good performance would be helpful in the long run (we may end up porting to mobile platforms).
Are there any considerations I need to take into account before making a decision? Has anyone worked with WebKit or Gecko before? If so, are there any articles or tutorials I might find useful?
Update:
Thanks for the responses guys. We ended up going with Qt 4.5, which includes WebKit. We're really pleased with it so far, in fact I think Qt is probably the best UI framework I've ever used; the difference between coding with the native Win32 APIs and this is staggering. It's also real easy to learn, the only major issue we had was getting used to the signals/slots paradigm.
A little history might help in your decision. When Apple was considering which engine to use in making Safari they looked at Gecko, but decided to go with KHTML, fork it and called it WebKit. Their reasons for doing this was that Gecko had tons of legacy cruft still leftover from Netscape and was far more complicated.
KHTML/WebKit was newer, and thus had less legacy. It was also cleaner, quicker, and better documented.
One of the goals of Firefox 3 was to clean up the codebase and simplify it. From what I've heard they did do this, but I don't know how it compares with current iterations of WebKit. It apparently wasn't enough for Google when they made Chrome, and they have a significant stake in Firefox.
See here for more details.
I am biased, but if you do not mind using (LGPL-ed) Qt, what about using QtWebKit? It is fairly easy to embed, cross-platform of course, has a nice web browser demonstration, and also other related examples.
It depends on your needs. Even Webkit can be overkill if you just want to display plain-old HTML. In some of my applications I use wxHTML instead. It's a component from wxWidgets library (not sure if you can use it without wx though). It's lightweight, supports just basic HTML stuff (some CSS support might be available in the next version), and has a really nice wxHtmlEasyPrinting control which gives nice print preview and also prints very well. As for cross-platform, wxWidgets works on Windows, Linux, Mac, and some other systems, so that would surely fit your requirements.
I don't recommend going down the Gecko road. It is possible to integrate it, but it's much harder to do than KHTML/Webkit - simply because Gecko was not built with embedding in mind.
I think I would suggest Safari/Chrome's WebKit engine which was derived from KHTML, the Konqueror rendering engine.
Try to opt for Webkit as it is used by many different browsers (Konqueror, Safari and Google chrome). This makes Webkit more versatile and more adaptable to other needs.
The development of Gecko is very tied with Firefox. A lot of modifications made to Gecko are done because Firefox dictates them. For instance, Firefox 3 decided that it was going to block all self signed certificates for security purposes. The implementation has been done into Gecko's engine which means that any application that decides to embed Gecko has this security constraint added to them.
If you can stay with Webkit as it mainly a rendering engine for HTML pages. That's been developed with the intention to be used among different web browser. While Gecko is primarily the rendering engine of a single browser which just happens to offer an API for embedding.
My understanding is Webkit is pretty good & smaller than Gecko. Gecko is supposed to have had a revamp recently which makes it fairly comparable, though.
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.