Compile-Time Assertion

Compile-time assertion?

See static_assert (C++0x only); if on an older version, see Boost's StaticAssert.

C compiler asserts - how to implement?

A compile-time assert in pure standard C is possible, and a little bit of preprocessor trickery makes its usage look just as clean as the runtime usage of assert().

The key trick is to find a construct that can be evaluated at compile time and can cause an error for some values. One answer is the declaration of an array cannot have a negative size. Using a typedef prevents the allocation of space on success, and preserves the error on failure.

The error message itself will cryptically refer to declaration of a negative size (GCC says "size of array foo is negative"), so you should pick a name for the array type that hints that this error really is an assertion check.

A further issue to handle is that it is only possible to typedef a particular type name once in any compilation unit. So, the macro has to arrange for each usage to get a unique type name to declare.

My usual solution has been to require that the macro have two parameters. The first is the condition to assert is true, and the second is part of the type name declared behind the scenes. The answer by plinth hints at using token pasting and the __LINE__ predefined macro to form a unique name possibly without needing an extra argument.

Unfortunately, if the assertion check is in an included file, it can still collide with a check at the same line number in a second included file, or at that line number in the main source file. We could paper over that by using the macro __FILE__, but it is defined to be a string constant and there is no preprocessor trick that can turn a string constant back into part of an identifier name; not to mention that legal file names can contain characters that are not legal parts of an identifier.

So, I would propose the following code fragment:

/** A compile time assertion check.
 *
 *  Validate at compile time that the predicate is true without
 *  generating code. This can be used at any point in a source file
 *  where typedef is legal.
 *
 *  On success, compilation proceeds normally.
 *
 *  On failure, attempts to typedef an array type of negative size. The
 *  offending line will look like
 *      typedef assertion_failed_file_h_42[-1]
 *  where file is the content of the second parameter which should
 *  typically be related in some obvious way to the containing file
 *  name, 42 is the line number in the file on which the assertion
 *  appears, and -1 is the result of a calculation based on the
 *  predicate failing.
 *
 *  \param predicate The predicate to test. It must evaluate to
 *  something that can be coerced to a normal C boolean.
 *
 *  \param file A sequence of legal identifier characters that should
 *  uniquely identify the source file in which this condition appears.
 */
#define CASSERT(predicate, file) _impl_CASSERT_LINE(predicate,__LINE__,file)

#define _impl_PASTE(a,b) a##b
#define _impl_CASSERT_LINE(predicate, line, file) \
    typedef char _impl_PASTE(assertion_failed_##file##_,line)[2*!!(predicate)-1];

A typical usage might be something like:

#include "CAssert.h"
...
struct foo { 
    ...  /* 76 bytes of members */
};
CASSERT(sizeof(struct foo) == 76, demo_c);

In GCC, an assertion failure would look like:

$ gcc -c demo.c
demo.c:32: error: size of array `assertion_failed_demo_c_32' is negative
$

Compile time assert in Swift?

This has been accepted into Swift as of version 4.2, here is the Swift evolution for the proposal.

Compile Time Assertion is Unreliable?

This is called the most vexing parse. The following statement:

CompileTimeChecker<expr>(Type());

is equivalent to

CompileTimeChecker<expr> Type();

which declares a function named Type. You can work around the issue by using the = form of initialization:

CompileTimeChecker<expr> var = Type();

This way, it cannot be interpreted as a declaration. You can also use the {} initialization since C++11. On the other hand,

CompileTimeChecker<expr>(Type(0));

is an expression statement that creates an object as desired because Type(0) cannot possibly declare a function.

Since C++11, just use static_assert.

Compile-time assertion to determine if pointer is an array

For compile-time assertion on whether or not dst is an array,
I would use @Lundin solution (or _Static_assert) in case C11 is available.

Else, I would use the following:

#define BUILD_BUG_ON_NON_ARRAY_TYPE(e) (sizeof(struct { int:-!!(((void*)(e)) != ((void*) & (e))); }))

Which basically takes your compile-time evaluated expression ((void*)(dst)) == ((void*) & (dst)) but instead of using it in run time assert just use it in a compile-time assertion manner.

So, overall I would change your macro into:

#define STRCPY(dst, src) do { BUILD_BUG_ON_NON_ARRAY_TYPE(dst); \
                              strlcpy(dst, src, sizeof(dst)); } while (0)

Compile time assertion as part of an expression but without _Static_assert

Perl uses a bit-field instead of an array to define a static_assert fallback:

#define STATIC_ASSERT_2(COND, SUFFIX) \
    typedef struct { \
        unsigned int _static_assertion_failed_##SUFFIX : (COND) ? 1 : -1; \
    } _static_assertion_failed_##SUFFIX PERL_UNUSED_DECL
#define STATIC_ASSERT_1(COND, SUFFIX) STATIC_ASSERT_2(COND, SUFFIX)
#define STATIC_ASSERT_DECL(COND) STATIC_ASSERT_1(COND, __LINE__)

No compiler implements variable length bit-fields.

static_assert on indices know at compile time

I don't think it's possible obtain what do you want with a single function.

Even if you develop a constexpr function, I don't think your are able to detect when is executed run-time and when executed compile time and act in a different way.

But you can develop different functions.

By example, a template get<>(), where the template argument is the index, that can be used only with an index known at compile-time and that can perform a static_assert(), and an at(std::size_t), that can receive an index computed at run time with a run time check.

En passant:

1) I suggest, as usual in STL, the use of at() for a bound checked access and an operator[]() for a bound unchecked access

2) and I suggest the use of an unsigned index or you have to check that the index is >= 0.

The following is a working example

#include <iostream>
#include <stdexcept>

template <class T, std::size_t Dim>
class Foo
 {
   private:
      T _data[Dim];

   public:
      T const & operator[] (std::size_t idx) const
       { return _data[idx]; }

      template <std::size_t IDX>
      T const & get () const
       {
         static_assert(IDX < Dim, "out of range");

         return this->operator[](IDX);
       }

      T const & at (std::size_t idx) const
       {
         if ( idx >= Dim )
            throw std::range_error("out of range");

         return this->operator[](idx);
       }
 };

int main ()
 {
   Foo<float, 2U> foo;

   foo.get<0U>();
   foo.get<1U>();
   //foo.get<2U>(); // compiler error

   for ( auto i = 0U ; i < 5U ; ++i )
      foo.at(i); // run time exception when i > 1

   return 0;
 }

Assert sizeof(obj) at compile time and print the actual size if it doesn't match (c++98)

One way to "display" value at compile time is in the error:

template <std::size_t N> struct Debug; // No definition

template <> struct Debug<1234> {}; // Definition for "old" sizeof;

template struct Debug<sizeof(obj)>; // Issue error if definition is missing

Demo without error

Demo with error

Error message is similar to:

error: explicit instantiation of ‘struct Debug<5678ul>’ before definition of template

compile time assertion in c++

If you pass an expression to the macro that evaluates to false, the macro will give a typedef like follows:

typedef CompileAssert<false> PassRefPtr_should_never_be_assigned_to[false ? 1 : -1];

which is

typedef CompileAssert<false> PassRefPtr_should_never_be_assigned_to[-1];

So, since negative array lengths are not allowed, the compiler will emit an error for the typedef, containing "msg" as the array name.

Does GCC have a built-in compile time assert?

According to this page, gcc has had static_assert since 4.3.

---

Related Topics