Wikipedia says it has a garbage collector, yet I never heard of any JIT compiler for it (e.g. JRE, CLR, ect). Does it compile at run-time or compile-time?
D is compiled (at compile time, natch).
D has an optional garbage collector. GC is orthogonal to static/dynamic compilation.
There are other examples of GCed, static languages without JIT compilation, like Eiffel.
Related
Is there a way to forbid the usage of potential unsafe functions like malloc, _memcpy and others from being used by the clang compiler when compiling objective c code?
AFAIK, LTO can reduce dead codes and do some cross-file inlining. However,
Objective-C is based on runtime. Whether a method is indeed called is resolved until runtime, so it's not possible to reduce dead methods in Objective-C at link time, right? For cross-file inlining, it couldn't happen either as a method's implementation can be replaced during runtime.
So, how could LTO affect Objective-C codes?
I'm new to LLVM, so any advice is appreciated.
Since Objective-C is basically an extension of C, Does the code get converted to pure C code before it is compiled to native code ?
If so, does the conversion happens on RAM or a temporary file containing C code on disk is created by the compiler which is further compiled by C compiler to native code ?
That Objective-C syntax is an extension of C syntax does not mean that it could not have its own compiler. C++ is the same way - its syntax is compatible with C (for the most part, anyway) but it has its own set of tools. Compilers for C, C++, and Objective-C can reuse parts of each other for preprocessing, syntactic analysis and code generation, but there is not need to run them sequentially (e.g. Objective-C ==> C ==> Target code). Compilers no longer go through human-readable assembly language, either (this has been the case for a very long time, too).
No, Objective-C gets compiled to assembler directly (assuming GCC).
g++ compiler complains about conversions between related types (from int to enum, from void* to class*, from const char* to unsigned char*, etc.). Compiler handles such convertions as errors and won't compile furthermore. It occurs only when I compile using Dev-C++ IDE, but when I compile the same code (using the compiler which Dev-C++ uses) such errors (even warnings) do not appears.
How to mute errors of such types?
I suspect that in one case you are compiling your code as C and the other as C++. In C++, there is no implicit conversion from void * to any other type of pointer, and a C++ compiler which did not diagnose this as an error would be broken. You need to supply more details of how you are compiling your code.
Also, DevC++ is a pretty awful piece of code. It's buggy and no longer being actively developed, as well as being butt-ugly. You should seriously consider switching to a more modern and capable IDE, such as Code::Blocks.
All of your implicit conversions are disallowed in standards conforming C++. G++ is simply enforcing these rules.
I know my way around Objective-C and I have experience with garbage collection from .NET, although I never used it in objective-c. I write my code without using it.
Now I'm thinkig about using one of the frameworks (Blocks) which is available as GC-only. My question is - can I still use the framework without any changes to my current non-GC code and without using GC myself?
A process is either GC or non-GC. That is, all Objective-C will either always be GC'd or will never be GC'd. There is no mixing of the two memory models in a single process. You cannot mix a GC only framework with a non-GC only framework.
When building a framework, you can set GC to "supported" at which point in time the framework could be used in either a GC'd or a non-GC'd process. However, you will have to maintain correctness for both running environments separately.
What is this "Blocks" framework to which you refer? If you are talking about Blocks, the language feature shipped in Snow Leopard's Objective-C, then it works just fine under both GC and non-GC.
As stated in the garbage collection programming guide, "Code compiled as GC Required is presumed to not use traditional Cocoa retain/release methods and may not be loaded into an application that is not running with garbage collection enabled."
So no, unfortunately. But how much work it would be to adopt garbage collection depends on your app. You might try testing to see if it looks like a big project. (It often is, but sometimes it's not so bad.)
In project settings, you can compile with GC supported (NOT required) and they should mix just fine. Compiling with GC supported but not required should allow retain/release to work alongside GC
If you can't compile the project with GC supported, then you'll be in trouble.
EDIT: To clarify: If you compile your project with GC required (-fobjc-gc-only) your retain/release code will be ignored. If you compile without any regard for GC, you can't use the GC framework. However, if you compile with GC supported (-fobjc-gc), your retain/release code will function as needed, and the GC framework will also work.
EDIT: To further clarify (I'm really tired today): If you include a GC-only framework, you have to compile with -fobjc-gc or -fobjc-gc-only and run with garbage collection, in which case your retain/release statements will indeed be no-ops. However, if you compile with -fobjc-gc-only and try to include a framework that is not build with any GC support, you'll have issues. Whereas my understanding is if you compile with -fobjc-gc, you can include a GC-only framework as well as a non-GC framework. From the docs I linked above:
Code compiled as GC Supported is
presumed to also contain traditional
retain/release method logic and can be
loaded into any application.
So if you wanted your Framework to play nice with anything, you'd be better served to compile with -fobjc-gc instead of -fobjc-gc-only.
Apparently I was having a hard time getting my thoughts to the keyboard yesterday. According to the docs:
-fobjc-gc-only This means that only GC logic is present. Code compiled as GC
Required is presumed to not use
traditional Cocoa retain/release
methods and may not be loaded into an
application that is not running with
garbage collection enabled.
So if you build your framework with GC Required, you can't load it into a non-GC-enabled application.
Also according to the docs:
-fobjc-gc This means that both GC and retain/release logic is present. Code
compiled as GC Supported is presumed
to also contain traditional
retain/release method logic and can be
loaded into any application.
So while the burden is on the developer to include retain/release logic in a project that is compiled GC Supported, this allows a framework to be loaded in any application.
I apologize for my unclear rambling yesterday. I was running on 3 hours sleep and trying to do several things at once. Never a good idea.