@deezo

4 Followers
25 Following
140 Posts

@kimapr
> cast random pointers left and right

TBH that's how I see C programming in a nutshell 😂

@kimapr I think another factor is that C might be more forgiving when casting stuff.
@kimapr Reading into it more carefully, I still think it's UB, but my initial reasoning was incorrect.
An object can be treated as an array of size 1.
But adding any integral value j to the pointer to i'th element that will result in (i+j) outside of array bounds of the array is UB (even without access).
So you can only create span<sigma> of size 1 from ligma.
@kimapr
I misunderstood the initial question, sorry about that.
I do think it's technically UB for the case with arrays. I think the relevant part is 7.6.6 Additive operators. Pointer addition is defined for pointer P if it is a pointer to an array element. Since there's no array of sigmas, it's UB.
I'm not a standard expert, I am studying it myself, please verify :)
Do you need the `std::span` specifically? Some range adaptor would be legal and likely as performant with optimizations enabled.
@kimapr you can reinterpret_cast between pointers to `pointer-interconvertible` types.
If ligma is a standard-layout class, you can cast a pointer to ligma object to pointer to it's first member's type.
[basic.compound] in standard spec
You should check the requirements for standard layout and see if you can satisfy them
@mkretz
Not using, just curious. Do You know which tool that Codacy runs gives the most false positives?
Emulating simd seems to be a pretty low level code with raw pointers, the most memory-dangerous kind.
Might be the reason for amount of warnings for this project.

@jakub_neruda When I've encountered this problem I've concluded that it's not currently possible to partially specify template parameters for constructors, and from quick search it doesn't seem to have changed. Unfortunately I do not have a reference to standard, so I might be missing something.

Have you considered using `std::type_identity<T>` or a similar wrapper to pass types as arguments? While not as clean it might work when you cannot use a function template.

@mkretz I have explained myself poorly. What I mean is if the complex multiplication/division is defined as a combination of float multiplications and additions, then the resulting state follows from IEEE.
While it may be a bad idea to define something by it's implementation, I think it fits well in this case. And it doesn't require a definition of complex infinity.
I wish you luck with this, and thanks for your work.🙏

@mkretz I think with Cartesian representation being standard defining multiplication and division defines how zeros and infinities are handled because of the IEEE 754. I think making stronger guarantees is excessive. Would it interfere with usage of FMA instructions?

Handling of edge float values already requires special attention, and a situation that requires knowing argument of infinities and zeros seems like a very special and niche case, and non-standard representation should be used.

@ringtailringo do you mean that you find pressing and holding Ctrl more ergonomic than pressing leader?