Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #119852 > unrolled thread

General Preference in C++

Back to article view | Back to comp.lang.c++

Contents

  General Preference in C++ Jack <noreply@mandrill.com> - 2024-08-21 01:30 +0000
    Re: General Preference in C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-20 18:53 -0700
      Re: General Preference in C++ Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-08-22 13:18 -0400
        Re: General Preference in C++ scott@slp53.sl.home (Scott Lurndal) - 2024-08-22 17:54 +0000
          Re: General Preference in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-22 20:08 +0200
          Re: General Preference in C++ David Brown <david.brown@hesbynett.no> - 2024-08-23 09:08 +0200
            Re: General Preference in C++ Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-08-23 09:41 -0400
    Re: General Preference in C++ Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-08-20 20:07 -0700
      Re: General Preference in C++ David Brown <david.brown@hesbynett.no> - 2024-08-21 09:07 +0200
    Re: General Preference in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-22 11:33 +0200

#119852 — General Preference in C++

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.

[toc] | [next] | [standalone]

#119853

Jack <noreply@mandrill.com> writes:
> Do you guys have any preference in C++ to use something like this:
>
> constexpr size_t N = 12;
> #define N 12

The first N is of type size_t.  The second is of type int (the type of
the literal 12).

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

There is unlikely to be any difference in efficiency.

> You can then define an array like so:
>
> double numbers[N] {0};
>
> I wonder if you guys have anything to say about this.

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.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#119883

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"

[toc] | [prev] | [next] | [standalone]

#119884

Chris Ahlstrom <OFeem1987@teleworm.us> 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.

[toc] | [prev] | [next] | [standalone]

#119885

Am 22.08.2024 um 19:54 schrieb Scott Lurndal:
> Chris Ahlstrom <OFeem1987@teleworm.us> 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).

lol

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

[toc] | [prev] | [next] | [standalone]

#119899

On 22/08/2024 19:54, Scott Lurndal wrote:
> Chris Ahlstrom <OFeem1987@teleworm.us> 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.

[toc] | [prev] | [next] | [standalone]

#119901

David Brown wrote this copyrighted missive and expects royalties:

> On 22/08/2024 19:54, Scott Lurndal wrote:
>> Chris Ahlstrom <OFeem1987@teleworm.us> 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

[toc] | [prev] | [next] | [standalone]

#119854

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

[toc] | [prev] | [next] | [standalone]

#119867

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.

[toc] | [prev] | [next] | [standalone]

#119876

Am 21.08.2024 um 03:30 schrieb Jack:
> Do you guys have any preference in C++ to use something like this:
> 
> constexpr size_t N = 12;
> #define N 12

I prefer constexpr / static constexpr (membe) because it can be scoped.


> 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.
> 
> 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web