Board index » cppbuilder » Re: Open Letter discussed on Slashdot

Re: Open Letter discussed on Slashdot


2004-10-26 06:49:40 PM
cppbuilder36
Diamondback has never been promised to support C++.....yet.
I write in C++ also and eagerly await a version that does support C++
properly.
I hope that a version will be out next year - 2nd quarter would be nice - so
that I can move forwards.
Rgds Pete
"Mark Jacobs" <www.jacobsm.com/mjmsg?Borland%20Newsgroup>wrote in
message news: XXXX@XXXXX.COM ...
Quote
My first point is "I write in C++ - how does Diamondback help me?"

My second point is "OK then, where is Diamondback? I cannot see it on any
of
PC World's shelves. It does not seem to be available from Borland. How do
I
obtain a copy? If it has not been released yet, then that's no use to us.
We
need something that works now."
--
Mark Jacobs
DK Computing
www.dkcomputing.co.uk

"Pete Fraser" < XXXX@XXXXX.COM >wrote in
message
news:417d07f5$ XXXX@XXXXX.COM ...
| Mark, you do know that Diamondback has both Win32 VCL, VCL.NET and
Winforms
| support as well as C# support? And code folding and refactoring and.....


 
 

Re:Re: Open Letter discussed on Slashdot

Mark Jacobs wrote:
Quote
My second point is "OK then, where is Diamondback? I cannot see it on
any of PC World's shelves.
Probably because Diamondback was only the (internal) project name. It
is called Delphi 2005 now.
--
Rudy Velthuis [TeamB]
"Mit der Dummheit kämpfen Götter selbst vergebens"
"Against stupidity the (very) gods themselves contend in vain"
-- Friedrich von Schiller
 

Re:Re: Open Letter discussed on Slashdot

[Cancelled message]
Parts of your message were defamatory bordering on slanderous.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

{smallsort}

Re:Re: Open Letter discussed on Slashdot

"Marcelo R. Lopez, Jr." < XXXX@XXXXX.COM >writes:
Quote
>Perhaps a copy of the letter should be sent to Forbes and Fortune.
>PHBs tend to read them.
>
Actually, I'm forwarding a link to a certain editor I know at SD
Times. Maybe it'll get picked up from there...
Dr Dobbs would be interested too.
They had a satirical item about Borland sometime last year.
 

Re:Re: Open Letter discussed on Slashdot

Quote
new language? We *DO NOT NEED A NEW LANGUAGE*. Why? Because C++ is almost
perfect, and it comes from a pedigree of languages that fitted with their
hardware environment more snugly. BCPL by Martin Richards was so simply
defined, that writing a compiler for it might take the best part of an
afternoon at the most. Its only assumptions about the underlying hardware were
I'd like to see the m$ extensions added to the C++ standard because
the lack of GC semantics and things like properties are all that is
hold C++ back from being the perfect RAD language as well.
 

Re:Re: Open Letter discussed on Slashdot

Mike Margerum wrote:
Quote
I'd like to see the m$ extensions added to the C++ standard because
the lack of GC semantics and things like properties are all that is
hold C++ back from being the perfect RAD language as well.
Properties and GC have comparitively little to do with RAD. There are
certainly many RAD environments without GC, and a little creativity can
solve the lack of properties too.
What is holding C++ RAD back is a lack of detailed RTTI, and the lack
of cross-platform GUI (as *something* has to draw the RAD tools!)
The GUI can easily be provided as a non-standard library on each
interested platform, the RTTI really does involve extending the
language.
As for C++/CLI, it is a bit of a mixed bag and focused entirely on
making C++ play nice with other .NET languages. That is a worthy
enough goal that ECMA are prepared to work on a standard for the
binding, and there is a good chance it will get fast-tracked through
ISO too (much like C#) It does not mean I want a lot of .NET specific
features in the base ISO language.
Note that several issues are being worked on in conjunction with the
C++/CLI committee (which is largely populated by ISO members anyway!)
For instance, forwarding constructors have evolved in parallel between
both committees, so they have looked at how best to implement the
feature compatibly. long long was worked through ECMA before ISO by
the same people (largely a time-tabling issue)
AlisdairM(TeamB)
 

Re:Re: Open Letter discussed on Slashdot

"Alisdair Meredith [TeamB]" < XXXX@XXXXX.COM >writes:
Quote
The GUI can easily be provided as a non-standard library on each
interested platform, the RTTI really does involve extending the
language.
I'd claim it involves extending the COMPILER, but not necessarily the
language. For example, Stroustrup's XTI library is a pure C++ library
that can read special additional files generated by the compiler, such
that at runtime you can query it for just about any info about the
progrma you can imagine, including querying about OTHER program's
types if you read their files.
That the compiler must generate an additional file (or set of files)
for this to work would be a new requirement in the compiler
implementation, but it would not affect users of C++ "seeing" any
changes in the syntax or semantics of the languages (though they would
have a new library to learn.)
If RTTI querying were not done in a library, but changed the syntax,
THEN it would be a language change. Though there may be very good
arguments in favor of a language change, I just don't think it's
entirely essential.
Have you heard anything about XTI lately? Is he still working on it?
Quote
As for C++/CLI, it is a bit of a mixed bag and focused entirely on
making C++ play nice with other .NET languages. That is a worthy
enough goal that ECMA are prepared to work on a standard for the
binding, and there is a good chance it will get fast-tracked through
ISO too (much like C#) It does not mean I want a lot of .NET specific
features in the base ISO language.
100% agreed. But there are some things in C++/CLI that I really
like and wouldn't mind seeing added to the ISO standard.
--
Chris (TeamB);
 

Re:Re: Open Letter discussed on Slashdot

"Chris Uzdavinis (TeamB)" wrote:
Quote
Have you heard anything about XTI lately? Is he still working on it?

According to one of his collagues he still is (few montsh ago).
/Pavel
 

Re:Re: Open Letter discussed on Slashdot

Quote
What is holding C++ RAD back is a lack of detailed RTTI, and the lack
of cross-platform GUI (as *something* has to draw the RAD tools!)

This is what i was talking about. published properties. you need
RTTI for a RAD designer and I dont want macros or obscure template
tricks to be the answer.
 

Re:Re: Open Letter discussed on Slashdot

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >writes:
Quote
>The GUI can easily be provided as a non-standard library on each
>interested platform, the RTTI really does involve extending the
>language.

I'd claim it involves extending the COMPILER, but not necessarily the
language. For example, Stroustrup's XTI library is a pure C++ library
that can read special additional files generated by the compiler, such
that at runtime you can query it for just about any info about the
progrma you can imagine, including querying about OTHER program's
types if you read their files.
Does it allow to look up all methods with certain name and signature,
create an instance of every class that contains such methods, and
invoke them?
[snip]
--
Oscar
 

Re:Re: Open Letter discussed on Slashdot

Oscar Fuentes < XXXX@XXXXX.COM >writes:
Quote
Does it allow to look up all methods with certain name and signature,
create an instance of every class that contains such methods, and
invoke them?
The talk I saw him give was back in 2001, and I don't quite remember
all the capabilities. I'd doubt that you could create an instance of
a class at runtime by looking at RTTI without some serious
restrictions. For example, you'd at least have to know ahead of time
what the class's base type was, or else how would you hold a pointer
to the object just created?
Second, since it was (IIRC) more to answer questions about types, it
works with the output code from OTHER programs. One of the motivating
examples he was interested in was distributed computing and
marshalling data. One thing of interest was the ability to "check" if
a remote connecting program is compatible with your data by inspecting
the class structure the remote program is using, with some protocol
that would have the client upload its info to the server, and the
server would validate it's correct.
Other uses were to detect version changes, etc.
Clearly, you couldn't instantiate an object whose definition isn't
linked into your application, so being able to read this library
information isn't in general enough to instantiate the objects unless
you could also provide a dynamic link library, and then figure out a
way to make calls into a unknown type to your code except from dynamic
discovery. Might as well embed scheme interpreter... :)
--
Chris (TeamB);