[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inline function expansion
From: |
Emanuel Berg |
Subject: |
Re: inline function expansion |
Date: |
Mon, 08 May 2023 02:21:25 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Lynn Winebarger wrote:
>> Isn't the idea of inlining that the behaviour/effect of
>> invoking a function shouldn't change, just that the
>> resulting code might be more efficient?
>
> The main thing I am interested in is the ability to do
> compile-time evaluation on constant expressions.
What exactly are "constant expressions" in the context of
this discussion?
The same as this?
https://www.stroustrup.com/sac10-constexpr.pdf
> I'm trying to design/implement a way of defining generic
> methods so that the specialization may be determined (or
> explicitly constructed) at compile time and compiled to
> a non-generic function call, and left to dynamic
> dispatch otherwise.
Okay, so what would be the gain(s) of having such
a capability?
--
underground experts united
https://dataswamp.org/~incal
- inline function expansion, Lynn Winebarger, 2023/05/07
- Re: inline function expansion, Basile Starynkevitch, 2023/05/07
- Re: inline function expansion, Philip Kaludercic, 2023/05/07
- Re: inline function expansion, Lynn Winebarger, 2023/05/07
- Re: inline function expansion, Lynn Winebarger, 2023/05/11
- Re: inline function expansion, Emanuel Berg, 2023/05/13
- Re: inline function expansion, Lynn Winebarger, 2023/05/18
- Re: inline function expansion, Stefan Monnier, 2023/05/19
- Re: inline function expansion, Lynn Winebarger, 2023/05/20
- Re: inline function expansion, Stefan Monnier, 2023/05/20
- Re: inline function expansion, Lynn Winebarger, 2023/05/21
- Re: inline function expansion, Stefan Monnier, 2023/05/18