porting from C++Builder

167 views
Skip to first unread message

emavisu

unread,
Oct 8, 2008, 9:39:01 AM10/8/08
to
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

unread,
Oct 8, 2008, 10:01:04 AM10/8/08
to

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

unread,
Oct 8, 2008, 10:27:06 AM10/8/08
to

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.

emavisu

unread,
Oct 8, 2008, 10:33:29 AM10/8/08
to
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

unread,
Oct 8, 2008, 11:18:44 AM10/8/08
to
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.

emavisu

unread,
Oct 9, 2008, 5:03:01 AM10/9/08
to
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

unread,
Oct 9, 2008, 7:32:09 AM10/9/08
to
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.

emavisu

unread,
Oct 9, 2008, 8:49:00 AM10/9/08
to
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

unread,
Oct 9, 2008, 9:31:09 AM10/9/08
to
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.

emavisu

unread,
Oct 9, 2008, 10:21:01 AM10/9/08
to
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

Daniel James

unread,
Oct 10, 2008, 7:15:46 AM10/10/08
to
In article news:<u#TZJNhKJ...@TK2MSFTNGP04.phx.gbl>, David
Wilkinson wrote:
> MFC has full support for Unicode.

That's correct.

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

Nothing is certain in this world. I would say that as WTL and wxWidgets
are Open Source projects they will be around for as long as anyone
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.

> 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.

It's old and its design reflects some decisions that had to be made in
order to support it under Microsoft's old and non-compliant 16-bit C++
compiler -- it is therefore inelegant in places and not a great example
of good C++ design ... but it's hardly bloated (it is quite a thin
layer over the Win32 API) and the learning curve is not steep if you
know Win32 programming.

On the contrary, I'd say that VCL is a more heavyweight framework, and
that the learning curve is steeper because it provides a richer
abstraction of the underlying APIs (though this is mitigated
considerably by fact that the RAD IDE does a lot of the early work for
you). For the C++ programmer the fact that VCL is written in a
different language (Object Pascal) that whose functionality doesn't map
exactly onto that of C++ makes the learning curve just a little
steeper.

As you say, MFC works. It's the pragmatic choice for developers wanting
to write native-code C++ applications on Windows with Microsoft tools.

Of all the above my current favourite is wxWidgets -- largely because
it's cross-platform and free -- but if I had a large project in VCL and
I had no requirement to port it to non-Windows platforms I'd stick with
VCL. There's nothing to be gained by porting it.
--
Cheers,
Daniel.

Jonathan Wilson

unread,
Oct 10, 2008, 7:52:16 AM10/10/08
to
> 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)

emavisu

unread,
Oct 10, 2008, 9:31:00 AM10/10/08
to

"Daniel James" wrote:

> Nothing is certain in this world. I would say that as WTL and wxWidgets
> are Open Source projects they will be around for as long as anyone
> 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.
>

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.



> It's old and its design reflects some decisions that had to be made in
> order to support it under Microsoft's old and non-compliant 16-bit C++
> compiler -- it is therefore inelegant in places and not a great example
> of good C++ design ... but it's hardly bloated (it is quite a thin
> layer over the Win32 API) and the learning curve is not steep if you
> know Win32 programming.
>
> On the contrary, I'd say that VCL is a more heavyweight framework, and
> that the learning curve is steeper because it provides a richer
> abstraction of the underlying APIs (though this is mitigated
> considerably by fact that the RAD IDE does a lot of the early work for
> you). For the C++ programmer the fact that VCL is written in a
> different language (Object Pascal) that whose functionality doesn't map
> exactly onto that of C++ makes the learning curve just a little
> steeper.
>

For what is my experience I would say that VCL is very userfriendly and
powerful to be used. As long as you have a pointer to an object in your
application and a big set of methods/properties to use you really do not mind
which is the layer they used under to implement this object...and I have to
say that my application has really no problems concerning speed and GUI
responsiveness.



> As you say, MFC works. It's the pragmatic choice for developers wanting
> to write native-code C++ applications on Windows with Microsoft tools.
>
> Of all the above my current favourite is wxWidgets -- largely because
> it's cross-platform and free -- but if I had a large project in VCL and
> I had no requirement to port it to non-Windows platforms I'd stick with
> VCL. There's nothing to be gained by porting it.

I've heard that also Qt is cross-platform and there is a version for Eclipse
but I have no idea if these solutions are really reach enough from a
graphical point of view to build a good commercial solution as a customer is
expecting nowadays.

emavisu

Daniel

unread,
Oct 10, 2008, 11:12:00 PM10/10/08
to
> 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

Daniel

unread,
Oct 10, 2008, 11:14:00 PM10/10/08
to
well, why don't you download the free trial of C++Builder 2009 and see for
yourself (also ask for their companion/partner cd)

Daniel

unread,
Oct 10, 2008, 11:15:00 PM10/10/08
to
unicode... right!
so is the new VCL (for both delphi and bcb 2009!)

Daniel

unread,
Oct 10, 2008, 11:19:00 PM10/10/08
to
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... :-)

Daniel

unread,
Oct 10, 2008, 11:23:00 PM10/10/08
to
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... :-)

Daniel

unread,
Oct 10, 2008, 11:28:01 PM10/10/08
to
> 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

Daniel

unread,
Oct 10, 2008, 11:41:00 PM10/10/08
to
absolutely, great point! and the person is called ANDERS!!!
some things are not too clear tough... for example, the fact that you can:

1. buy bcb 2009 and you will feel like a fish in water, with full unicode
support, more compliant ANSI stuff, better RTL, better STL, better everything!
2. then start isolating the layers (and I did not call them tears!)
3. understand that actually, you can instantiate EVERY SINGLE .NET CLASS
(sorry, COMPONENT) from inside your BCB application! you can even host .NET
contols in your NATIVE VCL FORMS! so, you are not really in a cage... you
just preserve your investment, until Microsoft decides to purchase
Embarcadero (just kidding)

but consuming .NET classes from inside your VCL NATIVE application is NOT A
JOKE!
also, it's not a joke that the COM support just got better (in BCB 2009!) -
I'm gonna make a little bit of fun of their ridl (restricted idl) but hey,
it's better than persisting in tlb (that hurted... :-) anyway, if you start
isolating your tiers and encapsulate the basic/core functionality in COM
objects, well, your migration path to .NET would be so easy... after-words...
but if the BCB application is spagetti, it's not even worth to keep in this
state... (forgime my directness).

so, what i would do, i would just start "layering" my bcb application, with
bcb 2009 or even with old bcb 6 (i do not work for borland, nor i am trying
to make a sale here!) and then start build definitely layers (let's say based
on COM) then, if you don't like ADO.NET, you can use OLEDB bridges, and go
from there... to implement the presentation tier is not the end of the world,
if your application is already properly architected...

now, a joke, a friend of mine asked me "why don't we build a bridge like
OLEDB for .NET" exactly the opposite of ".NET bridge for OLEDB / ODBC" -
since so many applications currently use OLEDB, this may be an interesting
idea... :-)

stick with VCL, do not promisse anything to your folks, porting legacy VCL
application from BCB to ANYTHING ELSE is not a walk in the park, and the
first steps, the first porting strategy may not require any purchase of any
kind (we all have subscriptions anyway, btw, they offer subscriptions for
bcb/delphi as well) so, it's the architectural discipline in your application
giving you freedom of choice and not a tool/framework or another)

best regards, may have no reply to the right persons, have fun,
d++

Daniel

unread,
Oct 10, 2008, 11:52:01 PM10/10/08
to
> 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.

absolutely! except that anders did not have a sens of humor when he decided
to use the system namespace, not for us, the ones who temporary joined the
borland croud after elvis left the building :-)

the cool thing about microsoft purchasing embarcadero is about adding a
smooth migration path to all all the VCL developers (about 3.5 millions, by
my precise statistics) - this is about being able to port a VCL application
from VCL to VCL.NET (even a BCB one) with minimal changes. but then again, if
they cared, they would have offered the very same smooth migration path to
VB6 and MFC developers, in a way, the VB6 folks do not matter much, because
they would digest what is offered to them... no disrespect for QuickBasic
folks, with a mouse, now even having implementation inheritance :-) but there
would be a MFC.NET (idi*t idea, right? well, not really!) I wish Bill (or
other senior architects) were here, to remember the episode from 1989 when
the c++ folks offered him something which had all it needed, componentness,
elegance, everything! but it needed 45% more memory, and of course, Bill said
no! What happened with those classes - well, they turned into intrinsic
controls of Visual Basic ONE. Sad story - Microsoft had no idea that the
component market will book and take VB with it, in the sky... Even the COM
model made to us (to you, actually) by a "pragma"... :-) Anyway, at least,
the MFC developers got a late update (the ribon interface, of course, without
designing capabilities, BCB has one with FULL DESIGNER! and about 3-4 3rd
party alternatives) - because in order to have a RAD experience you need a
form designer (and not just a dialog editor) and you need full component
model, at language level... But I was to say that the MFC developers got a
smooth migration path via hybrid applications... the ones who really did
software in box know exactly what I am talking about... The VCL developers
were almost to get a VCL.NET support for BCB, but nah, Danny, Eli & many
others decided that enough was enough... and left the building, just like
their older brother Anders!

d++

Daniel

unread,
Oct 10, 2008, 11:55:00 PM10/10/08
to
> 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++

Daniel

unread,
Oct 11, 2008, 12:00:01 AM10/11/08
to
> [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

Daniel

unread,
Oct 11, 2008, 12:05:01 AM10/11/08
to
> 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

unread,
Oct 11, 2008, 12:29:00 AM10/11/08
to
> 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)

absolutely, and if someone finds out that you have been using the GPLed QT
and ask you to publish you entire systems, well, my friend, you will need
reinforcements in the legal department :-)

it's getting even funnier when it comes to commercial products (not in
house, i mean software in a box)

would you also like to know how much our "friends" from gpl/gnu asked a
friend of mine, when he wanted to add GCC/GDB capabilities to Visual Studio?
they needed like a month to answer and they asked him for $300,000 (tree
hundreds thousands US dollars) to use GCC/GDB in a commerical product. of
course, my friend asked them what they were smoking

i thought that this forum knows better than to even mention the abomination
of desolation called GPL! and to make the whole story super funny, who's the
good samaritean... NOKIA (a multi billion dollars hardware manufacturer which
knows about software about how much I know about other galaxies, wich just
realized that symbian is a joke (just burned 45 billions bucks on garbage),
and have some senior vp(s) to figth for their red velvet chairs and purchased
QT?!? what a joke)

guys, let's get serious, there is NO GPL! linus... is he helping his
neighbors? his salary is far in six figures and it's definitely not paid by
anybody's neighbor! i tell you the truth that the linux kernel has so little
to do with the bazaar development that it would be easy to any brilliant guy
to joing the Microsoft Windows Kernel Team! (great place to work!) rather
than pushing a single driver in that abomination...

same about GCC/GDB, you name it... don't believe me? try it for yourselves!
and get back in TEN YEARS. i felt pitty and wrote some gdb stl evaluators,
for the poor folks loosing their time with "against the nature" hobies like
open source... do you know what happened. they've published me all over (i
was laughing with my wife, big time, what a stupid things, the great debugger
gdb, cannot tell you an stl vector of ints, containing 1, 2, 3?!? and then a
year later, i've checked the initial wiki site, some bimbos (from canada)
took ownership and they were actively maintaining my scripts like hosting
eveything into a california based proprietary repository and claiming fixes
against bugs which were not bugs and about features which were practically
illegal in any decent c++ compiler implementation... i said "hush" to them
over email and they started to appologize that they were trying to maintain
my code (whata joke - i tell you what, open source is about hungry people,
trying, just like in hell, to take profit, to earn credits from sombody
elses, idealistic, business-wise, illogical coding investments)

CODE IS LIKE MONEY IN THE BANK, YOU HAVE OR NOT (in which case, at least
HOPE THAT YOU CAN PRODUCE IT). I am your neighbor, would you share your debit
card with me? I would not! Because it is my investment, my hard work, my
merits, my account. PERIOD. the rest is smoke and mirrors, and hidden
interests (from industry "partners" like sun, ibm, novel, et cetera - the
entire list of loosers, defeated so many times, the it would be booring to
even remember...) When you need help, I tell you what, YOU ARE GOING TO HELP
YOURSELF, BY FULFILLING YOUR BEST EXCITMENT and by previously being respected
by so many, because your ideas made sense and sometimes, happen to put money
in their BANK as well. This is credible... But Open Source is a joke!

there is NO OPEN SOURCE! the reality is simple. brilliant, hard working,
well educated, CODE NINJAS produce professinal code/applications employed and
respected by large corporations (so they sell their work, at a fair price,
based on their needs, to provide for their family, employees, in case you
have some, etc). And so is linus torvalds doing as well! And there is nothing
wrong with this. The rest is simple / cheap stalman fairy tale... :-) Time
will say, you have been told, i tell you again, they will not lost.

c++ folks we'll be here, happy to have you back (seriously)

d++

Daniel

unread,
Oct 11, 2008, 2:48:00 AM10/11/08
to
> 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.

yes, that's correct and there is a very strong reason for taking this
position. the reasons is not entirely technical. the reason got his roots in
late 90s. the java was growing and, obviously, microsoft initially tried to
do their best to make every single java developer a better life when
programming in java, under windows. but the treat of having crowds of
developers raising questions like "if my program runs the same everywhere,
why would i wanna stay in windows, that means that my skills are portable"
and this simple idea, java as a platform, write once run everywhere was
something to make microsoft do something about! so far so good. now, after
almos 13 years, we realize that sun's java campain was smoke and mirrors.
that java didn't run all that well anywhere, that it left behind a huge trace
of "so and so code" and despites everything looked so good (better c++,
implementation inheritance) in reality java suffered from the less common
denominator syndrom (of not really running well anywhere). but microsoft felt
the treat and reacted in the most normal way, i would you would you name it.
they stopped investments in java, especially after the very same anders
finished windows foundation classes, a better java, the father of .net
framework and we all know what happened. microsoft got inspired by many and
they made their own programming language, in this case, c#, architected by
the one of the most brilliant minds of the 20st centuries (anders). .NET
meant a better life for all windows programmers and give microsoft the chance
they've been looking for, to offer a new opportunity a new practical reason
that crowds of developers would rather stay and develop windows applications.
.NET was a better java! a finally, native and unrestricted JAVA, being able
to actually fulfill real life, daily, practical needs for so many, in the
industry. and that mattered! whatever java was missing, c# (and .net/cli) did
have, true support for properties, object oriented support of intermediate
assembly, true windows support, and instead of cross platform, offered cross
language interoperability. the crowds reacted and in a way, it makes perfect
sense not to certify C++ developers, since these guys know so much, that
their systems certify themselves! on the other hand, in mfc (and later on in
atl) you see a bizare mix of the most advanced C++ features (templates,
multiple inheritance) coupled, mixed together with horrible (completely
unnaceptable, type unsafe) c preprocessor macros, so horrible and
innapropiate that they make one wonder... it's legacy, it was the way to go,
a long time back, they've been accepted for aparent simplicity, when in fact,
the C++ language supposed to get true support for properties, events, etc in
order to offer true COMPONENTNESS to the masses (just like BCB dialect, and
VCL, never fully ported to C++ did once). Even today, the 0x upcoming C++
standard say NOTHING about support for properties and events (true
componentness) for the simple reason that the ANSI C++ comitee is 99%
politics and 20 years old technical agendas (spliting hairs instead of
actually doing what the crowd need). from this point of view, c# is
definitely better, vb as well was alligned, keeping some familiar feel and
touch and the impression that still feels like the old days, etc.

i am adding all these words, trying to give you the reason microsoft
recommends c# instead of C++ for most cases, especially when it comes to
inhouse programming for data entry forms, fat client applications, etc.

what will happen with C++ is another story. i sure hope that microsoft
realized that an entire segment of developers (the industry standards via mfc
crowd) maybe desearved a smother life, in terms of porting their applications
into the 21st century. on top of that, i bet that a lot of expenisve
marketing analysis show that one of the reasons unix still exists (in one
form or another) is the fact that many people can reuse their existing skills
(mostly in c and c++) over decades. then it's the issues of still running
applications writen tens of years ago, et cetera, et cetera, et cetera.

you recommended, possibly, a complete rewrite in C#. this sentense tells me
that you most likely deal with systems under a million lines of source code
(10k, 20k, etc)

for the rest of us, porting legacy applications of high complexity to C# is
as impossible (read funny) as deciding not to use English in business, but
esperando...

thigs just don't work that way, not in this time and space. that WHY, if you
pay attention, you will see microsoft (we do) remembering that there is an
entire market segment of legacy MFC apps (interesting VCL and BCB belong to
that segment as well, except that the C++ dialect in BCB does have full
support of properties and events and an anternative framework which still
feel fresh even after almost 13 years) - so, they remembered that crowds of
excellent developers, dealing with super complex C++ legacy code, could not
possibly migrate, not over night to .NET. some of them do, but others just
had to keep those systems running, offering whatever features their users
needed, on daily basis.

another category is commercial software applications. .NET runtime did not
always exist everywhere. sometimes, in certain commercial applications, raw
performance is essential. in other applications, security is very important.
and i am not talking about security in general, but precisely about the level
of confidence that your native, fully compiled and encrypted and compressed
code, could not be reverse engineered because the cost of this would be
higher than the cost of simply rewriting it.

i know, .NET offers a full range of obfuscators, sometimes, entire apps are
dressed into a native stub, instantiating the managed stuff in memory, it's a
looooong story. i do know about JITs, about the strategy of actually bringing
manged code at the level of "native" code, but there are places where native
code is needed, and the (so hard to get) skills of C++ programmers will
always be fully rewarded.

so, it's commercial software (in a box). then drivers. then system level
development, anti viruses, security software, even legacy enterprise
applications, then development tools, reality cannot be put in a box and go
like "hey, this is better, it's my way or the highway" - it simply doesn't
work that way.

So, David, if you pay attention, you should be aware that most recently,
Microsoft started to actually pay attention to this market segment. I
recently received my MSDN Magazine (October 2008, vol 23 no 11) containing an
invitation to best practices, october 27-30, 2008, hynes convention center,
boston, ma). Do yourself and other a favor and take a look at that flier.
It's mostly C++!!! NATIVE C++!!! Among speakers, you see his excellency herb
sutter, even the "god" of C++ bjarne stroustrup himself, embarassing everyone
about the lack of properties and events support in the new upcoming C++0x
standard (which will take another 20 years of dog fights to get to the market
:-) No disrepect! But don't you see a pattern here? I would! And I do not
think that this is about "hey, my language is better than yours" (i am
personally fluent in about 20 programming languages, frameworks, etc) but
about the Microsoft's realization that the world we live in is getting to the
point of general acceptance at standard levels, for languages, frameworks,
one day even component models (unrelated to framework's definition) and even
kernels! so, C++ has definitely a good place and will still secure an
excellent position, for at least our life time! well, if this is the case
(just like the reality of global economy, village, you name it) it's time for
Microsoft to realize that and take the world again, by storm, and win! just
like they always did and we did, with them as well. I remember a yellow flier
I've got in late 80's from Microsoft, it said like that: do you wanna know
who is the most important person at Microsoft? Well, open it! and inside it
said simply "YOU ARE!"

So is here and now.

Let's hope for the best, I am super confident that the most brilliant minds
in the known universe will find a way and we'll get all better and better,
day by day, as developers, business men, managers, owners, consultants, in a
way, we are all a part of Microsoft and the other way around, right?

Have Fun, Follow your Joy,
Daniel

Daniel

unread,
Oct 11, 2008, 3:01:02 AM10/11/08
to
I am answering myself. C0x standard did not accept native support for
properties and events (componentness) because one of the highest values of
C++ itself is to keep things simple and NO MAGIC. The ANSI comittee
considered that implementing a componentness model or another is not and
should not be a part of the language itself, having portability, raw
performance and other things in mind. Most of the new features give up the
initial C++ axiomes, and I do believe that standard support of PME
(property-method-event) model would have made a better C++, but then again, I
am NOT the ANSI comittee, nobody actually is, except inherent politics...
From what I've been informed, they simply believed that the PME should be a
part of the framework itself and not the language. Obviously, this is yet
another historycal mistake in C++ evolution! :-) Time will tell...

Have fun,
d++

Daniel James

unread,
Oct 11, 2008, 7:24:38 AM10/11/08
to
In article news:<679FAD0D-9EA4-4660...@microsoft.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.

Daniel James

unread,
Oct 11, 2008, 7:24:37 AM10/11/08
to
In article news:<usEhm6sK...@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

unread,
Oct 11, 2008, 7:24:37 AM10/11/08
to
In article news:<3763B447-30F6-4EF0...@microsoft.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

unread,
Oct 11, 2008, 11:11:01 AM10/11/08
to
Hurb Sutter: For me, easily the biggest news of the meeting was that we voted
lambda functions and closures into C++0x. I think this will make STL
algorithms an order of magnitude more usable, and it will be a great boon to
concurrent code where it's important to be able to conveniently pass around a
piece of code like an object, to be invoked wherever the program sees fit
(e.g., on a worker thread).

and this is so true!

there are two things i would personally like to see, in the standard (not in
a brilliant proprietary set of language extensions or another).

1. better property support, and when i say better, i mean better than this:
http://www.codeguru.com/cpp/cpp/cpp_mfc/article.php/c4031#more
2. infering! and i don't have to say no more :-)

happy c++,
d

Cholo Lennon

unread,
Oct 12, 2008, 9:08:06 PM10/12/08
to

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 :-)
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 :-)
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.

--
Cholo Lennon
Bs.As.
ARG

Daniel

unread,
Oct 12, 2008, 9:44:00 PM10/12/08
to
> 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

Daniel

unread,
Oct 12, 2008, 10:21:11 PM10/12/08
to
> 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

Daniel

unread,
Oct 13, 2008, 9:37:01 AM10/13/08
to
> 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

unread,
Oct 13, 2008, 11:59:15 PM10/13/08
to
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, int> m_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

Daniel

unread,
Oct 14, 2008, 8:32:01 AM10/14/08
to
> 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

Daniel

unread,
Oct 14, 2008, 8:38:01 AM10/14/08
to
> 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

unread,
Oct 14, 2008, 12:02:50 PM10/14/08
to
In article news:<3CC19F28-03DA-4BB0...@microsoft.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.

Daniel

unread,
Oct 14, 2008, 3:02:01 PM10/14/08
to
> 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

unread,
Oct 14, 2008, 11:07:03 PM10/14/08
to


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

Daniel

unread,
Oct 15, 2008, 12:58:01 AM10/15/08
to
> // 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++;

you are correct, in bcb, by prop definition, chained assignments of
properties is not allowed. both cases are 100% identical. this has been
stated in the help since bcb1... the reasons for that it "accomodating vcl"...

however, why looking at bcb only? msvc has FULL support of properties,
covering everything, including chained assignments, as following:

struct S {
void putprop(int j) { i = j; }
int getprop() { return i; }
__declspec(property(get = getprop, put = putprop)) int the_prop;
private:
int i;
};

void main()
{
S foo;
int i = foo.the_prop++, j = 10 + foo.the_prop++;
}

this will compile and work very well. the idea of having compiler support
for properties was about c++ as a language, not about an implementation or
another. msvc property implementation is really covering everything and in
order to accomodate such power with a class template model for properties,
well... you hear me

ps
never meant a war tone :-)

regards,
d

Daniel James

unread,
Oct 15, 2008, 6:58:18 AM10/15/08
to
In article news:<B698907D-9509-4A05...@microsoft.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/radstudio/radstudio2007/RS2007_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.

Daniel

unread,
Oct 15, 2008, 9:52:04 AM10/15/08
to
> 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/radstudio/radstudio2007/RS2007_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_mfc/article.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

unread,
Oct 16, 2008, 6:31:15 AM10/16/08
to
In article news:<0B7F2296-4CAE-4A1B...@microsoft.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.


Daniel

unread,
Oct 16, 2008, 11:12:01 AM10/16/08
to
> you were lying?

?!? what is this place ?!?

> Enough, already!

correct

Daniel

unread,
Oct 16, 2008, 11:58:01 AM10/16/08
to
> 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

Daniel

unread,
Oct 16, 2008, 1:21:02 PM10/16/08
to
> 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]

unread,
Oct 21, 2008, 4:55:35 PM10/21/08
to

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]

unread,
Oct 21, 2008, 5:02:46 PM10/21/08
to
> of cross platform, offered cross language interoperability. the
> crowds reacted and in a way, it makes perfect sense not to certify
> C++ developers, since these guys know so much, that their systems
> certify themselves! on the other hand, in mfc (and later on in atl)

You're not only a troll, you're rather naive as well. .NET systems don't
certify themselves any more than C++ systems do.

> you see a bizare mix of the most advanced C++ features (templates,
> multiple inheritance) coupled, mixed together with horrible
> (completely unnaceptable, type unsafe) c preprocessor macros, so
> horrible and innapropiate that they make one wonder... it's legacy,
> it was the way to go, a long time back, they've been accepted for
> aparent simplicity, when in fact, the C++ language supposed to get
> true support for properties, events, etc in order to offer true
> COMPONENTNESS to the masses (just like BCB dialect, and VCL, never
> fully ported to C++ did once). Even today, the 0x upcoming C++
> standard say NOTHING about support for properties and events (true

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

> componentness) for the simple reason that the ANSI C++ comitee is 99%
> politics and 20 years old technical agendas (spliting hairs instead
> of actually doing what the crowd need). from this point of view, c#
> is definitely better, vb as well was alligned, keeping some familiar
> feel and touch and the impression that still feels like the old days,
> etc.
>

[snip]

>
> i know, .NET offers a full range of obfuscators, sometimes, entire
> apps are dressed into a native stub, instantiating the managed stuff
> in memory, it's a looooong story. i do know about JITs, about the
> strategy of actually bringing manged code at the level of "native"
> code, but there are places where native code is needed, and the (so
> hard to get) skills of C++ programmers will always be fully rewarded.
>
> so, it's commercial software (in a box). then drivers. then system
> level development, anti viruses, security software, even legacy
> enterprise applications, then development tools, reality cannot be
> put in a box and go like "hey, this is better, it's my way or the
> highway" - it simply doesn't work that way.
>

Wow, you rag on C++ and then say it's necessary. Make up your mind please.


Ben Voigt [C++ MVP]

unread,
Oct 21, 2008, 5:03:37 PM10/21/08
to
Daniel wrote:
> Hurb Sutter: For me, easily the biggest news of the meeting was that
> we voted lambda functions and closures into C++0x. I think this will
> make STL algorithms an order of magnitude more usable, and it will be
> a great boon to concurrent code where it's important to be able to
> conveniently pass around a piece of code like an object, to be
> invoked wherever the program sees fit (e.g., on a worker thread).
>
> and this is so true!
>
> there are two things i would personally like to see, in the standard
> (not in a brilliant proprietary set of language extensions or
> another).
>
> 1. better property support, and when i say better, i mean better than
> this: http://www.codeguru.com/cpp/cpp/cpp_mfc/article.php/c4031#more
> 2. infering! and i don't have to say no more :-)

Already there, see the new and improved 'auto' keyword.

Ben Voigt [C++ MVP]

unread,
Oct 21, 2008, 5:08:50 PM10/21/08
to
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.


Daniel

unread,
Oct 21, 2008, 7:27:01 PM10/21/08
to
> 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...

Daniel

unread,
Oct 21, 2008, 7:31:00 PM10/21/08
to
> 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]

unread,
Oct 22, 2008, 12:13:09 PM10/22/08
to
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.

Daniel James

unread,
Nov 1, 2008, 2:20:49 PM11/1/08
to
In article news:<#qBPe97M...@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/licensing/licensing

seems to say that they manage it somehow.

Cheers,
Daniel.

Ben Voigt [C++ MVP]

unread,
Nov 3, 2008, 10:36:21 AM11/3/08
to

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

unread,
Nov 4, 2008, 4:51:00 AM11/4/08
to
In article news:<eeSFtncP...@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]

unread,
Nov 4, 2008, 1:03:52 PM11/4/08
to

"Daniel James" <waste...@nospam.aaisp.org> wrote in message
news:VA.0000155...@nospam.aaisp.org...

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

>
> Cheers,
> Daniel.
>
>

Daniel James

unread,
Nov 5, 2008, 8:19:22 AM11/5/08
to
In article news:<B70AF9DC-8DBA-41A5...@microsoft.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.


Reply all
Reply to author
Forward
0 new messages