Board index » cppbuilder » Re: The Open Letter Day Arrived

2004-05-18 03:32:07 PM
cppbuilder77
I R T wrote:
pre-announce it very early in case things change and features which were
announced, then aren't included.
Who's betting that Longhorn goes under many changes before it is finally
released in 2047 or whenever? You can't really plan for Longhorn
development yet because you don't know what it will finally contain.
So Borland's policy does have its merits, but a simple statement as to
which is there RAD library of choice for future win32 development (wx or
VCL) must be possible. If they haven't decided that yet, then they must
be in a very bad shape internally.
Thanks
Russell
 

Russell Hind < XXXX@XXXXX.COM >writes:
 

I R T wrote:
Whidbey framework.
And if that takes too long, again in Longhorn.
M$, home of the eternal re-implementor anonymous fan club.
<g>trying to get ones goat, dude.
 

{smallsort}

I R T wrote:
would be nothing worse than planning your next 2 years development
around a feature that suddenly gets dropped until a later version or
altogether.
Don't get me wrong, Borland's attitude to lack of information is
appalling. How can you plan any development with the mixed signals
we've had from them wrt RAD and libraries.
I'm just trying to say that pre-announcing everything at an early stage
(more in regards to Longhorn than Whidbey) isn't always the best thing
for customers.
Cheers
Russell
 

Valence Crearer < XXXX@XXXXX.COM >wrote:
Win API or MFC never even had a doubt
about ther code's future. It is still
supported, there always were rather easy
migration paths, and the current C++
compiler compiles most of the old code
(including even old 'for' loop scoping).
They have stated numerous times that they
have a vast interest in this as they have
billions of old C++ LOC themselves that
needs to compile and so far this seems
to be true.
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 

Hendrik Schober wrote:
The overall windows framework did not change before but now it will. I
refer to the .NET wagon, not MFC. What .NET framework changes are
upcomming for Whidbey? How much will that be diffent from Longhorn?
(Will MFC work in .NET now?:->) Will Win32 apps need to be
re-implemented to use these new technologies for organizations to do
tomorrow what they are already doing today in Win32? Will Delphi
developers be uniquely possitioned for this change? Will consultants and
consulting firms be able to capitalize on all levels of these changes?
But better questions are: (redirect to topic)
Will BCB provide Whidbey development in the future with VCL like Delphi?
(CLX?) (CBX?)
Will BCB provide Lonhorn development in the future with VCL like Delphi?
(CLX?) (CBX?)
How will Borland go about radically simplifying the migration to each
step?
How will Borland address the needs of the diverse community with a
"one-stop shop" C++ that will retain my, and your interest?
If they proceed in a non-standard/propietary way, what can they put
forward to show that the industry can rely on heading in that direction?
(Tie it to Delphi?)(Tie it standards so that if it fails, you can run?)
Borland needs to say how they intend to proceed so as to maintain
our(your/my) focus.
But as stated earlier in this thread, their needs to be some level of
accuracy to whats said or any plans to for the future made based on them
would join the re-implement bandwagon.
 

Russell Hind wrote:
of CBX, when everyone was 'expecting' the release of BCB7, and were then
caught completely by surprise by the 'end' of BCB. There was no excuse
for it then, and there is no excuse for it now.
There's a huge difference between releasing announcements of
'vaporware', and keeping an about-to-be-released 'product change' so
completely under wraps that you alienate your entire user base.
David Erbas-White
 

Valence Crearer < XXXX@XXXXX.COM >wrote:
meaning.
birth and porting code to newer versions
were by orders of magnitude easier than all
the transitions Borland's customers were
supposed to go through (OWL1 ==>OWL2 ==>
VCL ==>CLX ==>wxWin?).
I think you are supposed to be able to run
old apps (that includes MFC apps) on Longhorn.
What's more, since in VC you can freely mix
std C++ with MC++, you are able to not only
maintain old code, you can even extend old
code with .NET stuff -- if you want, in the
very same .cpp file.
I'm not trying to tell you how incredibly
good MFC and .NET are -- I have never used
them, so I wouldn't know. (I have, OTOH used
OWL1, OWL2, VCL and think, compared to their
competitors, they all were exceptional good.)
But my point is that those who used MS stuff
always had a smooth transistion path from the
past to the future, while Borland customers
had the exact opposit. This is in response to
your statement
"M$, home of the eternal re-implementor
anonymous fan club."
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 

David Erbas-White wrote:
stage where they can tell us which IDE they will focus on (BCB/CBX) and
which RAD library (wx/VCL). So we can only hope they do deliver the
next letter ASAP.
I am finally now considering how easy it would be to implement C#
interfaces with a C++ back end (probably require some managed C++
interfaces wrapping the C++ objects) as I wasn't keen on the current
managed C++ WinForms applications. I don't know how much the new
C++/CLI has improved for the next version. But this is the first time I
have considered it now due to lack of information about the future and
what tools I am to be using.
I like BCB and I like CBX and I had accepted that Borland's future lay
with CBX and wx. But the last few weeks on these groups has led me to
believe that this might not be the case and we may see a BCB7 and no CBX2.
This has really p****d me because I no longer have a clue about where
development is heading.
Cheers
Russell
 

Russell Hind wrote:
may be left off. If Borland is going to pour $$ back into the VCL in BCB it
would seem that they are doubling up if they also put money into a designer
etc for wx. This is unless they decide to build the 'framework independant
designer' that was mentioned a while back. Maybe then it can handle both. I
doubt it though.
My guess is that BXB2 will come out focused on cross platform with little to
no improvements in the areas of wx/a wx designer.
Enough 'testing the water' with regards to the new info policy. Start
talking Borland.
--
Vesty.
 

Adam Versteegen wrote:
would be very happy to see the CBX IDE along with a VCL designer as I
think the prime time framework lends itself towards more complex C++
projects than the Delphi/C# IDE does (basically the project manager and
build system are what a C++ IDE needs (ignoring the numerous BOE bugs,
the project manager and build system in BCB is very sub-standard in
comparison in terms of features).
But all this again is just speculation and rumor-mongering until we hear
something official ...
Cheers
Russell
 

Hendrik Schober wrote:
trying to get his dander up. You showed me the word trolling. I said that so
I R T would not feel it necessary to respond. I was anti-trolling, maybe.
transition smoothly to Whidbey's new framework, which is different from the
current one. Though I read that it was going to change again in Longhorn,
who knows now for sure? That is the origin of the re-implementor anonymous
club. Again, it may not be so bad once the real things actually come out if
MS does not create a chasm like they did between .NET apps and Win32 apps.
(Anti-troll: I know that it was necessary and I know that Win32 can interact
with .NET reasonably well. I'm specifically talking about present Win32 apps
that will become .NET apps). Maybe some Delphi folk can tell us how well
their transition went from Win32 to .NET in similar circumstances.
 

Russell Hind wrote:
Whidbey, rather than jump into managed C++ now.
It seems to be even more extensions (if that is possible!) but they
feel 'cleaner' in the way they interact with ISO C++, with fewer
reserved words. (Everything else is a 'context sensitive keyword)
Oh, and at least one of the new reserved words is also proposed for
C++0x (nullptr)
The big difference will be seen when authoring for .NEt though, rather
than consuming it. With managed C++ you can consume .NET, and it is
ugly, but providing CLS compliant code looks painful.
With C++/CLI you can write for .NET just as easily as with C# or those
other .NET languages, so it should be a lot easier to communicate with
you C# front end (if you still prefer to implement in C# at this point
anyway!)
Waiting for Whidbey just about gives Borland time for one last stab at
a Windows C++ product to evaluate against, but that is pretty much a
bonus.
AlisdairM (TeamB)
 

"Alisdair Meredith" wrote:
Peter
 

Alisdair Meredith wrote:
newsgroup access again!
Russell