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
