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@miator.net>
Sent: Wednesday, May 12, 2021 11:50 AM
To: liaison@lists.isocpp.org
Cc: Charlie Barto <Charles.Barto@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@lists.isocpp.org> 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
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.
_______________________________________________