|
|
|
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  |
 |
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 #4276 is a reply to message #4274] |
Mon, 31 July 2006 10:10  |
 |
mirek
Messages: 13975
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  . 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 |
|
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"...
That means, more programmable, flexible and managable "spaggetti" relations strengths beetween objects in u++ than BOOST... ?
(I'm trying to find "visual understanding"... )
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Materials for articles: "U++ Core comparison to BOOST" [message #4296 is a reply to message #4291] |
Mon, 31 July 2006 21:31 |
|
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 |
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Apr 19 11:37:03 CEST 2024
Total time taken to generate the page: 0.03476 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
