porting from C++Builder

[Daniel]

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]

[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]

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]

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]

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]

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]

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]

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

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.

 

[Daniel]

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]

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]

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]

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]

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]

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]

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]

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

 

[Daniel]

// 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]

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]

you were lying?

?!? what is this place ?!?

Enough, already!

correct

 

[Daniel]

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