OT: on IDEs and code writing on steroids

Bill Baxter wbaxter at gmail.com
Wed May 20 14:45:08 PDT 2009


On Wed, May 20, 2009 at 1:09 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Yigal Chripun wrote:
>>
>> I think you miss the point here.
>> Generics and code generation are two separate and orthogonal features that
>> where conflated together by C++.
>
> It's kind of odd, then, that for example the Generative Programming book
> (http://www.generative-programming.org) chose to treat the two notions in
> conjunction.

Yeh, there's definitely a overlap.  Orthogonal isn't quite the right word there.

I'm reading a bit on C++/CLI right now, which is C++ extended to
inter-operate with CLR.
C++/CLI has *both* classic C++ templates and CLR generics:

  template<typename T> ...    // all code specializations generated at
compile-time (if at all)
  generic<typename T> ... // code generated at compiletime
unconditionally, specialized at run-time.

I'm not clear on exactly what happens at runtime in the generic<>
case.  I had been thinking it was simply that the compiler does some
type checking at compile time and the VM code then just manipulates
pointers to Object from there.  That may be what happens in Java
generics, but in CLR generics at least you can specialize on
non-Object value types and that apparently does not result in
everything getting boxed.  So it seems like there's a little something
extra going on.

I think the main reason for having Generics is that they're the best
anyone currently knows how to do at the IL bytecode level.  Generics
give you a way to define generic parameterized types that work across
all the languages that target a given VM's bytecode.  But that doesn't
preclude any language that targets that VM from *also* implementing
compile-time templates, or code generators, or AST macros at the
source code level.

But the problem with source-level code generation is that you then
need the source code in order to use the library.  I think they were
trying to avoid that with C#.   If you have a compiled C# assembly,
then you have everything you need to use it.   Period.   (I think.)
At any rate, a tech that requires inclusion of source code is not very
interesting to Microsoft, because Microsoft doesn't generally like to
let people see their source code in the first place, and they know
that many of their biggest customers don't like to either.  They're
nervous enough about just putting de-compileable bytecode out there.

--bb



More information about the Digitalmars-d mailing list