Build-C-as-C++ Patches

[AE1020]

As per C++ core guidelines CPL.2, it's best for C code to be buildable with a C++ compiler. (my codebase using CRoaring has to build as both C99+ and C++11+). Because of this I had contributed some of the necessary changes to CRoaring to achieve that some years ago.

At that time, I also slipped in some "experimental" ideas involving how container_t* could be a void* in C, but in C++ it could use the "empty base class optimization" with the container subclasses inheriting from it. This meant it would be type checked more strongly if built as C++...so that you got the benefit of typed inheritance...only allowing containers to be passed to container_t* vs arbitrary pointers.

It was the start of a good idea, but only the start (and the way I did it then was often more clutter than it provided benefit, as well as an ABI break with C-built code in some compilers in some circumstances). Those ideas have evolved into a vastly richer framework now... which may be applied to many problems. Including solving your memory allocation failures/propagation in a "Rust-like" way, by using the type system to annotate the return values of routines that can fail, and forcing compile-time errors when triage is not performed:

https://needful.metaeducation.com/

This new model removes the wacky C++ from CRoaring's codebase entirely; the "enhancements" are in a repository that only those who wish to build with instrumentation "install". It becomes a tool that you sideload in certain developer/CI builds--not part of CRoaring itself. (Your focus on "amalgamation" demonstrates you are interested in pragmatic packaging, and Needful is also very pragmatic: removing the clutter, while delivering the benefit.)

Which is good: e.g. in my fork I've eliminated of all the below kind of junk, while delivering the actual value that a "C++ enhanced build" was theoretically supposed to provide:

CRoaring/include/roaring/containers/container_defs.h

Lines 73 to 88 in d60ba3f

	#ifdef __cplusplus
	#define CAST(type, value) static_cast<type>(value)
	#define movable_CAST(type, value) movable_CAST_HELPER<type>(value)
	template <typename PPDerived, typename Base>
	PPDerived movable_CAST_HELPER(Base **ptr_to_ptr) {
	typedef typename std::remove_pointer<PPDerived>::type PDerived;
	typedef typename std::remove_pointer<PDerived>::type Derived;
	static_assert(std::is_base_of<Base, Derived>::value,
	"use movable_CAST() for container_t** => xxx_container_t**");
	return reinterpret_cast<Derived **>(ptr_to_ptr);
	}
	#else
	#define CAST(type, value) ((type)value)
	#define movable_CAST(type, value) ((type)value)
	#endif

CRoaring/include/roaring/containers/array.h

Lines 54 to 56 in d60ba3f

	#define CAST_array(c) CAST(array_container_t *, c) // safer downcast
	#define const_CAST_array(c) CAST(const array_container_t *, c)
	#define movable_CAST_array(c) movable_CAST(array_container_t **, c)

(etc.) This is all gone, replaced by a (via a single downcast operator), that's just #define downcast (void*) in the baseline C distribution (and minor magic in non-enhanced C++ builds)... but metaprogramming sorcery once you sideload the C++ enhanced files. It detects the target type implicitly without you having to say what it is and validates the inheritance relationship, it won't downcast const pointers to non-const, it won't cast double-pointers to single ones, it can compile-time restrict the allowed to and from casts, or runtime validate the bit patterns based on what you're casting to what, and so on and so forth...

---

But to get the ball rolling to show you what I mean, the atrophy in C++ builds has to be fixed first. Here are some (I hope) uncontroversial patches to start with.

[AE1020]

Upon review I notice this line is actually superfluous: including roaring.h (as opposed to roaring.hh) when building as __cplusplus) automatically includes the roaring::api namespace.

https://github.com/RoaringBitmap/CRoaring/blob/master/include/roaring/roaring.h#L1367-L1382

Perhaps that points to a potential separation of configreport.h vs. configreport.hh that does a similar trick; you don't need a using namespace roaring::misc; if you use the .h version?

[madscientist]

I don't think this comment belongs in the code. That's information for the Git commit message.