Re: C++

[William Leslie]

2009/11/2  <address@hidden>:
> 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