with the u++ moving to c++17,

code like this (Core/Vcont.h line 13)

	void Malloc(size_t size) {
		if(std::is_trivially_destructible<T>::value)
			ptr = (T *)MemoryAlloc(size * sizeof(T));
		else {
			void *p = MemoryAlloc(size * sizeof(T) + 16);
			*(size_t *)p = size;
			ptr = (T *)((byte *)p + 16);
		}
	}

can benefit from constexpr-if compile time trimming to produce more compact and faster binary (theoretically).

How? I have noticed that some people tend to constexpr to everything, but I fail to see a reason. If that is supposed to perform the test only in compile time, then 30 years old compiler will do that anyway. But I might be missing something perhaps?

template <class T>
void memcpy_t(void *t, const T *s, size_t count)
{
	if((sizeof(T) & 15) == 0)
		memcpy128(t, s, count * (sizeof(T) >> 4));
	else
	if((sizeof(T) & 7) == 0)
		memcpy64(t, s, count * (sizeof(T) >> 3));
	else
	if((sizeof(T) & 3) == 0)
		memcpy32(t, s, count * (sizeof(T) >> 2));
	else
	if((sizeof(T) & 1) == 0)
		memcpy16(t, s, count * (sizeof(T) >> 1));
	else
		memcpy8(t, s, count * sizeof(T));
}

For optimization purposes, modern compilers will generally treat non-constexpr if-statements that have constexpr conditionals as if they were constexpr-if-statements. However, they are not required to do so.

A compiler that encounters a non-constexpr if-statement with a constexpr conditional may issue a warning advising you to use if constexpr instead. This will ensure that compile-time evaluation will occur (even if optimizations are disabled).

I take back the hint about code size and efficiency difference. But personally I would use if constexpr () in this and similar cases.

Quote:

For optimization purposes, modern compilers will generally treat non-constexpr if-statements that have constexpr conditionals as if they were constexpr-if-statements. However, they are not required to do so.

A compiler that encounters a non-constexpr if-statement with a constexpr conditional may issue a warning advising you to use if constexpr instead. This will ensure that compile-time evaluation will occur (even if optimizations are disabled).

A compiler that encounters a non-constexpr if-statement with a constexpr conditional may issue a warning advising you to use if constexpr instead. This will ensure that compile-time evaluation will occur (even if optimizations are disabled).

Lance wrote on Mon, 21 October 2024 13:01

A compiler that encounters a non-constexpr if-statement with a constexpr conditional may issue a warning advising you to use if constexpr instead. This will ensure that compile-time evaluation will occur (even if optimizations are disabled).

Well, thinking about it, I guess actually the real benefit for me would be something else: compiler issues an error if the expression you marked constexpr is not...

union Flags{
	int32 dummy;
	struct{
		byte	borderLeft  :3;
		byte	borderRight :3;
		byte	borderTop   :3;
		byte	borderBottom:3;
		byte	halign      :2;
		byte	valign      :2; //16th bit
	
		bool	faceNotNull     :1;
		bool	boldNotNull     :1;
		bool	heightNotNull   :1;
		bool	widthNotNull    :1;
		bool	underlineNotNull:1;
		bool	italicNotNull   :1;
		bool	strikeoutNotNull:1; //23rd bit
	};
	
	constexpr Flags() : dummy(0){ static_assert(sizeof(*this)==sizeof(dummy)); }
	
	
	static constexpr int32 FontMask()
	{
		Flags f;
		f.faceNotNull = true;
		f.boldNotNull = true;
		f.heightNotNull = true;
		f.widthNotNull = true;
		f.underlineNotNull = true;
		f.italicNotNull = true;
		f.strikeoutNotNull = true;
		return f.dummy;
	}
};