Board index » cppbuilder » BDS2006 and .NET for C++

BDS2006 and .NET for C++


2005-11-10 03:58:13 PM
cppbuilder78
Being totally unexperienced with .NET but planing to get some
experience with it I am wondering if I could use BDS2006 with it's
.NET languages (Delphi, C#) TOGETHER with my C++-Source
library-functions, i.e. write the .NET main application with e.g. C#
and link the .obj-Files from C++ (perhaps after a recompilation) into
it?
If yes, are some VCL-Types like AnsiString allowed to be used inside
these C++ functions?
Is (a direct) .NET-support for C++ not possible or is this planed for
the next version of BDS?
Thanks a lot,
Michael
 
 

Re:BDS2006 and .NET for C++

MR wrote:
Quote
Being totally unexperienced with .NET but planing to get some
experience with it I am wondering if I could use BDS2006 with it's
.NET languages (Delphi, C#) TOGETHER with my C++-Source
library-functions, i.e. write the .NET main application with e.g. C#
and link the .obj-Files from C++ (perhaps after a recompilation) into
it?

If yes, are some VCL-Types like AnsiString allowed to be used inside
these C++ functions?

Is (a direct) .NET-support for C++ not possible or is this planed for
the next version of BDS?
That's right - *force* all your clients to install half a gigabyte of flaky software on
their already burgeoning PCs!
People who opt for Java or .NET as their development frameworks, deserve what they get -
ease of use, platform independence, future-proof applications ... ;-)
--
Mark Jacobs
www.dkcomputing.co.uk
 

Re:BDS2006 and .NET for C++

<MR>wrote in message news: XXXX@XXXXX.COM ...
Quote
Is (a direct) .NET-support for C++ not possible or is
this planed for the next version of BDS?
.NET does not recognize or support C++ at this time. According to Borland's
roadmap, it plans to have C++ support for .NET implemented by 2007.
Gambit
 

{smallsort}

Re:BDS2006 and .NET for C++

Remy Lebeau (TeamB) wrote:
Quote
<MR>wrote in message news: XXXX@XXXXX.COM ...


>Is (a direct) .NET-support for C++ not possible or is
>this planed for the next version of BDS?


.NET does not recognize or support C++ at this time.
If by .NET you mean Microsoft .NET, this is not true. C++ has been
supported since the 1.0 release of .NET in October of 2001. Managed C++
has existed for the 1.0 and 1.1 versions of .NET, and C++/CLI will be
the C++ dialect for the 2.0 version of .NET officially released at about
the same time as the C++ Builder 2006.
If by .NET you mean Borland's support of .NET, you are of course right.
Quote
According to Borland's
roadmap, it plans to have C++ support for .NET implemented by 2007.
So soon ? Borland has got to slow down in their C++ support.
 

Re:BDS2006 and .NET for C++

"Remy Lebeau \(TeamB\)" < XXXX@XXXXX.COM >wrote:
Quote
<MR>wrote in message news: XXXX@XXXXX.COM ...

>Is (a direct) .NET-support for C++ not possible or is
>this planed for the next version of BDS?

.NET does not recognize or support C++ at this time. According to Borland's
roadmap, it plans to have C++ support for .NET implemented by 2007.
And in the meantime, VC 2005 Express is now available, supports .NET
with C++, and is free to download for the next year.
I hope Borland can achieve .NET support before 2007.
Alan Bellingham
--
Team Thai Kingdom
<url:www.borland.com/newsgroups/>Borland newsgroup descriptions
<url:www.borland.com/newsgroups/netiquette.html>netiquette
 

Re:BDS2006 and .NET for C++

Edward Diener < XXXX@XXXXX.COM >wrote:
Quote
C++/CLI will be
the C++ dialect for the 2.0 version of .NET officially released at about
the same time as the C++ Builder 2006.
It's on my machine as I write. And we're not talking a beta - Visual C++
2005 Express is available free for download from Microsoft.
Alan Bellingham
--
Team Thai Kingdom
<url:www.borland.com/newsgroups/>Borland newsgroup descriptions
<url:www.borland.com/newsgroups/netiquette.html>netiquette
 

Re:BDS2006 and .NET for C++

In article < XXXX@XXXXX.COM >,
"Remy Lebeau \(TeamB\)" < XXXX@XXXXX.COM >wrote:
Quote
.NET does not recognize or support C++ at this time. According to Borland's
roadmap, it plans to have C++ support for .NET implemented by 2007.
There was a session scheduled for today by Chris Bensen: C++ and .net
interoperability
It was canceled. Maybe the OP can email him for some details.
--
-David
Nihil curo de ista tua stulta superstitione.
 

Re:BDS2006 and .NET for C++

Remy Lebeau (TeamB) wrote:
Quote
<MR>wrote in message news: XXXX@XXXXX.COM ...


>Is (a direct) .NET-support for C++ not possible or is
>this planed for the next version of BDS?


.NET does not recognize or support C++ at this time. According to Borland's
roadmap, it plans to have C++ support for .NET implemented by 2007.

.NET is not language specific. It's a platform for languages. So I would
it write the other way round:
CBuilder doesn't (yet) support .NET, but it will support (C++/CLI ECMA
standard) it in a future version and compile MSIL code for the .NET
platform.
Quote

Gambit
 

Re:BDS2006 and .NET for C++

MR wrote:
Quote
Being totally unexperienced with .NET but planing to get some
experience with it I am wondering if I could use BDS2006 with it's
.NET languages (Delphi, C#) TOGETHER with my C++-Source
library-functions, i.e. write the .NET main application with e.g. C#
and link the .obj-Files from C++ (perhaps after a recompilation) into
it?
A .NET compiler doesn't emit native code. It generates MSIL code, which
cannot be used directly by native languages. There's currently only one
research compiler I know of that compiles MSIL code to native code.
So you have to use either one of the following possibilities to call to
native code from your C# code:
a) PInvoke (DllImport) to use a native DLL directly
Have a look at www.pinvoke.net for some Win32 examples
b) COM interop - COM objects may be used directly from .NET
and .NET objects may be compiled with an automatically generated
COM interface
c) Write a managed wrapper in Delphi
d) Write a C++/CLI wrapper (not yet supported by BCB)
Quote

If yes, are some VCL-Types like AnsiString allowed to be used inside
these C++ functions?
.NET uses unicode (16 bit) strings only. You have to marshal (convert)
them to AnsiString and vice versa.
Quote
Is (a direct) .NET-support for C++ not possible or is this planed for
the next version of BDS?
It's currently planned (by Borland) to support the ECMA standard C++/CLI
in 2007, perhaps in an earlier version.
Quote
[...]
Andre
 

Re:BDS2006 and .NET for C++

Ed wrote:
Quote
C++/CLI will be the C++ dialect for the 2.0 version of .NET
What does CLI stand for?
In VS 2005, how does one specify whether they want a C++ project to
compile to native/Win32 or .NET/MSIL? Is there simply a project-level
switch, so that one can toggle a project between the two? Or are the
differences between C++/CLI and ANSI C++ great enough that one must make
the decision at the time the project is created?
 

Re:BDS2006 and .NET for C++

"C.R. Hinners" < XXXX@XXXXX.COM >wrote:
Quote
Ed wrote:
>C++/CLI will be the C++ dialect for the 2.0 version of .NET

What does CLI stand for?
Common Language Infrastructure, if I remember correctly. I was proposing
++CLI as the name, but no-one went with me. Rotten swizz.
Quote
In VS 2005, how does one specify whether they want a C++ project to
compile to native/Win32 or .NET/MSIL? Is there simply a project-level
switch, so that one can toggle a project between the two? Or are the
differences between C++/CLI and ANSI C++ great enough that one must make
the decision at the time the project is created?
You set it as a project option. Oh, and you link to a whole bunch of
different things. So yes, you tend to do it at project creation time,
just as you do when you're choosing MFC or WTL, for example.
Actually, I think you may be able to generate a console app as either
Win32 or .NET, but the moment you start picking your APIs, I suspect the
choice of framework pretty much determines the choice of Win32 or MSIL.
Alan Bellingham
--
ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK
 

Re:BDS2006 and .NET for C++

Alan Bellingham wrote:
Quote
[...]
You set it as a project option. Oh, and you link to a whole bunch of
different things. So yes, you tend to do it at project creation time,
just as you do when you're choosing MFC or WTL, for example.
[...]
Actually, I think you may be able to generate a console app as either
Win32 or .NET, but the moment you start picking your APIs, I suspect the
choice of framework pretty much determines the choice of Win32 or MSIL.

Alan Bellingham
No. You enable CLR (common language runtime) support for a whole project
or for single files, but you are not restricted to use managed or native
code only.
You can freely mix managed and native code.
The compiler will either emit pure MSIL code (even for normally native
code) or mixed executables, holding managed and native code.
Andre
 

Re:BDS2006 and .NET for C++

Andre Kaufmann < XXXX@XXXXX.COM >wrote:
Quote
No. You enable CLR (common language runtime) support for a whole project
or for single files, but you are not restricted to use managed or native
code only.

You can freely mix managed and native code.

The compiler will either emit pure MSIL code (even for normally native
code) or mixed executables, holding managed and native code.
Aha. Thanks - I hadn't spotted that.
I was getting the impression that talking to .NET as opposed to talking
to Win32 native APIs was going to be a major part of the difference.
(And I've doing too much Java recently - it's rotting my brains.)
Alan Bellingham
--
Team Thai Kingdom
<url:www.borland.com/newsgroups/>Borland newsgroup descriptions
<url:www.borland.com/newsgroups/netiquette.html>netiquette
 

Re:BDS2006 and .NET for C++

At 08:58:13, 10.11.2005, MR wrote:
Quote
Being totally unexperienced with .NET but planing to get some
experience with it I am wondering if I could use BDS2006 with it's
.NET languages (Delphi, C#) TOGETHER with my C++-Source
library-functions, i.e. write the .NET main application with e.g. C#
and link the .obj-Files from C++ (perhaps after a recompilation) into
it?
No, you can't.
But you can create a Delphi for .NET library project, and export the
functions you need from the .NET side as if they were Win32 code. The
help describes this (at least, the D2005 help does, so I guess it is in
DeXter too). This is something C# can't do, so you'll have to use Delphi
for .NET.
AFAIK, you can also expose these .NET DLLs as interfaces, somehow. Never
tried it, but the help should also explain that.
--
Rudy Velthuis [TeamB] velthuis.homepage.t-online.de
"Distrust any enterprise that requires new clothes."
- Henry David Thoreau (1817-1862)