I was just curious by default does Microsoft's C/C++ Optimizing Compiler compile down to machine language or byte code?
It compiles down to machine language (microprocessor opcodes) by default, or CIL, using the /clr switch.
For comparison, C# and Visual Basic compile to CIL, and Visual Basic 6 can compile to either P-code (a form of byte code) or native code (machine language).
It can do both.
By default it produces native machine code.
With the /clr command line option it will produce .NET IL byte code.
Related
I'm trying to analyze the causes for long compilation times in my work (Visual studio 2017, many C++ and some C++/CLI projects), so I've turned on the /Bt+ flag and got the nive detailed output regarding how much time c1xx and c2 spent in each file.
I'm not sure though what each of them is responsible for, so I'd be glad if someone could elaborate on that.
Thanks in advance
c1xx and c2 are tools part of Microsoft's compilation toochain. The first is responsible of translating your C++ to an intermediate representation (an AST most likely, something suitable for code generation) and the second translates that intermediate representation to machine code.
They are the "Microsoft C++ Front-end compiler" and "Microsoft C++ Compiler back-end". Their invocations are done through cl.exe which overviews the whole compilation toolchain
I'm wanting to compile C++ extensions to SQL Server, from the docs
Safe mode: Run verifiably typesafe code; compiled with /clr:safe.
Does mingw's C++ compile support /clr:safe?
The Common Language Runtime (CLR) of the Microsoft .NET framework has no
application to non-Microsoft, non-.NET compilers. The several Windows ports
of GCC that can be meant by "mingw" are all non-.NET, native compilers. Microsoft's
managed C++-like language, C++/CLI, to which /clr:safe applies, isn't C++.
/clr:safe directs the Microsoft compiler to generate an output file that contains
no native code, only verifiably typesafe Microsoft Intermediate Language code for
managed execution with the CLR. By definition a native compiler cannot provide
an equivalent option: generating native code is what they do.
If what you are after is how to compile C++ with the strictest diagnostics GCC can
provide, a diligent answer would be off-puttingly long, since there is a plethora
of options for diagnosing corner cases of safety. Settle at least on:
-Wall -Wextra -pedantic
(see 3.8 Options to Request or Suppress Warnings)
and perhaps augment the list as prompted by bitter exerience and mounting paranoia ;)
Beyond the regular static diagnostics another level of hygeine is available
through the large -fsanitize=... family of the 3.11 Program Instrumentation Options.
I am writing code in VS that should be ported later to Linux. I found that sometimes, I may use some functions or code that is available only on Windows and not on Linux.
Is there any way that I can set my Visual Studio to report me these non portable pieces of code?
I prefer to use VS during development and then use the code base and compile it in Linux.
You can treat MinGW as a reference compiler, just to check whether the code you write is portable.
You can also disable MSVC compiler extensions in the compiler options settings in Project Properties (or set /Za flag). That will most likely make at least <windows.h> stop compiling.
Frankly, though, I don't see a problem in simply not using nonportable things. Stick to standard library and libraries that you know are portable and you're good to go. (granted, syntactic extensions are easier to accidentally use, but then again their usages are also typically trivial to put back in proper way).
I started working just a few hours ago on a pseudocode translator, which will translate a specific pseudocode, reguarding work with stacks and queues, to c/c++ executable code. The translator has education propuses.
I am still designing the project.
I've started thinking about how this could be done; I figured that maybe the best way to do this is to, in the first place, analize the pseudocode, change it to make it c/c++ code and then compiling it to make it an exe.
NOW, this would mean that the client machine SHOULD HAVE a c/c++ compiler installed on it.
As I'm working with .NET clases ( System.Collections.Generic.Queue(Of T) and System.Collections.Generic.Stack(Of T) ), I thought that a solution to this would be to use the same compiler visual studio uses to compile c/c++ code.
I've been investigating about this proccess, and as far as I know, the only way to compile c/c++ code by using a visual studio tool, is executing cl.exe from the Visual Studio Command Prompt. I found that information here at MSDN (article about how to manually compiling a c/c++ program)
So my first question is: does the USER versión of .NET Framework (this means, assuming the user DOES NOT have Visual Studio) include a c/c++ compiler? If yes, is it the same included in visual studio, cl.exe? How can I get access to it? If no, is there a free compiler WITHOUT IDE I can include on my translator setup?
Notice that here we're talking about transforming a pseudocode string to executable c/c++ code here, the output string MUST BE COMPILED FROM THE USER PC, that's what the project is about.
There is no compiler included in the .Net framework - it is for running binary files produced by the compiler.
It's possible to get the compiler for free through for example the Visual Studio Express free download scheme. There are some license limitations on that ("no commercial use", if I remember correctly - so that would mean that if one of your customers uses your product, they can no sell the resulting code they have produced [and still be within the contract with MS]). Unfortunately, this isn't "without IDE", but the compiler that is part of the download is usable without the IDE, so if "without IDE" is simply that you want to be able to run the compiler with your program, then it will work.
If you really need a package that contains the compiler (in .Net variant) but no IDE code, then you will have to find a different solution - and for .Net I'm not sure there is one. The DDK (Device Driver Kit) contains the native C and C++ compilers. But it won't, as far as I understand, produce .Net code [I could be wrong].
Edit: It seems like if you are writing your own code, you can compile it using CSharpCodeProvider - however, this is not the same as a command-line compiler of cl.exe.
The long, the short, and the ugly is "no". The only C++ compiler remotely suitable for inclusion as a library is Clang, it's free and not toooooo bad to work with, and you'll have to write your own .NET binding, and don't forget to have fun with providing your own linker and stdlib.
I like the Visual Studio IDE. I'm used to it and find it is the best IDE I've ever tried. We also find increasing use of C#/.NET here.
However, after the underwhelming announcement regarding C++11 features in VS11 I'm looking into replacing the compiler.
It seems that the Intel compiler fully integrates with VS but that doesn't mean it will compile our Windows code. I don't know how I'd fare with a try of g++ or clang
Can VS actually be productively used with a different C++ compiler to compile Windows code, that is legacy code using all kinds of Win32 / MFC / COM stuff?
Depends on how much use you made of the Microsoft-proprietary extensions. Things like #pragma once tend to be supported by all the major compilers, but the weirder COM things (e.g., #import and anything C++/CLI) probably won't be. No idea if MFC will build under the new compiler, but you'll probably have to link it statically or ship your own DLL; G++ definitely uses a different mangling scheme than MSVC.
I'm not sure how easy it is to replace cl.exe and keep your vcproj files intact (though some compilers actually do it), but there are always Makefile projects.
I have never actually worked with the Intel C++ compiler, but I see no reason why it wouldn't compile the code that VC++ does. Here is official Intel documentation.
I use Visual Studio 2008 with a Makefile project to cross-compile; no reason you couldn't do the same with a different Windows compiler.