Ultimate++ another Cross-Platform Framework for C++

[Masterx]

Hello all .
has anyone had any experience with this framework ?
how is it compared with Boost, Wxwidgets or Qt?
is it wise to use it in a practical environment ?
i had a look at their samples on their main page and i must admit they are really easier to code compared to Wxwidgets with its weird naming styles !
creating a window and or any other GUI related control was a breeze never seen anything that simple any where !
example:

#include <CtrlLib/CtrlLib.h>
 
using namespace Upp;
 
class MyApp : public TopWindow {
        Button button;
 
        void Click() {
                if(PromptYesNo("Button was clicked. Do you want to quit?"))
                        Break();
        }
 
        typedef MyApp CLASSNAME;
 
public:
        MyApp() {
                Title("Hello world");
                button.SetLabel("Hello world!");
                button <<= THISBACK(Click);
                Add(button.HSizePos(100, 100).VSizePos(100, 100));
        }
};
 
GUI_APP_MAIN
{
        MyApp().Run();
}

the IDE is kinda suck though ,its code generating is way far from complete , and almost you need to type everything , though there is a primitive GUI designer plus a code-completion feature (called assist++ ) .
One can live with that but what matters here is that whether they are flexible , well-written and of course supported well on a variety of platforms .
here its their homepage in case you haven't seen it before :
Ultimate++ is a C++ cross-platform rapid application development framework :: Ultimate++

thanks in advance

[phantomotap]

O_o

It doesn't compare with "Boost" at all. "Ultimate++" offers a several facilities that are similar to what "Boost" offers, but "Ultimate++" is principally a GUI framework and "Boost" has no such facilities.

I prefer both "Qt" and "wxWidgets" over "Ultimate++". I know what secrets lie in the heart of... "Ultimate++" implementation techniques. The concepts are fine and have their use, but they have no business being part of a GUI framework.

Soma

[Masterx]

O_o It doesn't compare with "Boost" at all. "Ultimate++" offers a several facilities that are similar to what "Boost" offers, but "Ultimate++" is principally a GUI framework and "Boost" has no such facilities. I prefer both "Qt" and "wxWidgets" over "Ultimate++". I know what secrets lie in the heart of... "Ultimate++" implementation techniques. The concepts are fine and have their use, but they have no business being part of a GUI framework. Soma

Thank you Soma and what exactly do you mean by this part?

The concepts are fine and have their use, but they have no business being part of a GUI framework.

[Cynic]

Thank you Soma and what exactly do you mean by this part?

I would like to know also.

[MK27]

I know what secrets lie in the heart of... "Ultimate++" implementation techniques. The concepts are fine and have their use, but they have no business being part of a GUI framework.

Perhaps...

ULTIMATE EVIL

[phantomotap]

ULTIMATE EVIL

Well, that is exactly what I meant, but it gets worse!

No, really, I'm simply talking about well known problems and why they aren't acceptable here.

Before I get started, keep in mind that I love templates and meta-programming. I tend to reach for C++ by default because C++ has those features I find myself needing fairly regularly. I'm just not some fool "fanboy" who doesn't recognize problems. When source can fully benefit from templates the associated problems are only at best tolerable. That's it: "tolerable". That's the best that can be said. When source doesn't actually benefit from templates (take a good look at raw typed allocator designs that when they could easily be normal classes) or only tangentially benefit from templates (take a good look at `std::string') the problems are horrid.

The point to what I said is that while templates offer a wonderful and unique implementation mechanism the problems that arise when you mix templates, macros, and the wonderful world of... the real world you get a lot of problems passed along to clients of the code from a GUI toolkit doesn't actually benefit from using templates as an implementation technique.

"Ultimate++" simply doesn't do anything so spectacular with templates to have forced those problems on client code.

I could literally talk for pages/hours about this, but I'll limit myself to a few choices that creep up to knee programmers most often.

Violating the unique definition rule: because of the way compilers compile templates linkers must treat template expansions uniquely which when coupled with macros means that common design patterns may silently violate this rule and neither the compiler or linker can complain. (It is important to note that I said "can"; most suites simply don't have any mechanism to verify correctness and only assume based on the mangled names of expansions.) Violating this may or may not be a issue which is really the biggest problem. It could work fine; it could randomly fail because of an invalid expectation; it could silently fail without any obvious reason that normal use of a debugger can't tell you. You can reduce this problem with liberal use of "rebuild all" when starting to resolve new bug tickets.

The winner of the worlds worst error messages: macros can result in error messages that are difficult to track down all by themselves but by combining them with templates you get nonsense that can take ages to work out. It wouldn't be as big a deal as it is but build systems don't know templates meaning a lot of needless "rebuild all" when tracking down errors or manually writing headers that only serve to notify the build system of a components dependance and with template specialization involved dependencies can be "interesting".

Soma