Boost logo

Boost-Build :

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
# ia64
# Sparc
# RS/6000 & PowerPC
mips1 mips2 mips3 mips4 mips32 mips32r2 mips64
# Java byte code
: 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.



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at