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

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-16 02:04:21

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.

Do you mean for functions declared __declspec(deprecated) or for actual 
warnings that have no use?

>>>>>>[4] support for managed (CLR) and Java bytecode
> I actually didn't make a difference between MC++ and C++/CLI. I called 
> them both MC++ as opposed to standard C++.

Ok. I get you.

>>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.

What I mean't by "their" was that Microsoft invented it. I was aware of 
the Mono project, however I didn't know that GCC-CIL targetted Mono. 
Thanks for the info.

>>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?

You keep referring to GCC-*CIL* -- that's what cil was there.

> 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.

Agreed.

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

This makes sense.

> feature architecture :
...
> # CLR CIL
> clr
> # Java byte code
> java
> : propagated optional ;

Do we even need the clr/java bytecode separation? Could we have 
<architecture>bytecode, and have .NET/Mono compilers generate CLR and 
Java compilers generate Java bytecode.

> <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.

I was not championing the use of a <bytecode> feature, just finding the 
best way to support CLR and JavaVM. You have convinced me of a better 
way of representing them :).

- Reece