Re: [jamboost] Re: [BBv2] [msvc] scoping interest for other extensions

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-09-15 22:43:53

Reece Dunn wrote:
> Andrey Melnikov wrote:
> 
>>Reece Dunn wrote:
>>
>>
>>>Andrey Melnikov wrote:
>>>
>>>
>>>>Reece Dunn wrote:
>>>>
>>>>
> 
> 
> 
> /wd0000 gives the following error:
> 
> cl : Command line warning D4014 : invalid value '0' for '/wd'; assuming 
> '4999'

0000 was just a placeholder for the real "deprecated" warning number.

>>>>>[4] support for managed (CLR) and Java bytecode
>>>>>
>>>>>feature clr :
>>>>> cppcli # Use the new C++/CLI (VC8-style) style CLR
>>>>> managed # Use old-style (VC7.x-style) managed code syntax
>>>>> pure # Use C++/CLI (VC8-style) pure CLR
>>>>> safe # Use C++/CLI (VC8-style) safe (validated) CLR
>>>>>: propagated ;
>>>>
>>>>Is this a MC++-specific, a CLR-specific feature? It looks like it's a 
>>>>MC++-specific feature. Does it affect code generation, compile-time 
>>>>checks, C++ language extensions or both?
>>>
>>>MC++ is the C++ way to target to .NET (i.e. the CLR). 
>>
>>Not exactly. IMO "MC++" means the extension to the C++ language that allows:
>>1) to mix native and managed code
>>2) to use all the features of CIL and CLI in C++
> 
> 
> The "managed" option is a poor name and hence I think where some 
> confusion lies (but see below). What managed means is "vc7x-syntax". So 
> that should be updated.

I actually didn't make a difference between MC++ and C++/CLI. I called 
them both MC++ as opposed to standard C++.

> 
>>I think it's possible to write a compiler that will produce CIL from
>>
>>class CMyManaged
>>{
>>	int x()
>>	{
>>	return 2;
>>	}
>>}
>>
>>without a need for language extensions.
> 
> 
> Sure.
> 
> 
>>If it's possible (and especially if GCC-CIL goes this way) the feature 
>>won't be Microsoft-specific but will be CLR-specific.
> 
>>
> 
>>Also IMO "pure" means "no native code" and "safe" means "portable, no 
>>indirect PInvoke calls". I haven't written a line for the CLR in my 
>>life, so my comments can be lame here :)
> 
> 
> Here is another attempt at this:
> 
> Normally, a compiler targets a specific CPU architecture to generate 
> machine code/assembler for that CPU. This is "native" compilation.
> 
> Java compiles to an intermediate bytecode that the Java Virtual Machine 
> (JVM) runs. This allows Java to run on any platform that has a JVM 
> installed.
> 
> Microsoft have added facilities for their .NET platform, which is 
> another bytecode (Intermediate Language) system running on the Common 
> Library Runtime (CLR). C#, VB.NET and others implicitly target the CLR 
> like Java targets the JVM.

.NET platform isnt "their". There are open, free and compatible clones: 
Mono and DotGNU. There are free cross-platform C# compilers that compile 
to the same intermediate language as MS, free CLR libraries and 
JIT-compilers. It's possible to run the same managed exe on Windows and 
*nixes. The GCC-CIL I mentioned is the C++ compiler for Mono project. It 
generates Microsoft CIL too.

> Other compilers are providing a bytecode/intermediate form as an 
> optional target.

I don't see a contradiction with my comments.

> So, if we have:
> 
> # builtin.jam
> feature bytecode :
> native # target native CPU machine code
> java # target the JVM machine code
> dotnet # target the .NET/CLR machine code
> cil # other (e.g. GCC) intermediate representation
> ;

What is "cil" here?

IMO there are no big difference between bytecode executed by a virtual 
machine, bytecode compiled just-in-time and executed natively and native 
code. They are all compiler outputs.

So there's no need for <bytecode>. We already have "<architecture>" and 
CLI and Java are just two virtual architectures.

feature architecture :
# x86 and x86-64
x86
# ia64
ia64
# Sparc
sparc
# RS/6000 & PowerPC
power
# MIPS/SGI
mips1 mips2 mips3 mips4 mips32 mips32r2 mips64
# CLR CIL
clr
# Java byte code
java
: propagated optional ;

<clr>pure/safe feature IMO OK. I'm just against "bytecode". And so far 
you didn't provide any arguments in favour of a searate feature.

Andrey