Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » PR, media coverage, articles and documentation » Materials for articles: "U++ Core comparison to BOOST"
Materials for articles: "U++ Core comparison to BOOST" [message #4271] Mon, 31 July 2006 01:07 Go to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
from wikipedia:
Quote:


Boost provides extension libraries in the following areas:

Algorithms
Concurrent programming (threads)
Containers
Correctness and testing
Data structures
Function objects and higher-order programming
Generic programming
Graphs //aris "no in U++" remove completely?
Input/output
Interlanguage support (for Python) //aris: not yet in U++
Iterators
Math and Numerics
Memory
Misc
Parsers
Preprocessor Metaprogramming
Smart pointers (shared_ptr), with automatic reference counting[2]
String and text processing
Template metaprogramming
Workarounds for broken compilers



I think we could provide a similar list but maybe just re-ordered in terms of importance for u++...
Some short comments would be good...
I think u++ vs BOOST is also important...

[Updated on: Mon, 31 July 2006 01:08]

Report message to a moderator

Re: Materials for articles: "U++ Core comparison to BOOST" [message #4272 is a reply to message #4271] Mon, 31 July 2006 01:24 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
from u++ homepage
Quote:


NTL is a library of container and algorithm templates. It is designed to solve some problems we see in current C++ standard library STL.



Would it be reasonable to somehow structuraly emphasize NTL part in the list of all Core pieces?
Re: Materials for articles: "U++ Core comparison to BOOST" [message #4273 is a reply to message #4272] Mon, 31 July 2006 01:27 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
What are BOOST problems in the eyes of u++?
Re: Materials for articles: "U++ Core comparison to BOOST" [message #4274 is a reply to message #4273] Mon, 31 July 2006 01:49 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
Is smart (shared) pointers of BOOST not enough to solve "value transfer semantics"? What advantages have Ptr / Pte? over them?
Re: Materials for articles: "U++ Core comparison to BOOST" [message #4275 is a reply to message #4274] Mon, 31 July 2006 02:41 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
fudadmin wrote on Mon, 31 July 2006 00:49

Is smart (shared) pointers of BOOST not enough to solve "value transfer semantics"? What advantages have Ptr / Pte? over them?


Or maybe a better question:

Do BOOST and STL "share" a legacy of beeing on average at least 2 times slower than U++ counterparts making some assumptions from:
http://www.ntllib.org/benchmark.html
?
Re: Materials for articles: "U++ Core comparison to BOOST" [message #4276 is a reply to message #4274] Mon, 31 July 2006 10:10 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13984
Registered: November 2005
Ultimate Member
fudadmin wrote on Sun, 30 July 2006 19:49

Is smart (shared) pointers of BOOST not enough to solve "value transfer semantics"? What advantages have Ptr / Pte? over them?


The difference and the main problem from my view is that

- boost smart shared pointers are "shared"
- boost smart shared pointers are "pointers"

It complicates the design because the entity represents both the pointer AND object and can be owned by more than single entity (something belongs everywhere Smile. You have e.g. to watch carefuly for cyclical references, you have to alter your algorithms so that they work on pointers rather than on object itself.

Often, you never know when instance really is destructed due to "shared" nature of pointer.

Note that Ptr is quite different beast - it is just pointer, does not have any influence of pointee lifetime.

Anyway, Ptr to some degree represents "inverse" problem that U++ has.

In classic GC and also with boost-like smart pointers to some degree, you always know that as long as something points to object, the object itself exists. Means there are no dangling pointers possible. Con in such arrangement is that destructors are not really possible, which leaves you with manual non-memory resources management.

As U++ has taken opposite direction in resource management, using deterministic destructor cleanup, it has potential for dangling pointers. While in most situations this is really not a big trouble (as usually lifetime of pointer does no extent beyond lifetime of pointee), there are a couple of situation, esp. in CtrlCore, where situation is too fuzzy. Therefore Ptr/Pte - pointers that go NULL if pointee dies.

Mirek

[Updated on: Mon, 31 July 2006 10:10]

Report message to a moderator

Re: Materials for articles: "U++ Core comparison to BOOST" [message #4277 is a reply to message #4276] Mon, 31 July 2006 11:20 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
Mirek, has anyone ever done any performance comparisons between u++ and BOOST? If not, what assumtions could be drawn?
Or, from what you've said, is a short short conclusion correct:
1. "while performance u++ vs. BOOST is the same (or very similar?), u++ reduces code, programmers headeaches and program memory.
And (AFAIK,) for big projects smaller memory usage leads to speed improvements."

2. Or "Do BOOST and STL "share" a ANY legacy of beeing on average at least 2 times slower than U++ counterparts"?

P.S.
3. Also, in other words,( as I understand):
in some cases U++ objects behave like very quick "full occupants" and destroy everything what belongs to them (and/or(?) only inside of them?),
in other (which?) cases they can be told by a programmer "be generous, don't care, "they will die themselves"... Smile
That means, more programmable, flexible and managable "spaggetti" relations strengths beetween objects in u++ than BOOST... ?
(I'm trying to find "visual understanding"... Smile)
Re: Materials for articles: "U++ Core comparison to BOOST" [message #4280 is a reply to message #4277] Mon, 31 July 2006 12:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13984
Registered: November 2005
Ultimate Member
2.: "average" is too strong word here. In some particular cases, U++ containers are much faster (e.g. Vector<String>::Insert), in some very specific cases, they can be slightly (say 5%) slower due to different featureset. The lesson to learn is that you do not pay the price for relative simplicity. And sometimes you can even gain the speed while using simpler to use library.

Mirek
Re: Materials for articles: "U++ Core comparison to BOOST" [message #4281 is a reply to message #4280] Mon, 31 July 2006 12:57 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13984
Registered: November 2005
Ultimate Member
...and the legacy STL has is "copy requirement". In other words, STL performs a lot of copies of elements in containers.

Mirek
Re: Materials for articles: "U++ Core comparison to BOOST" [message #4289 is a reply to message #4281] Mon, 31 July 2006 17:16 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
luzr wrote on Mon, 31 July 2006 11:57

...and the legacy STL has is "copy requirement". In other words, STL performs a lot of copies of elements in containers.

Mirek


And BOOST "sits" on STL with all the consequences Smile ...?
Re: Materials for articles: "U++ Core comparison to BOOST" [message #4291 is a reply to message #4289] Mon, 31 July 2006 18:03 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13984
Registered: November 2005
Ultimate Member
Well, there is much more in boost than STL related stuff....

Thinking about it, second STL feature that is not necessary in NTL is iterator concept.

Sure, any container library needs a way how to identify element. The reason why NTL does not need iterators is the invention of Index - associative container with random access.

Now considering boost, there really is a lot of stuff that somehow deals with those two STL features. On one side there are smart pointers that try to defeat copy problem. On other side there are endless attempts to introduce lambda calculus to easen iterator deadly syntax...

Mirek
Re: Materials for articles: "U++ Core comparison to BOOST" [message #4296 is a reply to message #4291] Mon, 31 July 2006 21:31 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
Please have a look at
http://en.wikipedia.org/wiki/Ultimate%2B%2B
and correct any mistakes:
Quote:


Ultimate's "Core" package extends the functionality of C++ with extensive use of templates similarly as Boost libraries.

The base for the fundamental differences between any C++ "container based" libraries, however, is the use and legacy of STL.

There are at least 2 fundamental innovations in Ultimate's "Core" (NTL):
1. "picked behaviour" - architectured "to be in harmony" with STL containers "copy requirement" but to improve performance by avoiding "memory traffic" while copying elements of containers.
2. Index (an associative container with random access) -designed to make STL iterator concept (and syntax) a reduntant balast and to free a programmer from most to it related problems which STL derivative libraries users including Boost libraries are bound to deal with.



Edit:
P.S
And suggest what else to mention/extend...

[Updated on: Mon, 31 July 2006 21:57]

Report message to a moderator

Re: Materials for articles: "U++ Core comparison to BOOST" [message #4299 is a reply to message #4296] Mon, 31 July 2006 23:42 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13984
Registered: November 2005
Ultimate Member
May I rather suggest to start with something else? I do not think boost comparison or history is the most important thing right now.

Having implemented SVG import, you must now understand U++ XML quite well and have it fresh in memory. What about writing nice short tutorial (like the one about NTL or that one unfinished about GUI)?

I think we should rather concentrate on things like this.

Speaking about it, I have established new nest (and assembly) for tutorial examples. So if you would proceed, example packages should be named XML01, XML02 etc...

Mirek
Re: Materials for articles: "U++ Core comparison to BOOST" [message #4303 is a reply to message #4299] Tue, 01 August 2006 00:09 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
luzr wrote on Mon, 31 July 2006 22:42

May I rather suggest to start with something else? I do not think boost comparison or history is the most important thing right now.

Having implemented SVG import, you must now understand U++ XML quite well and have it fresh in memory. What about writing nice short tutorial (like the one about NTL or that one unfinished about GUI)?

I think we should rather concentrate on things like this.

Speaking about it, I have established new nest (and assembly) for tutorial examples. So if you would proceed, example packages should be named XML01, XML02 etc...

Mirek



Before writing about any GUI or other parts I wanted myself to be "crystal clear" if I understand correctly the fundamentals of U++... and why U++ Ctrls (widgets) are faster than those of other toolkits...
And, I guess, I would also have progressed faster with U++ if I had found easy explanations earlier...

P.S.
Maybe just a few more words for Ultimate's GUI section to wikipedia today?
What do you think?
I'll have to be off-line tomorrow...
Re: Materials for articles: "U++ Core comparison to BOOST" [message #4314 is a reply to message #4303] Tue, 01 August 2006 08:14 Go to previous message
mirek is currently offline  mirek
Messages: 13984
Registered: November 2005
Ultimate Member
Then of course it is a good oportunity to discuss. I was afraid that we are gathering resources for "great BOOST U++ comparison article" which is a bit scary idea to me.

As for U++ widgets being faster... Well, first of all, I am not quite sure they are necessary faster Smile

Easier to use, producing more compact and easier to maintain code for large apps, that is the design goal.

But of course, we are trying hard to be fast too. Concerning widgets, the most impact has effective repainting.

Also worth noting is that regular U++ widgets are not implemented as host platform widgets - in other words, for host platform it looks like U++ window is covered by single big widget. That might make things less resource intensive as well (sizeof(Ctrl) is now around 100 bytes, that are all resources needed for widget to exist).

Mirek
Previous Topic: Materials for Articls: "Ultimate++ history and design fundamentals"
Next Topic: U++ connection with other tools...
Goto Forum:
  


Current Time: Wed Jun 12 17:06:28 CEST 2024

Total time taken to generate the page: 0.02083 seconds