When programming in C++/CLI, you occassionally receive compilation errors, since some C++ features (like std::thread for instance) are not supported when compiling with /clr.
I wonder if there is a (resonably up-to-date) document clarifying which C++ constructs are not possible in managed code? Does anybody have a link or a hint where to find something?
Just to make clear: I'm pretty aware that in a managed class, i.e. ref class etc., the subset of possible C++ features is restricted even further. My question is targeting ordinary unmanaged code that happens to be compiled with /clr switched on.
MSDN has a "Migrate to clr" guide, try reading it for a start.
Related
If I write a program in C++CLI / managed C++, does the compiler perform any optimizations?
I know that for C#, there are some optimizations done at compile time, with most optimizations being done by the JIT. Is the same true for C++CLI?
A similar question: can I do the equivalent of an -O2 flag, for C++CLI? I already know about the "-c Release" flag, but I'm unclear on what kind of optimizations it does.
Thanks!
C++/CLI code is always optimized in the Release build, yes. By whom is the key, you can freely mix as you dare. This tends to go wrong with too much native C++ code getting compiled to MSIL. Hard to notice, the code generator can handle any compliant C++03 code and rarely squeals about any C++1x incantations.
A good reminder that the jitter isn't that much different from a C++ compiler's back-end. MSIL compares pretty well to, say, the IR that LLVM needs. The IR that the MSVC++ compiler uses for native code isn't documented and not visible.
Which makes it a good practice to isolate the native C++ you wrap in its own static library or DLL. But mixing at the function-level is possible, you can switch back-and-forth with #pragma un/managed.
So it is much like you'd guess, #pragma unmanaged code gets the full optimizer love and #pragma managed gets optimized at runtime by the jitter. You'll find jitter optimizations documented in this post.
When generating native code, the C++/CLI compiler supports the same optimizations as Microsoft's native C++ compiler.
When generating MSIL, the C++/CLI compiler supports a smaller number of optimizations (but still more than C#), and then another optimization pass takes place during JIT (same JIT and same JIT-time optimizations as apply to C#).
For example, loop unrolling is possible when generating MSIL, but auto-vectorization is not, because MSIL doesn't have SIMD instructions. Vectorization may theoretically still be done by the JIT, but in practice the resource constraints of a JIT mean that optimization is less effective.
In addition, there are some optimizations possible for C++ but not C# due to language design. For example, C++ templates (including in C++/CLI) are compiled for each combination of template arguments, while .NET generics (including in C# and in C++/CLI) are fully resolved only based on the generic constraints.
I am interested to learn more about how the .NET framework works internally. I have downloaded Reflector and also SSCLI. The following link says: "The Shared Source CLI is a compressed archive of the source code to a working implementation of the ECMA CLI and the ECMA C# language specification": http://www.microsoft.com/en-gb/download/details.aspx?id=4917.
Does the SSCLI not include the source code for the implementation of VB.NET i.e. only C sharp?
I realise that the VB.NET specification can be downloaded here: http://www.microsoft.com/en-us/download/details.aspx?id=15751
The SSCLI distribution was intended to help anybody to port a compliant implementation of the CLR to another platform. Most of it is C++ source code, the language used to implement the CLR, just-in-time compiler and the C# and JScript compilers. The .NET framework libraries were written in C#, that's included as well. They are a pretty decent snapshot of the source code used in .NET 2.0, albeit that it is hard to tell what might have been removed or substituted. I've never run into an obvious mismatch, but it gets less and less obvious with this source code aging and departing more and more from current .NET releases.
But no, there is no VB.NET compiler included, nor the source code for the classes in the Microsoft.VisualBasic namespace. Nor is there a C++/CLI compiler. The included C# and JScript compilers are also not a complete implementation of the Microsoft version of those compilers, the Windows and VS specific bits were removed. Particularly the C# compiler source code is dated, a lot of work was done on it since.
There are lots of oop languages, but I couldn't find any that has conveniences like garbage collection, but compiles natively to machine code. Sort of like between C and java/c#. One interesting language I found was Vala, but that's limited to the GNOME platform and is not that well-known
Go is probably closest.
But why on earth do you want it natively compiled anyway?
JIT compilation of portable bytecode has proved to be an extremely effective strategy. It compiles down to native code at runtime (so you get up to the performance of native code after the first few iterations) and it avoids the issues of having to build and manage platform-specific compiled binaries.
Are you thinking about C++? That is in high usage and can be compiled on nearly any (major) platform.
In the case you want to use an oo language that compiles down to native code you will "always" have to use header files and stuff as the elf format doesn't support oo (There is no class information in elf).In case you want to use classes from external libs you need to make the compiler aware somehow about the fact that there are classes, functions, etc. that are declared outside of your project. In C++ this is solved by the use of header files. So that's, I think, a major drawback in native object oriented languages. To resolve that issue a few tweaks would need to be made to elf/loader/linker in order to support the kind of features (like "linking" against "classes") you might expect. Even though mechanism for garbage collection could be implemented even in native languages. But that seems no good for os implementation.
There are C++ libs to do that for userspace apps like:
Boehm collector
Smart pointers
I love static analysis and compile-time checks, almost to a fault, but most of my day job is in Objective-C. To resolve this tension, I'd like to be able to write my own analysis tools that I can run on my Objective-C projects.
But googling around the Internet suggests that people are having a hard time putting together a complete Objective-C grammar. One site basically recommends giving up.
I did find a grammar on the ANTLR website, but when I fired it up, I couldn't get it to parse anything at all. For example, it responded to the line:
void x();
with src/main/resources/somecode.m line 1:0 no viable alternative at input 'void'
:(
I took a closer look at the grammar and found the following disheartening disclaimer:
it's a work in progress, most of the .h file can be parsed
But I need something that can parse both interface and implementation.
Is there a complete Objective-C 2.0 grammar out there somewhere? I'd prefer something that can work with Scala (so anything Java compatible, like ANTLR, would be perfect), but at this point I'd be willing to adapt something designed for another parser toolkit.
As others mentioned, Clang would be the right solution. You can provide your own AST consumers, i.e. classes that will be invoked when going over the AST, leaving you not having to worry about parsing or messing with grammar.
Clang supports Objective-C in its entirety, and there's a lot of classes already in the static analyzer that you can model your own checks after. (in clang/lib/StaticAnalyzer/Checkers).
That directory contains a lot of static analyzer checkers, but you can also just create a normal AST consumer. Refer to http://code.google.com/p/chromium/wiki/WritingClangPlugins for more information.
Clang is a static analysis tool that has support for Objective-C. I've found it very useful in the past.
http://clang-analyzer.llvm.org/
clang is extensible; you can extend their existing static analysis or create your own. llvm / clang is architected as a series of libraries you can link to (dynamically or statically). A great starting point is the ARC (automatic reference counting) migrator library, which is responsible for statically analysing and rewriting objective-c code.
arcmt-test is a small example program that consumes the ARC migrator library.
You can use OCDepend, it's a static analysis tool based on Clang that simplifies managing Objective-C code quality and provides a highly flexible code query framework.
Having recently read up a on Objective-C it strikes me as a fairly neat language with plenty of cool features.
I have no intention of doing any iPhone development, however I understand that GCC is able to compile Objective-C code and so I wanted to know - Is Objective-C a viable alternative language to C99 for Windows development?
In particular:
Is anyone currently doing Windows development using Objective-C?
Are there any runtime components that would need to be distributed with my applications?
I understand that Objective-C is a superset of C, does this mean that it is possible to use any C-compatible library? (for example the Windows API)
Would I get garbage collection in my applications?
I've found Cocotron and GNUstep which are often mentioned when talking about using Objective-C on other platforms, however as GCC can already be used to compile Objective-C I don't really understand why I would need these.
Are there any other pitfalls or traps I might run in attempting Windows development using Objective-C?
With respect to your first question, I don't know if anyone is seriously doing development on windows with Objective-C, but there may be, though those numbers would probably be less than those doing serious work with a language like whitespace.
Secondly, you would need, at a minimum the objective-c runtime. There are two runtimes, NeXT's (now Apple's) runtime, and the GNU Objective-C runtime. They are not compatible. If you are on a non-NeXT and non-Apple platform, such as windows, you have no choice, GNU runtime only.
Objective-C is a superset of C, and yes you can use the Win32 API if you so desire directly in your objective-c code. As well, you would only get garbage collection if you use a conservative collector, and it ties in with the libraries you're using. In short: No.
What GCC has is support for the objective-c language, and runtime, no standard library. What the GNU objc runtime provides you with in terms of a standard library, is two objects: Object, and NXConstantString class, which is needed to support the #"" syntax. Object is merely a base class. Not very useful, eh? This is why frameworks like Cocotron and GNUstep exist — to give you access to an implementation of OPENSTEP/Cocoa.
Regarding pitfalls or traps, yeah: Your application, even using Cocotron or GNUstep may never be portable to the Mac for instance, or you may get bit by things like typed selectors in the GNU objc runtime, or a plethora of other problems. Let me finish answering this by posing another question: What pitfalls or traps might you run into targeting .NET? I'm sure some if not most of those apply in this case too. Standard pitfalls and traps apply.
I hope this helps.
There is no mature solution yet. If you develop the solution itself, you can do it anyway. But if you're not, it's not the time.
For compiler tools, there is LLVM/Clang which are open-source under BSD license.
The compiler is sponsored by Apple, so it compiles Objective-C completely, and is becoming primary compiler for Apple. So compiler is no problem anymore.
Problem is runtime environment library. Objective-C language is depends it's runtime to execute. The runtime defines all behavior of object system and some more. Runtime environment library is core system and different with framework library like Cocoa or Quartz. in .NET, it's CRE, not .NET framework class library.
Without runtime, program cannot be executed like .NET program executed on Windows without .NET runtime.
For more details, check this conversation:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-January/007593.html