Conditional compiling to be replaced by metaprogramming constructs?

[ilg-ul]

This is a follow up of #2052, but addressing a different topic.

With metaprogramming expected to replace the preprocessor, I'm trying to figure out how current C++ code would have to be changed to no longer use the preprocessor conditional compiling syntax.

Conditional compiling examples

For this I collected some snippets from my projects (comments removed to reduce clutter):

Conditional include header

#if defined(MICRO_OS_PLUS_INCLUDE_CONFIG_H)
#include <micro-os-plus/config.h>
#endif // MICRO_OS_PLUS_INCLUDE_CONFIG_H

Conditional compile function content

micro_os_plus_startup_initialize_hardware_early (void)
{
  SystemInit ();

#if defined(__ARM_ARCH_7M__) || defined(__ARM_ARCH_7EM__)
  SCB->VTOR = (uint32_t)(&__vectors_start);
  __DSB ();
#endif // defined(__ARM_ARCH_7M__) || defined(__ARM_ARCH_7EM__)

#if defined(MICRO_OS_PLUS_INCLUDE_STARTUP_INIT_FP) || defined(__ARM_FP)
  SCB->CPACR |= (0xF << 20);
  FPU->FPCCR |= FPU_FPCCR_ASPEN_Msk | FPU_FPCCR_LSPEN_Msk;
#endif // defined(MICRO_OS_PLUS_INCLUDE_STARTUP_INIT_FP) || defined (__ARM_FP)

#if defined(MICRO_OS_PLUS_DEBUG_SEMIHOSTING_FAULTS)
  SCB->SHCSR |= SCB_SHCSR_USGFAULTENA_Msk;
#endif
}

Conditional compile type content

  typedef enum
  {
    NonMaskableInt_IRQn = -14, 
#if defined(__ARM_ARCH_7M__) || defined(__ARM_ARCH_7EM__)
    MemoryManagement_IRQn = -12, 
    BusFault_IRQn = -11,
    UsageFault_IRQn = -10,
#endif
    SVCall_IRQn = -5,
#if defined(__ARM_ARCH_7M__) || defined(__ARM_ARCH_7EM__)
    DebugMonitor_IRQn = -4,
#endif
    PendSV_IRQn = -2,
    SysTick_IRQn = -1,
  } IRQn_Type;

Similar cases can be imagined for struct/class content.

Conditional compile array content

__attribute__ ((section(".interrupt_vectors"),used))
handler_ptr_t _interrupt_vectors[] =
  {
    // Cortex-M Core Handlers
    (handler_ptr_t) &__stack,          // MSP
    Reset_Handler,                     // The reset handler

    NMI_Handler,                       // The NMI handler
    HardFault_Handler,                 // The hard fault handler

#if defined(__ARM_ARCH_7M__) || defined(__ARM_ARCH_7EM__)
    MemManage_Handler,                 // The MPU fault handler
    BusFault_Handler,                  // The bus fault handler
    UsageFault_Handler,                // The usage fault handler
#else
    0,                                 // Reserved
    0,                                 // Reserved
    0,                                 // Reserved
#endif
    0,                                 // Reserved
    0,                                 // Reserved
    0,                                 // Reserved
    0,                                 // Reserved
    SVC_Handler,                       // SVCall handler
#if defined(__ARM_ARCH_7M__) || defined(__ARM_ARCH_7EM__)
    DebugMon_Handler,                  // Debug monitor handler
#else
    0,                                 // Reserved
#endif
    0,                                 // Reserved
    PendSV_Handler,                    // The PendSV handler
    SysTick_Handler,                   // The SysTick handler
};

Conditional function declarations

#if defined(__ARM_ARCH_7M__) || defined(__ARM_ARCH_7EM__)
  void
  dump_exception_stack (exception_stack_frame_s* frame, uint32_t cfsr,
                        uint32_t mmfar, uint32_t bfar, uint32_t lr);
#endif // defined(__ARM_ARCH_7M__) || defined(__ARM_ARCH_7EM__)

#if defined(__ARM_ARCH_6M__)
  void
  dump_exception_stack (exception_stack_frame_s* frame, uint32_t lr);
#endif // defined(__ARM_ARCH_6M__)

Similar cases can be imagined for function definitions.

Comments

Apart from the second example (function content) where I can imagine some if constexpr () statement (fictive syntax!) to replace the functionality of the preprocessor, for the other examples I have some difficulties to imagine how the metaprogramming syntax would look like. :-(

It seems like we'll need to accept some form of if constexpr () statements both outside any scope (at file scope) and in unusual places, like inside type definitions.

I don't imply that such a syntax is wrong or impossible, I just confess that I have no experience with other languages able to do this, and I would expect that designing such a metaprogramming syntax will require some inovative ideas and a lot of thinking.

If someone more knowledgeable has experience with such languages and can share it, or suggest possible syntax that will have similar functionality as the previous preprocessor examples, please contribute to this thread.

[mossaiby]

I completely agree. And if constexpr () in unusual places seems to me the same (or even worse than) pre-processor.

[ilg-ul]

The actual purpose of this thread was to identify possible alternate solutions to the preprocessor.

If we don't have a proper answer now it doesn't necessarily mean that such alternate solutions do not exist. I'd not give up that easily. ;-)

[ilg-ul]

Another good question is, without the preprocessor, what would be the most convenient data structure to pass the compile-time constants with the default definitions (similar to the preprocessor default macros) back to the compiled source?

With the preprocessor, it is very convenient to use #if defined(), and so different compilers can define only the macros of interest, leaving all other undefined; the alternate solution to use boolean values is less convenient, since all compilers have to implement all those unused values as false; thus a mechanism to check for the presence of those definitions is highly preferred.

[L4stR1t3s]

Some languages have a special type of constants that can be overruled on the command line.

Do you have examples of that?

[OlaFosheimGrostad]

Some languages have a special type of constants that can be overruled on the command line.

Do you have examples of that?

https://chapel-lang.org/docs/users-guide/base/configs.html

[L4stR1t3s]

https://chapel-lang.org/docs/users-guide/base/configs.html

This makes it a completely different feature than C++ preprocessing commands:

"... all config declarations are processed at program startup time ..."

While that is a useful feature in some cases, I would still like to be able to completely disable code when compiling. There are lots of things you simply don't want users to be able to activate (e.g. debug rendering modes in multiplayer games that would offer more information than players are supposed to be able to see).

[ilg-ul]

I would still like to be able to completely disable code when compiling

Right. But not only to disable code, I would like to adjust my code for various target platforms, at compile-time, as shown in the examples before.

I don't know what the design team has in mind, but in principle metaprogramming should be able to do this, plus many more.

[OlaFosheimGrostad]

While that is a useful feature in some cases, I would still like to be able to completely disable code when compiling. There are lots of things you simply don't want users to be able to activate (e.g. debug rendering modes in multiplayer games that would offer more information than players are supposed to be able to see).

Yes, but you could easily extend the concept with the consteval marker ! in Carbon.

[L4stR1t3s]

I think there are several issues with using compile-time expressions instead of preprocessor commands to enable/disable code:

• Preprocessor removes code before compilation. Enabling/disabling code at compile-time means more code will be compiled. This will have an impact on compile speed and memory usage.
• In some cases it will be difficult to tell if a compile-time expression is evaluating a configuration set by the build system, or if it is related to code generation. This will affect both the developer's and automated tool's ability to tell the difference. For C++ IDEs are easily able to detect what code is active and what code isn't, I think Carbon should definitely not make that more complicated.
• You can not override compile-time constants. Sometimes C++ code will override macros or even #undef them, based on other macros. The alternative is to add another constant that overrides another constant, but that makes the code more verbose, and it's easier to make mistakes by checking the wrong constants somewhere or in the wrong order.

[ilg-ul]

Your concern on speed and memory usage is probably right, and this might affect both the compiler and other tools (like syntax colouring IDEs), but I would not consider this a show stopper, perhaps in the end, with a careful design, things will not be that bad.