Sorry, I probably should have tagged you in (or mentioned the paper number).

But in any case the before/after comparison

extern “C” VkResult vkCreateInstance(const VkInstanceCreateInfo*, const VKAllocationCallbacks*, VkInstance*);


in c++:

VkApplicationInfo appinfo {
                .sType = VK_STRUCTURE_TYPE_APPLICATION_INFO,
                .pApplicationName = “Hello World”,
                .applicationVersion = VK_MAKE_VERSION(0, 1, 0),
                .pEngineName = “No Engine”,
                .apiVersion = VK_API_VERSION_1_2
};
VkInstanceCreateInfo createInfo {
                .sType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO,
                .pApplicationInfo = &appinfo,
};
VkInstance instance = 0;
auto result = vkCreateInstance(&createInfo, nullptr, &instance);

in C:
VkInstance instance = 0;
VkResult result = vkCreateInstance(&(VkInstanceCreateInfo){
                .sType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO,
                .pApplicationInfo = &(VkApplicationInfo) {
.sType = VK_STRUCTURE_TYPE_APPLICATION_INFO,
                                .pApplicationName = “Hello World”,
                                .applicationVersion = VK_MAKE_VERSION(0, 1, 0),
                                .pEngineName = “No Engine”,
                                .apiVersion = VK_API_VERSION_1_2
                }}, NULL, &instance);

This usecase isn’t supported if the semantics are (T){…} === T{…}

I realized while writing this mail that you _can_ actually get his behavior in c++ by writing code like the following:


struct v {
    int i;
};
struct t {
    const v* vs;
};
#define compound(v) new (alloca(sizeof(v)))(v)
void fn(const t*);
int main() {
    // good
    fn(compound(t){.vs = compound(v){.i = 4}});
}

Note that alloca is non-standard, so this won’t work on windows, but windows does have _alloca.

Pretty sure this won’t run destructors, however.

I don’t think there’s a way to run destructors (via __attribute__((__cleanup__(…))) ) in GCCs C implementation of compound literals either






From: Zhihao Yuan <zy_at_[hidden]>
Sent: Wednesday, May 12, 2021 11:50 AM
To: liaison_at_lists.isocpp.org
Cc: Charlie Barto <Charles.Barto_at_microsoft.com>
Subject: Re: [wg14/wg21 liaison] P2174 Status (and a tenuous offer to help)

On Tuesday, May 11, 2021 6:10 PM, Charlie Barto via Liaison <liaison_at_[hidden]<mailto:liaison_at_[hidden]>> wrote:

(as a side note, few people can associate
document numbers with their own paper... I guess)

This email brought to you by fixing an ffmpeg wrapper that wouldn’t compile on MSVC because we don’t implement compound literals in c++ mode.
That, is my motivation -- to reduce engineers'
time wasted on this issue.


I’ve written a decent amount of wrapper code and/or Vulkan code that would have found compound literal support desirable. And from the looks of it the main problems with the proposal were that it didn’t follow the C lifetime semantics and that it didn’t really motivate itself (especially without the C lifetime semantics).
According to an EWG discussion in wg21,
there is no consensus for supporting C's block
lifetime semantics.

Given the discussion, I found that the main
problem of this paper is that it failed to
explain the semantics of compound literals
implemented as C++ extensions in todays'
compilers in great details. EWG, Clang, and
GCC are all different in certain contexts.



It occurs to me that C style compound literals may allow a real “defer” construct: consider



template<void (*fn)()>

struct defer {

   ~defer() {

      fn();

   }

};



right now we need to use this as:



defer<some_function_call> _;



(we need to name the local variable)



with C style compound literals:



(defer<some_function_call>){};

I'm aware of that, and I find it being
accidental rather than something
we should build upon.

There are people interested in adding
`defer` to C http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2589.pdf
I'm excited by this effort and would like
to see a paper coming to this group.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________