Linked by Andrew Youll on Mon 8th Aug 2005 06:05 UTC, submitted by Mirek Fidler
General Development Ultimate++ 0.98.7 was released. Ultimate++ (U++) is an attempt to provide the optimal Windows/Linux development platform based on C++. By utilizing of new ideas in C++ development, Ultimate++ achieves significant reduction of source code complexity for most applications when compared to other development platforms. To get a clue how development using U++ looks like, see this example.
Thread beginning with comment 15545
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Ultimate++ vs. VCF
by rover on Mon 8th Aug 2005 17:29 UTC in reply to "RE: Ultimate++ vs. VCF"
rover
Member since:
2005-08-07

Well, there was bug in pre 0.98.7 release that caused linux builds to slow down.

I'll try the new release. But I tried it under Windows.

Generally, U++ builds are faster than anything else thanks to blitz-build technology, but first builds e.g. after download might be slower - U++ does not ship with prebuild libraries, so that first build has to build everything.

They were not fast in my experience. I'll try again. Any common misconfiguration I should be aware of?

Any reason not to include prebuilt libraries?

Well, the basic set (CtrlLib) contains about 100 different widgets.

Those accesible from the all menu in the GUI are only 26. I can mention at least a dozen commonly used GUI elements that do not appear in the demos.

Also:

How well does it play with alternative (read better than make) build systems. scons? jam?

Reply Parent Score: 1

RE[3]: Ultimate++ vs. VCF
by on Mon 8th Aug 2005 19:33 in reply to "RE[2]: Ultimate++ vs. VCF"
Member since:

> I'll try the new release. But I tried it under Windows.
> They were not fast in my experience. I'll try again. Any common misconfiguration I should be aware of?

Well, I think that subscribing U++ mailing list is the best option here.

> Any reason not to include prebuilt libraries?

Because that is not how U++ works. You are actually at any time working with complete sources of U++ + your app. Existence of .lib (.a, .so) files is just an implementation detail of build process.

> Those accesible from the all menu in the GUI are only 26.

Only most often used are there now. Also, some often used widgets, like Splitter, are not typically used in layouts (that is why it is missign as well).

That said, I do not say that there are missing widgets. OTOH, implementation of widgets is usually quite easy (one of primary U++ design goals). E.g. Button implementation has about 40 lines....

> How well does it play with alternative (read better than make) build systems. scons? jam?

You are on your own. Anyway, the original purpose of TheIDE is to be THE alternative build / project management system. Try to learn something about packages, dependencies, building and blitz, you might (or might not...) like it.

Reply Parent Score: 0

RE[4]: Ultimate++ vs. VCF
by rover on Mon 8th Aug 2005 23:00 in reply to "RE[3]: Ultimate++ vs. VCF"
rover Member since:
2005-08-07

You are actually at any time working with complete sources of U++ + your app. Existence of .lib (.a, .so) files is just an implementation detail of build process.

I'd like to link against a dinamic library without having to rebuild the whole U++ every time. Is there a upp.dll or something?

Only most often used are there now.

This fact should be documented somewhere.

I don't like the way U++ ties you to a particular development environment. While TheIDE seems ok, having more choice is good. In particular, I want to be able to use my editor and my build system (vi and scons). But this doesn't seem to be very easy. I took a look at the generated Makefile, it is 300KB! Any chance U++ developers dump the aging make in favor of a more modern alternative? It seems to me that you are pushing make to its limits. I recomend jam or scons.

There's another thing that is bugging me: This Esc language that comes with the library. I don't think we need yet another scripting language. A more sensible alternative would be to provide the required hooks to embed a language and let the people do it. There are more than enought python/tcl/perl/javascript/etc zealots out there who would do this even if they don't plan to use U++.

Otherwise this seems like a very good library. I'm eager to give it a try.

Reply Parent Score: 1