Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.

From: David Kastrup <dak@gnu.org>
Date: Sep 7, 2007, 08:08 UTC
Message-ID: <85bqce7v9j.fsf@lola.goethe.zz>
In-Reply-To: <200709070841.33057.andyparkins@gmail.com>

Andy Parkins <andyparkins@gmail.com> writes:

Show 14 quoted lines

> On Friday 2007 September 07, David Kastrup wrote:
>
> (Disclaimer: I'm certainly not joining the "C++ for git" chant; this reply is 
> merely to the statements made about C++ in David's message).
>
>> The problem with C++ is that every C++ developer has his own style,
>> and reuse is an illusion within that style.  Take a look at classes
>> implementing matrix arithmetic: there are as many around as the day is
>> long, and all of them are incompatible with one another.
>
> One could say the same about any API.  "Take a look at that C
> library libXYZ - it does exactly the same thing as libPQR but all
> the function calls and structures are different.  Conclusion: C is
> shit".  Obviously nonsense.

The difference is that you can pass structures from one library into another with tolerable efficiency. Because there are only basically 2 ways to lay out a two-dimensional array of floats.

Show 6 quoted lines

>> With regard to programming styles, C++ does not support multiple
>> inheritance.  For a single project grown from a single start, you
>> can
>
> Multiple inheritance is the spawn of the devil, but C++ _does_
> support it.

What about "With regard to programming styles" did you not understand? I was not talking about a technical feature at class level, but about code merging from multiple sources.

Show 5 quoted lines

> I would imagine the reason people often turn up wanting to rewrite
> Linux and git in C++ is because they are so object oriented in
> nature already and it's natural to think "wouldn't this be even
> better if I wrote it in an object oriented language"?  Maybe, maybe
> not, but why bother?

Maintainability and extensibility certainly are valid arguments for rewrites. But C++ does not really shine in that regard.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum