C++ *for Git*

C++ *for Git*

[Dmitry Kakurin]

We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in 
general*.
In no way I want to restart it. But *very specifically*, and *for Git*:
We already have strbuf "class" to do string/buffer manipulations.
Kudos to Pierre Habouzit for doing the refactoring work!
Now, what I fail to understand is how this:

static void write_global_extended_header(const unsigned char *sha1)
{
    struct strbuf ext_header;

    strbuf_init(&ext_header, 0);
    strbuf_append_ext_header(&ext_header, "comment", sha1_to_hex(sha1), 40);
    write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
    strbuf_release(&ext_header);
}

is better than this:

static void write_global_extended_header(const unsigned char *sha1)
{
    strbuf ext_header;

    ext_header.append_ext_header("comment", sha1_to_hex(sha1), 40);
    write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
}

?
Note, there is no Boost/multiple inheritance/template 
metaprogramming/std::string/whatever-else-scares-you-in-C++ in the second 
piece of code.
Just a very straight-forward usage of only 3 C++ features:
1. Constructors
2. Destructors
3. Better syntax (ext_header.append_ext_header vs. 
strbuf_append_ext_header(&ext_header, )

The generated code will be exactly the same.
Yet the source code becomes more readable and MUCH less error prone. How is 
this not a win?

One (sensible) argument that I've heard in the previous discussion was: you 
let a little bit of C++ in and then it gets more and more complex and the 
code quality decreases.
This problem is solved by having "quality gates".
Again, *for Git* these quality gates already exist: only few people have 
"commit access".
If/when somebody tries to be too fancy, what stops Junio from replying "we 
don't use Library-X/C++-feature-Y in Git, please change your code and 
resubmit" and throwing that fix away? Nothing.

- Dmitry

Re: C++ *for Git*

[David Kastrup]

Dmitry Kakurin <dmitry.kakurin@gmail.com> writes:

> We've had this theoretical (and IMHO pointless) discussion C vs. C++
> *in general*.
> In no way I want to restart it.

Then don't.

> Just a very straight-forward usage of only 3 C++ features:
> 1. Constructors
> 2. Destructors
> 3. Better syntax (ext_header.append_ext_header
> vs. strbuf_append_ext_header(&ext_header, )
>
> The generated code will be exactly the same.

It won't.  It will _do_ exactly the same (modulo the tenfold
likelihood of compiler bugs) but hardly using the same code.

> Yet the source code becomes more readable and MUCH less error
> prone. How is this not a win?

Because it is just your claim that this is more readable.

> One (sensible) argument that I've heard in the previous discussion
> was: you let a little bit of C++ in and then it gets more and more
> complex and the code quality decreases.
> This problem is solved by having "quality gates".
> Again, *for Git* these quality gates already exist: only few people
> have "commit access".
> If/when somebody tries to be too fancy, what stops Junio from replying
> "we don't use Library-X/C++-feature-Y in Git, please change your code
> and resubmit" and throwing that fix away? Nothing.

Well, what stops him from replying "we don't use C++ in Git, please
change your code and resubmit"?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: C++ *for Git*

[Johannes Schindelin]

Hi,

On Sat, 22 Sep 2007, Dmitry Kakurin wrote:

> We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in
> general*.

I think "pointless" is more to the point.

We don't want C++.  Why is that so hard to accept?

Ciao,
Dscho

Re: C++ *for Git*

[Kyle Rose]

You know, git *is* free software.  Feel free to fork it and add all the
C++ code you want.

FWIW, I am of the opinion that Python or Ruby (or god forbid, Perl)
would have been a better choice for something like git that does lots of
text processing... furthermore, I think the exception handling, garbage
collection, and implicit object destruction provided by those languages
(and by C++, as overwrought as it is) makes any codebase easier to
understand and maintain.

But that's irrelevant: git is written in C.  That's the way it is, and
you should accept that or fork.

Kyle

Dmitry Kakurin wrote:
> We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in
> general*.
> In no way I want to restart it.

Re: C++ *for Git*

[Marco Costalba]

On 9/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> We don't want C++.  Why is that so hard to accept?
>

Dmitry, I think what Johannes says in the above line is 100% the core
point of this (sad) discussion.

You cannot force/convince someone to use something he hates. That's
it. And there's no point in trying to do this.

git developers were also kind enough to give explanations on 'why' C++
is not a good language for them. Do you don't agree? do you find the
arguments not totally satisfying for you? That's not their problem.

I like C++ (a my little git related GUI tool called qgit is done in
C++) and at the same time I understand also much of the concerns that
where expressed in the list.

Your position will never be successful for a number of reasons, some
clear expressed other less clear but at the same time, perhaps more
important. So I really don't understand why you insist.

Thanks
Marco


P.S: The example you show is a pity for C++, it's like to advertise a
1000cc 200Hp motorbike saying "...and you will no have problems in
parking in your box."

Re: C++ *for Git*

[Miles Bader]

Kyle Rose <krose@krose.org> writes:
> I think the exception handling, garbage collection, and implicit
> object destruction provided by those languages (and by C++, as
> overwrought as it is) makes any codebase easier to understand and
> maintain.

Of course, some of the most horrid unreadable source code I've ever seen
is in one of git's competitors -- written in python....

-Miles
-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

[OT] Re: C++ *for Git*

[Kyle Rose]

Miles Bader wrote:
> Of course, some of the most horrid unreadable source code I've ever seen
> is in one of git's competitors -- written in python....

Indeed. :-)

At the office, people constantly badmouth Perl, which has some
admittedly evil syntax (especially around exception handling).  My view
is that good Perl programmers can produce good, readable, maintainable
Perl programs, while bad Perl programmers can produce spaghetti the
likes of which can't be found outside Italy.

OTOH, I think it is much harder to hang one's self with Python, though
admittedly possible, as it is when you combine a bad coder with *any*
language.  Still, typical bad programmer + Perl is much worse than
typical bad programmer + Python.

C++ is in the same category as Perl IMO: too easy to produce unreadable
code.  I contend that C is pretty much just as bad, though in a
different way: while C lacks C++'s ability to bury code in multiple
layers of opaque abstractions, C makes up for it by providing absolutely
no GC-type structures (i.e., I do this now, you clean it up later when
I'm no longer interested in it).  C is all explicit, which is nice when
you have a good handle on everything that is going on *or* an explicit
system for remembering to do those types of cleanup tasks that is
well-understood by all developers involved.

I like Ruby, except for the performance problems.  Once they have those
worked out, Ruby will be "Perl done right." ;-)

Kyle

Re: [OT] Re: C++ *for Git*

[David Kastrup]

Kyle Rose <krose@krose.org> writes:

> Miles Bader wrote:
>> Of course, some of the most horrid unreadable source code I've ever seen
>> is in one of git's competitors -- written in python....
>
> Indeed. :-)
>
> At the office, people constantly badmouth Perl, which has some
> admittedly evil syntax (especially around exception handling).

Since Perl has agglomerated pretty much _every_ syntax, it is not
surprising that evil syntax is included.

> C++ is in the same category as Perl IMO: too easy to produce
> unreadable code.

Not quite.  Perl gives you a hundred illegible ways to _say_ the same
thing, C++ gives you a hundred illegible ways to _achieve_ the same
thing, but using different means.

> I like Ruby, except for the performance problems.  Once they have
> those worked out, Ruby will be "Perl done right." ;-)

Ruby again is in the "throw every syntactical idiom I can think of
together" ballpark.  I find that a design mistake in Perl, a design
mistake in Ruby, and even in C++ (Ada syntax for templates was just
stupid, but at least there is no alternative syntax for it).

That's one of the things I like about Lua: its syntax fits on one page
in the reference manual.  And the reference manual has a paper size of
about A5.  While the syntax for Lisp would probably fit in the margin,
it does so at a cost in legibility.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: C++ *for Git*

[Martin Langhoff]

On 9/23/07, Kyle Rose <krose@krose.org> wrote:
> But that's irrelevant: git is written in C.  That's the way it is, and
> you should accept that or fork.

Or - as Marco's done - write complementary bits to git. I'm a
Perl-head, and I've ended up writing bits of Perl for git, some of
them have been reimplemented in C, some have stayed in Perl.

Arguing is a waste of time -- code! Help Marco, or write something new
and glorious. Make it useful for people who don't care what it's
written in, and beautiful so that the infidels are enlightened with
how elegant C++ can be.

Codefest > Flamefest

cheers,



m

Re: [OT] Re: C++ *for Git*

[Alex Unleashed]

On 9/22/07, Kyle Rose <krose@krose.org> wrote:
> C++ is in the same category as Perl IMO: too easy to produce unreadable
> code.  I contend that C is pretty much just as bad, though in a
> different way: while C lacks C++'s ability to bury code in multiple
> layers of opaque abstractions, C makes up for it by providing absolutely
> no GC-type structures (i.e., I do this now, you clean it up later when
> I'm no longer interested in it).  C is all explicit, which is nice when
> you have a good handle on everything that is going on *or* an explicit
> system for remembering to do those types of cleanup tasks that is
> well-understood by all developers involved.

I'd say being forced to be explicit is a good thing here, so that the
programmer at least has some sort of good understanding of what is
going on, and chances are that if he doesn't really know, things just
won't work out (quite unlike a lot of other languages where this
programmer might actually end up with something half-assed that
"mostly" works).

For some reason it seems to me a lot harder to find bad programmers
surviving using C than a lot of the other languages.

Alex

Re: [OT] Re: C++ *for Git*

[Frank Lichtenheld]

On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:
> I'd say being forced to be explicit is a good thing here, so that the
> programmer at least has some sort of good understanding of what is
> going on, and chances are that if he doesn't really know, things just
> won't work out (quite unlike a lot of other languages where this
> programmer might actually end up with something half-assed that
> "mostly" works).
> For some reason it seems to me a lot harder to find bad programmers
> surviving using C than a lot of the other languages.

Idiot-proofness-by-complexity is a myth IMHO. Idiots can be quite
persistent...

Gruesse,
-- 
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/

Re: C++ *for Git*

[Dmitry Kakurin]

On 9/22/07, Marco Costalba <mcostalba@gmail.com> wrote:
> On 9/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > We don't want C++.  Why is that so hard to accept?
> >
>
> Dmitry, I think what Johannes says in the above line is 100% the core
> point of this (sad) discussion.

Actually after a couple of responses to this thread I had a BFO
(Blinding Flash of Obvious). I cannot believe I was so naive :-). Now
I have my answer.

P.S. Mysteries like this could drive me crazy. Now I'm much happier.

-- 
- Dmitry

Re: [OT] Re: C++ *for Git*

[David Brown]

On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:
>On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:
>> I'd say being forced to be explicit is a good thing here, so that the
>> programmer at least has some sort of good understanding of what is
>> going on, and chances are that if he doesn't really know, things just
>> won't work out (quite unlike a lot of other languages where this
>> programmer might actually end up with something half-assed that
>> "mostly" works).
>> For some reason it seems to me a lot harder to find bad programmers
>> surviving using C than a lot of the other languages.
>
>Idiot-proofness-by-complexity is a myth IMHO. Idiots can be quite
>persistent...

I work with plenty of them :-)  It's all C.  All of the same things happen,
with management looking for magic bullets to solve problems caused by bad
programmers.

Dave

Re: [OT] Re: C++ *for Git*

[David Kastrup]

David Brown <git@davidb.org> writes:

> On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:
>>On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:
>>> I'd say being forced to be explicit is a good thing here, so that the
>>> programmer at least has some sort of good understanding of what is
>>> going on, and chances are that if he doesn't really know, things just
>>> won't work out (quite unlike a lot of other languages where this
>>> programmer might actually end up with something half-assed that
>>> "mostly" works).
>>> For some reason it seems to me a lot harder to find bad programmers
>>> surviving using C than a lot of the other languages.
>>
>>Idiot-proofness-by-complexity is a myth IMHO. Idiots can be quite
>>persistent...
>
> I work with plenty of them :-) It's all C.  All of the same things
> happen, with management looking for magic bullets to solve problems
> caused by bad programmers.

C++ is good for creating black boxes.  A black box that has been
fitted into its environment and that has good innards is fine.  A
black box with rotten innards, or not really being well-suited for the
job at hand, isn't.  For a project where people come and go, black
boxes might hide a lot about bad design and implementation.

In particular, changing an algorithm to require different black boxes
is something that is very unpleasant to do.

Having everything in the open is an advantage as long as the
complexity to be managed is at a reasonable level.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [OT] Re: C++ *for Git*

[Marco Costalba]

On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> David Brown <git@davidb.org> writes:
>
> > On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:
> >>On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:
> >>> I'd say being forced to be explicit is a good thing here, so that the
> >>> programmer at least has some sort of good understanding of what is
> >>> going on, and chances are that if he doesn't really know, things just
> >>> won't work out (quite unlike a lot of other languages where this
> >>> programmer might actually end up with something half-assed that
> >>> "mostly" works).
> >>> For some reason it seems to me a lot harder to find bad programmers
> >>> surviving using C than a lot of the other languages.
> >>

Well, according to your reasoning assembly should be the gotha of
elite programmers, only very disciplined and meticulous programmers
survive, much more then in C.

Is this a good way to measure a language?

>
> C++ is good for creating black boxes.

Object oriented languages creates black boxes: that's the reason why
object oriented exsists and also the reason why Linus hates it ;-)

Difference between C++ and other OO languages is mostly in the size of
the applications written in that language IMHO.

C++ noramlly has the bigger code bases, so problem you mention are
enanched and perhaps seem to depend on the language itself not on the
size of application. IOW a Python (Ruby) app probably does not have
the size of Firefox or Open Office, this _could_ induce the naive idea
that the python app is cleaner or easier to understand just becasue of
Python vc C++.

I really don't think so. I think this could be true for toy problems,
but for real, for big applications is the design of the appllcation,
not the language, that at 90% state the difference between clean and
crap.

>A black box that has been
> fitted into its environment and that has good innards is fine.  A
> black box with rotten innards, or not really being well-suited for the
> job at hand, isn't.

I really agree here. The biggset downside of OO is that for it to work
you should have a much deeper knowledge of the problem you want to
handle. OO force you to analyze more and know more because a bad
design normally means throwing everything in the trash can and start
again.

Procedural programming as C is more immune to this 'good problem
analysis'  dependency.

Marco

Re: [OT] Re: C++ *for Git*

[David Kastrup]

"Marco Costalba" <mcostalba@gmail.com> writes:

> On 9/23/07, David Kastrup <dak@gnu.org> wrote:
>> David Brown <git@davidb.org> writes:
>>
>> > On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:
>> >>On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:
>> >>> I'd say being forced to be explicit is a good thing here, so that the
>> >>> programmer at least has some sort of good understanding of what is
>> >>> going on, and chances are that if he doesn't really know, things just
>> >>> won't work out (quite unlike a lot of other languages where this
>> >>> programmer might actually end up with something half-assed that
>> >>> "mostly" works).
>> >>> For some reason it seems to me a lot harder to find bad programmers
>> >>> surviving using C than a lot of the other languages.
>> >>
>
> Well, according to your reasoning

Who is "you"?  You are replying to a post of mine, yet commenting on
Alex.

> assembly should be the gotha of elite programmers, only very
> disciplined and meticulous programmers survive, much more then in C.

I am neither disciplined nor meticulous, yet have designed and
programmed applications and complete systems in assembly language.
Programmers can easily survive assembly language without being
disciplined or meticulous.  Their projects can't: they get tied to the
programmers.  Porting an assembly language application to a different
processor might be easier than porting it to another programmer.

> Is this a good way to measure a language?

It is a good way to measure programmers, at least concerning some
interesting metrics.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [OT] Re: C++ *for Git*

[Marco Costalba]

On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> >
> > Well, according to your reasoning
>
> Who is "you"?  You are replying to a post of mine, yet commenting on
> Alex.
>

Sorry, you are right, I'm not meticolus either ;-)

Marco

Re: [OT] Re: C++ *for Git*

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 4098 bytes --]

On Sun, Sep 23, 2007 at 09:29:45AM +0000, Marco Costalba wrote:
> On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> > David Brown <git@davidb.org> writes:
> >
> > > On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:
> > >>On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:
> > >>> I'd say being forced to be explicit is a good thing here, so that the
> > >>> programmer at least has some sort of good understanding of what is
> > >>> going on, and chances are that if he doesn't really know, things just
> > >>> won't work out (quite unlike a lot of other languages where this
> > >>> programmer might actually end up with something half-assed that
> > >>> "mostly" works).
> > >>> For some reason it seems to me a lot harder to find bad programmers
> > >>> surviving using C than a lot of the other languages.
> > >>
> 
> Well, according to your reasoning assembly should be the gotha of
> elite programmers, only very disciplined and meticulous programmers
> survive, much more then in C.

  This non argument was raised before in the recent thread we just had.
Could we at least wait say, a month, before spawning the same trolls
again and again ?

> > C++ is good for creating black boxes.
> 
> Object oriented languages creates black boxes: that's the reason why
> object oriented exsists and also the reason why Linus hates it ;-)

  This is just nonsense. This has been proved, though I can't find the
paper about this anymore, than modules (or packages whichever name you
give them) plus abstract types are as good as OO languages at creating
black boxes. I mean it has been proved that it gives the exact same
amount of expressiveness. So please stop with this myth. And don't speak
for people, I would be very surprised that Linus would dislike "black
boxes". Abstractions are good, when used wisely, and I would be much
surprised to see Linus pretend otherwise.

  The real problem with big applications, is not that they are written
with C, C++, D, APL or Perl, but that they are big. Most of the time,
big means that many people are not able to grok the big picture, and you
end up with 102 implementations of base64, 10 string libraries, 4
general purpose buffers, and at least half of the common lisp
features[0]. And for the record git is _not_ big. It's around 100k
slocs, which rougly the size of postfix or mutt.

  I for one do believe that bad programmers will write bad code
whichever language they use, and that what is wrong is to end with code
bases in one monolithic thing like in [1]. OO design patterns and other
craps of the like helps you generate insane amount of codelines, and
hide all the simplicity under huge loads of proxies and interfaces. In
C, when your API suck, you usually need to refactor it under the
pressure of the huge amount of code you have to repeat each time you use
the API. in an OO language, you add a new class for that purpose. In C++
it's even worse, you just hide it in a copy constructor, or an operator
so that when you write:

  Foo a = b;

  Instead of a simple memcpy, you end up with an horrible pile of crap
to be started and run behind your back. C++ is very good at hiding bad
code. At least in C, when someone writes bad code, it's obvious to any
reader. C has many many quirks, I don't discuss that, but OO programming
solves none of them, and the problems OO addresses are not the one that
may interfere in the git development. I mean, the two really interesting
things in OO (that haven't a tremendous cost in return) are member
overloading and inheritance. I see very few places where git would
benefit from that, and believe me, I looked at git's code with
refactoring in mind and only that.

  Can we go back to git now ?



  [0] http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule

  [1] http://www.ohloh.net/projects/29/analyses/latest

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [OT] Re: C++ *for Git*

[Marco Costalba]

On 9/23/07, Pierre Habouzit <madcoder@debian.org> wrote:
> >
> > Object oriented languages creates black boxes: that's the reason why
> > object oriented exsists and also the reason why Linus hates it ;-)
>
>   This is just nonsense. This has been proved, though I can't find the
> paper about this anymore, than modules (or packages whichever name you
> give them) plus abstract types are as good as OO languages at creating
> black boxes. I mean it has been proved that it gives the exact same
> amount of expressiveness. So please stop with this myth. And don't speak
> for people, I would be very surprised that Linus would dislike "black
> boxes". Abstractions are good, when used wisely, and I would be much
> surprised to see Linus pretend otherwise.
>

>From a Linus recent thread:

> - inefficient abstracted programming models where two years down the road
>  you notice that some abstraction wasn't very efficient, but now all
>   your code depends on all the nice object models around it, and you
>   cannot fix it without rewriting your app.
>
>In other words, the only way to do good, efficient, and system-level and
>portable C++ ends up to limit yourself to all the things that are
>basically available in C. And limiting your project to C means that people
>don't screw that up, and also means that you get a lot of programmers that
>do actually understand low-level issues and don't screw things up with any
>idiotic "object model" crap.

Perhaps I have misunderstood, but the idea I got is that for Linus OO
brings in more problems than what it tries to fix.


>   The real problem with big applications, is not that they are written
> with C, C++, D, APL or Perl, but that they are big.

I have said exactly this, I don't understand where's your point in
repeating the same concept.

> C has many many quirks, I don't discuss that, but OO programming
> solves none of them, and the problems OO addresses are not the one that
> may interfere in the git development.

I really don't get how you made up your mind I'm advocating OO ? The
only comment I made on OO until now was to highlight one of its
downsides.


> I mean, the two really interesting
> things in OO (that haven't a tremendous cost in return) are member
> overloading and inheritance.

You have listed two things that are a world apart one from each other.

member overload is just syntactic sugar for name mangling, while
inheritance and the _strictly_ related virtual member functions (AKA
polymorphism) is what opens the gates to all the stuff you have deeply
blamed in your post.

>I see very few places where git would
> benefit from that

Instead I see none. But probably you have looked at git code better then me.


>   Can we go back to git now ?
>

You are not forced to follow this thread if this bores you.

Thanks
Marco

Re: [OT] Re: C++ *for Git*

[Nicolas Pitre]

On Sun, 23 Sep 2007, Marco Costalba wrote:

> From a Linus recent thread:
> 
> > - inefficient abstracted programming models where two years down the road
> >  you notice that some abstraction wasn't very efficient, but now all
> >   your code depends on all the nice object models around it, and you
> >   cannot fix it without rewriting your app.
> >
> >In other words, the only way to do good, efficient, and system-level and
> >portable C++ ends up to limit yourself to all the things that are
> >basically available in C. And limiting your project to C means that people
> >don't screw that up, and also means that you get a lot of programmers that
> >do actually understand low-level issues and don't screw things up with any
> >idiotic "object model" crap.
> 
> Perhaps I have misunderstood, but the idea I got is that for Linus OO
> brings in more problems than what it tries to fix.

You must have misunderstood.  Why?  The linux kernel is itself very 
heavily "object oriented" already, even if it is written in C.  You 
don't need C++ for that.


Nicolas

Re: [OT] Re: C++ *for Git*

[David Kastrup]

"Marco Costalba" <mcostalba@gmail.com> writes:

> On 9/23/07, Pierre Habouzit <madcoder@debian.org> wrote:
>> >
>> > Object oriented languages creates black boxes: that's the reason
>> > why object oriented exsists and also the reason why Linus hates
>> > it ;-)

>> So please stop with this myth. And don't speak for people, I would
>> be very surprised that Linus would dislike "black
>> boxes". Abstractions are good, when used wisely, and I would be
>> much surprised to see Linus pretend otherwise.
>
> From a Linus recent thread:
>
>>In other words, the only way to do good, efficient, and system-level
>>and portable C++ ends up to limit yourself to all the things that
>>are basically available in C. And limiting your project to C means
>>that people don't screw that up, and also means that you get a lot
>>of programmers that do actually understand low-level issues and
>>don't screw things up with any idiotic "object model" crap.
>
> Perhaps I have misunderstood, but the idea I got is that for Linus
> OO brings in more problems than what it tries to fix.

I read that as OO bringing in more programmers capable of creating
problems than those capable of fixing them.

It is not the fault of OO in itself, but it is the bottom line that
counts: if it draws the wrong audience for the wrong reasons, it
better had great benefits to offset that.  Not quite unsimilar with
communism: the idea is great in principle, but the idea has no
built-in self-check.  Capitalism, in contrast, is a distasteful idea
at its heart, but it is rooted soundly in individual egoism.  Which
does not make it any less distasteful, but at least it tends to work.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [OT] Re: C++ *for Git*

[Marco Costalba]

On 9/23/07, Nicolas Pitre <nico@cam.org> wrote:
> You must have misunderstood.  Why?  The linux kernel is itself very
> heavily "object oriented" already, even if it is written in C.  You
> don't need C++ for that.
>

Yes it's true, you don't need it. Object oriented in C is achived
using function pointers.

In C you fill a struct of function pointers with proper values instead
of inherithing from an (abstract) base class as you would do in C++.
The results are more or less the same modulo some type safe.


Marco

Re: [OT] Re: C++ *for Git*

[Marco Costalba]

On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> >
> > Perhaps I have misunderstood, but the idea I got is that for Linus
> > OO brings in more problems than what it tries to fix.
>
> I read that as OO bringing in more programmers capable of creating
> problems than those capable of fixing them.
>
> It is not the fault of OO in itself, but it is the bottom line that
> counts: if it draws the wrong audience for the wrong reasons, it
> better had great benefits to offset that.

Perhaps I'm wrong, but I think one of the advantages of big projects
written in C vs comparable size projects in an OO  language (read C++)
it's exactly the opposite.

Because C lets a random developer to understand, quickly enough, and
do little local modifications also to big projects like Linux, it
attracts a lot of developers that have the possibility to start with
some janitorial work or some little patch without incurring in the
very steep learning curve you have understanding the object hierarchy
of a big C++ code base, an almost mandatory step, before to start
hacking as example in Firefox.

This is, IMHO, a big advantage: fresh meat is always welcomed, the
damage it can potentially create is more then compensated by the long
term benefit of a large and live developer community.


Marco

Re: [OT] Re: C++ *for Git*

[Linus Torvalds]

On Sun, 23 Sep 2007, Marco Costalba wrote:
> 
> Perhaps I have misunderstood, but the idea I got is that for Linus OO
> brings in more problems than what it tries to fix.

Not really.

I'm a huge believer in OO, and if you look at the kernel, for example, 
there's just a ton of interfaces that are basically object-oriented. All 
the VFS is, for example, is really just a object model around low-level 
filesystems. The same largely goes for virtual memory mappings, or indeed 
for things like the interrupt or DMA controller abstractions, the network 
packet filtering etc etc etc.

But I'm also a huge believer in *explicit*syntax*. People should see what 
is going on, and the abstraction should be explicit.

[ Honesty in advertising: we do end up often hiding *some* abstractions. 

  Sometimes it happens for historical reasons: if the code didn't have any 
  indirection/abstraction initially, we may end up using macros and inline 
  functions to hide the fact that it now is actually going through an 
  indirect object-oriented interface.

  And sometimes it happens because the thing is *so* common or *so* 
  obvious that making the indirection explicit is just syntactically too 
  intrusive. ]

And we do all of this in C. There is no need to go to C++ for any "object 
oriented principles". It really is just a syntactic issue, and in many 
ways the syntax "advantage" of C++ is actually a big *disadvantage*.

I'm one of those people who think that interactions should be *locally* 
visible. If you need to understand the "big picture" in order to 
understand what a line of code does, that's usually a bad idea. So 
syntactic tricks that hide what is actually going on are bad.

You can see some of my opinions on C in the extensions I did for sparse. I 
think the C type system is a bit too sloppy, and much of what sparse does 
is more totally static type checking. Things like being able to decorate 
types statically, and having to explicitly carry those decorations around 
is a *good* thing - because it does the opposite of hiding. Having to say

	struct somestruct __user *p

to explicitly say that it's a pointer to user space - and then having 
every function that takes that pointer have to have that "__user" there is 
a VERY GOOD THING.

That's very different from having "accessor functions" and making "p" an 
abstract type, and having the compiler automatically generate the right 
kind of access. That kind of stuff is TOTAL CRAP, and it's an example of 
how C++ has a horrible design, where you carry around _implicit_ knowledge 
instead of making the knowledge explicit and visible locally too.

(And no, C doesn't do it very well. The C type system makes it too hard to 
add explicit markers that get statically checked, and you generally have 
to do it by making the code unreadable by turning things into special 
structures, one for each use, or something like that).

The same goes for things like memory allocation. Memory allocation issues 
are often some of the *biggest* performance issues, and that means that 
they have to be explicit. I'm actually a big fan of GC, but most languages 
that implement GC do it exactly the wrong way in my opinion: they make it 
a fundamental thing that covers everything, and it all happens implicitly, 
instead of making it explicit.

I don't know how many people have noticed that git internally actually 
does do some garbage collection. It's just that we call it "caches", and 
we do it explicitly. I'd love to have a language that helps me with that, 
but I would *hate* to have a language that does it for everything. As it 
is, we *could* do garbage collection much more, but we don't, just because 
it's a bit too painful.

In practice, it means that I'm considering writing some helper routines in 
C, which actually would do exactly what I want them to do: make the 
(reasonably few) data structures that want to have a dynamic cache use 
that dynamic cache explicitly, the way we now do for delta caching etc.

There are a few features of C++ that I really really like. For example, I 
think the C preprocessor is absolutely horrid, and a preprocessor that is 
built into the language - and integrates with the syntax - would be 
wonderful. And while C++ doesn't improve on that, at least templates are 
an example of something like that. Not perfect, but that's the kind of 
feature that C really would like.

In the kernel, we (ab-)use the C preprocessor a lot for things like that. 
Some of our macros are really disgusting. I'm not proud, but it works 
well, and together with gcc extensions like "__typeof__" and thigns like 
"__builtin_constant_p()" you can do some rather powerful things.

But other parts of C++ are just nasty. The whole OO layer seems designed 
to do a lot of things implicitly and in the wrong way. I also disagree 
with exception handling, and the "new" keyword kind of exemplifies a lot 
of what is wrong in C++.

So in short:

 - the one big feature that I think really makes a huge difference to 
   people, C++ does not have: garbage collection. Yes, there are GC 
   modules, but let's face it, you can do that equally well in C too, it's 
   just slightly different syntax.

 - the stuff C++ *does* have is usually nasty. Implicit initializers and 
   destructors and the magic lifetime rules of objects etc are all just a 
   piece of incredible bogosity. And that all comes from the OO stuff that 
   is totally worthless, because it's really just syntactic fluff that can 
   be done easily in C.

 - the C preprocessor really is horrible, and every single language beats 
   C handily in this area. Except for C++, which didn't fix anything at 
   all in that area.

   Even assemblers have macro languages that allow conditionals, 
   repetition, nesting, etc etc.  C and C++? Not so much. (Some languages 
   don't need it, because the language itself is dynamic and you can do 
   everything from within the language - ie you just evaluate an 
   expression that you built up dynamically as in LISP etc).

   (And don't tell me about m4. It's a better preprocessor, but it's not 
   syntactically integrated, and it's too complex, imho)

There are other problems in C. The implicit type conversions should at 
least have some way to be disabled on a type-for-type basis.

		Linus

Re: [OT] Re: C++ *for Git*

[Paul Franz]

To me the methods that an OO class defines is the same thing as an API.  
And you can screw up an API whether it is C++ or C. Both give you the 
same opportunity to screw up the model and create code that needs to be 
re-written.

Paul Franz

David Kastrup wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
>   
>> On 9/23/07, Pierre Habouzit <madcoder@debian.org> wrote:
>>     
>>>> Object oriented languages creates black boxes: that's the reason
>>>> why object oriented exsists and also the reason why Linus hates
>>>> it ;-)
>>>>         
>
>   
>>> So please stop with this myth. And don't speak for people, I would
>>> be very surprised that Linus would dislike "black
>>> boxes". Abstractions are good, when used wisely, and I would be
>>> much surprised to see Linus pretend otherwise.
>>>       
>> From a Linus recent thread:
>>
>>     
>>> In other words, the only way to do good, efficient, and system-level
>>> and portable C++ ends up to limit yourself to all the things that
>>> are basically available in C. And limiting your project to C means
>>> that people don't screw that up, and also means that you get a lot
>>> of programmers that do actually understand low-level issues and
>>> don't screw things up with any idiotic "object model" crap.
>>>       
>> Perhaps I have misunderstood, but the idea I got is that for Linus
>> OO brings in more problems than what it tries to fix.
>>     
>
> I read that as OO bringing in more programmers capable of creating
> problems than those capable of fixing them.
>
> It is not the fault of OO in itself, but it is the bottom line that
> counts: if it draws the wrong audience for the wrong reasons, it
> better had great benefits to offset that.  Not quite unsimilar with
> communism: the idea is great in principle, but the idea has no
> built-in self-check.  Capitalism, in contrast, is a distasteful idea
> at its heart, but it is rooted soundly in individual egoism.  Which
> does not make it any less distasteful, but at least it tends to work.
>
>   

-- 

-------------------------------------------

There are seven sins in the world.
     Wealth without work.
     Pleasure without conscience.
     Knowledge without character.
     Commerce without morality.
     Science without humanity.
     Worship without sacrifice.
     Politics without principle.

   -- Mohandas Gandhi

-------------------------------------------

Re: [OT] Re: C++ *for Git*

[Marco Costalba]

On 9/23/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> There are a few features of C++ that I really really like. For example, I
> think the C preprocessor is absolutely horrid, and a preprocessor that is
> built into the language - and integrates with the syntax - would be
> wonderful. And while C++ doesn't improve on that, at least templates are
> an example of something like that. Not perfect, but that's the kind of
> feature that C really would like.
>

Yes, I really agree. IMO templates are the thing that more resembles
procedural programming, a common way of using them is to split data
structures (containers) from functions that operates on them
(algorithms). I find them very similar to the struct + functions
classical approach of C.

And BTW

template <typename T>

is the thing in C++ that more remembers me of opaque pointers and
their use in C, the difference is that the first is fully type
checked.

Marco

Re: [OT] Re: C++ *for Git*

[David Kastrup]

"Marco Costalba" <mcostalba@gmail.com> writes:

> On 9/23/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>> There are a few features of C++ that I really really like. For example, I
>> think the C preprocessor is absolutely horrid, and a preprocessor that is
>> built into the language - and integrates with the syntax - would be
>> wonderful. And while C++ doesn't improve on that, at least templates are
>> an example of something like that. Not perfect, but that's the kind of
>> feature that C really would like.
>>
>
> Yes, I really agree. IMO templates are the thing that more resembles
> procedural programming, a common way of using them is to split data
> structures (containers) from functions that operates on them
> (algorithms). I find them very similar to the struct + functions
> classical approach of C.
>
> And BTW
>
> template <typename T>
>
> is the thing in C++ that more remembers me of opaque pointers and
> their use in C, the difference is that the first is fully type
> checked.

Not really.  The difference is that the first generates new (and
optimized) code for every type which is something you can only do
using macros in C.  Class programming is similar to opaque pointers
(in particular concerning the generated code) but templates are really
more like macros, as their instantiation generates specialized code,
not at all like the handling of opaque pointers.

While I tend to agree that templates are probably the one thing
actually worth having, it was stupid to lift the restrictions syntax
along with the concept of generics from the Ada shop.  Borrowing
syntax along with features is such a Perlesque approach.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [OT] Re: C++ *for Git*

[Marco Costalba]

On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > On 9/23/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >>
> >> There are a few features of C++ that I really really like. For example, I
> >> think the C preprocessor is absolutely horrid, and a preprocessor that is
> >> built into the language - and integrates with the syntax - would be
> >> wonderful. And while C++ doesn't improve on that, at least templates are
> >> an example of something like that. Not perfect, but that's the kind of
> >> feature that C really would like.
> >>
> >
> > Yes, I really agree. IMO templates are the thing that more resembles
> > procedural programming, a common way of using them is to split data
> > structures (containers) from functions that operates on them
> > (algorithms). I find them very similar to the struct + functions
> > classical approach of C.
> >
> > And BTW
> >
> > template <typename T>
> >
> > is the thing in C++ that more remembers me of opaque pointers and
> > their use in C, the difference is that the first is fully type
> > checked.
>
> Not really.  The difference is that the first generates new (and
> optimized) code for every type which is something you can only do
> using macros in C.  Class programming is similar to opaque pointers
> (in particular concerning the generated code) but templates are really
> more like macros, as their instantiation generates specialized code,
> not at all like the handling of opaque pointers.
>

Probably if I had written like this was more clear:

template <typename T>  int some_function(T* p);

And regarding 'new' code for each type I would like to remember that
template instantations of different types can be removed by
compiler/linker when the instantations are the same (i.e. produce the
same binary instuctions), this could happen for function templates
that handle pointers, as example.

Marco

Re: [OT] Re: C++ *for Git*

[David Kastrup]

"Marco Costalba" <mcostalba@gmail.com> writes:

> On 9/23/07, David Kastrup <dak@gnu.org> wrote:
>> "Marco Costalba" <mcostalba@gmail.com> writes:
>>
>> > And BTW
>> >
>> > template <typename T>
>> >
>> > is the thing in C++ that more remembers me of opaque pointers and
>> > their use in C, the difference is that the first is fully type
>> > checked.
>>
>> Not really.  The difference is that the first generates new (and
>> optimized) code for every type which is something you can only do
>> using macros in C.  Class programming is similar to opaque pointers
>> (in particular concerning the generated code) but templates are really
>> more like macros, as their instantiation generates specialized code,
>> not at all like the handling of opaque pointers.
>
> Probably if I had written like this was more clear:
>
> template <typename T>  int some_function(T* p);

Huh?  How is this supposed to support your point?  There is nothing
like an opaque pointer involved here.  The point of opaque pointers is
that they can stand for a variety of types, whereas each template
instantiation can only substitute a single type.

> And regarding 'new' code for each type I would like to remember that
> template instantations of different types can be removed by
> compiler/linker when the instantations are the same (i.e. produce
> the same binary instuctions), this could happen for function
> templates that handle pointers, as example.

Hardly.  The type constraints/virtual function tables of any called
function depending on T will be different.  And if indeed nothing
depends on T at all inside of the template, it is pointless not to
declare it as void *p in the first place: the type of *p will never be
used then.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [OT] Re: C++ *for Git*

[Dmitry Potapov]

On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:
> 
> And we do all of this in C. There is no need to go to C++ for any "object 
> oriented principles". It really is just a syntactic issue, and in many 
> ways the syntax "advantage" of C++ is actually a big *disadvantage*.

Certainly, in this respect, C++ provides only syntactic sugar over C,
and there is a real danger of abuse, which leads to horrible programs.
This is especially likely to happen to those who think that the evil
of C++ is lying in templates, exceptions, or something other feature
of C++, because they start to abuse the only "good" feature they know
and inevitably end up with horrible code.

> 	struct somestruct __user *p
> 
> to explicitly say that it's a pointer to user space - and then having 
> every function that takes that pointer have to have that "__user" there is 
> a VERY GOOD THING.

user_ptr<somestruct> p;

> 
> That's very different from having "accessor functions" and making "p" an 
> abstract type, and having the compiler automatically generate the right 
> kind of access. That kind of stuff is TOTAL CRAP, and it's an example of 
> how C++ has a horrible design, where you carry around _implicit_ knowledge 
> instead of making the knowledge explicit and visible locally too.

Whether it will convert to something or not depends entirely on the
definition of user_ptr. So, it can be as explicit as you wish, or
completely implicit. C++ does not impose anything on you here. So,
the problem is not in C++ but in the crappy mentality -- "let's hide
everything behind 'higher' abstraction" or "let's hide this thing too
because we can". Yes, these people end up with total crap. And yes,
those people tend to prefer C++ over C, just because C++ is better at
hiding. But I don't think that C++ forces anyone to do that...

> The same goes for things like memory allocation. Memory allocation issues 
> are often some of the *biggest* performance issues, and that means that 
> they have to be explicit. I'm actually a big fan of GC, but most languages 
> that implement GC do it exactly the wrong way in my opinion: they make it 
> a fundamental thing that covers everything, and it all happens implicitly, 
> instead of making it explicit.

Stroustrup was not a big fan of GC, so he made the language to be useful
in absence of any GC, and it allows to manage memory and some other
resources though not automatically, but with much less efforts than in C.

Maybe, your idea of more explicit GC is better than what C++ offers. It
is difficult for me to say without trying, but as you said most languages
implement GC in the wrong way in your opinion, so I don't think I will
have a chance to try any language that does it right. As to "caches" in
Git, it works really nicely, but Git is not a programming language.

> But other parts of C++ are just nasty. The whole OO layer seems designed 
> to do a lot of things implicitly and in the wrong way.

It could do a lot of things implicitly, but it does not force you,
except calling destructor when the control leaves the scope of
declaration, but I hardly can consider it as implicit.

> I also disagree with exception handling,

Perhaps, you look at it from the kernel point of view. Otherwise, I
would like to hear your arguments against it. In fact, I don't think
it is possible to write generic algorithms without exceptions. Of
course, if you write a program that can print an error to stderr and
exit, there is no much need for them. So, it may depend on the task.

>  - the stuff C++ *does* have is usually nasty. Implicit initializers and 
>    destructors and the magic lifetime rules of objects etc

I am not sure what is wrong with initializers and destructors in C++,
but certainly there is no magic lifetime rules in C++, as it is fully
determined by the scope. In fact, other high level languages that use
GC have much more unpredictable lifetime rules for objects.


Dmitry Potapov

PS Please, do not confuse me with Dmitry Kakurin, who started this
thread, because my position is opposite to his. Though I like C++,
I fully understand most of your consideration in choosing C for Git.

Re: [OT] Re: C++ *for Git*

[David Kastrup]

Dmitry Potapov <dpotapov@nbs-eng.ru> writes:

> On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:
>
>>  - the stuff C++ *does* have is usually nasty. Implicit
>>  initializers and destructors and the magic lifetime rules of
>>  objects etc
>
> I am not sure what is wrong with initializers and destructors in
> C++, but certainly there is no magic lifetime rules in C++, as it is
> fully determined by the scope.

It has been some time since I last looked, but the lifetime of objects
constructed in return statements was a moving target through several
standards.  The last standard I bothered looking at had the object
survive until the statement with the function call expression ended:
quite a strange synchronization point with regard to language design.

> In fact, other high level languages that use GC have much more
> unpredictable lifetime rules for objects.

Mostly objects are alive as long as you can refer to them.  Not really
complicated.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [OT] Re: C++ *for Git*

[Reece Dunn]

On 23/09/2007, Dmitry Potapov <dpotapov@nbs-eng.ru> wrote:
> On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:
> > The same goes for things like memory allocation. Memory allocation issues
> > are often some of the *biggest* performance issues, and that means that
> > they have to be explicit. I'm actually a big fan of GC, but most languages
> > that implement GC do it exactly the wrong way in my opinion: they make it
> > a fundamental thing that covers everything, and it all happens implicitly,
> > instead of making it explicit.
>
> Stroustrup was not a big fan of GC, so he made the language to be useful
> in absence of any GC, and it allows to manage memory and some other
> resources though not automatically, but with much less efforts than in C.

The next version of C++ is going to have garbage collection that the
user can enable, disable or remain neutral about. However, this is
program-wide and has many traps that you could fall into.

> > But other parts of C++ are just nasty. The whole OO layer seems designed
> > to do a lot of things implicitly and in the wrong way.
>
> It could do a lot of things implicitly, but it does not force you,
> except calling destructor when the control leaves the scope of
> declaration, but I hardly can consider it as implicit.

You have to add the explicit keyword to any constructor to prevent an
automatic conversion. Therefore, the constructors that are called are
implicit by default. If you have a conversion operator, this is always
implicitly called when there is a match by the compiler.

I agree with Linus here, there are a lot of things that happen implicily.

> > I also disagree with exception handling,
>
> Perhaps, you look at it from the kernel point of view. Otherwise, I
> would like to hear your arguments against it. In fact, I don't think
> it is possible to write generic algorithms without exceptions. Of
> course, if you write a program that can print an error to stderr and
> exit, there is no much need for them. So, it may depend on the task.

There are many issues with exceptions.

Firstly, there is throwing an exception from a destructor, which is
warned against in any good C++ book, but does not prevent you from
doing so (even if it is inadvertantly)! If the program is in the
process of handling an exception, the program is toast.

More importantly though, is the loss of contextual information.
Consider throwing the same exception on all calls to API that return
the same error code type. The code that processes this may be anywhere
in the system. This makes it impossible to do any sensible recovery
(if possible), or error reporting. The exception can be rethrown or
translated to another exception, making it impossible to find the
originator of the exception. This makes it harder, if not impossible,
to track the exception back to the source when you are at a breakpoint
in the exception handler.

Then there is dealing with caller boundaries. That is, when a callback
or interface function in the application will return to the operating
system (e.g. when handling a draw request from X11), or another
language such as Python. Also, because different compiler vendors and
versions handle exceptions differently, if you want to support
different compilers (and you have resolved the name mangling
incompatibilities), you need to handle exceptions correctly in these
cases, or risk having major problems that would be impossible to
trace. Not to mention that anywhere new, dynamic_cast and other
language features are used may throw exceptions.

- Reece

Re: [OT] Re: C++ *for Git*

[Robin Rosenberg]

söndag 23 september 2007 skrev David Kastrup:
> Dmitry Potapov <dpotapov@nbs-eng.ru> writes:
> 
> > On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:
> >
> >>  - the stuff C++ *does* have is usually nasty. Implicit
> >>  initializers and destructors and the magic lifetime rules of
> >>  objects etc
> >
> > I am not sure what is wrong with initializers and destructors in
> > C++, but certainly there is no magic lifetime rules in C++, as it is
> > fully determined by the scope.
> 
> It has been some time since I last looked, but the lifetime of objects
> constructed in return statements was a moving target through several
> standards.  The last standard I bothered looking at had the object
> survive until the statement with the function call expression ended:
> quite a strange synchronization point with regard to language design.

The idea is that you should be able to use temporaries by reference and
trust them to be valid over function calls end even function returns, so 
you can write efficient matrix math libraries that do not copy data much while
retaining value semantics with overloaded operators. It is a purely practical
matter, what actually works and is efficient, not dogmatic language "design".

Earlier versions failed to make up something useful here.

> > In fact, other high level languages that use GC have much more
> > unpredictable lifetime rules for objects.
> 
> Mostly objects are alive as long as you can refer to them.  Not really
> complicated.

What could be simpler, besides all static variables.

-- robin

Re: [OT] Re: C++ *for Git*

[Dmitry Potapov]

On Sun, Sep 23, 2007 at 11:25:01PM +0100, Reece Dunn wrote:
> The next version of C++ is going to have garbage collection that the
> user can enable, disable or remain neutral about. However, this is
> program-wide and has many traps that you could fall into.

Sure. C++ has not been design to be garbage collection friendly, in
fact, even now, you can use some GC with C++, but it can be painful.
I don't think that the new standard will change much in this respect.

> > > But other parts of C++ are just nasty. The whole OO layer seems designed
> > > to do a lot of things implicitly and in the wrong way.
> >
> > It could do a lot of things implicitly, but it does not force you,
> > except calling destructor when the control leaves the scope of
> > declaration, but I hardly can consider it as implicit.
> 
> You have to add the explicit keyword to any constructor to prevent an
> automatic conversion. Therefore, the constructors that are called are
> implicit by default.

Yes, I would prefer if it were opposite by default, but it was an
initial mistake in design, and you cannot change it without breaking
a lot of people code.

> If you have a conversion operator, this is always
> implicitly called when there is a match by the compiler.

Conversation operator should be written only if you do want an implicit
conversation, and that may be useful sometimes, albeit very rarely.

> 
> I agree with Linus here, there are a lot of things that happen implicily.
> 
> > > I also disagree with exception handling,
> >
> > Perhaps, you look at it from the kernel point of view. Otherwise, I
> > would like to hear your arguments against it. In fact, I don't think
> > it is possible to write generic algorithms without exceptions. Of
> > course, if you write a program that can print an error to stderr and
> > exit, there is no much need for them. So, it may depend on the task.
> 
> There are many issues with exceptions.
> 
> Firstly, there is throwing an exception from a destructor, which is
> warned against in any good C++ book, but does not prevent you from
> doing so (even if it is inadvertantly)!

In general, the compiler does not have all information to know whether
a destructor can or cannot throw an exception, and even less it knows
about your real intentions. There are many ways to write something
that will not work. You can create an infinite recursion, but I don't
think it is a good argument against recursion.

> 
> More importantly though, is the loss of contextual information.

Do you think that an error code contains much more contextual
information?

> Consider throwing the same exception on all calls to API that return
> the same error code type. 

I did not mean that all error codes should be returned as an exception.
Exception in C++ is something that should not normally happen, like
failure to allocate memory. So, you usually do not want to handle
this situation immediate.

> The code that processes this may be anywhere
> in the system. This makes it impossible to do any sensible recovery
> (if possible), or error reporting. The exception can be rethrown or
> translated to another exception, making it impossible to find the
> originator of the exception. This makes it harder, if not impossible,
> to track the exception back to the source when you are at a breakpoint
> in the exception handler.

In gdb, you can catch all exception when thrown using "catch throw".
And again, I don't see how it is better when a program returns an
error code, especially if this error code is recoded couple times
in the process of returning. So the problem is not with exceptions,
but usually with bad design.

> Then there is dealing with caller boundaries. That is, when a callback
> or interface function in the application will return to the operating
> system (e.g. when handling a draw request from X11), or another
> language such as Python. Also, because different compiler vendors and
> versions handle exceptions differently, if you want to support
> different compilers (and you have resolved the name mangling
> incompatibilities), you need to handle exceptions correctly in these
> cases, or risk having major problems that would be impossible to
> trace.

You named some interoperability issues with C++ (and there are many
of them), but it is not an argument against exceptions per se.

> Not to mention that anywhere new, dynamic_cast and other
> language features are used may throw exceptions.

dynamic_cast throws an exception only for references, but not for
pointers, and there is a good reason for that -- references should
not be NULL; and if you want to avoid bad_alloc exception, you can
use "T* p = new (std::nothrow) T;" but it is rarely needed.


Dmitry Potapov