Vimr for windows code#
a compiler that runs as a simple standalone application can just use globals for the state and perhaps not even free memory at shutdown - see dlang as an example - whereas a compiler meant to be integrated as a library cannot do that).Īs an example, for a Borland-like approach (at least based on my understanding of it), adding a language extension to -say- provide meta-data for classes wouldn't be something that only the compiler developers cared about, but something that the developers of the compiler, the debugger (for being able to display the meta-data), the IDE (for editor auto-completion and automatic code editing - later Borland IDEs could modify the code - and debugger UI), the framework library (for taking advantage of it and providing a 'best use' scenario), etc.
Vimr for windows software#
I'm not sure if 'philosophy' is the proper term here, but it is certainly about how you believe that software should be made and having that in mind at all times when designing it at all levels - be it the functionality to provide or how that will be implemented (e.g.
They're not seen as a single "C++ development environment" project but as two separate projects that happen to communicate with each other. MSVC could in theory be able to do that since the IDE is made by the same company as the compiler, but in practice the teams behind it are probably acting as separate "sub-companies" inside the bigger organization. Honestly i do not believe it is even possible to what the sort of integration i'm talking about by stitching together separate projects no matter how many extension points and hooks those projects provide - by definition they aren't made with a singular coherent vision where everything is meant to work together, instead each project has its own idea of how it should work. Libclang might be a bit closer but it still is something separate from whatever IDE it is used for. for C++ MSVC always called out to a separate compiler program that had to reparse/restart its state for each file whereas BCC had the compiler as part of the IDE executable that would keep state across compilation in memory and even use the editor text buffer for 'input' if there was one instead of loading a file from disk) and Smalltalk (where the IDE and runtime are the same thing, you are modifying a live environment with tools written in that same environment instead of cold-running everything from start). No i think it is actually about philosophies (or at least a way of looking at how software should be made) - again, i point out to Borland (whose IDEs were always provided a way more integrated environment than anything Microsoft ever did - e.g.
0 kommentar(er)
