2009/11/2 <[email protected]>: > Hi, > > On Wed, Oct 28, 2009 at 10:53:56PM +0100, Bas Wijnen wrote: >> I've used Python for some larger projects. It's a very nice language, >> but I wouldn't consider it higher level than C++. > > Err... You are the first person I ever saw making such a claim. > > (I don't actually know Python, so I don't really have an opinion of my > own... What I heard from other people made me place it as much more > high-level than C++ though.)
I would call a language with any of closures, stronger typing, namespaces, or automatic memory management higher level than C++. Consistent dynamic dispatch, a metaclass model, and high-performance built-in data types are also a bonus. As a *bare minimum*, though, built-in automatic memory management makes a big difference. I can't imagine doing application development without it. Disclaimer: pypy is the vehicle for my current research. >> The nice thing about templates is that they really are very low-level. >> This means they can actually be usable for kernel programming. No >> library support or magic compiler-generated code is required for them. >> They do exactly what you expect. But they are still capable of things >> that become extremely ugly in C (you can choose from huge #define >> blocks or lots of code duplication). > > I actually consider generic programming with the C preprecessor pretty > fun -- though not exactly helping readability ;-) > > However, I'm not talking about runtime features, nor explicit code > generation. I'm talking about the type inference implemented by some > languages (mostly functional ones), allowing the compiler to > automatically instance any function for the types it is actually used > on, without any explicit template handling. Polyinstantiation has been a big topic for bitc. See: http://www.bitc-lang.org/docs/bitc/bitc-origins.html#Polyinstantiation "Parametric types, explicit unboxing, and separate compilation do not get along. " I suppose that you can reasonably rule out separate compilation as a problem when writing kernels, and be content with some link-time compilation otherwise (or I suppose these are the same thing). But I think that this is the point Barry was trying to make: C++ templates do all that work for you, at compile time. Whether one approach is /better/ than another it is hard to say. *I* think link-time polyinstantiation is a shade nicer, particularly in the case that you modify an important classes innards (possibly including, in C++, private attributes) and find yourself recompiling all of its dependencies. Resolving external structure (including vtable) offsets at link-time probably isn't that expensive, and makes library usage seem much more managable. William Leslie
