[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++

From: olafBuddenhagen
Subject: Re: C++
Date: Mon, 2 Nov 2009 00:30:11 +0100
User-agent: Mutt/1.5.19 (2009-01-05)


On Wed, Oct 28, 2009 at 10:53:56PM +0100, Bas Wijnen wrote:
> On Tue, Oct 27, 2009 at 09:48:17AM +0100, address@hidden
> wrote:

> Being able to make classes and do inheritance is definitely a Good
> Thing, for which there isn't a proper alternative in C, IMO.

I never worked on any code where inheritence was central enough to
warrant an extra language feature... There might be situations where it
is indeed (GUI programming is typically cited as the standard example)
-- but kernel hacking is definitely not one of them.

> In C, you would need to add the parent class as a first member, which
> would lead to variable.parent.parent.foo and variable.parent.bar.  If
> what you mean is inheritance (so top is just a specialized version of
> middle, which is a specialized version of base), then all those parent
> references are not adding information, but instead only obscuring
> things.

No, they are definitely *not* obscuring things. They make things more
explicit. Whether it is good or bad is a different question. (I for my
part consider it good in most cases.)

> > The fact that it's possible to use a certain subset that is pretty
> > elegant and consistent -- called C -- doesn't change the fact that
> > C++ as a language is dead ugly.
> This subset isn't exactly C.  It's C with inheritance, member
> functions, default function arguments and templates.

Regardless whether these features are considered useful in themselfs (I
don't like them, but I know that not many people share my opinion), the
way they are implemented in C++ is ugly -- almost everyone I talked to
agrees with that.

> > > I thought this as well, but I have found that using only a few
> > > features (in particular organizing code in classes with member
> > > functions, instead of creating interfaces which pass their object
> > > as an explicit first argument) will really make the result a lot
> > > more readable.
> > 
> > That is precisely what I take issue with: this doesn't really hide
> > any complexity.
> It does.  It organizes all functions which handle certain data into a
> single place (the class definition).

Organising things isn't hiding complexity. It's managing complexity at
best. Moreover, it can be done perfectly well without a special language
syntax IMHO.

> > It's just a different notation
> I don't have a problem with that, if it is useful, and it is.

As I already said, this is subjective -- *I* don't consider it useful.

> 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.)

> > Note however that using a more common language, the "we" can
> > potentially be much larger...
> This is true in theory, but I haven't seen so many people jump in to
> help, even though we have so far always been using C...

Actually, there are quite a lot of people offering help; only we don't
manage to keep their interest long enough...

In either case, the fact that few people are helping now, doesn't mean
it wouldn't be even fewer if we used a less common language. While I
can't actually prove it, common sense tells me it's pretty obvious.

> > Of course it's a tradeoff, which might actually be positive, if
> > using a language that really improves productivity a lot. (Hint: not
> > C++.) 
> I think it will be positive if a language is found that enough people
> like.  For me, C++ is a good candidate.

I know very few people who actually *like* C++ -- most just tolerate it
at best. (Admittedly, that's true for C as well...)

> > > Additionally, the point about free software you cite is that it is
> > > useful for educational purposes.
> > 
> > No, not really. Studying the code can happen for educational
> > purposes of course: but more important is the ability to know what
> > the software really does;
> I consider that educational.

No, it's not about learning kernel programming. It's about being in
control. This is very different. When learning programming, it might be
wise to choose a language that supports learning. But here, we assume
that people already know programming. Choosing a language for
"educational value" would be pointless. Choosing a *common* language is
what puts more people in control.

> On Tue, Oct 27, 2009 at 10:48:49AM +0100, address@hidden
> wrote:
> > On Wed, Sep 23, 2009 at 06:45:49PM +0200, Tom Bachmann wrote:

> > > Apart from that you can do wonderful things with templates, but
> > > ??? lets  not go into this.
> > 
> > You can do much more wonderful things with true high-level languages
> > that don't need such kludges in the first place... :-)
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]