Board index » cppbuilder » Re: Borland plans separate company for Delphi, JBuilder, C++Builder,InterBase,JDataStoreand other developer products...

Re: Borland plans separate company for Delphi, JBuilder, C++Builder,InterBase,JDataStoreand other developer products...


2006-02-09 03:22:27 AM
cppbuilder63
Michael Lueck wrote:
Quote
Rodrigo Gómez wrote:

>I don't think somebody would spend maybe 100+ US millions to later
>release the products as OSS.

Na, just start from scratch and make a OSS/FS equiv of Borland's wares.
There is OpenOffice out there, ja know. So no, it does not "require" the
use of Borland's source to create OSS/FS development tools that operate
the way Borland's did. I just simply wondered what state the licensing
around the source code is in.
Well, one can certainly try. And yes, there are very successful OSS projects out there,
but it requieres a huge effort, usually a lot of time, and those who will work in it also
need to eat. So, unless they work at something else, or for some reason have that part of
their lifes granted, the time they can spend in that is usually much less than what is
needed. up to now most of the software written with Borland tools gets sell in some way or
another (my guess, of course), and those companies need to have a certain security that
they are building in some strong foundation. And you don't get that kind of foundation
from OSS projects just by wanting, from one day to another.
For the moment I need to get my company going, and that means using Borland (or whatever
name it will take) products.
Quote
And you know, there are a few of us left in this world motivated by
other things than piling up a big huge pile of money that we can't take
with when our time here on Earth is done...
Yes, I know. And I consider myself among those, whom I don't believe are a few. I guess
everybody wants to let something here after dead. But, in the mean time, I also need to
get food into the table, pay the bills and, incidentally, getting money for the other side
of my life, the one more transcendental: photography, so that means making some money,
either working or winning the lotto, and obviously the second hasn't happened. Money for
me is a way to fulfill needs (and if possible, desires), not just because its nice to have it.
Regards,
Rodrigo Gómez
 
 

Re:Re: Borland plans separate company for Delphi, JBuilder, C++Builder,InterBase,JDataStoreand other developer products...

Alex Bakaev [TeamB] wrote:
Quote
I can open up an account in Caymans :)
Shame on you...!!!
Actually I just sent an email off to a well known and respected person in the OSS/FS community who is a friend of mine asking for his input on how to best roll with the momentum which seems to be
building.... like so as to not make an a$$ of myself. This story is over on SlashDot already, same tone there with the first posting... "It's just begging for some gas to be added to the fire!" ;-) I
will be interested to see what his input is.
I was involved in such a grass roots campaign nearly 10 years ago... it was a very interesting period actually. Not my "daily grind" by any means, but I would not have bypassed that period either, not
for anything. Thus, definitely not opposed to contributing to such an effort again.
--
Michael Lueck
Lueck Data Systems
www.lueckdatasystems.com/
Remove the upper case letters NOSPAM to contact me directly.
 

Re:Re: Borland plans separate company for Delphi, JBuilder, C++Builder,InterBase,JDataStoreand other developer products...

Will you keep us updated and perhaps let us know how we might participate?
"Michael Lueck" < XXXX@XXXXX.COM >wrote in message
Quote

I was involved in such a grass roots campaign nearly 10 years ago... it
was a very interesting period actually. Not my "daily grind" by any means,
but I would not have bypassed that period either, not
Quote
for anything. Thus, definitely not opposed to contributing to such an
effort again.

--
Michael Lueck
Lueck Data Systems
www.lueckdatasystems.com/

Remove the upper case letters NOSPAM to contact me directly.
 

{smallsort}

Re:Re: Borland plans separate company for Delphi, JBuilder, C++Builder,InterBase,JDataStoreand other developer products...

Edward Diener wrote:
Quote
Andre Kaufmann wrote:
>Tamas Demjen wrote:
>>David Intersimone "David I wrote:
>
>>[...]
>>does. However, the C++/CLI syntax for managed coding is different
>>enough from ISO C++ that we won't be able to compile our existing VCL
>>C++ code with a C++/CLI compiler. We won't be able to produce managed
>>and native output from the exact same code base
>
>Why ? IMHO a (currently) native VCL application could be directly
>compiled to managed code by using VCL.NET. The C++/CLI compiler could
>also support the VCL extensions and generate the appropriate managed
>code.
>
>You could also add C++/CLI code to this applications.
>
>A managed VCL application could use C++/CLI syntax, but IMHO isn't
>forced to do so. The compiler could rather support both variants.
.NET is a much richer environment than the current VCL. If one used the
current VCL to target .NET applications, one would be losing out on
quite a bit of .NET functionality which the VCL does not currently have.
Maybe VCL .NET has this richer functionality, but since I am a C++
programmer I have never used it.
Don't get me wrong. I like the .NET framework.
But I think it's rather a matter of migration and my impression is that
most of the current BCB developers don't want to drop Win32 support - at
least for their WinXP/Win2K/Win98 applications.
I only stated that current native VCL applications could be compiled
also to managed code without (that much) code change. That does not
prevent them from using the NET framework and WinForms - only if the
code must compile to native code also. Which I think won't be supported
by the Borland C++/CLI compiler for WinForms applications.
What framework you should use, when you start a new GUI application is
another question.
Quote
One of the biggest items is that .NET, through delegates, allows
multiple handlers for events. There is no current VCL equivalent except
Why shouldn't a C++/CLI VCL not support / use delegates ?
Quote
[...]
Andre
 

Re:Re: Borland plans separate company for Delphi, JBuilder, C++Builder,InterBase,JDataStoreand other developer products...

Tamas Demjen wrote:
Quote
Andre Kaufmann wrote:

>Sure. But since VCL is an extension to the C++ standard it
>doesn't/wouldn't need the additional ref keyword for VCL classes.

Only if you compile native code.

>Yes. But classic code can be compiled to CLI code too.

Not unless the code is trivial.
I don't agree. You cannot compile most of the native code to "safe" CLI
code. But there are only minor restrictions to compile it to CLI code.
Quote
The .NET framework is so far away from
the native C++ concept that it's not possible to compile real-world C++
code into managed code without making a few adjustments to it.
You can freely mix native and CLI/C++ code and hopefully a coming BCB
version will support that too.
Quote
In the
.NET framework there is a clear distiction between value types and
reference types. Value types use stack syntax, but they don't support
virtual functions or copy constructors.
Hm. In C++ stack and heap types are also clearly separated. Stack and
heap. The C++ syntax for stack and heap objects doesn't change in
C++/CLI. But the managed objects are not allocated on the stack. We are
discussing compilation - not internal changes made under the hood.
Each .NET language maps their allocation schemes differently, when
compiled to CLI code.
And you still can use "native structures". The only restriction is that
surely other .NET languages cannot use the native C++ classes.
->So native code cannot be exported / accessed directly, it must be
wrapped - to be (easily) accessible from other CLI code.
Quote
Reference classes must be
created on the heap and are always garbage collected. Again, there is no
concept for destructor or copy constructor. .NET Strings are
There is a concept for constructor / destructor. For managed classes it
will be transformed to the Dispose() method which will be automatically
called on destruction.
Quote
non-mutable, which means you can't change their content. This would even
make the migration of AnsiString difficult. In .NET you can't get the
address of any object, because the garbage collector freely moves them
around in the memory. So basically any pointer other than VCL objects
would have to be banned.

>Or define that VCL classes are compiled as managed ones if .NET is
>targeted.

If a C++ VCL application uses only VCL classes, nothing else, then there
may be a chance. Still, Borland would have to write a special compiler,
because there's nothing out
Hmpf. I don't like to discuss other compilers here in a Borland
newsgroup. But you force me to do that.
Quote
there currently that produces managed output
from C++ source.
VC 2005 does that.
E.g.:
void Output()
{
for(int i = 0; i < 10; ++i)
{
cout << "hello world";
}
}
Will be converted in pure mode to:
(parts of the resulting code)
.method assembly static void
modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl)
Output() cil managed
{
.vtentry 34 : 1
// Code size 33 (0x21)
.maxstack 2
.locals ([0] int32 i)
IL_0000: ldc.i4.0
IL_0001: stloc.0
IL_0002: br.s IL_0008
IL_0004: ldloc.0
....
IL_0018: call valuetype
std.'basic_ostream<char,std::char_traits<char>>'* .....
Quote
Both the old Managed C++ and the new C++/CLI are based
on extensions to the language, which are not compatible with Borland's
extensions.
Yes. But the point is VCL could use the C++/CLI syntax, but must not.
Optionally Borland could implement it that way that you can freely
choose which syntax to use, same as for C++ or managed classes.
If that would be a good idea is another story.
Quote
I, too, have been thinking about the possibility of designing a compiler
that creates managed output from C++ code that's using the VCL. It is
clear that it can't be pure managed output, it's gotta be a mixed-mode
output, which is perfectly fine.
See above - you have finally 2 options. Generate pure CLI code or mixed
code. Hope BCB will support that too. Better said must support that too
to allow a smooth migration of VCL code ;-).
Quote

Only classes derived from TObject would be compiled to managed code. The
compiler has to be able to recognize that you inherit from a
TObject-based class, and make that automatically a ref class. Native
members of such classes must be converted to pointers. For example, if
you have an std::vector<int>inside a VCL form's implementation, that
must be automatically changed to a pointer, created with new in the
constructor, deleted in the destructor. Every "member." would have to be
treated as "member->". It's questionable whether that level of
automation is acceptable in a compiler. If it's inside a private
declaration, it may be alright, but if it's public, it's simply too
much. Everything that includes the form is affected by that.
Embedded native classes in managed ones is currently only possible as
pointers. (In VC). Embedding native classes directly will be supported
in a coming version, so I don't see why the next BCB version could not
support that too ?
Quote
This brings us to another gray area -- the public member function
declarations. If they have POD arguments and return types, there's no
problem. If they have AnsiString, that can be converted into
System::String. The real problems begin when a member function passes a
native class by value -- in that case, the function can't be exported to
the managed assembly.
You can deal with pointers into the managed heap. But these objects must
be pinned and will clutter the managed heap. But as you can mix managed
and C++ code freely - why change the native code ?
Only for components BCB could support a compilation mode, so that only
code will be generated, which is accessible from other .NET languages.
Quote
There are further problems. In C++Builder a VCL class is still a native
class. Although you can't create them on the stack, you can store them
inside native containers. std::vector<TForm*>is valid. So is
boost::shared_ptr<TForm>. That kind of thing is very difficult to do
with .NET. Storing a managed class inside a native class requires that
you gcroot it, which is a kind of a reference counting. It has
implications, potential code-breaking effects. weak_ptr<TForm>, for
example, wouldn't play well with managed classes. You can completely
break your program logic.
Sure. But the compiler could do that under the hood. Borland has done
that already, with Delphi. Though supporting managed C++ VCL compilation
without code changes is not that>easy< as in Delphi.
Quote
[...]
I would go even further. Is it worth at all? Why do you want to use
.NET? The answer may be

1. Because of the RAD provided by WinForms. But VCL already has that.
Yes. But only a single compiler supports VCL. In C++/CLI I can change
the compiler freely. Another option would be to support the VCL for
other compilers too *g*.
Quote
2. Because .NET can target multiple platforms. Not so, because only if
it's pure CLR. If it's mixed-mode, it can not.
But in pure mode it can. Surely the C++ runtime must be available for
the other platform.
Quote
3. You want the dynamic component programming model of .NET, i.e.
exposing your classes in a distributed, language-independent way, such
as COM or CORBA, but without the intricacies of those horribly
cumbersome legacy technologies? Just wrap your code into .NET
interfaces. It doesn't require that you recompile your existing code
into .NET.
Did I write something different ?
Quote
To summarize it, it would be very difficult to write a compiler that
uses existing C++ source code to produce managed output. It would
Why - the compiler generates code for the backend - the backend
generates either x86, x64 or CLI code.
And since there's already a compiler doing that, it's not impossible to
do the same for Borland. Ehm - or whoever will buy BCB.
Quote
[...]

It's not just language issue, it's not that by modifying "class" to "ref
class" you have migrated. Designing .NET classes requires a different
thinking from the ground up.
Sure. But as Borland has done the automatic conversion already in Delphi
it's an example that it's not impossible to do so.
Quote
[...]
Tom
Andre