Re: C++

[Bas Wijnen]

Hi,

On Tue, Oct 27, 2009 at 09:48:17AM +0100, address@hidden wrote:
> > > Unfortunately, in spite of the name and resulting general
> > > perception, C++ can not really be considered an evolution of C.
> > > While it adds a couple of useful features, and a couple of features
> > > considered useful by some, it also takes away an essential feature
> > > of C -- its elegance.
> > 
> > Not at all.  You can still write C code in C++, which means that
> > whatever you consider elegant is still possible.  If you mean that it
> > is possible to write horrible code in C++, then I agree.  But that is
> > very easy in C as well.  Both languages allow many things, which is
> > what makes them so powerful.
> 
> My point is that many of the "features" added by C++ are dead ugly in
> themselfs. (cin/cout probably being the worst of them.)

I don't use streams, except in very simple programs.  But that doesn't
mean the whole language is bad.  Being able to make classes and do
inheritance is definitely a Good Thing, for which there isn't a proper
alternative in C, IMO.  What if you have:

struct base { int foo; };
struct middle : public base { int bar; }
struct top : public middle { int baz; }
top variable;

Now you can access variable.foo and variable.bar as you would expect.
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.

> 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.  At least.  For most programs,
the standard template library is extremely cool.  For a kernel it isn't,
which is why it shouldn't be used there (as well as streams,
polymorphism, and exceptions, for example).  That doesn't make the
language bad, though.

> > I heard that the egcs fork of gcc was really a quarrel between him and
> > people who wanted a C++ port integrated into it.
> 
> Not at all.

Ok, I was badly informed then.  Sorry about 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).

> It's just a different notation

I don't have a problem with that, if it is useful, and it is.

> -- which obscures the fact that the object is really just an argument
> like all the others;

It doesn't.  Everyone who is interested in kernel writing knows that a
member function can't work if the object isn't passed to the function.

> limits flexibility by strict class boundaries;

What do you mean with this?  By using inheritance, I am in fact more
flexible than I would be in C, IMO.  Except if you would use the "parent
as attribute" approach, which is as flexible, but more ugly.

> and I don't find it more readable either, quite the opposite. (Though
> the latter is obviously a matter of taste...)

It is indeed. :-)  But I have a reason to consider it more readable:
there is no namespace problem in C++.  When I call a member function on
a Thread object, it will obviously be something that works on a thread.
So instead of

thread_sleep (my_thread, timeout);

I can say

my_thread.sleep (timeout);

Notice that in the C version, both the variable type and the function
name carry the information that this is about threads.  The only reason
this is required is that a simple name such as "sleep" may collide with
some other use.

Note also that if you don't like classes and member functions, you can
still get rid of the prefix, because C++ allows overloading functions,
so that sleep (thread) and sleep (some_other_type) can both exist
without colliding.  But when using that in the wrong way, it does really
become much less readable. ;-)

> > > While for the kind of code where a higher-level language is more
> > > useful, you better use a true high-level language.
> > 
> > I come from real low-level languages (assembly and sometimes even raw
> > machine code), and C++ is high enough for me. ;-) It is well possible
> > that some other languages offer even more.  I just haven't discovered
> > those languages yet.
> 
> Are you at all familiar with high-level languages; say Haskell, Lisp, or
> even Python?...

Not Haskell, I've seen very little lisp and didn't like it.  I've used
Python for some larger projects.  It's a very nice language, but I
wouldn't consider it higher level than C++.  In fact, the way I use both
languages, C++ is more high level.  But that is probably not because of
the language, but more because of my experience with both.

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

> 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.  Then again, I'm busy enough
with other things at the moment, such as my own kernel, so I probably
wouldn't immediately do much anyway.

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

> and adapting it to ones own needs.

But that is indeed more, and very useful.

> > It does not make sense to teach people to use a language which really
> > isn't the best tool for the job.  So if you would think that C is not
> > the best language to write a kernel in, doing it anyway "because
> > people can learn from it" isn't actually a good idea.
> 
> This point is moot, as I consider C to be the best language for
> low-level stuff like the microkernel :-)

No, this is still a valid point.  I'm saying that "this language can be
understood by more people" is not a valid argument.  Obviously the
existance of an invalid argument doesn't mean that C isn't the right
language to use. ;-)

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

Thanks,
Bas

signature.asc
Description: Digital signature