Re: C# syntax as an option in Delphi w32

Andre Kaufmann wrote:
Paul Nichols [TeamB] wrote:
Andre Kaufmann wrote:
paul nichols [TeamB] wrote:

What do you mean exactly ? AFAIK there's also a proposal for the next
C++ standard to include GC.
ar

Of course you can do this, if you are willing to have some type of
mechanism that will monitor objects created on the HEAP, and then when
they go out of scope, GC them. But the underlying results means that
you are not running a self contained binary. The GC mechanism would
have to run as an addendum to the program you have compiledm AFAIK.
Otherwise there would be no way to GC the objects. Something has to
monitor the Objects lifecycle.
So in a sense this to is a runtime, even though it may be statically
linked.

Sure. Each native executable has it's own heap manager, which can use
the system heap manager. So why shouldn't a native executable not have
it's own native GC. E.g. for example GCC is AFAIK distributed with the
Boehm-Demers-Weiser GC for C++. AFAIK this GC is triggered manually, so
you have to call a function, which traverses the allocation tree and
frees the objects which aren't used anymore.

.NET has IIRC it's own thread, which does that. But I don't see a reason
why a native application couldn't use the same architecture.

That is basically what I am saying COULD be done as well. The GC could
be a library that you statically link to. The framework would kick this
off this monitor (system level) that contains an allocation table for
the app, which is monitored by the GC framework. We are thinking alike
here. :)

This is something JavaSoft has been discussing for a while now. Having a
VM that runs with each application. While a little different (for
XPlatform), it is the same type of concept.


[...]




I don't know what you exactly mean with self-contained binary. Where is
the difference if a native application deletes the objects if you call
Object.Free / delete object or if the programmer, or a thread running in
the background, calls from time to time GC.Collect ?

The difference is SOMETHING has to monitor the lifecycle of the Object
HEAP space for that application. Each application has its own entry
point (if we are going to use a System wide GC), and each Object in this
entry point, would have to be monitored during its lifecycle, within
that application framework. Without the monitor, you do not have a GC
type app. Wen you are responsible for allocating and deallocating
memeory, there is no GC running in the background. Objects are not
monitored for release from the memory pool, that is why if they are left
hanging we have memory leaks.


That's true. The linking mechanisms calls C++ to be slow in first
tiyme compiles. But this is a one time thing, and the resulting
program is usually almost as fast as C (or the same depending on the
code compiled).

I meant macros, which are the main reason why a C++ compiler has to
compile the same code over and over again, because each single macro
affects each included header file. Delphi is such a fast compiler,
besides that the syntax is simpler, because it has modules.


Well I agree with this as well. The beauty of Macros is, however, that
they are inlined. Of course, like anything else, they can be abused, if
they are not used as intended.


A GCed language is going to be slower than a non GCed one due to the
running monitor that MUST keep track of the objects created on the
heap. Of course with multi-core processors, it is possible to reduce
the overhead and thus make speed differences negligible.

I don't think so. Allocating (small) objects on the GC heap is way
faster than heap allocations in native applications and you the GC heap
doesn't need to be locked, as it's (commonly) the case in native
applications. Also native applications will use a lock if a single
object is freed/deleted from the heap, while the GC suspends all threads
and deletes multiple objects and compacts the memory from time to time.
While it doesn't make that much difference now for single threaded
applications, it surely will have an impact on applications that must
scale to multiple processor cores.

With the new multi-core processors, I would tend to agree. That is what
I wrote in the last communication (or at least I thought I did :)).


I still prefer to have control over the memory allocations /
deallocations. But to tell the truth, I use so much code that I didn't
wrote, that I in the end don't have that much control over the
allocations ;-).

True. always true. Don't get me wrong, I am willing to change complexity
for control in most situations, Of course it all depends upon the
application specs themselves.


Delegates, or better said member function pointers, for example are used
in GUI frameworks. You surely can use templates to build a pure C++
templated GUI framework. But IMHO templates lead to slow compilation and
code bloat. Don't get me wrong, I like templates, though I know their
impacts if they are "misused".

That's what I meant. You have function pointers in C++ and have had for
a long time. Templates, like anything else, can be misued.

But function pointers can be used by all languages, Delphi for example
couldn't use a template based C++ GUI framework.

Well it could, but it is not a design of the language/compiler.

well] how you could hope to keep the same constructs for a native C#
and a runtime type approach. Of course this could change now, since
Java is GPL.

I don't see any restrictions, if the compiler would be also shipped with
the native application. :-9. The native application could also ship with
the meta data and information, which is normally appended to a .NET
assembly. The only restriction I would see for native applications is
security, you couldn't restrict precompiled applications the way you can
do with .NET or Java applications.

Now we get back to my self-contained binary statement. :)


If you use NGEN, then the whole .NET assembly will be compiled to native
code. This is why the installation of the .NET framework needs that much
time, it's compiling the installed assemblies.
So where is the real difference to native applications ?
(Beside the huge runtime and that NGEN for what reason ever doesn't have
a good optimizer).

Ah yes unsafe code. But this does away with the easier contructs of C#.
BTW, I really
like this ability.


Agreed. Bartok is for example such a compiler, though it uses a smaller
runtime.
IMHO it doesn't make that much sense to create a native C# compiler
which only targets for example the VCL. A VCL which could be targeted by
many native languages (not only the ones from Borland), however, would
have been a very attractive platform (in the past).

This would work. gcj is such a concept, as is Excelsior for Java.

A huge benefit of such a native C# compiler (same applies to Delphi)
would be if you could mix native and managed code. So you would get the
best from both worlds.

With the latter solution (as per above), yes.

I am not sure that this is what the original poster had in mind or not.
But this latter solution (an intermediate constructor-compiler) would
work and work better, IMHO. Be much easier to implement, IMHO.
.

Relevant Pages

  • Re: Is MSDN wrong? or I made a mistake? about static member function
    ... the heap" or some such reference. ... shouldn't we have a uniform notation? ... You can tell a heap object from a stack object by ... the result of trying to build a compiler on a tiny computer by someone who wasn't a very ...
    (microsoft.public.vc.mfc)
  • Re: Lcc-win32 extensions to C
    ... compiled with a C++ compiler or a C compiler. ... Yes, but if you do not use GC, you allocate more memory than needed to ... Using a non-GC'ed heap+ a GC'ed heap requires also more memory... ... Collector, since GC technologies are much more advanced than simple ...
    (comp.std.c)
  • Re: screen resolution
    ... I would not suppose the compiler was amiss again. ... Identifier "Screen0" ... Monitor "Monitor0" ... VendorName "Monitor Vendor" ...
    (Fedora)
  • Re: Struct inside class
    ... In this case, boxing must be done. ... that the compiler will have to generate addition calls into the memory ... so it's stored on the heap. ... If GC_ALLOCATE can't allocate the requested ...
    (microsoft.public.dotnet.framework)
  • Re: Java (bytecode) execution speed
    ... faster or slower than a compiled language. ... likely to be slower (the compiler must run quickly, so it won't do a lot ... garbage collection and management of the heap. ...
    (comp.lang.java.programmer)