Do you guys have any preference in C++ to use something like this:

constexpr size_t N = 12;
#define N 12

constexpr is modern way of doing things but in terms of efficiency what
is the best way to do?

You can then define an array like so:

double numbers[N] {0};

I wonder if you guys have anything to say about this.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/20/24 6:30 PM, Jack wrote:

constexpr size_t N = 12;
#define N 12

constexpr is modern way of doing things but in terms of efficiency what
is the best way to do?

There's no difference in efficiency.

One can probably come up with a few reasons to prefer a macro for this
purpose, like

1. Compatibility with C in cross-compiled header files
2. Ability to use a named constant in subsequent preprocessor directives
(e.g. `#if`)
3. Probably something else...

But these reasons are focused rather narrowly of some niche
applications. When you _have_ a choice, there's no reason to avoid
`constexpr`.

--
Best regards,
Andry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/08/2024 05:07, Andrey Tarasevich wrote:

On 08/20/24 6:30 PM, Jack wrote:

constexpr size_t N = 12;
#define N 12

constexpr is modern way of doing things but in terms of efficiency what
is the best way to do?

There's no difference in efficiency.

One can probably come up with a few reasons to prefer a macro for this purpose, like

1. Compatibility with C in cross-compiled header files

"enum { N = 12 };" also works if you need compatibility with C in
headers. And if you are on C23, then "constexpr size_t N = 12;" is fine
in C too.

You can also write "static const size_t N = 12;" and use it in a fair
number of circumstances, though not as many as with a constexpr or
macro. You can use it for local variable array sizes in C and C++, but
not for a file-scope array in C.

2. Ability to use a named constant in subsequent preprocessor directives (e.g. `#if`)

"if constexpr" and templates can provide alternatives to using #if, and
work with constexpr values. But conditional preprocessor may be simpler
and clearer, depending on the context and usage.

3. Probably something else...

Two things come to mind for "#define N 12" :

3a. You can later on write :

#undef N
#define N 42

3b. You can write :

#ifndef N
#define N 100
#endif

These make #define's nice for things like configuration files where you
might have defaults that you want to override. Template variables,
including template constexpr variables, can be an alternative.

But these reasons are focused rather narrowly of some niche
applications. When you _have_ a choice, there's no reason to avoid `constexpr`.

Agreed. A key point is that constexpr variables (like other variables)
follow scoping rules, and can be put in namespaces or inside classes.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris Ahlstrom <[email protected]> writes:

Keith Thompson wrote this copyrighted missive and expects royalties:

<brevsnip>

I believe the general consensus (and my own preference) is to use core
language features rather than macros unless there's a very good reason
to use a macro.

I use macros for enabling/disabling code depending on developer preference or >platform.

Is that a sensible use of macros? (A little off-topic, sorry).

Generally speaking, that's sensible.

However it can be taken to an extreme that makes maintenance of
the application more complicated. Every conditional used to
select optional code needs to be tested combinitorially to ensure
proper operation of the application, which can consume considerable
QA time. If N is the number of macros, then there are as many
as 2^n (or more for non-boolean conditionals) different compiles
required for full verification of the application (just to ensure
that it compiles sucessfully).

Maintenance can be very difficult when there are an excessive number of conditionally compiled segments in a codebase.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson wrote this copyrighted missive and expects royalties:

<brevsnip>

I believe the general consensus (and my own preference) is to use core language features rather than macros unless there's a very good reason
to use a macro.

I use macros for enabling/disabling code depending on developer preference or platform.

Is that a sensible use of macros? (A little off-topic, sorry).

--
My only love sprung from my only hate!
Too early seen unknown, and known too late!
-- William Shakespeare, "Romeo and Juliet"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/08/2024 19:54, Scott Lurndal wrote:

Chris Ahlstrom <[email protected]> writes:

Keith Thompson wrote this copyrighted missive and expects royalties:

<brevsnip>

I believe the general consensus (and my own preference) is to use core
language features rather than macros unless there's a very good reason
to use a macro.

I use macros for enabling/disabling code depending on developer preference or
platform.

Is that a sensible use of macros? (A little off-topic, sorry).

Generally speaking, that's sensible.

However it can be taken to an extreme that makes maintenance of
the application more complicated. Every conditional used to
select optional code needs to be tested combinitorially to ensure
proper operation of the application, which can consume considerable
QA time. If N is the number of macros, then there are as many
as 2^n (or more for non-boolean conditionals) different compiles
required for full verification of the application (just to ensure
that it compiles sucessfully).

Maintenance can be very difficult when there are an excessive number of conditionally compiled segments in a codebase.

Usually the number of valid combinations is not nearly that many, as
they are rarely independent. (And if they are truly independent, then
they can often be tested independently.) But you are right that too
many of them can make code hard to handle in many aspects.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Brown wrote this copyrighted missive and expects royalties:

On 22/08/2024 19:54, Scott Lurndal wrote:

Chris Ahlstrom <[email protected]> writes:

Keith Thompson wrote this copyrighted missive and expects royalties:

<brevsnip>

I believe the general consensus (and my own preference) is to use core >>>> language features rather than macros unless there's a very good reason >>>> to use a macro.

I use macros for enabling/disabling code depending on developer preference or
platform.

Is that a sensible use of macros? (A little off-topic, sorry).

Generally speaking, that's sensible.

However it can be taken to an extreme that makes maintenance of
the application more complicated. Every conditional used to
select optional code needs to be tested combinitorially to ensure
proper operation of the application, which can consume considerable
QA time. If N is the number of macros, then there are as many
as 2^n (or more for non-boolean conditionals) different compiles
required for full verification of the application (just to ensure
that it compiles sucessfully).

Maintenance can be very difficult when there are an excessive number of
conditionally compiled segments in a codebase.

Usually the number of valid combinations is not nearly that many, as
they are rarely independent. (And if they are truly independent, then
they can often be tested independently.) But you are right that too
many of them can make code hard to handle in many aspects.

Thanks for the responses. Periodically I go through the code and look at the macros to find ways to get rid of them.

- Making the feature permanent
- Removing the feature entirely
- Off-loading/hiding the feature choices in a function

--
Civilization is the limitless multiplication of unnecessary necessities.
-- Mark Twain

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)