This project has moved and is read-only. For the latest updates, please go here.

is it possible to treat managed C++ and just another port?

Feb 26, 2007 at 7:13 PM
Here is the fundamental question. Is it possible to have an application written in C and to treat it as just another port when run in a managed C++ environment?
Can we keep the source code relatively clean, and compile from the same sources for platforms
as divergent as Cygwin, Linux, unmanaged C, managed C++, and in different operating systems,
and CLR such as Windows .NET and Linux Mono?

Experience with Purify and some very old C interpreters, including the C compiler for the CADR circa 1982, suggest that it is possible to do this, as long as the overhead of dealing
with the "MAKE/BUILD" environment does not get out of control.

We've been dealing with differences between C compilers for 30 years, and know that it is not
Apr 14, 2007 at 12:51 PM
I have done an initial port to CLR. Things that trigger "native code generation" were removed.

1. valist, varstart,vaend, vaarg. So instead of having listn, I have made list2,list3. Perhaps there is another implementation of "..." which does not generate a warning in CLR. Using it in portable code by using macros might be tricky. This is unfortunate, because "..." can be used to considerably reduce the verbosity of code.

2. all the garbage collector related stuff removed. lookspointerp, and stackstartptr. gcmarkandsweep(), the use of jmp_buf structure. Just removed.

3. stacklimitptr removed, and STACK_CHECK(X) macro is a no-op.

4. the jmpbuf removed from the catchframe structure. And all code that referenced it. Also other calls to setjmp and longjmp removed.

I also did a bit of rewrite around functions that are warned as
being unsafe or security risks. Of course this could also be done
in the C version as well. sprintf, strcat, getenv, etc. But the thing
that confused me about this was why, in a fully managed environment
these functions would be unsafe? Doesn't even a raw char * in managed
code have a length associated with it that comes from the point
where you called malloc to get the memory in the first place? Perhaps
not. (In the LISPMACHINE implementations of C of course this was done,
and C pointers were a kind of locative, or closure, into other

Anyway, the result is code that works, read-eval-print, but no garbage
collector. I will post it to the site, as soon as the TFS here on
codeplex is running again.

Aug 25, 2008 at 12:24 AM
could you "redirect" to using the CLR's GC system?