100 likes | 228 Views
My plans/dreams for C# in CDT. Doug Schaefer. Why C#. Needed to prove multi-language capabilities Fortran already being done and I don’t really know Fortran Ada is a great language but use is on decline Java already done with JDT C# very popular in Windows circles
E N D
My plans/dreams for C# in CDT Doug Schaefer
Why C# • Needed to prove multi-language capabilities • Fortran already being done and I don’t really know Fortran • Ada is a great language but use is on decline • Java already done with JDT • C# very popular in Windows circles • Mono project bringing C# other platforms, especially Linux • C# (IMHO) is a better Java • Operator overloading • Structs – inline object store • Easy integration to native methods
Why C# - Ulterior motives • Eclipse Foundation very excited about this project • A path to bring Windows developers into Eclipse world • Helps the cause of Eclipse as valid alternative to VisualStudio • There is nothing VisualStudio does that can’t be done in Eclipse • Takes member commitment, though. • Help grow the CDT community as well • More users mean more testers • And the odd developer • High profile project could mean more commercial interest • Thus even more developers
What components are needed? • ILanguage implementation for Core Models • ILanguageUI implementation for Editor adaptation • Compiler Integration for building • Debugger Integration for debugging • In theory, that should be it
ILanguage • New DOM implementation • Extend IAST interfaces for AST • Extend IBinding and IType for semantic info • Extend PDOM classes for index • C# Scanner and Parser • Using ANTLR v3 to expedite • Need sharable preprocessor • Reusable with other ANTLR based parsers (others?) • CModelBuilder needed too • Extend ICElement interfaces, build using DOM
ILanguageUI • Right now only have new code scanner • Clone of C++ scanner • Different keywords, types, constants • Many other things should be same • May want to override editor menu to remove items
Compiler Integration • C# compilers different than C/C++ compilers • No object code, direct source to DLL/EXE • No linker • Need to compile all files producing the build target in one command invocation. • Not a lot of command line options • But does do debug versus release (i.e. configs needed) • Debating my own builder versus managed make • Independent contributor is looking at managed make • Microsoft (csc) and Mono (mcs) compilers very similar
Debugger Integration • Windows and Mono very different here, need different solutions • Windows – C++ COM interfaces to debugger APIs • Mono – young (0.20) written in C# • Maybe later… • How to hook up Windows debugger • CDI layer that uses JNI to talk to debugger API • DSF instead of CDI? • Separate executable that talks MI to CDT a la gdb
Debugger Integration • MI seems to be safer alternative • Out of process, won’t bring down Eclipse if it crashes • Can test from command line • Use similar architecture for C++ debugging on Windows • Which will use dbghelp APIs (similar architecture to .Net) • Build reusable MI library in C++ • EPL for all to use/contribute to • Using CDT, of course! • But how do you debug your debugger…
Who’s working on it? • This is where plan turns into dream • Or, how to build a community from scratch. • Already have one independent guy working in personal time • Myself very part time • The hope is, as it starts to materialize, interest will spike • Start making noise about it in developer forums • Mono • Even Microsoft C# forums • Mentioned in my Podcast for EclipseZone