User talk:D41D8CD98F

Thanks for fixing a bug in the mini-example for template argument deduction from an overload set! In retrospect, it was pretty dumb error. --Cubbi (talk) 08:43, 20 April 2015 (PDT)

I also made a mistake. I thought P means "the parameter type". Now I realize that P actually means "type to be deduced".--D41D8CD98F (talk)

C17 DRs

regarding your question Should the change made by C17 be treated as DR (and thus applied retroactively to C11)

I'd say yes for most of them, but the ATOMIC_VAR_INIT change is considered to be more significant, at least by the WG14 member who posted that comment to SO. --Cubbi (talk) 11:58, 12 December 2017 (PST)

I see. Thanks for your response. --D41D8CD98F (talk) 00:48, 13 December 2017 (PST)

constexpr rollback

The change you rolled back had a purpose. constexpr, when applied to a variable, is not "possibly" anything; it is very definitely and without question a constant expression (or it's ill-formed). So the form of the statement you restored is misleading. Korval (talk) 20:17, 6 January 2020 (PST)

I think saying a constexpr variable "is a constant expression" is even less correct. It depends on how the variable is used:

void test() {
    constexpr int b = 42;
    constexpr int ib = b;         // OK: the value of b can be used in constant expression
    constexpr const int& rb = b;  // Error: not taking the "value" of b
 
    static const int a = std::random_device{}();
    constexpr const int& ra = a;
    constexpr const int* p = &ra; // OK. The "value" of reference can be thought of as
                                  // the identity of the referenced variable
    constexpr const int  n = ra;  // Error: can't read the referenced variable in
                                  // a constant expression
}

(cpp/language/constant_expression#Constant_expression has a similar example.)

Moreover, the constexpr variable might have a mutable member. Such variable can be used in constant expressions (as long as the mutable member is not accessed), but IMO it doesn't make sense to say that the variable, as a whole, is a constant expression. --D41D8CD98F (talk) 21:47, 6 January 2020 (PST)

typename revert

Hi, I see you reverted my change to typename. I see now that using typename inside casts only works on MSVC, I apologize, I think I misunderstood the relaxed typename rules described in Vandevoorde's book. Without more context though, I could only guess at what you thought was wrong; it would help if you could be more specific next time. For example, in [temp.res] the standard says "A name used in a template declaration or definition and that is dependent on a template-parameter is assumed not to name a type unless the applicable name lookup finds a type name or the name is qualified by the keyword typename." I interpret this as the typename hinting the compiler that something is a typename if name lookup fails.

Jeffythedragonslayer (talk) 20:01, 17 May 2020 (PDT)

Sorry. I thought that you meant static_cast<typename int>(0) is valid, so I thought the problem is too obvious to be noted.

The usage you described has been mentioned in the second and third bullets in cpp/keyword/typename, but the wording can probably be improved. --D41D8CD98F (talk) 23:46, 17 May 2020 (PDT)

Yes, that was exactly what I thought was valid. I'll test on more compilers next time.

Jeffythedragonslayer (talk) 08:10, 18 May 2020 (PDT)

On static lambdas

Considering "static lambdas" from P1169R4 static operator():

Shouldn't the next-gen C++ provide a static lambda as a means of generating a class with static fields!? The "source" of types and initializes for such static fields would obviously be the capture-list.

This approach enhances utility of static lambdas, whereas the restriction "A static lambda shall have no lambda-capture" looks somewhat artificial.

Promoting this we would have these simple rules:

• non-static lambda → non-static data members,
• static lambda → static data members.

Benefits:

• static ClosureType::operator() has natural access to static data members;
• static data members (naturally) hold their state after lambda-object is out of scope (destroyed). This is useful in scenarios, when the static lambda-expression is defined in a function that is being invoked several times, so the "state" of the lambda is "preserved" between calls.

C++-insight pseudo-example:

auto st = [x=42]() static { print("{}", x++); };   // decomposition: struct __static_lambda1 { inline static int x = 42; // one-time initialization, the source of type (int) // and initializing value is the capture-list.   static /*constexpr*/ void operator()() { print("{}", x++); } }; __static_lambda1(); One possible usage pseudo-example: bool foo() { auto state_machine = [state=0 /* <- one-time initializer */]() static { switch(state++) { case 0: { /*...*/ } break; case 1: { /*...*/ } break; case 2: { /*...*/ } break; default: state = 0; } return state; } return state_machine() != 0; }   int main() { while(foo()) { /* ... */ } }

This is only a raw idea, maybe not viable. --Space Mission (talk) 16:11, 8 October 2022 (PDT)