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
> 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?
>>>>>> 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:
>>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.
> 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
> # Java byte code
> : 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 :).
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk