Inline variables are only available in C++17 and above

[johnDeSilencio]

The Problem

Rust code like this:

#[repr(C)]
pub struct Foo {
  foo: u32,
}

impl Foo {
  pub const SPECIAL_NUM: u32 = 153;
}

generates code like this:

struct Foo {
  uint32_t foo;
  static const uint32_t SPECIAL_NUM;
};
inline const int32_t Foo::SPECIAL_NUM = 153;

However, inline variables are only available in C++17 and above: Godbolt Link. At my company in particular, we're stuck with C++11 for the foreseeable future (😭)

Solution

Make generating associated constants with the inline keyword configurable.

In this PR, I add the new [const] config setting allow_inline which defaults to true. I also added a test when allow_inline is set to false.

[emilio]

Hmm, but I don't think this works tho, right? If they're not inline, as soon as you include this header from different translation units stuff blows up due to duplicate symbols, doesn't it?

[johnDeSilencio]

Hmm, but I don't think this works tho, right? If they're not inline, as soon as you include this header from different translation units stuff blows up due to duplicate symbols, doesn't it?

Oh that's a great catch! Yeah, I didn't think about the case of multiple compilation units. From what I can tell, it looks to be dependent on the constant's type. For integers, it looks like g++ on my machine doesn't have any problems with const uint32_t FOO_BAR = 153; being defined in a header file. I only get into trouble if I try to define a pointer in a header file, such as const char* OTHER_FOO_BAR = "cbindgen is awesome!":

foo1.h

#pragma once

// const char* THIS_IS_MY_SUPER_SPECIAL_SYMBOL = "cbindgen is awesome!";
// ^^^ this won't compile because the compiler can't inline the pointer (I think)
//     like it can inline an integer constant
const int THIS_IS_MY_SUPER_SPECIAL_SYMBOL = 153;

void print_function();

foo1.cpp

#include <iostream>
#include "foo1.h"

void print_function() {
    std::cout << "[*] print_function() [*]" << std::endl;
    std::cout << THIS_IS_MY_SUPER_SPECIAL_SYMBOL << std::endl;
}

foo2.h

#pragma once
#include "foo1.h"

void another_print_function();

foo2.cpp

#include <iostream>
#include "foo1.h"

void another_print_function() {
    std::cout << "[*] another_print_function() [*]" << std::endl;
    std::cout << THIS_IS_MY_SUPER_SPECIAL_SYMBOL << std::endl;
}

main.cpp

#include <iostream>
#include "foo1.h"
#include "foo2.h"

int main() {
    std::cout << THIS_IS_MY_SUPER_SPECIAL_SYMBOL << std::endl;
    print_function();
    another_print_function();
    return 0;
}

vs.

[johnDeSilencio]

The question is, does cbindgen ever produce constants that are pointers like const char* ...? If not, then I think removing the inline keyword would be okay for those constants? And again, this is a flag that defaults to true. I want to see this new config flag implemented to produce associated constants that can be compiled on older C++ versions, like my company (sadly still) uses

[emilio]

But without inline you'll get linker errors as soon as you include this header from two translation units right? I think requiring C++17 for allow_static_const is reasonable in 2026.

[emilio]

Ah indeed this had been pointed out above, sorry, I jumped directly to the code.