Board index » cppbuilder » Standard C++ programming will be difficult under Longhorn

Standard C++ programming will be difficult under Longhorn


2004-12-04 08:31:06 PM
cppbuilder101
msdn.microsoft.com/Longhorn/Support/lhdevfaq/default.aspx
About halfway down the page under "General Topics" The Basics
Look for "Can I use C++ to develop for Longhorn?"
Here is a snippet of what it says:
"If you mean the C++ that targets the MS CLR by producing IL, then the
program model is the same for C++ as it is for any .NET language and you can
find a set of C++ samples on the LHSDK samples page.
If you mean Standard C++ that targets a specific chip by producing assembly
code, you're going to be doing a lot of .NET interop to make it work. I
recommend the other thing."
Maybe I'm misunderstanding this, but I wanted to put it to a discussion.
 
 

Re:Standard C++ programming will be difficult under Longhorn

Relaxin wrote:
Quote
If you mean Standard C++ that targets a specific chip by producing
assembly code, you're going to be doing a lot of .NET interop to make
it work. I recommend the other thing."
Delphi for .NET's VCL is currently doing a lot of Interop as well, so I
don't see the problem.
--
Rudy Velthuis [TeamB]
"Humor is the great thing, the saving thing. The minute it crops up, all
our irritations and resentments slip away and a sunny spirit takes
their place." -- Mark Twain (1835-1910)
 

Re:Standard C++ programming will be difficult under Longhorn

It's not talking about Delphi, or any other ".NET" compliant tool, it's
talking about standard (I assume straight) C++.
"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
Relaxin wrote:

>If you mean Standard C++ that targets a specific chip by producing
>assembly code, you're going to be doing a lot of .NET interop to make
>it work. I recommend the other thing."

Delphi for .NET's VCL is currently doing a lot of Interop as well, so I
don't see the problem.
--
Rudy Velthuis [TeamB]

"Humor is the great thing, the saving thing. The minute it crops up, all
our irritations and resentments slip away and a sunny spirit takes
their place." -- Mark Twain (1835-1910)
 

{smallsort}

Re:Standard C++ programming will be difficult under Longhorn

Relaxin wrote:
Quote
It's not talking about Delphi, or any other ".NET" compliant tool,
it's talking about standard (I assume straight) C++.
Yes, I know.
--
Rudy Velthuis [TeamB]
"How can I lose to such an idiot?"
- A shout from chessmaster Aaron Nimzovich (1886-1935)
 

Re:Standard C++ programming will be difficult under Longhorn

My guess is the question was assumed to read "Can I use standard C++ to
access the OS via the .NET interfaces".
Call me stubborn, but I refuse to believe that there won't be something
resembling a Win32 API as well which gives conventional access to the OS.
If not, then Microsoft will sell lots of copies of Virtual PC. Maybe *that'*
is the long-term reasoning for .NET...
- Roddy
"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
Relaxin wrote:

>If you mean Standard C++ that targets a specific chip by producing
>assembly code, you're going to be doing a lot of .NET interop to make
>it work. I recommend the other thing."

Delphi for .NET's VCL is currently doing a lot of Interop as well, so I
don't see the problem.
--
Rudy Velthuis [TeamB]

"Humor is the great thing, the saving thing. The minute it crops up, all
our irritations and resentments slip away and a sunny spirit takes
their place." -- Mark Twain (1835-1910)
 

Re:Standard C++ programming will be difficult under Longhorn

Roddy Pratt wrote:
Quote
My guess is the question was assumed to read "Can I use standard C++
to access the OS via the .NET interfaces".

Call me stubborn, but I refuse to believe that there won't be
something resembling a Win32 API as well which gives conventional
access to the OS.
I bet there will be. But rumours are that it may be a layer on top of
.NET (or whatever it will be called at that time), i.e. the reverse
situation of what we have now.
--
Rudy Velthuis [TeamB]
"God is a comedian playing to an audience too afraid to laugh."
- Voltaire (1694-1778)
 

Re:Standard C++ programming will be difficult under Longhorn

I'm not too clued up on .NET, etc. Could someone tell me what CLR, IL,
LHSDK and interop mean please?
Thanks...
Quote
"If you mean the C++ that targets the MS CLR by producing IL, then
the
program model is the same for C++ as it is for any .NET language and
you can
find a set of C++ samples on the LHSDK samples page.
If you mean Standard C++ that targets a specific chip by producing
assembly
code, you're going to be doing a lot of .NET interop to make it
work. I
recommend the other thing."
 

Re:Standard C++ programming will be difficult under Longhorn

John wrote:
Quote
I'm not too clued up on .NET, etc. Could someone tell me what CLR, IL,
LHSDK and interop mean please?
CLR : common language runtime (.net "base" components libraries)
IL : intermediate language to which all languages are compiled (eq. to
java bytecode)
LHSDK: ?? some software development kit
interop : "wrappers" to call "native" code from .net code or vice versa
(all .net code lives in it's own VM, like java, so to speak)
HTH,
Micha
 

Re:Standard C++ programming will be difficult under Longhorn

Make no mistake: Microsoft's main plan in all this, is to make it
*harder* to develop cross-platform applications. It boggles my mind
when the DotNet advocates come up with all the pie-in-the-sky thoughts
of why DotNet is going to lead to more cross-platform development. They
are basing all their hopes on the Linux Mono project, but I think MS has
a surprise or two in store for them; not to mention that they have no
officially taken the position of Microsoft followers.
Does anybody have some comments concerning the FCL that would help me
understand why it is such a pain for ordinary C++ applications to
utilize the FCL objects? It seems to me that FCL has the distinction of
being the first system library to require garbage collection, but surely
this has an impact on overall system performance.
 

Re:Standard C++ programming will be difficult under Longhorn

"Roddy Pratt" <roddy at spam fritter dot com>wrote in message
Quote
My guess is the question was assumed to read "Can I use standard C++ to
access the OS via the .NET interfaces".

Call me stubborn, but I refuse to believe that there won't be something
resembling a Win32 API as well which gives conventional access to the OS.

If not, then Microsoft will sell lots of copies of Virtual PC. Maybe
*that'*
is the long-term reasoning for .NET...
The very first question in the "The Basics" category is, "Will my existing
Win32 and .NET apps continue to run under Longhorn without modification?"
Since the answer is 'yes' for "apps written agains documented Win32
API's...", then the next logical conclusion is that future apps written
against the existing Win32 API's will also work.
- Dennis
 

Re:Standard C++ programming will be difficult under Longhorn

Micha Nelissen wrote:
Quote
LHSDK: ?? some software development kit
Since this was about Longhorn, I guess the Longhorn SDK is meant.
--
Rudy Velthuis [TeamB]
"The most overlooked advantage of owning a computer is that if they
foul up there's no law against whacking them around a bit."
-- Eric Porterfield.
 

Re:Standard C++ programming will be difficult under Longhorn

Micha Nelissen wrote:
Quote
John wrote:
>I'm not too clued up on .NET, etc. Could someone tell me what CLR,
>IL, LHSDK and interop mean please?

CLR : common language runtime (.net "base" components libraries)
Not just the components, actually the entire runtime, including the
core classes, etc.
--
Rudy Velthuis [TeamB]
"I hear Glenn Hoddle has found God. That must have been one hell
of a pass." -- Bob Davies.
 

Re:Standard C++ programming will be difficult under Longhorn

Mike Vance wrote:
Quote
Make no mistake: Microsoft's main plan in all this, is to make it
harder to develop cross-platform applications.
I disagree, although first you must understand what Microsoft means by
'portable' <g>
When I look what is involved in writing 'portable' software today I see
two approaches. 'Old school' practiced by C/C++ and their ilk is to
provide a language that targets the hardware directly, and maps
language types as appropriate for your environment. This means that if
you want to use the native data-width of your CPU you are in luck, int
will automatically pick up the right size for your environment. On the
other hand, if you are worrying about precise data widths where int in
always 32 bits (such as serializing binary information across your
network) then you are out of luck, and need some other technique,
usually managed through pre-processor magic and typedefs. It works,
but you are no longer dealing with the fundamental language types.
Ultimately, writing portable code leaves a lot of effort for the author.
'modern' languages such as Java, Python or the .NET family define the
environment as the virtual machine. This is a very clear, easy target
for the language authors and application developers. Your code is then
only as portable as the virtual machine, and it is the job of the VM
implementors to target all the different OS/hardware combinations.
Again, their task is greatly simplified as they only need worry about
portability of a single application - the VM, and not anything written
in the host language. Ultimately, this abstraction into two layers
should greatly ease writing portable software in the future.
Now when Sun talk about portable, they look at running a JVM on most
hardware imaginable. That is quite a wide range of systems <g>
When MS talk about portable, they are talking about anywhere they want
to run Windows. This librerates them from their Intel dependency,
allowing them to target both the mobile market with the Compact
Framework and different Server architectures at the high end. The plan
is that they will all be running Windows, and all those
non-Standardised .NET libraries are there to lure you into their
platform. But you will still be able to run your applications on a
wide range of systems, ultimately wider than the range you run today.
[and if you don't think your Windows code is portable today, just think
of the range of different hardware that might plug together to make a
system Windows runs on. Compare that variety to the concerns of early
Unix developers when C was their answer to a portable assembly
langauge...]
Portable does not need to mean 'runs on every system you can imagine'.
It does mean it will run on more than one kind of system.
AlisdairM(TeamB)
 

Re:Standard C++ programming will be difficult under Longhorn

"Alisdair Meredith" <alisdair.meredith@ XXXX@XXXXX.COM >writes:
Quote
'modern' languages such as Java, Python or the .NET family define the
environment as the virtual machine. This is a very clear, easy target
for the language authors and application developers. Your code is then
The serious problem of this is that through time, the design of the VM
becomes obsolete as the predefined sizes of integers and other types
no longer match the native size of platforms.
Imagine if Java were invented on 16 bit machines and all of today's
Java programs were written to that platform. Their hands are tied
about modernizing the JVM because it'll break code to change the
predefined sizes. So what happens? 20 years from now, will the JVM's
specifications make sense for the machines running then?
If they decide that the sizes do need changing, then what's the point
in having predefined sizes according to the langauge, if it's only
true for a while and not a real guarantee?
IMHO, it's a short-sighted solution that offers an improvement over
the status quo only for the near-term. And in the long term it's
detrimental.
--
Chris (TeamB);
 

Re:Standard C++ programming will be difficult under Longhorn

"Alisdair Meredith" <alisdair.meredith@ XXXX@XXXXX.COM >writes:
Quote
Mike Vance wrote:

>Make no mistake: Microsoft's main plan in all this, is to make it
>harder to develop cross-platform applications.

I disagree, although first you must understand what Microsoft means by
'portable' <g>
[snip]
Portable does not need to mean 'runs on every system you can imagine'.
It does mean it will run on more than one kind of system.
The problem here is that seems that lots of people assume, consciously
or not, that MS talks to us as a fellow talks to another, which
implies some care wrt technical correctness. The reality is that the
corporate world, along with politicians and other snake oil retailers,
have a tradition of twisting the language to fit their convenience.
For me and most other IT people I know, "portable" means "works on
every platform that meets such-and-such commonly found set of
features". "Made by MS" is not one of those features. Precisely,
vendor independence often is the most appreciated benefit of being
portable.
--
Oscar