Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

警告 C26495 #22

Open
wfs20 opened this issue Jul 13, 2023 · 4 comments
Open

警告 C26495 #22

wfs20 opened this issue Jul 13, 2023 · 4 comments

Comments

@wfs20
Copy link

wfs20 commented Jul 13, 2023

警告 C26495 未初始化变量 jnk0le::Ringbuffer<char const *,256,0,0,unsigned __int64>::data_buff。始终初始化成员变量(type.6)。

@jnk0le
Copy link
Owner

jnk0le commented Jul 16, 2023

initializing this array will cause the memcpy zeroing, or calling constructors for every element

only something like this:

	//remove constructors
	alignas(cacheline_size) std::atomic<index_t> head = {}; //!< head index
	alignas(cacheline_size) std::atomic<index_t> tail = {}; //!< tail index
	alignas(cacheline_size) T data_buff[buffer_size] = {}; //!< actual buffer

doesn't emit global constructor (for POD T, on gcc)

@jnk0le
Copy link
Owner

jnk0le commented Jul 16, 2023

	//remove constructors
	alignas(cacheline_size) std::atomic<index_t> head = {}; //!< head index
	alignas(cacheline_size) std::atomic<index_t> tail = {}; //!< tail index
	alignas(cacheline_size) T data_buff[buffer_size]; //!< actual buffer

This again emits constructors for intializing head and tail in globals/statics and warning is still there

@jnk0le
Copy link
Owner

jnk0le commented Jul 27, 2023

[[uninitialized]] of course is not a thing.

At least for POD, llvm recognizes .bss placement and workaround constructor is not necessary.

@jnk0le
Copy link
Owner

jnk0le commented Jul 27, 2023

non POD T constructors are always called

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants