Re: coreutils & building w/C++

[Eric Blake]

On 02/03/2017 07:31 PM, L A Walsh wrote:
> I was wondering if there has ever been any consideration given
> to migrating the coreutils to C++, or at least making it such
> that it would build cleanly under either?

No, and there probably is no interest in it either.  Finding a
standards-compliant C++ compiler on as many platforms as we already have
a working C compiler is unlikely to happen, but would be a necessary
prerequisite.

> 
> It would seem, theoretically, that the resulting binaries should
> be ~roughly~ equivalent (though that may be a naive impression),
> but it would open the door for future inclusion or refactoring using
> C++ paradigms...which might result in easier maintenance, code reuse,
> type-checking and possibly better optimization in some cases.

Sorry, but I don't see any reason to rewrite in a different language.
Most of the core contributors are more familiar with C than with C++,
and so even if C++ were used, it would look a lot more like weird C than
it would like proper C++.  I also don't buy the argument that being more
object-oriented will help things; coreutils is not a large corpus of
multiple inter-related pieces, but a bunch of individual utilities that
do one thing.  Gcc and binutils are better projects for using C++, and
it shows, as both of them have already made progress towards that front.

> Maybe it's already been done and the result wasn't so great?  If so,
> how long ago was it done -- i.e. was it done with the current C++
> standard?

No, no one's ever been interested enough to even bother with it, because
it is probably not worth doing.

> 
> FWIW, I gave it a spin, and there seem to be several "__THROW"
> keywords.  I'm not familiar with those in the C-standard.

That's because they're not in the C standard.  That particular macro is
defined by glibc:

misc/sys/cdefs.h:#  define __THROW        __attribute__ ((__nothrow__
__LEAF))

as an optimization hint for gcc, and as a no-op for other compilers.

But this is all open source - if you are questioning what the code
means, rather than following the source and finding the answer yourself,
then you're already facing an uphill battle at trying to rewrite the source.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature