[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 27 Oct 2009 09:48:17 +0100
On Wed, Sep 23, 2009 at 06:31:41PM +0200, Bas Wijnen wrote:
> On Wed, Sep 23, 2009 at 12:59:06AM +0200, address@hidden
> > On Tue, Sep 15, 2009 at 06:26:10PM +0200, Bas Wijnen 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 not that C++ encourages writing ugly code. (Though some
people claim this too -- but I haven't cared to look at enough C++ code
to be able to judge for myself :-) )
My point is that many of the "features" added by C++ are dead ugly in
themselfs. (cin/cout probably being the worst of them.) 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.
> > > Of course Richard Stallman is a known hater of C++. He has a
> > > point that everybody knows C, so using that makes the code
> > > readable for everyone. [...] IMO his love for C is unreasonable.
> > Richard Stallman is not a C++ hater,
> 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. C++ has been a part of gcc long before the fork. (In fact, I
think I read somewhere that it was the first native C++ compiler -- but
I'm not sure on this point.)
According to Wikipedia, the original gcc maintainers were generally
conservative about merging improvements; which is why at some point many
improvements were collected to form egcs. *Some* of these were indeed
improvements for better C++ support -- but concluding that RMS hates C++
> 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
That is precisely what I take issue with: this doesn't really hide any
complexity. It's just a different notation -- which obscures the fact
that the object is really just an argument like all the others; limits
flexibility by strict class boundaries; and I don't find it more
readable either, quite the opposite. (Though the latter is obviously a
matter of taste...)
> > 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
Using any of these (or others of a similar abstraction level) would at
least offer enough benefit to even consider a departure from C for
certain components being wothwhile.
> > > However, our main interest is not that everyone can read our code.
> > Free software is about enabling people to understand and adapt the
> > software. An obscure language is a major obstacle.
> Yes, I agree. As I wrote, it is a good thing if many people can read
> our code. But it is more important that we can efficiently write good
> code. It obviously helps to combine the two. But if both cannot be
> accomplished together, IMO actually getting the code written is more
> important than making it readable.
Note however that using a more common language, the "we" can potentially
be much larger...
Of course it's a tradeoff, which might actually be positive, if using a
language that really improves productivity a lot. (Hint: not C++.)
> 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; and adapting it to ones own needs.
> 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 :-)
Of course this is different for some higher-level components of the
Hurd... But then, all the other points still apply :-)
- Re: C++, olafBuddenhagen, 2009/10/28
- Re: C++, olafBuddenhagen, 2009/10/28
- Re: C++, Jonathan S. Shapiro, 2009/10/28
- Re: C++,