porting from C++Builder

[=?Utf-8?B?ZW1hdmlzdQ==?=]

Dear guys,
I'm in trouble having to port my project from C++Builder6 to VisualC++.
Has anyone of you idea if there are any tools to help my doing this job?
My current project is widely using VCL and these 2 IDE (C++Builder and
VisualC++) seems to be so far each other that I can hardly think to find out
a tool to "automatically" perform something for me.
Thank you.

[David Wilkinson]

emavisu wrote:

Dear guys,
I'm in trouble having to port my project from C++Builder6 to VisualC++.
Has anyone of you idea if there are any tools to help my doing this job?
My current project is widely using VCL and these 2 IDE (C++Builder and
VisualC++) seems to be so far each other that I can hardly think to find out
a tool to "automatically" perform something for me.
Thank you.

emavisu:

Visual C++ is a compiler, not a GUI framework. It is actually a compiler for
three languages: C, C++ and C++/CLI.

If you want to create a GUI program using Visual C++ you have to decide whether
you want a plain Win32 application (using C or C++), MFC application (using
native C++) or a .NET application (using C++/CLI).

The porting issues will be completely different in these three cases. But in
each case, before you start, you should try to separate the core functionality
of your C++Builder6 applications from the GUI part. This core functionality can
then be used in Visual C++.

[If you want to go the .NET route, you might consider whether you want to write
the GUI part of your application in C#, or even rewrite everything in C#.]

--
David Wilkinson
Visual C++ MVP

[RFOG]

On Wed, 08 Oct 2008 15:39:01 +0200, emavisu
<em*****@discussions.microsoft.comwrote:

Dear guys,
I'm in trouble having to port my project from C++Builder6 to VisualC++.
Has anyone of you idea if there are any tools to help my doing this job?
My current project is widely using VCL and these 2 IDE (C++Builder and
VisualC++) seems to be so far each other that I can hardly think to find
out
a tool to "automatically" perform something for me.
Thank you.

C++Builder (and Delphi) VCL is not compatible with MFC/.NET in any way.
The only thing to do is continue with Builder or do David Wilkinson has
answered you.

VCL model is near to .NET Windows Forms model (Same person did it), but
completelly incompatible because VCL is built in Pascal and .NET is built
in... er... C# and names and some concepts are different. Then passing
from VCL to .NET is significant easier than pass to MFC (or other C++
framework), but you will find a lot of things that does not work as
expected in .NET that worked in VCL. Plus Windows Forms designer is er..
"easy to crash" and you need to do very bad and uncommon things to crash
VCL form designer.

Both VCL and .NET have the concepts of Event Driven User interface,
passing sender object and event cause to events but all common things
stops here. Concepts are the same, but names are very different.

However you have VCL.NET, an Pascal VCL extensions to use Pascal and VCL
in .NET, but there are none similar in C++ Borland side like Microsoft
C++/CLI.
--
Microsoft Visual C++ MVP
========================
Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y programación
========================================
La causa de la mujer es la del hombre; los dos se levantan o sucumben
juntos.
-- Alfred Tennyson. (1809-1892) Poeta británico.

[=?Utf-8?B?ZW1hdmlzdQ==?=]

THank you for considering my question. I know these possibilities and for
sure I want to use .NET framework. Do you think it is better to use VisualC#?
In this way I cannot reuse my C++ classes. Which can be the benefits instead?

Thanks.
emavisu

"David Wilkinson" wrote:

emavisu wrote:

Dear guys,
I'm in trouble having to port my project from C++Builder6 to VisualC++.
Has anyone of you idea if there are any tools to help my doing this job?
My current project is widely using VCL and these 2 IDE (C++Builder and
VisualC++) seems to be so far each other that I can hardly think to find out
a tool to "automatically" perform something for me.
Thank you.

emavisu:

Visual C++ is a compiler, not a GUI framework. It is actually a compiler for
three languages: C, C++ and C++/CLI.

If you want to create a GUI program using Visual C++ you have to decide whether
you want a plain Win32 application (using C or C++), MFC application (using
native C++) or a .NET application (using C++/CLI).

The porting issues will be completely different in these three cases. But in
each case, before you start, you should try to separate the core functionality
of your C++Builder6 applications from the GUI part. This core functionality can
then be used in Visual C++.

[If you want to go the .NET route, you might consider whether you want to write
the GUI part of your application in C#, or even rewrite everything in C#.]

--
David Wilkinson
Visual C++ MVP

[David Wilkinson]

emavisu wrote:

THank you for considering my question. I know these possibilities and for
sure I want to use .NET framework. Do you think it is better to use VisualC#?
In this way I cannot reuse my C++ classes. Which can be the benefits instead?

emasivu:

You should be aware that Microsoft is no longer promoting C++/CLI as a language
for .NET GUI applications, just for interfacing to native C++ code. C# is really
recommended for GUI code. You can use it for GUI code, but you may regret it.

You do have legacy C++ code, but it contains VCL code that cannot be used in
Visual C_++. Two possibilities:

1. A complete rewrite in C#

2. Use C++/CLI to wrap your (cleaned) C+ code into C++/CLI classes which can be
consumed by a C# GUI.

--
David Wilkinson
Visual C++ MVP

[=?Utf-8?B?ZW1hdmlzdQ==?=]

Dear Mr. Wilkinson,
you are confirming my feeling that MS is, as usual, pushing developers in
the direction of working in a complete proprietary solution!

Frankly speaking I think C++Builder and VCL are great tool to work with but
the problem is that you can hardly find people using it (mainly in italy,
whare I live). In this situation, when you need something is nearly
impossible to find out a forum like this one where to chat with someone about
the possible solution for the problem you are facing.
I think this is the main reason why I'm thinking about this migration.

Which is your personal point of view? It seems you are a very experienced
person so your suggestion would be really worthwhile.

Thanks so much.

emavisu
"David Wilkinson" wrote:

emavisu wrote:

THank you for considering my question. I know these possibilities and for
sure I want to use .NET framework. Do you think it is better to use VisualC#?
In this way I cannot reuse my C++ classes. Which can be the benefits instead?

emasivu:

You should be aware that Microsoft is no longer promoting C++/CLI as a language
for .NET GUI applications, just for interfacing to native C++ code. C# is really
recommended for GUI code. You can use it for GUI code, but you may regret it.

You do have legacy C++ code, but it contains VCL code that cannot be used in
Visual C_++. Two possibilities:

1. A complete rewrite in C#

2. Use C++/CLI to wrap your (cleaned) C+ code into C++/CLI classes which can be
consumed by a C# GUI.

--
David Wilkinson
Visual C++ MVP

[David Wilkinson]

emavisu wrote:

Dear Mr. Wilkinson,
you are confirming my feeling that MS is, as usual, pushing developers in
the direction of working in a complete proprietary solution!

Frankly speaking I think C++Builder and VCL are great tool to work with but
the problem is that you can hardly find people using it (mainly in italy,
whare I live). In this situation, when you need something is nearly
impossible to find out a forum like this one where to chat with someone about
the possible solution for the problem you are facing.
I think this is the main reason why I'm thinking about this migration.

Which is your personal point of view? It seems you are a very experienced
person so your suggestion would be really worthwhile.

emavisu:

My personal decision is to stick with MFC, but I have 10 years invested in
learning it. Also, after 10 years of neglect. Microsoft is once again investing
resources in it, because they have accepted that this is what the majority of
their existing C++ customer base wants.

Of course MFC is also a proprietary Microsoft solution. If you are interested,
there are other native C++ libraries (QT, wxwidgets, WTL ...) that are not
controlled by Microsoft.

--
David Wilkinson
Visual C++ MVP

[=?Utf-8?B?ZW1hdmlzdQ==?=]

I also would like to stick with VCL but the problem is to know if Embarcadero
and CodeGear want to keep a good support to this product or not! from the
other side (MS) I would need a good library with a full support for Unicode
(for Chinese GUI) but as far as I know I see that MFC is not enough (they
told me I have to use .NET).
Also I would like to keep using C++ (I also invested a lot of time on this
language) but I do not know if using one of the others libraries/frameworks
you are talking about (QT, wxwidgets, WTL ...) would be a good choice for the
future of my applications.

"David Wilkinson" wrote:

emavisu wrote:

Dear Mr. Wilkinson,
you are confirming my feeling that MS is, as usual, pushing developers in
the direction of working in a complete proprietary solution!

Frankly speaking I think C++Builder and VCL are great tool to work with but
the problem is that you can hardly find people using it (mainly in italy,
whare I live). In this situation, when you need something is nearly
impossible to find out a forum like this one where to chat with someone about
the possible solution for the problem you are facing.
I think this is the main reason why I'm thinking about this migration.

Which is your personal point of view? It seems you are a very experienced
person so your suggestion would be really worthwhile.

emavisu:

My personal decision is to stick with MFC, but I have 10 years invested in
learning it. Also, after 10 years of neglect. Microsoft is once again investing
resources in it, because they have accepted that this is what the majority of
their existing C++ customer base wants.

Of course MFC is also a proprietary Microsoft solution. If you are interested,
there are other native C++ libraries (QT, wxwidgets, WTL ...) that are not
controlled by Microsoft.

--
David Wilkinson
Visual C++ MVP

[David Wilkinson]

emavisu wrote:

I also would like to stick with VCL but the problem is to know if Embarcadero
and CodeGear want to keep a good support to this product or not! from the
other side (MS) I would need a good library with a full support for Unicode
(for Chinese GUI) but as far as I know I see that MFC is not enough (they
told me I have to use .NET).
Also I would like to keep using C++ (I also invested a lot of time on this
language) but I do not know if using one of the others libraries/frameworks
you are talking about (QT, wxwidgets, WTL ...) would be a good choice for the
future of my applications.

emavisu:

MFC has full support for Unicode. In fact, a default MFC application created in
VS2005 or VS2008 uses Unicode characters by default.

Who told you otherwise?

While nothing is certain, I also think that the future of MFC is much better
assured than QT, wxwidgets, WTL or VCL.

The downside of MFC is that it is old, bloated, and not very elegant. It also
has quite a learning curve. But it works, and there is a ton of code samples
available for it.

--
David Wilkinson
Visual C++ MVP

[=?Utf-8?B?ZW1hdmlzdQ==?=]

Well I think I will test MFC solution for a while...but my learning curve
MUST be very short so, for sure, I will need to hire good people if I will
decide to go on in this direction: do you know a place to find some of them?

Thanks very much for your time.

emavisu
"David Wilkinson" wrote:

emavisu wrote:

I also would like to stick with VCL but the problem is to know if Embarcadero
and CodeGear want to keep a good support to this product or not! from the
other side (MS) I would need a good library with a full support for Unicode
(for Chinese GUI) but as far as I know I see that MFC is not enough (they
told me I have to use .NET).
Also I would like to keep using C++ (I also invested a lot of time on this
language) but I do not know if using one of the others libraries/frameworks
you are talking about (QT, wxwidgets, WTL ...) would be a good choice for the
future of my applications.

emavisu:

MFC has full support for Unicode. In fact, a default MFC application created in
VS2005 or VS2008 uses Unicode characters by default.

Who told you otherwise?

While nothing is certain, I also think that the future of MFC is much better
assured than QT, wxwidgets, WTL or VCL.

The downside of MFC is that it is old, bloated, and not very elegant. It also
has quite a learning curve. But it works, and there is a ton of code samples
available for it.

--
David Wilkinson
Visual C++ MVP

[Jonathan Wilson]

needs them, which is probably not true of MFC, VCL, or Qt which will

only be around for as long as Microsoft, Embarcadero (aka CodeGear,
formerly part of Borland), and Nokia choose to keep them going -- I
imagine that will be quite a long time, though.

Actually, QT is available under the GPL as well as under a proprietary
license. If Nokia/trolltech folded or stopped developing it, the community
would just keep using the GPL version. (at least those releasing open
source software that is)

[=?Utf-8?B?RGFuaWVs?=]

You should be aware that Microsoft is no longer promoting C++/CLI as a
language

for .NET GUI applications, just for interfacing to native C++ code. C# is really
recommended for GUI code. You can use it for GUI code, but you may regret it.

we noticed this :-) LOL

[=?Utf-8?B?RGFuaWVs?=]

well, why don't you download the free trial of C++Builder 2009 and see for
yourself (also ask for their companion/partner cd)
"emavisu" wrote:

I also would like to stick with VCL but the problem is to know if Embarcadero
and CodeGear want to keep a good support to this product or not! from the
other side (MS) I would need a good library with a full support for Unicode
(for Chinese GUI) but as far as I know I see that MFC is not enough (they
told me I have to use .NET).
Also I would like to keep using C++ (I also invested a lot of time on this
language) but I do not know if using one of the others libraries/frameworks
you are talking about (QT, wxwidgets, WTL ...) would be a good choice for the
future of my applications.

"David Wilkinson" wrote:

emavisu wrote:

Dear Mr. Wilkinson,
you are confirming my feeling that MS is, as usual, pushing developers in
the direction of working in a complete proprietary solution!
>
Frankly speaking I think C++Builder and VCL are great tool to work with but
the problem is that you can hardly find people using it (mainly in italy,
whare I live). In this situation, when you need something is nearly
impossible to find out a forum like this one where to chat with someone about
the possible solution for the problem you are facing.
I think this is the main reason why I'm thinking about this migration.
>
Which is your personal point of view? It seems you are a very experienced
person so your suggestion would be really worthwhile.

emavisu:

My personal decision is to stick with MFC, but I have 10 years invested in
learning it. Also, after 10 years of neglect. Microsoft is once again investing
resources in it, because they have accepted that this is what the majority of
their existing C++ customer base wants.

Of course MFC is also a proprietary Microsoft solution. If you are interested,
there are other native C++ libraries (QT, wxwidgets, WTL ...) that are not
controlled by Microsoft.

--
David Wilkinson
Visual C++ MVP

[=?Utf-8?B?RGFuaWVs?=]

unicode... right!
so is the new VCL (for both delphi and bcb 2009!)

"David Wilkinson" wrote:

emavisu wrote:

I also would like to stick with VCL but the problem is to know if Embarcadero
and CodeGear want to keep a good support to this product or not! from the
other side (MS) I would need a good library with a full support for Unicode
(for Chinese GUI) but as far as I know I see that MFC is not enough (they
told me I have to use .NET).
Also I would like to keep using C++ (I also invested a lot of time on this
language) but I do not know if using one of the others libraries/frameworks
you are talking about (QT, wxwidgets, WTL ...) would be a good choice for the
future of my applications.

emavisu:

MFC has full support for Unicode. In fact, a default MFC application created in
VS2005 or VS2008 uses Unicode characters by default.

Who told you otherwise?

While nothing is certain, I also think that the future of MFC is much better
assured than QT, wxwidgets, WTL or VCL.

The downside of MFC is that it is old, bloated, and not very elegant. It also
has quite a learning curve. But it works, and there is a ton of code samples
available for it.

--
David Wilkinson
Visual C++ MVP

[=?Utf-8?B?RGFuaWVs?=]

qt is super expnsive! that's a fact the getlemen from nokia (current owner of
qt) don't seam to quite follow (it doesn't fit in their power point
presentations...)

both wxWidgets and VCL currently are maintained FULL SPEE AHEAD and they
have full support for UNICODE. the problem with wxWidgets (i was to say
wxWindows) is that in terms of database development (especially dbaware
controls) they are like 15 years in the past... and they don't seam to
undestand that where people cannot build vertical database client
applications, well, there is a problem right there! (don't need to be a
genius to agree) - it's not that we're all buiding compilers, debuggers,
frameworks, kernel stuff... :-)

"Jonathan Wilson" wrote:

needs them, which is probably not true of MFC, VCL, or Qt which will
only be around for as long as Microsoft, Embarcadero (aka CodeGear,
formerly part of Borland), and Nokia choose to keep them going -- I
imagine that will be quite a long time, though.

Actually, QT is available under the GPL as well as under a proprietary
license. If Nokia/trolltech folded or stopped developing it, the community
would just keep using the GPL version. (at least those releasing open
source software that is)

[=?Utf-8?B?RGFuaWVs?=]

nokie has NOT changed the dual license of QT, if you wanna do "commercial"
software (in a box or not/in house) you HAVE TO BUY A LICENSE FOR EVERY
SINGLE DEVELOPER! (which, if you phone their marketing geniuses and request a
price tag, you will find out that it's about $3,000/developer/plaform, ONLY
FOR THEIR FRAMEWORK, which, because of MOC, it's a tramp in terms of
debugging), 100% inferior to VCL (BCB has native support of properties
methods events model, for NATIVE code! 2 way designers, etc) - so let's not
compare an exorbitant cheap stuff from EUROPE with BCB...

and the geniuses from GPL go like "you can use this, but hey, your
work/source code is common good" - you have to share it, whith whom? nobody
knows... but then again, do GPL stuff from Nokia/QT and let us know how it
went... :-)

"Jonathan Wilson" wrote:

needs them, which is probably not true of MFC, VCL, or Qt which will
only be around for as long as Microsoft, Embarcadero (aka CodeGear,
formerly part of Borland), and Nokia choose to keep them going -- I
imagine that will be quite a long time, though.

Actually, QT is available under the GPL as well as under a proprietary
license. If Nokia/trolltech folded or stopped developing it, the community
would just keep using the GPL version. (at least those releasing open
source software that is)

[=?Utf-8?B?RGFuaWVs?=]

This is just the point! How far will Embarcadero-CodeGear will support VCL,

and even more C++Builder? I think the aswer is "as long as some big customer
will keep on using it". Unfortunately I do not know any big brand that is
using these tools.

For starters, Embarcadero products are writen in VCL (and BCB). For them, to
spare 23 million bucks was paddy cash, just to have the tools on board.

Second, they've just released BCB 2009, with enhanced VCL (100% backward
compatible) and FULL UNICODE SUPPORT (among other things...)

Third, there were 2 products in Borland's history which registered amazing
sales. The two products are: Borland Pascal 7 and... BCB 6!?! (bcb6 because
borland was "cooking" on aberations like cbuilderX instead of doint what they
always did bet (well, more or less, since 75% of their top engineers, smile
at us from Redmond WA - and hey, nothing wrong with this!)

Embarcadero will support BCB, that's for SURE! They have to, and are
extremely motivated by the vibrant help they've got from Microsoft (which
currently does just a little bit of C++, right?)

Regards,
d

[=?Utf-8?B?RGFuaWVs?=]

However you have VCL.NET, an Pascal VCL extensions to use Pascal and VCL

in .NET, but there are none similar in C++ Borland side like Microsoft
C++/CLI.

correct! but remember, if you think a little bit, you will find ways to
instantiate .NET "components" inside VCL applications! will not enter in any
details because of nice NDAs, but you get the idea, from the internet...

BCB was almost about to offer this, but it wasn't to be...

C++/CLI is super! and with ALL DUE RESPECT, marginalizing this compiler and
hybrid applications, it's not a very brilliant idea... TIME WILL TELL!
(actually, it's already telling, right?)

d++

[=?Utf-8?B?RGFuaWVs?=]

[If you want to go the .NET route, you might consider whether you want to
write

the GUI part of your application in C#, or even rewrite everything in C#.]

with all due repect, tipical mvp answer, since you are so valuable, why
don't you suggest Microsoft to port kernel32, gdi32, user32 and ntdll.dll in
c# as well, since C/C++ are not in fashion, so they tell you... :-) LOL!!!

btw, what do you think about drivers in c#? or software on box (which sells
in store and it's not in the league of inhouse programming with a mouse)

now, beyond (absolytely innocent and respectful) joke, if Phonix will MAKE
IT, you could actually see things like:

1. use the language of your choice (c++, c#, vb!)
2. where do you wanna go today? native or managed?

this was the purpose... the initial dream... just to let you know!

d

[=?Utf-8?B?RGFuaWVs?=]

If you want to create a GUI program using Visual C++ you have to decide
whether

you want a plain Win32 application (using C or C++), MFC application (using
native C++) or a .NET application (using C++/CLI).

great, you've learned your lesson very well (are you a valuable consultant?
:-)

anyway, MFC has its own virtues. but when it comes to multi tier
applications, with super complex dbaware data entry forms, with literaly
hundreds of forms, etc, you will not make it (in time and budget) not even
with WinForms (.NET)

Delphi/VCL still has CLEAR VIRTUES, some managers fail to understand,
because it's been a while since they were developers developers developers
developers themselves...

Same about Architects, Senior Architects (e.g. the ones who designed ADO.NET
or the "generous" NET.dbAwarness - obviously they had more important things
to do than have a friendly chit chat with Anders... available, otherwise...)

d++

[Daniel James]

In article news:<us**************@TK2MSFTNGP02.phx.gbl>, Jonathan
Wilson wrote:

Actually, QT is available under the GPL as well ...

Yup. I got the impression (perhaps wrongly) that the OP wasn't working
on Open Source code, though. IIUC Qt's licensing makes it clear that
the GPL version can only be used for free (as in beer) software.

Cheers,
Daniel.

[Daniel James]

In article news:<37**********************************@microso ft.com>,
Daniel wrote:

... the problem with wxWidgets (i was to say wxWindows) is that
in terms of database development (especially dbaware
controls) they are like 15 years in the past...

[Lest anyone be confused: that "Daniel" is a different Daniel.]

wxWidgets is primarily a GUI toolkit. It does have some database
functionality but that is, as you say, quite old and not well supported.

However, not every application is a database application, and
applications that are database applications don't need to use database
functionality provided by the GUI framework -- there are better database
APIs around.

... and they don't seam to undestand that where people cannot build
vertical database client applications, well, there is a problem
right there!

But one CAN build vertical database client applications, it's just that
one doesn't get much handholding from the framework on the database
side.

I worked on a very database-oriented MFC application a few years ago. We
first wrote it using ODBC and looked at ADO and DAO when that started to
creak at the seams ... in the end a co-worker converted it to use SQL
through some non-MFC interface (I'm uncertain of the details, I was on a
different project at the time).

One can always pick and choose ...

Cheers,
Daniel.

[Daniel James]

In article news:<67**********************************@microso ft.com>,
Emavisu wrote:

This is just the point! How far will Embarcadero-CodeGear will
support VCL, and even more C++Builder?

I'm much more confident in the future of Delphi, the VCL and C++
builder since Embarcadero took charge of CodeGear. The management at
Borland seemed to have no clue whatsoever and might well have run the
product(s) into the ground, but there is now hope and enthusiasm again.

Their hiring Alisdair Meredith as product manager for C++ Builder is
another sign that they take C++ seriously. Alisdair is not the sort of
guy who would have taken the job if he had not thought that they were
serious about the product.

This is good for Microsoft too -- they need some sincere competition to
keep them focused on what the customers want and to stop them wandering
off on flights of fantasy of their own, as they have shown some signs
of doing lately.

I certainly think that Embarcadero recognize that VCL is a major asset
and is much valued by their user community. They won't abandon it in a
hurry.

Cheers,
Daniel.

[=?Utf-8?B?RGFuaWVs?=]

I agree with you, but how about the combination of std::function/std::bind
for

events? This is the way to go in C++ 0x (and with older compilers you have
boost)... (yeah I know... std::function is not the fastest implementation...but
it exists :-)

well, if events are somehow achievable, properties are not so easy...

For properties it's easy to build a property class using templates.
C++ is too flexible (and complex) to avoid (in general) adding every
favorite feature into the core language, just build a library :-)

really? but when your property (called foo) needs to be engaged in
expressions, then it's not that easy, you need to implement tones of
operators and of course, you loose generality. that's why, implementing
something like properties in the language seams to be required (both borland
and microsoft did it)

regular joe implements a class template, then realizes that

foo++ would not work... the power of a datatype comes from many things,
expression engageability being definitely a first class citize (for the lack
of a more fortunate/democratic idiom)

Of course, there are a lot things that could be better if the language is
enhanced, but this is not the case, at least in my opinion.

having native properties in the language itself is not one of those "nice to
have things, different people think it would make their lives better"...

properties are the beginning of componentness, a design paradigm c++ should
be aware of! before it is too late... it's been already 10 years and this
doesn't seam to happen...

we're not talking about nice to have features average joe dreams about,
without understanding the core axiomes of the language itself... we are
talking about c++, being capable to have at least the minimum decency and
understand what is going on... and the very same thing about true rtti(s)!

just my $.02

d

[=?Utf-8?B?RGFuaWVs?=]

I agree with you, but how about the combination of std::function/std::bind
for

events? This is the way to go in C++ 0x (and with older compilers you have
boost)... (yeah I know... std::function is not the fastest implementation...but
it exists :-)

right

For properties it's easy to build a property class using templates.

well, not really... not when you want properties of any kind, to enagage in
expressions freely...

C++ is too flexible (and complex) to avoid (in general) adding every
favorite feature into the core language, just build a library :-)

i am perfectly aware of that, stroupsrtoup postulated this axiome a long
time back, but now, the very same stroustroup is planning to implement
garbage collection?!? how is this logical? how is this consistent with his
own public statements, when he said "a better language is a language which
doesn't have garbage, so there won't be anything to collect". we both garbage
collection is so obscure and so potentially threatening (by allowing
irresponsable average joes to build apparently healty software, in fact below
any acceptable standards). we're not talking about sales here...
irresponsable sales, given a mouse to the many without carying about long
term consequences...

Of course, there are a lot things that could be better if the language is
enhanced, but this is not the case, at least in my opinion.

i am aware of this, if i didn't strongly believe that properties
implementation at langauge level was crucial, i would have not even mentioned
it (please notice that i am not an mpv or something). but in a way, you're
right... since most of c++ codebase is based on existing/legacy code,
billions of lines writen in a language which obviously did not have this
feature, then maybe it's futile... maybe it's like trying to change a kernel
square headed engineer that even 1-3% slower, a c++ (object oriented) kernel
would actually be way more manageable, more scalable (in terms of complexity
and potential abstraction, you name it). i tried this, believe me, it's
futile... :-) squared heads have many right angles!

i know they will not adopt properties, natively, in the soul of the language
itself. but this will trigger fragmentation at frameworks level, this will
enhance the wall between componentness and simple oop and speed up the
absolitation of one of the best programming lanuge ever created. i sure hope
i am not right, but this is what i believe. and, like i said, at least
borland' and microsoft' c++ compiler teams proved me right...

it's been nice talking to you, follow your excitment (bashar...;-)
d out

[=?Utf-8?B?RGFuaWVs?=]

For properties it's easy to build a property class using templates.

actually, nothing could be further away from the truth! despites that class
you are talking about is actually a class template, properties implemented
that way cannot be generic, because of speciffic operators. there are many
implementations which seam to work but choke on simple things like
my_property++; and btw, properties go far beyond having a setter and a
getter and formal sintactic shoogar!

1. properties have setters and getters.
2. properties can engage in expressions of any kind, freely, just like they
were their "non-property" counteparts.
3. properties should be inheritable (let's say that this works already,
despites many implementation propose excruciating binding macros for setters
and getters...)
4. properties should be RTTI querable (have enough self defined RTTI)
5. properties should persist properly, regardless of their type

now, you see, this goes far beyond naive implementations based on class
templates... MOST major compiler vendors implemented properties at language
level, having to extend a language which seams to be damned to keep its c
roots, for as long as their initial authors still have influence over the
standard... (in reality, author or not, NOBODY should be able to do more than
proposals to a STANDARD)... unless the standard is CONFISCATED/formal or
protective for different compiler manufacturers agendas. obviously ANSI C++
standard is:

1. always too late, hilariously late: which prooves how useful/really needed
it really is...
2. always protective (today, in c++0x is actually protecting g++ incapacity
to implement stronger language improvements)

i'll give you two names, both compiler engineers, both abandoned the
comitee, for these 2 reasons: eli boling and john wigley!

have fun,
d

[Cholo Lennon]

Daniel wrote:

>For properties it's easy to build a property class using templates.

actually, nothing could be further away from the truth! despites that
class you are talking about is actually a class template, properties
implemented that way cannot be generic, because of speciffic
operators. there are many implementations which seam to work but
choke on simple things like my_property++;

Borland Builder (version 6 at least) doesn't allow ++ (and related)
for properties.

and btw, properties go far
beyond having a setter and a getter and formal sintactic shoogar!

1. properties have setters and getters.

I have never forgotten that!

2. properties can engage in expressions of any kind, freely, just
like they were their "non-property" counteparts.

That's the idea :-)

How about the following 10 minutes class for a read/write property?

template <typename T, typename U>
class Property
{
public:
typedef U value_type;
typedef void (T::*SetFn)(const U&);
typedef U (T::*GetFn)();

Property(T* pT, SetFn pSetFn, GetFn pGetFn)
: m_pT(pT)
, m_pSetFn(pSetFn)
, m_pGetFn(pGetFn)
{
}

operator value_type()
{
return (m_pT->*m_pGetFn)();
}

Property& operator=(const value_type& rhs)
{
(m_pT->*m_pSetFn)(rhs);
return *this;
}

/// @todo operator++, const getter, etc

private:
T* m_pT;
SetFn m_pSetFn;
GetFn m_pGetFn;
};

////////////////////////////

class Foo
{
public:
Foo()
: m_nInt(this, &Foo:SetInt, &Foo::GetInt)
, m_nValue(0)
{
}

Property<Foo, intm_nInt;

private:
int m_nValue;

void SetInt(const int & rhs) { m_nValue = rhs; }
int GetInt() { return m_nValue; }
};

////////////////////////////

void TestFoo()
{
Foo foo;
foo.m_nInt = 10;
int a = 20 + foo.m_nInt;
}

This a minimal example, not optimus, but it works.

3. properties should be inheritable (let's say that this works
already, despites many implementation propose excruciating binding
macros for setters and getters...)

The example shows that. Just declare setters or getters like virtual...

4. properties should be RTTI querable (have enough self defined RTTI)

Well I'am talking about the properties and its implementation, not RTTI, this
is another topic in C++

5. properties should persist properly, regardless of their type

The same as previous point, I'm talking about the properties and its
implementation, not C++ persistence. If you want persistence just use
boost::Serialization or any other framework.

now, you see, this goes far beyond naive implementations based on
class templates... MOST major compiler vendors implemented properties
at language level, having to extend a language which seams to be
damned to keep its c roots, for as long as their initial authors
still have influence over the standard... (in reality, author or not,
NOBODY should be able to do more than proposals to a STANDARD)...
unless the standard is CONFISCATED/formal or protective for different
compiler manufacturers agendas. obviously ANSI C++ standard is:

1. always too late, hilariously late: which prooves how useful/really
needed it really is...
2. always protective (today, in c++0x is actually protecting g++
incapacity to implement stronger language improvements)

i'll give you two names, both compiler engineers, both abandoned the
comitee, for these 2 reasons: eli boling and john wigley!

have fun,
d

I don't know if a property concept is so essential (in C++ of course). C++ is
used
in a lot of fields. GUI field perhap needs properties, but the other ones? I
work in
the telecom industry and I 've never feel the necessity of properties but this
is
just my opinion (BTW I used to program a lot with borland builder and mfc so
I'm not
an outsider :-)

Just my last 2 cents... bye

[=?Utf-8?B?RGFuaWVs?=]

Borland Builder (version 6 at least) doesn't allow ++ (and related)

for properties.

Well, for your information, Borland C++ Builder FULLY supports ++ and many
other operators against properties, SINCE RELEASE 1.0! (of course, including
6.0, 2007, 2009, etc)

Same about Microsoft C++ compiler!

PS
Your 10 minutes class is giving a 10 minutes result. Properties unable to
engage in expressions.

This will terminate this tread.

Daniel

[=?Utf-8?B?RGFuaWVs?=]

I don't know if a property concept is so essential (in C++ of course). C++ is

used
in a lot of fields. GUI field perhap needs properties, but the other ones? I
work in
the telecom industry and I 've never feel the necessity of properties but this
is
just my opinion (BTW I used to program a lot with borland builder and mfc so
I'm not
an outsider :-)

Happy to hear that, but if you did, how come you do not know that
properties, for both compilers are fully implemented. Don't you think that
borland's and microsoft's compiler engineers are smart enough to implement
ONLY what they HAVE to? Asking you this simple question, as an exBorlander...

PS
It is incorrect that properties are needed primarly for GUI field.
Properties allow you to create full blown components and libraries. From my
understanding, the declared purpose (axiomatic manifesto) of C++ language
itself, writen and published by stroustrup himeself, including the upcoming
C++0X IS:

1. To facilitate system programming.
2. To facilitate construction of libraries.

Well, the second point is majorly violated by the absence of properties.

PS
I would appreciate it if you test a statement (with the compiler) before
making it. Referring to "cbuilder does not support ++ for properties". Since
I am a guest in here and a very busy persons, I guess it's time for me to get
back to my work.

Regards,
d

[Daniel James]

In article news:<3C**********************************@microso ft.com>,
Daniel wrote:

Well, for your information, Borland C++ Builder FULLY supports ++
and many other operators against properties, SINCE RELEASE 1.0!

That is not so ...or, rather, the support may be "full" (for some meaning
of "full") but it is broken.

There are problems with ++ and similar operators when applied to
properties in BCB (up to at least version 5, I'm not sure about more
recent versions) where the property is a temporary. What happens is that
the temporary is incremented (and discarded) and the original object that
the programmer intended to increment in unchanged. This is a well-known
and well-documented shortcoming of BCB that does not arise in Delphi.

Cheers,
Daniel.

[=?Utf-8?B?RGFuaWVs?=]

There are problems with ++ and similar operators when applied to

properties in BCB (up to at least version 5, I'm not sure about more
recent versions) where the property is a temporary. What happens is that
the temporary is incremented (and discarded) and the original object that
the programmer intended to increment in unchanged. This is a well-known
and well-documented shortcoming of BCB that does not arise in Delphi.

This seams to be a well documented BCB superstition. BCB functions by
consuming Delphi components. If this did not work, BCB would never have
worked in first place. What you are describing is a black box pseudo
explanation for what is going on when compiler generates code for properties.
The simplest example possible (with a mouse) is:

void __fastcall TForm1::Button1Click(TObject *Sender)
{
assert(Width == 651);
Width++;
Width += 10;
Caption = Width;
assert(Width == 662);
}

note both ++ and += operators fully engaged against Width property. note
default string conversion of the property (at Caption's assignment), etc

this has always been working perfectly since BCB1! (1996)

and for your information, BCB can also accomodate Microsoft's VC++
properties semantics as well.

if you have a practical example contradicting my words, be my guest and post
it here. if you do not, let's take superstitions somewhere else!

regards,
dan

[Cholo Lennon]

Daniel wrote:

>There are problems with ++ and similar operators when applied to
properties in BCB (up to at least version 5, I'm not sure about more
recent versions) where the property is a temporary. What happens is
that the temporary is incremented (and discarded) and the original
object that the programmer intended to increment in unchanged. This
is a well-known and well-documented shortcoming of BCB that does not
arise in Delphi.

This seams to be a well documented BCB superstition. BCB functions by
consuming Delphi components. If this did not work, BCB would never
have worked in first place. What you are describing is a black box
pseudo explanation for what is going on when compiler generates code
for properties. The simplest example possible (with a mouse) is:

void __fastcall TForm1::Button1Click(TObject *Sender)
{
assert(Width == 651);
Width++;
Width += 10;
Caption = Width;
assert(Width == 662);
}

note both ++ and += operators fully engaged against Width property.
note default string conversion of the property (at Caption's
assignment), etc

this has always been working perfectly since BCB1! (1996)

and for your information, BCB can also accomodate Microsoft's VC++
properties semantics as well.

if you have a practical example contradicting my words, be my guest
and post it here. if you do not, let's take superstitions somewhere
else!

regards,
dan

BCB has fully support for properties.. are you sure?

Try to compile this:

class Foo: public TObject
{
public:
Foo() : m_nX(0) {}

__property int x = { read=GetX, write=SetX };

void Test()
{
int a;

// Ok
x++;

// but.. how about this line? It doesn't compile
// (al least in my bcb 6)
a = x++;

// and how about this one?
a = 10 + x++;
}

private:
int m_nX;
int GetX()
{
return m_nX;
}

void SetX(int rhs)
{
m_nX = rhs;
}
};

BTW, why are you so agressive in your answers? This is a discussion group, not
a war.. we all make mistakes (like you when you talked about events in C++ 0x).
Take it easy man :-)

Regards

--
Cholo Lennon
Bs.As.
ARG

[Daniel James]

In article news:<B6**********************************@microso ft.com>,
Daniel wrote:

This seams to be a well documented BCB superstition.

It's not a superstition, it's well-established fact.

Further discussion of the details of bugs in BCB would be wildly
off-topic in a Microsoft discussion forum so I won't go into more
details, but I suggest you search the Borland newsgroups for details.

I haven't used the recent Borland/CodeGear/Embarcadero products much so
I'm not sure what's been fixed and what hasn't ... but this error
message explanation from RAD Studio 2007 suggests that all they've done
(in that version, anyway) is to flag an error if you try to use
properties in ways that they haven't implemented:

http://docs.codegear.com/docs/radstu...007_helpupdate
s/HUpdate3/EN/html/devwin32/compile_errbadpropasg_xml.html

The problem being discussed there is one manifestation of the bug I
mentioned.

this has always been working perfectly since BCB1! (1996)

The code in your example works because none of the properties there are
temporary objects. It's not what I was talking about at all.

Cheers,
Daniel.

[=?Utf-8?B?RGFuaWVs?=]

It's not a superstition, it's well-established fact.

it's a well documented limitation, present in the help file since bcb 1
since the whole thing started from "should we, or should we not have
language property support in new/forever-upcoming c++0x" - and btw, the msvc
compiler support for properties doesn't have these holes (i am not talking
about managed, they support properties in native code as well).

Further discussion of the details of bugs in BCB would be wildly
off-topic in a Microsoft discussion forum so I won't go into more
details, but I suggest you search the Borland newsgroups for details.

Correct. The relationship between me and Borland is years in the past, so I
have no need to go to any of their newsgroups and enjoy white noise

I haven't used the recent Borland/CodeGear/Embarcadero products much so
I'm not sure what's been fixed and what hasn't ... but this error
message explanation from RAD Studio 2007 suggests that all they've done
(in that version, anyway) is to flag an error if you try to use
properties in ways that they haven't implemented:

here is the help content, for chained assignments:

"The result of a property assignment is an lvalue. This implies for instance
that chained assignments of properties is not allowed; for example, x = y =
5, where both x and y are properties. Certain embedded assignments of
properties can also produce errors; for example, x != ( y = z ), where y is a
property."

http://docs.codegear.com/docs/radstu...007_helpupdate
s/HUpdate3/EN/html/devwin32/compile_errbadpropasg_xml.html

what you found is the very thing, assumed and documented since bcb1, but
described (most likely by someone from qa) in a way that makes you think that
their langauge support for properties is a toy one can emulate by writing a
10 mintes class template...

The problem being discussed there is one manifestation of the bug I
mentioned.

the ones who raised it did not know about the page of help which was added
since day one (bcb 1) to the help file. the only reasons borland added
"__property" to their c++ dialect was to accomodate vcl. it happens that i've
been involved in porting vcl to c++, but this has never been finalized for
reasons beyond newsgroups. the idea of having properties supported by the
language is very powerful and microsoft implemented it in several stages,
versions, dialects, you name - a did this right. even with the mentioned
limitation, borland's support for properties (at language level) is way more
powerful than any "framework supported alternative"

The code in your example works because none of the properties there are
temporary objects. It's not what I was talking about at all.

correct. the code works because i did not violate their help, which states:

"The result of a property assignment is an lvalue. This implies for instance
that chained assignments of properties is not allowed; for example, x = y =
5, where both x and y are properties. Certain embedded assignments of
properties can also produce errors; for example, x != ( y = z ), where y is a
property."

beyond this documented limitation, their support for properties seams to
come very handy, way handier than, for example, the following example:

http://www.codeguru.com/cpp/cpp/cpp_...icle.php/c4031

msvc implemented properties full speed ahead. i believe that ms
implementation is by far the best in existence. since ms has folks in ansi,
and ansi did not move a finger in this direction (language property support),
then i suspect that, by 2030, when new c0x will be fully completed, they will
not have this feature, because some folks implemented something half baked in
different frameworks

ps
we're about the set a new guinees record on number of replies per post, so i
wish you all the best and get back to work

have fun,
d :-)

[Daniel James]

In article news:<0B**********************************@microso ft.com>, Daniel
wrote:

[I wrote:]

It's not a superstition, it's well-established fact.

it's a well documented limitation, present in the help file since bcb 1

So you now admit that when you wrote:

Well, for your information, Borland C++ Builder FULLY supports ++ and
many other operators against properties, SINCE RELEASE 1.0!

you were lying?

Enough, already!
--
Cheers,
Daniel.

[=?Utf-8?B?RGFuaWVs?=]

you were lying?

?!? what is this place ?!?

Enough, already!

correct

[=?Utf-8?B?RGFuaWVs?=]

you were lying?

__some brits seam to have a problem with understanding semantics... when
they don't get it right, they get all upset (british empire stuff,
uninportant aroud here) LOL! - you may be amazed to find out that we have the
same queen (you and me) but we don't seam to speak the same language...

Enough, already!

right, you go back to you inhouse programming for a rack hosting internet
provider which also offers photographing and engraving services for few
nickels a month in the village of bracknell/england and i will go back to my
humble compilers... i was trying to help, by spreading some of the knowledge
i've got :-) such a waste of time, my teachers were all right!

regards,
d

[=?Utf-8?B?RGFuaWVs?=]

you were lying?

daniel, i am very confident that microsoft will do something about "triky"
individuals like you, who are not trying to help anything or anybody, but
rather engage in provocative non-sense. to make my point clearly, here are
some of your posts from the past:

That's a good point -- and well made -- and if your apps are all desktop
apps then it may be a good enough solution for you. I achieve much the
same by running Windows apps in a Windows VM under linux; it means I have
to have a licensed copy of Windows to run in the VM, which you avoid by
using Crossover (or Wine), but that is not a big problem.

or

So, yes, I think native code is the way to go for C++ ... and I'd choose
Java rather than C# for the sandboxed environments because it has greater
market penetration. To me, C# is a language that should never have been.

or from your website (http://www.calamity.org.uk/):

Sorry, nothing here. Maybe someday, maybe not.

or another example, your own statement:

>It doesn't help that Boost.Build works very badly with Windows 9x (I'm

mainly a linux user, so I never upgraded). Another part of the problem
is that I'm not sure what is causing the link errors in the test
results. Such as: http://tinyurl.com/c8tdo. Hopefully over the next week
or two I'll get a better idea.

So, if you mainly a linux user, what are you doing in here? Looking for
troubles? For provocations against people who spent all their lifes in good
faith and hard work under windows / ms platforms, since day one (msdos 1.0)?
About here, you are always welcome, if you really wanna get a taste of what
professional development on professional platforms (windows) looks like, but
please, try to respect the culture here... take your fights to linux world...
over there you may succed

Regards,
d :-)

[Ben Voigt [C++ MVP]]

Daniel James wrote:

In article news:<us**************@TK2MSFTNGP02.phx.gbl>, Jonathan
Wilson wrote:

>Actually, QT is available under the GPL as well ...

Yup. I got the impression (perhaps wrongly) that the OP wasn't working
on Open Source code, though. IIUC Qt's licensing makes it clear that
the GPL version can only be used for free (as in beer) software.

Ummm. IANAL but...

GPL can only ever be applied to free (as in speech) products, they don't
have to be free (as in beer) and the GPL is incompatible with any extra
licensing language that would add a zero-price-tag requirement.

>
Cheers,
Daniel.

[Ben Voigt [C++ MVP]]

Daniel wrote:

>For properties it's easy to build a property class using templates.

actually, nothing could be further away from the truth! despites that
class you are talking about is actually a class template, properties
implemented that way cannot be generic, because of speciffic
operators. there are many implementations which seam to work but
choke on simple things like my_property++; and btw, properties go far
beyond having a setter and a getter and formal sintactic shoogar!

1. properties have setters and getters.
2. properties can engage in expressions of any kind, freely, just
like they were their "non-property" counteparts.

There's not a language around where a property can be used with the
address-of operator like a regular variable.

3. properties should be inheritable (let's say that this works
already, despites many implementation propose excruciating binding
macros for setters and getters...)
4. properties should be RTTI querable (have enough self defined RTTI)
5. properties should persist properly, regardless of their type

This last one hasn't anything to do with properties at all. In fact you
want to persist the internal state, not just properties.

[=?Utf-8?B?RGFuaWVs?=]

This last one hasn't anything to do with properties at all. In fact you

want to persist the internal state, not just properties.

really? it's normal for a guy who never dealed with components to undertand
component life cycles, when NOT the underlying value (instance state) is
persisted but the actual property, with full blown side effects coming from
getters, setters, etc...

[=?Utf-8?B?RGFuaWVs?=]

Or rather, C had support for function pointers since before your pet

language was dreamt up. Stop complaining about this non-issue.

don't really know what pet language you're talking about, didn't know i had
a pet language. of course, c has pointers to functions (i am using this since
1978, by that time, you were drinking milk). but you seam to miss the point
of being type safe! it's really a huge waste of time to trip you over
closures and so on... you would not understand since you don't seam to get it
why c++ is better than c and why c++0x should be better than today's c++ (and
it's obviously not gonna)

happy mvp
d

[Ben Voigt [C++ MVP]]

Daniel wrote:

>Or rather, C had support for function pointers since before your pet
language was dreamt up. Stop complaining about this non-issue.

don't really know what pet language you're talking about, didn't know
i had a pet language. of course, c has pointers to functions (i am
using this since 1978, by that time, you were drinking milk). but you

Actually I wasn't born yet. But though I may be young I seem to have
learned something in the meantime.

seam to miss the point of being type safe! it's really a huge waste

Function pointers are type-safe, don't know what makes you think otherwise.
In fact, the type-safety may be a little overly restrictive by not allowing
covariance and contravariance (as appropriate, on return values and
parameters, which may or may not be read-only/write-only pointers) which
would also be type-safe. But variance with pointer arguments is HARD so
it's no surprise that it simply isn't allowed.

of time to trip you over closures and so on... you would not

Closures really aren't so important, nor even anonymous functions, they're
just syntactic sugar for local types. Allowing templates to specialize to
local types is the important change, the other two are just minor effects of
that enabling decision.

understand since you don't seam to get it why c++ is better than c
and why c++0x should be better than today's c++ (and it's obviously
not gonna)

happy mvp
d

[Daniel James]

In article news:<#q**************@TK2MSFTNGP03.phx.gbl>, Ben Voigt [C++
MVP] wrote:

GPL can only ever be applied to free (as in speech) products, they
don't have to be free (as in beer) ...

That's how I understand it, too.

... the GPL is incompatible with any extra licensing language that
would add a zero-price-tag requirement.

IANAL either, but the statement here

http://trolltech.com/products/appdev...sing/licensing

seems to say that they manage it somehow.

Cheers,
Daniel.

[Ben Voigt [C++ MVP]]

Daniel James wrote:

In article news:<#q**************@TK2MSFTNGP03.phx.gbl>, Ben Voigt
[C++ MVP] wrote:

>GPL can only ever be applied to free (as in speech) products, they
don't have to be free (as in beer) ...

That's how I understand it, too.

>... the GPL is incompatible with any extra licensing language that
would add a zero-price-tag requirement.

IANAL either, but the statement here

http://trolltech.com/products/appdev...sing/licensing

seems to say that they manage it somehow.

A quick look at that doesn't seem to have a zero-price-tag requirement. Can
you tell me what statement you are referring to?

The only thing I saw was that this statement is misleading:

"If you wish to use the Qt Open Source Edition, you must contribute all your
source code to the open source community in accordance with the GPL or Qt
Software's GPL Exception when your application is distributed."

You don't need to give your code to the community, only to the people who
buy your product. But they did say "in accordance with the GPL", so they
aren't actually wrong. Replacing "open source community" with "your users"
and "when ... distributed" to "if distributed" would be more clear and
accurate IMHO.

Again, IANAL. If you are building a business model around charging for GPL
software you definitely should consult a lawyer.

>
Cheers,
Daniel.

[Daniel James]

In article news:<ee**************@TK2MSFTNGP02.phx.gbl>, Ben Voigt
[C++ MVP] wrote:

A quick look at that doesn't seem to have a zero-price-tag
requirement. Can you tell me what statement you are referring to?

I was referring to the fact that they make Qt available under
different licences that allow the users to release their products in
different ways. In particular: if you don't want to release your
application under the GPL you have to use (and pay for) their
commercial licence, but if your application is Open Source you can use
their (free) Open Source licence.

I don't see an explicit statement that an Open Source Qt application
must be zero-cost, but it does say

The Qt Commercial Editions must be used for proprietary,
commercial development.

which rules out using the Open Source licence for anything but
non-commercial software. I have a little difficulty in imagining many
viable scenarios in which non-commercial software can be anything
other than zero-cost ... charityware, perhaps?

Cheers,
Daniel.

[Ben Voigt [C++ MVP]]

"Daniel James" <wa*********@nospam.aaisp.orgwrote in message
news:VA******************@nospam.aaisp.org...

In article news:<ee**************@TK2MSFTNGP02.phx.gbl>, Ben Voigt
[C++ MVP] wrote:

>A quick look at that doesn't seem to have a zero-price-tag
requirement. Can you tell me what statement you are referring to?

I was referring to the fact that they make Qt available under
different licences that allow the users to release their products in
different ways. In particular: if you don't want to release your
application under the GPL you have to use (and pay for) their
commercial licence, but if your application is Open Source you can use
their (free) Open Source licence.

I don't see an explicit statement that an Open Source Qt application
must be zero-cost, but it does say

The Qt Commercial Editions must be used for proprietary,
commercial development.

which rules out using the Open Source licence for anything but
non-commercial software. I have a little difficulty in imagining many
viable scenarios in which non-commercial software can be anything
other than zero-cost ... charityware, perhaps?

Well, in addition to "proprietary & commercial" and "non-commercial" there's
also "open source & commercial". Which the GPL permits.

>
Cheers,
Daniel.

[Daniel James]

In article news:<B7**********************************@microso ft.com>,
Ben Voigt [C++ MVP] wrote:

... there's also "open source & commercial". Which the GPL permits.

The GPL does, but Trolltech seem not to.

I think we're arguing round in circles here and getting a long way from
the original point. Probably time to stop.

Cheers,
Daniel.