|
|
Home » Community » Coffee corner » Which is the biggest drawback of U++ "unpopuliarity"?
|
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #7520 is a reply to message #7519] |
Thu, 04 January 2007 08:31   |
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 #15410 is a reply to message #15406] |
Tue, 22 April 2008 09:20   |
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   |
 |
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.
- Poor documentation; they're picky about having helpful documentation.
- The use of Ultimate++-centric interfaces instead of standard interfaces. More on this later.
- Possible portability issues.
- Possible size of system.
- namespace isn't in boost.
- 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).
- 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.
- You'll get serious, useful information for improving Ultimate++.
- 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 #15468 is a reply to message #15412] |
Fri, 25 April 2008 13:14   |
 |
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   |
 |
mirek
Messages: 14257 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   |
 |
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 #15488 is a reply to message #15482] |
Sat, 26 April 2008 08:11   |
 |
mirek
Messages: 14257 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 
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 
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 #15496 is a reply to message #15488] |
Sat, 26 April 2008 13:41   |
 |
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 
|
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 
|
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   |
 |
mirek
Messages: 14257 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 , I would be glad to deliver 
Mirek
|
|
|
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #15512 is a reply to message #15511] |
Sun, 27 April 2008 18:26   |
Novo
Messages: 1430 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   |
 |
mirek
Messages: 14257 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 
Mirek
|
|
|
Re: Which is the biggest drawback of U++ "unpopuliarity"? [message #16472 is a reply to message #307] |
Tue, 17 June 2008 09:55   |
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 
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.
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   |
|
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   |
 |
mirek
Messages: 14257 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
|
|
|
|
Goto Forum:
Current Time: Fri May 09 15:46:25 CEST 2025
Total time taken to generate the page: 0.01456 seconds
|
|
|