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 » Coffee corner » Which is the biggest drawback of U++ "unpopuliarity"?
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #7519 is a reply to message #7377] Thu, 04 January 2007 08:17 Go to previous messageGo to next message
agent86 is currently offline  agent86
Messages: 11
Registered: December 2006
Location: San Francisco
Promising Member
Thanks for the response. I had no idea that all that information was sitting behind the Ctrl-Enter key.

I've seen the Topic++ entry in the Assist menu, but somehow I got the idea that it was to generate docs, not read them...

Sigh.

The list of widgets is going to be a great help. My current work involves console apps, but I have plans...

Anyway, Thanks again.

chuck

ps, I am now running 612 dev 3 on Debian Etch, Fedora Core 6, Windows 2000, and Windows XP. Seems OK except for some of the hot-key listings on the menus (eg ctrl+100dc for split horizontal).

I guess they will be resolved before the next release.

Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #7520 is a reply to message #7519] Thu, 04 January 2007 08:31 Go to previous messageGo to next message
fallingdutch is currently offline  fallingdutch
Messages: 258
Registered: July 2006
Experienced Member
Hi Chuck,

agent86 wrote on Thu, 04 January 2007 08:17

My current work involves console apps, but I have plans...


Console Apps work with Upp, too
CONSOLE_APP_MAIN{
//your code goes here ;)
}

agent86 wrote on Thu, 04 January 2007 08:17


Seems OK except for some of the hot-key listings on the menus (eg ctrl+100dc for split horizontal).

I don't know at the moment, wether this bug is already known, but i remember something with Hotkeys.

Bas

[Updated on: Thu, 04 January 2007 08:32]

Report message to a moderator

Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15406 is a reply to message #307] Mon, 21 April 2008 21:40 Go to previous messageGo to next message
indiocolifa is currently offline  indiocolifa
Messages: 49
Registered: January 2008
Location: Argentina
Member
Thanks god I've discovered U++, instead of going through the MFC-ish WxWidget route...

When 2008 is released, all the U++ community (We) should build a proper documentation. 2009 the year of Ultimate++ Twisted Evil
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15410 is a reply to message #15406] Tue, 22 April 2008 09:20 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

The most significant causes of current U++ state are it`s targeting for experienced C++ programmers and lack of adequate documentation. The first one isn`t drawback, the second one should be improved in the near future.

1) U++ is heavily targeted for experienced C++ programmers.
That`s it. And there`s no way of feeling comfortable in U++ without strong experience in C++. This is NOT a drawback, it is just a professional instrument. It mustn`t be as pretty and fancy looking as more beginner` ones. It just should work effectively.
This is what I love in U++. And, yes, it solves many problems which experienced programmers meet before U++ was created.
As for me, I can compare U++ team efforts with many others: starting with Turbo Vision (yes! good old under DOS by Borland), plain Win32 programming, custom GUI for DirectDraw, MFC, VCL (Delphi & BC++B), QT, wxWidgets - and finally U++ beats them. But it requires strong knowledge of C++ language and tricks. Because it is created with C++ tricks. So, to use it effectively, one must be good enough to understand all behind these tricks. This way you have smaller code, well organized program structure and powerful abilities of U++. Again - this professional tool mustn`t have fancy look. It must be effective. And it is - if we talk about U++ and TheIDE.

2) Currently U++ authors targeted for widening framework abilities. And for now it has no appropriate documentation/manual/help system. Current documentation state covers most of basic things about basic abilities. Everything else you should find in forum or from sources. It is drawback but Mirek promised to focus on that in next major release. I hope he will also take into consideration community` ideas about documentation.

[Updated on: Tue, 22 April 2008 09:22]

Report message to a moderator

Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15411 is a reply to message #307] Tue, 22 April 2008 14:09 Go to previous messageGo to next message
tvanriper is currently offline  tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
Member
First and foremost, the documentation holds Ultimate++ back from mainstream adoption. It took me almost a month to get mostly comfortable with the toolkit, not because it isn't easy to use, but because I had to literally study the code in order to figure out how to work with it. This acts as a barrier to entry, when you have other toolkits with far better documentation (e.g. MFC *choke*).

Next, you need to get the attention of some heavy hitters. Most of these guys, from what I can tell, hang out at boost.org. In the United States, I've worked for about five different large-ish companies, and in all of them, they held a tremendous respect for the efforts at boost.org, because of the whole peer-review system, and because often the code at boost.org makes its way into the standard library over time.

You mentioned an interest in getting Bjarne Stroustrup's attention. You can find him participating at boost.org. If you seriously want to cause Ultimate++ to be put into the standard C++ library (which would be an amazing feat for a library like this), put the library up for review.

If you do this, I can tell you right now what will happen, at least initially.

Ultimate++ will be shot down.

  1. Poor documentation; they're picky about having helpful documentation.
  2. The use of Ultimate++-centric interfaces instead of standard interfaces. More on this later.
  3. Possible portability issues.
  4. Possible size of system.
  5. namespace isn't in boost.
  6. Duplication of technologies already available in boost (e.g. boost::thread already exists for multi-threading, and boost already has a system for handling signals and slots).
  7. Difficulty in using Ultimate++ without using TheIDE. I know you're already working (or maybe finished working) on addressing this issue.


The NTL system you developed will most likely be an issue for the boost.org team, not because the underlying technology is terrible, but because the interfaces do not match the kind of interfaces used with the standard library. It doesn't 'look' like something you'd see in the standard library.

I think that's a small issue. You can accomplish both your technical goals (fast, agile code) and still have the library 'feel' like it belongs as part of the standard template library.

Although I'm confident you'd get shot down, there are several significant benefits in submitting the library for review, regardless.

  1. You'll get serious, useful information for improving Ultimate++.
  2. You'll get serious, useful exposure to a very large community of developers, some of whom are surely interested in the problems solved by Ultimate++.


Note that almost all first attempts at a library get shot down at boost.org, so it isn't necessarily a bad thing. Personally, of all the toolkits out there, this is the only one I think could come close to being put up for review at boost.org without being outright mocked. You already have the right kind of license. You tend to follow ideals that seem in line with what I've seen at boost.org. You solve a problem domain that a lot of people need solved.

However, maybe you do not have a goal to cause Ultimate++ to become part of the standard library. In that case, don't bother submitting it to boost. You'd only be wasting each other's time. Personally, I think that'd be a pity, as I think both of you (boost and Ultimate++) could benefit from each other.
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15412 is a reply to message #15411] Tue, 22 April 2008 14:44 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
tvanriper wrote on Tue, 22 April 2008 08:09


I think that's a small issue. You can accomplish both your technical goals (fast, agile code) and still have the library 'feel' like it belongs as part of the standard template library.



I am not quite sure about it being a "small issue".

IMO it all starts with reasons for String vs std::string...

Mirek
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15468 is a reply to message #15412] Fri, 25 April 2008 13:14 Go to previous messageGo to next message
tvanriper is currently offline  tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
Member
luzr wrote on Tue, 22 April 2008 08:44

tvanriper wrote on Tue, 22 April 2008 08:09


I think that's a small issue. You can accomplish both your technical goals (fast, agile code) and still have the library 'feel' like it belongs as part of the standard template library.



I am not quite sure about it being a "small issue".

IMO it all starts with reasons for String vs std::string...

Mirek

This is where the peer review system is very helpful, I think.

To get an idea of what the review system looks like, you can view past reviews online, if you like:

http://blog.gmane.org/gmane.comp.lib.boost.announce

I don't think the Egg review is the best one to examine (not enough people participated)... I'd start with the review some folks did of the Logging library, to get a flavor for how the review process helps.
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15469 is a reply to message #15468] Fri, 25 April 2008 13:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
tvanriper wrote on Fri, 25 April 2008 07:14

luzr wrote on Tue, 22 April 2008 08:44

tvanriper wrote on Tue, 22 April 2008 08:09


I think that's a small issue. You can accomplish both your technical goals (fast, agile code) and still have the library 'feel' like it belongs as part of the standard template library.



I am not quite sure about it being a "small issue".

IMO it all starts with reasons for String vs std::string...

Mirek

This is where the peer review system is very helpful, I think.



How do you think it could help to resolve this problem?

The real issue IMO is that boost is std:: extension, while U++ is std:: replacement... The basic design fundamentals and requirements are quite alien to std:: / boost concepts. Therefore I just fail to see how std:: replacement could do anything with boost.

Well, the only advantage would be to "get the attention", but I am not quite sure that is a good idea either....

(OTOH, peer review process itself is a very good idea, I wish we had something like that for U++ too...).

Mirek
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15482 is a reply to message #15469] Sat, 26 April 2008 02:36 Go to previous messageGo to next message
tvanriper is currently offline  tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
Member
luzr wrote on Fri, 25 April 2008 07:52

tvanriper wrote on Fri, 25 April 2008 07:14

luzr wrote on Tue, 22 April 2008 08:44

tvanriper wrote on Tue, 22 April 2008 08:09


I think that's a small issue. You can accomplish both your technical goals (fast, agile code) and still have the library 'feel' like it belongs as part of the standard template library.



I am not quite sure about it being a "small issue".

IMO it all starts with reasons for String vs std::string...

Mirek

This is where the peer review system is very helpful, I think.



How do you think it could help to resolve this problem?

The real issue IMO is that boost is std:: extension, while U++ is std:: replacement... The basic design fundamentals and requirements are quite alien to std:: / boost concepts. Therefore I just fail to see how std:: replacement could do anything with boost.

Well, the only advantage would be to "get the attention", but I am not quite sure that is a good idea either....

(OTOH, peer review process itself is a very good idea, I wish we had something like that for U++ too...).

Mirek


If I have it right, your primary concern with std:: involves its relatively terrible performance, and I think the technical issue had to do with the way you manipulate memory. If that's the concern, someone could potentially help you find a way to achieve the same performance you currently get with NTL, while using a more std::-like interface.

I could, of course, be mistaken. I'm not completely clear on why you feel these are so incompatible... as perhaps I'm not 100% clear on your design goals, or I'm ignorant of the fundamental problem you see in std::. I've read and re-read this page, but I still can't quite see how U++ and std:: can be so incompatible that there's no hope of improving the std::-style system to the point of matching U++ performance. I've certainly seen quite a few tricks used at boost:: that involved improving performance in a variety of ways (sometimes by providing a replacement for an existing library in std::, I think)... I should think they'd take quite a bit of interest in your techniques, and could possibly figure out a way to keep the same performance while making fewer changes to the existing interfaces.

I only pose this idea because it feels to me like you and boost have similar goals. I could, of course, be wrong. I know, for example, that boost has less of an emphasis on performance and more of an emphasis on their idea of 'correctness', so you may differ significantly there. (This is certainly not to say you have no concern for 'correctness', but that you may have a slightly different idea of what is 'correct' from boost).

You can best decide for yourself whether or not to approach them by reading some of the reviews people have left, and examine the decisions used to arrive at their conclusions.

Regardless, you could probably have your own peer-review system... it'd be interesting to see how people here would work with that. At the very least, such a system might help you gain some continuity between various objects in the U++ system.

As for gaining the attention of some of those heavy-hitters... well, there can be positive and negative results, to be sure. I thought it was possibly of interest to you only because you had mentioned attracting the attention of Stroustrup.

Perhaps someone could submit an article to Dr. Dobb's Journal showcasing the use of Ultimate++; that's a fairly popular magazine, at least here in the United States (the CUJ folded to Dr. Dobb's a few years ago, sadly, or I would have recommended it instead).
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15485 is a reply to message #15482] Sat, 26 April 2008 03:23 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
Quote:


I could, of course, be mistaken. I'm not completely clear on why you feel these are so incompatible...


http://www.ultimatepp.org/srcdoc$Core$NTLvsSTL$en-us.html

I agree the interfaces could have been much more similar, no matter how much it differs inside.
Also in U++ there are still some inconsistencies across different APIs for similar things, so even if it has to be different from std::, at least some things should be united in the future.
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15488 is a reply to message #15482] Sat, 26 April 2008 08:11 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
tvanriper wrote on Fri, 25 April 2008 20:36


If I have it right, your primary concern with std:: involves its relatively terrible performance,



Well, not really. If am to put it in a very simple way, the main problem with std:: is that it makes you wish the C++ had garbage collector....

Quote:


If that's the concern, someone could potentially help you find a way to achieve the same performance you currently get with NTL, while using a more std::-like interface.



Well, what would be that? Something like these macros at the end of Core/topt.h?

// STL compatibility hacks

#define STL_INDEX_COMPATIBILITY(C) \
	typedef T             value_type; \
	typedef ConstIterator const_iterator; \
	typedef const T&      const_reference; \
	typedef int           size_type; \
	typedef int           difference_type; \
	const_iterator        begin() const          { return B::Begin(); } \
	const_iterator        end() const            { return B::End(); } \
	void                  clear()                { B::Clear(); } \
	size_type             size()                 { return B::GetCount(); } \

#define STL_BI_COMPATIBILITY(C) \
	typedef T             value_type; \
	typedef ConstIterator const_iterator; \
	typedef const T&      const_reference; \
	typedef int           size_type; \
	typedef int           difference_type; \
	const_iterator        begin() const          { return Begin(); } \
	const_iterator        end() const            { return End(); } \
	void                  clear()                { Clear(); } \
	size_type             size()                 { return GetCount(); } \
	typedef Iterator      iterator; \
	typedef T&            reference; \
	iterator              begin()                { return Begin(); } \
	iterator              end()                  { return End(); } \

#define STL_MAP_COMPATIBILITY(C) \
	typedef T             value_type; \
	typedef ConstIterator const_iterator; \
	typedef const T&      const_reference; \
	typedef int           size_type; \
	typedef int           difference_type; \
	const_iterator        begin() const          { return B::Begin(); } \
	const_iterator        end() const            { return B::End(); } \
	void                  clear()                { B::Clear(); } \
	size_type             size()                 { return B::GetCount(); } \
	typedef Iterator      iterator; \
	typedef T&            reference; \
	iterator              begin()                { return B::Begin(); } \
	iterator              end()                  { return B::End(); } \

#define STL_VECTOR_COMPATIBILITY(C) \
	typedef T             value_type; \
	typedef ConstIterator const_iterator; \
	typedef const T&      const_reference; \
	typedef int           size_type; \
	typedef int           difference_type; \
	const_iterator        begin() const          { return Begin(); } \
	const_iterator        end() const            { return End(); } \
	void                  clear()                { Clear(); } \
	size_type             size()                 { return GetCount(); } \
	typedef Iterator      iterator; \
	typedef T&            reference; \
	iterator              begin()                { return Begin(); } \
	iterator              end()                  { return End(); } \
	reference             front()                { return (*this)[0]; } \
	const_reference       front() const          { return (*this)[0]; } \
	reference             back()                 { return Top(); } \
	const_reference       back() const           { return Top(); } \
	void                  push_back(const T& x)  { Add(x); } \
	void                  pop_back()             { Drop(); }


Quote:


I could, of course, be mistaken. I'm not completely clear on why you feel these are so incompatible... as perhaps I'm not 100% clear on your design goals, or I'm ignorant of the fundamental problem you see in std::.



The real trouble starts with the fact that you cannot use std::string as map keys. You cannot use any concrete class defined in std:: as element of any Vector flavor U++ container.

So far, the main "incompatibility complaint" was that "U++ guys seem to define their own containers and string". This is not easy to fix Smile

I've read and re-read [url=http://www.ultimatepp.org/www$uppweb$vsstd$en-us.html]this page[/url], but I still can't quite see how U++ and std:: can be so incompatible that there's no hope of improving the std::-style system to the point of matching U++ performance.


Ah, but you could fix std::. But it is not likely to happen.

Moreover, adopting all U++ tricks into std:: would change its semantics and break existing code.

I only pose this idea because it feels to me like you and boost have similar goals.  I could, of course, be wrong.  I know, for example, that boost has less of an emphasis on performance and more of an emphasis on their idea of 'correctness', so you may differ significantly there.  (This is certainly not to say you have no concern for 'correctness', but that you may have a slightly different idea of what is 'correct' from boost).


Oh, I have a very strong concern for 'correctness' - to the degree that I often rather break existing code by fixing some "incorrectness" in U++ Core.

Also, please, do not think I am not aware about boost or that I think these people are stupid. Of course not, boost is a very good effort and the code is pretty good.

I just feel U++ is not a good fit there. It is almost like suggesting boost to adopt Java Smile

BTW: I mostly care about "optimality" with U++. If I would care about "popularity" more, I would certainly use another path and boost would be the part of it.

Quote:


Perhaps someone could submit an article to Dr. Dobb's Journal showcasing the use of Ultimate++; that's a fairly popular magazine, at least here in the United States (the CUJ folded to Dr. Dobb's a few years ago, sadly, or I would have recommended it instead).


I guess that would be much better idea:)

Mirek
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15489 is a reply to message #15485] Sat, 26 April 2008 08:13 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mr_ped wrote on Fri, 25 April 2008 21:23

Quote:


I could, of course, be mistaken. I'm not completely clear on why you feel these are so incompatible...


http://www.ultimatepp.org/srcdoc$Core$NTLvsSTL$en-us.html

I agree the interfaces could have been much more similar, no matter how much it differs inside.
Also in U++ there are still some inconsistencies across different APIs for similar things, so even if it has to be different from std::, at least some things should be united in the future.


Definitely. This happens if you develop/extend library to solve the problem:)

Mirek
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15496 is a reply to message #15488] Sat, 26 April 2008 13:41 Go to previous messageGo to next message
tvanriper is currently offline  tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
Member
luzr wrote on Sat, 26 April 2008 02:11

tvanriper wrote on Fri, 25 April 2008 20:36


If I have it right, your primary concern with std:: involves its relatively terrible performance,



Well, not really. If am to put it in a very simple way, the main problem with std:: is that it makes you wish the C++ had garbage collector....


I can appreciate that. I get frustrated sometimes, trying to write code that doesn't require 'new' when using std::. And I strongly agree with you that an object belongs somewhere.

luzr


tvanriper


If that's the concern, someone could potentially help you find a way to achieve the same performance you currently get with NTL, while using a more std::-like interface.



Well, what would be that? Something like these macros at the end of Core/topt.h?


(I only removed the quoted code to reduce the size of the message.)

Partially... but you also appear to introduce difference concepts for use with your collections than the standard. I would expect, if you were to incorporate this into boost::, you'd provide concept-checking mechanisms that would cause clear compiler errors if someone attempted to use an inappropriate data type... one that didn't support your collections' concept.

luzr


tvanriper


I could, of course, be mistaken. I'm not completely clear on why you feel these are so incompatible... as perhaps I'm not 100% clear on your design goals, or I'm ignorant of the fundamental problem you see in std::.



The real trouble starts with the fact that you cannot use std::string as map keys. You cannot use any concrete class defined in std:: as element of any Vector flavor U++ container.

So far, the main "incompatibility complaint" was that "U++ guys seem to define their own containers and string". This is not easy to fix Smile



I do not view this, necessarily, as a problem.

I note that boost currently has specialized containers to solve specific sorts of problems. Your containers are no different in that respect.

luzr


tvanriper


I've read and re-read this page, but I still can't quite see how U++ and std:: can be so incompatible that there's no hope of improving the std::-style system to the point of matching U++ performance.



Ah, but you could fix std::. But it is not likely to happen.

Moreover, adopting all U++ tricks into std:: would change its semantics and break existing code.



Bad choice of words on my part... a consequence of trying to write quickly.

By 'improving the std::style system', I didn't necessarily mean 'replace std:: containers'. I meant that you could create another set of containers that feel std::-like, but have the qualities you prefer.

luzr


tvanriper


I only pose this idea because it feels to me like you and boost have similar goals. I could, of course, be wrong. I know, for example, that boost has less of an emphasis on performance and more of an emphasis on their idea of 'correctness', so you may differ significantly there. (This is certainly not to say you have no concern for 'correctness', but that you may have a slightly different idea of what is 'correct' from boost).



Oh, I have a very strong concern for 'correctness' - to the degree that I often rather break existing code by fixing some "incorrectness" in U++ Core.

Also, please, do not think I am not aware about boost or that I think these people are stupid. Of course not, boost is a very good effort and the code is pretty good.

I just feel U++ is not a good fit there. It is almost like suggesting boost to adopt Java Smile



Well, firstly, I apologize if I seem pushy, or condescending. I suppose I just wanted this conversation to take place, just to fully explore the idea.

Secondly, while it might be true that this is like suggesting boost adopt Java, I wanted to at least explore the idea to see if that was really true. Other folks can eventually read all of this and see that we've covered all the points to cover on the subject.

At the very least, I thank you for your patience.

luzr


BTW: I mostly care about "optimality" with U++. If I would care about "popularity" more, I would certainly use another path and boost would be the part of it.



That is understandable.

luzr


tvanriper


Perhaps someone could submit an article to Dr. Dobb's Journal showcasing the use of Ultimate++; that's a fairly popular magazine, at least here in the United States (the CUJ folded to Dr. Dobb's a few years ago, sadly, or I would have recommended it instead).


I guess that would be much better idea:)



Hmmm... well, I need to buy some issues of Dr. Dobb's Journal, review the past articles, and see what sort of article they'd accept. I could probably write something... it's been a long time since I wrote anything for a journalistic venue, but I could probably do it, if they'd accept the article.

Oh, and many thanks to mr_ped for pointing out the other link. I had read that a long time ago, but couldn't remember where I saw it.
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15511 is a reply to message #15496] Sun, 27 April 2008 16:31 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
tvanriper wrote on Sat, 26 April 2008 07:41


Well, firstly, I apologize if I seem pushy, or condescending. I suppose I just wanted this conversation to take place, just to fully explore the idea.



It is all OK. Actually, it is not bad to reiterate all these issues from time to time.

Quote:


Hmmm... well, I need to buy some issues of Dr. Dobb's Journal, review the past articles, and see what sort of article they'd accept. I could probably write something... it's been a long time since I wrote anything for a journalistic venue, but I could probably do it, if they'd accept the article.



This would be excellent. I must admit I am a little bit short of energy to do something like this (or other forms of U++ propagation), besides, 3rd party article is always better.

If you would need any help (mostly with code Smile, I would be glad to deliver Smile

Mirek
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15512 is a reply to message #15511] Sun, 27 April 2008 18:26 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
luzr wrote on Sat, 26 April 2008 02:11



BTW: I mostly care about "optimality" with U++. If I would care about "popularity" more, I would certainly use another path and boost would be the part of it.




I still do not get the strategy behind U++. You are saying you do not care about "popularity", but you have posted almost five thousand messages on this forum. It looks to me like you care very much about users and "popularity".

What "popularity" means to you? And how do you understand "optimality"?

As I understand, U++ is a self-contained application framework, which is planned with two goals in mind: performance and easiness to use.

Everything that doesn't match these goals gets ignored. That includes third-party libraries like boost, dll-based builds, makefiles for Unix and project files for MSVS.

1) Boost is not just containers and algorithms. It intersects with U++ at least in Boost.Thread, Boost.Spirit, Boost.Wave, and Boost.Function. But that is an external dependency.

2) Dll-based architecture seems to introduce some performance worsening. Automatic exporting of all classes and functions would impair optimization. Manual marking functions and classes for export would require some time, and there still be some performance worsening.

3) Project files / make files for other build systems would definitely improve popularity of U++. It could be included in popular Linux distributives. That doesn't seem to break either "popularity" or "optimality" principles. Without make files it is not possible to build U++ in regular way.

IMHO, before investing resources in making U++ more popular it is absolutely necessary to understand (and clearly explain to others) what actually U++ is, and what it is going to be. Otherwise you will just confuse new users.


Regards,
Novo

[Updated on: Sun, 27 April 2008 18:30]

Report message to a moderator

Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15513 is a reply to message #15512] Sun, 27 April 2008 18:49 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Novo wrote on Sun, 27 April 2008 12:26

luzr wrote on Sat, 26 April 2008 02:11



BTW: I mostly care about "optimality" with U++. If I would care about "popularity" more, I would certainly use another path and boost would be the part of it.




I still do not get the strategy behind U++. You are saying you do not care about "popularity", but you have posted almost five thousand messages on this forum. It looks to me like you care very much about users and "popularity".



Eh, I wanted to say that "optimality" has priority. Not that I do not care about "popularity" at all. Sure I do.

Quote:


And how do you understand "optimality"?



Something that makes my life as programmer easier.

Quote:


As I understand, U++ is a self-contained application framework, which is planned with two goals in mind: performance and easiness to use.

Everything that doesn't match these goals gets ignored. That includes third-party libraries like boost, dll-based builds, makefiles for Unix and project files for MSVS.



I guess you got it right. Although most things are now ignored only because of lack of time/energy and it seems they are going to be supplied by community over time.

Quote:


IMHO, before investing resources in making U++ more popular it is absolutely necessary to understand (and clearly explain to others) what actually U++ is, and what it is going to be. Otherwise you will just confuse new users.



I agree. Note that this thread was revived after almost a year.

In fact I am in process of reviewing U++ strategy. We are now in quite different state than 4 years ago where basically there were 2 people in the world with deep knowledge of U++. This has changed quite a lot Smile

Mirek
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #16472 is a reply to message #307] Tue, 17 June 2008 09:55 Go to previous messageGo to next message
royalstream is currently offline  royalstream
Messages: 3
Registered: February 2006
Junior Member
Hi, I'm mostly a newcomer. I say mostly because I used UPP a few years ago for some small utility apps I needed.

With that said, I really can say my eyes are fresh and I can give you my humble opinion on my second first impression with UPP Smile

First of all, I like TheIDE. Yes, its different. Yes, it looks different than Visual Studio or Eclipse. But it works and its fast and as long as I can plug-in different compilers I'm happy. My only suggestion: lets get some new icons Smile TheIDE deserves to look as good as it works.

I love the way the API avoids unnecessary heap/pointer use. This very well may be the strongest reason why I like UPP. The naming convention is also clear and modern looking.

Love the String class and the NTL is fine, even though the naming of the classes (Vector/Array/etc) doesn't suggest how or why they differ from each other.

As you can see, I'm relatively open minded to new ways of doing things. So far the only characteristic I haven't been able to "like" is the frequent use of macros, especially the APP_MAIN ones.

I'm sure the GUI_APP_MAIN macro is awkward enough to scare away some curious newbies. Keep in mind "GUI_APP_MAIN" is about one fifth of what they see when the look at your Hello World's source code.

Obviously removing it at this point is no easy task but it could remain supported for backwards compatibility while a new way is offered. I think even having to include certain header in your main code file (depending on the type of application) would look more acceptable to some people. But that's just an quick idea, maybe there are even better ways of doing it.

Just my two cents and I'm not here to criticize, I really like UPP and I'd say we really "clicked". My true wish is for it to become as widely adopted as possible.

Regards,

Steven









[Updated on: Tue, 17 June 2008 10:01]

Report message to a moderator

Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #16473 is a reply to message #16472] Tue, 17 June 2008 10:28 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

Quote:

First of all, I like TheIDE. Yes, its different. Yes, it looks different than Visual Studio or Eclipse. But it works and its fast and as long as I can plug-in different compilers I'm happy. My only suggestion: lets get some new icons TheIDE deserves to look as good as it works.

TheIDE is our target right now. Soon it will get a docking system with new quicktabs (I have some nice ideas). Mirek is trying to improve C++ parser and Topic++. Don't worry about docking. It will be possible to turn off windows headers so everyone who likes thin splitters ant take care of screen space will be satisfied. As for icons I agree - especialy in assist. We need a good painter here. For assist we could use eclipse icons. I really like them.
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #16478 is a reply to message #16472] Tue, 17 June 2008 13:46 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
royalstream wrote on Tue, 17 June 2008 03:55


I'm sure the GUI_APP_MAIN macro is awkward enough to scare away some curious newbies. Keep in mind "GUI_APP_MAIN" is about one fifth of what they see when the look at your Hello World's source code.



Well, it is not very nice indeed, but one has to consider the only possible alternative:

#ifdef PLATFORM_WIN32
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE, LPTSTR, lpCmdLine, int nCmdShow) {
    InitWin32(hInstance, lpCmdLine);
#else
int main(int argc, const char **argv, const char **envptr) {
    InitPosix(argc, argv, envptr);
#endif


That is why GUI_APP_MAIN was introduced.

Mirek

P.S.: Concerning macros, I think it is good idea to avoid them when possible. Anyway, if they can avoid repetitive tasks (and that way often bugs too), I am not the one to avoid macros just because they are "ugly".

[Updated on: Tue, 17 June 2008 13:50]

Report message to a moderator

Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #16889 is a reply to message #7377] Sat, 19 July 2008 19:47 Go to previous messageGo to previous message
TeCNoYoTTa is currently offline  TeCNoYoTTa
Messages: 138
Registered: July 2008
Location: Egypt
Experienced Member

i really dont understand why this library isnt popular

i used this library from about only one week and quickly i realized that this is the best library for my program that i want to make

Previous Topic: Fantastic work!!
Next Topic: Which Upp version do you use?
Goto Forum:
  


Current Time: Wed Apr 17 00:25:48 CEST 2024

Total time taken to generate the page: 0.80857 seconds