Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The beauty and simplicity of the good old C-style void* in C++

giodicanio.com

Post reply on HN
Print view View original

31–40 of 182 posts

Re: The beauty and simplicity of the good old C-style void* in C++

#31

Post by pjmlp »

delta_p_delta_x wrote: post #20

The blogger and the blog says: > BTW: As a nice addition, if you use SAL annotations > Windows C++ Programming Not everyone will see the irony, but the Windows user-mode application and library suite and the kernel now very heavily rely on the safety mechanisms of C++ that the author calls 'complex', 'uglif[ied]', and has 'los[t] the taste for good readable code'. I'm of course referring to the Windows Implementation…

It goes even further their beloved C code is compiled in compilers written in C++, including the standard library, exposing C++ implementations as extern "C" functions.

It is a pity that Microsoft backtracked on their C support.

WWDC is happening this week, one set of announcements at State of the Union was how Apple replaced a few C, Objective-C and C++ components, including at OS level with Swift.

Re: The beauty and simplicity of the good old C-style void* in C++

#32

Post by repelsteeltje »

trumpdong wrote: post #11
gignico wrote: post #2

> It seems that some people are really losing the taste for good readable code. It seems that some people never had taste for good reliable code. Use `void ` and now any error whatsoever is a direct undefined behavior. Moreover `std::span` clearly says that you are not* taking ownership of the memory (even though the language does not check it of course), while `void *` does not. I understand that people can have man…

There's lots of UB in C-family execution models. Some of which is not actually UB because the implementation defines it - e.g. aligned DWORD-sized memory access is atomic on Windows because Microsoft said it is. By choosing to use this language you choose to navigate the UB. Otherwise you'd be writing in Go, or Python. It is possible to write reliable code despite the presence of UB in a language just like it's possi…

There is a difference between UB in C, and something being undefined in some version of Microsoft C on Windows.

Many of C's UB is specifically, intentionally left undefined in the standard to express code that relies on some specific way it is handled, is not proper, portable C. Indeed, the DWORD-sized memory access being atomic doesn't apply to MS Windows prior to version 3.0 running on a 80286.

It's UB because the ISO C spec says it's UB.

Re: The beauty and simplicity of the good old C-style void* in C++

#34

Post by repelsteeltje »

pjmlp wrote: post #31
delta_p_delta_x wrote: post #20

The blogger and the blog says: > BTW: As a nice addition, if you use SAL annotations > Windows C++ Programming Not everyone will see the irony, but the Windows user-mode application and library suite and the kernel now very heavily rely on the safety mechanisms of C++ that the author calls 'complex', 'uglif[ied]', and has 'los[t] the taste for good readable code'. I'm of course referring to the Windows Implementation…

It goes even further their beloved C code is compiled in compilers written in C++, including the standard library, exposing C++ implementations as extern "C" functions. It is a pity that Microsoft backtracked on their C support. WWDC is happening this week, one set of announcements at State of the Union was how Apple replaced a few C, Objective-C and C++ components, including at OS level with Swift.

Interesting. I'm know nothing about Apple, but maybe you can explain how idiomatic Swift handles Blobs and how that interfaces with C or C++ around void ptrs, std::spans etc.?

Re: The beauty and simplicity of the good old C-style void* in C++

#35

Post by pjc50 »

trumpdong wrote: post #11
gignico wrote: post #2

> It seems that some people are really losing the taste for good readable code. It seems that some people never had taste for good reliable code. Use `void ` and now any error whatsoever is a direct undefined behavior. Moreover `std::span` clearly says that you are not* taking ownership of the memory (even though the language does not check it of course), while `void *` does not. I understand that people can have man…

There's lots of UB in C-family execution models. Some of which is not actually UB because the implementation defines it - e.g. aligned DWORD-sized memory access is atomic on Windows because Microsoft said it is. By choosing to use this language you choose to navigate the UB. Otherwise you'd be writing in Go, or Python. It is possible to write reliable code despite the presence of UB in a language just like it's possi…

> Some of which is not actually UB because the implementation defines it

No - if something is UB in the spec, it's UB. The implementation will do something, sure, but what it does is not fixed and may even change based on compiler version and optimization level.

> DWORD-sized memory access is atomic on Windows because Microsoft said it is

Well, Intel said it is. Mind you I don't think there are any 32-bit native architectures where aligned dword access isn't atomic. Unaligned, on the other hand ...

Re: The beauty and simplicity of the good old C-style void* in C++

#36

Post by usrnm »

delta_p_delta_x wrote: post #22
gignico wrote: post #2

> It seems that some people are really losing the taste for good readable code. It seems that some people never had taste for good reliable code. Use `void ` and now any error whatsoever is a direct undefined behavior. Moreover `std::span` clearly says that you are not* taking ownership of the memory (even though the language does not check it of course), while `void *` does not. I understand that people can have man…

> A truly zero-cost abstraction Sadly the MSVC ABI makes std::span and std::string_view a pessimisation: https://github.com/tringi/win64_abi_call_overhead_benchmark https://godbolt.org/z/7baaox7re

Sounds like a compiler bug to me. It is a valid reason to avoid them in some rare cases right now, but it doesn't make the feature itself bad

Re: The beauty and simplicity of the good old C-style void* in C++

#37

Post by pjc50 »

_the_inflator wrote: post #21

I think that the author is right in everything he says and yes, there is beauty in it. However, the antithesis is also correct that there exist better solutions to solve the issues. Both premises hold true. I have an extensive assembler coding background on 6510, M68000, and i486. I had a very hard time accepting that something could be solved faster and more stable in a higher order language while the downside is mo…

One of these days I want to do a "typesafe macro assembler" that actually is the language people think that C is.

Re: The beauty and simplicity of the good old C-style void* in C++

#39

Post by pjmlp »

repelsteeltje wrote: post #34
pjmlp wrote: post #31

Earlier quoted context omitted.

It goes even further their beloved C code is compiled in compilers written in C++, including the standard library, exposing C++ implementations as extern "C" functions. It is a pity that Microsoft backtracked on their C support. WWDC is happening this week, one set of announcements at State of the Union was how Apple replaced a few C, Objective-C and C++ components, including at OS level with Swift.

Interesting. I'm know nothing about Apple, but maybe you can explain how idiomatic Swift handles Blobs and how that interfaces with C or C++ around void ptrs, std::spans etc.?

Those are unsafe buffers, and have specific primitives to handle them, Swift also has span, and interoperability with Objective-C and C++ code.

Re: The beauty and simplicity of the good old C-style void* in C++

#40

Post by myrmidon »

quietbritishjim wrote: post #15
arcadialeak wrote: post #6

char* is an exception to strict aliasing rules of C++ precisely to facilitate the author's use case. You would still need a reinterpret_cast to make it work, but it's actually good because it makes the intent clearer, and the cast would have still happened either way to read the raw bytes.

That was my first instinct too, but nothing the author said indicates they actually need non-strict aliasing. If the function had been: void DoSomething(void* src, void* dst, size_t numBytes); ... then it would be a different matter since maybe you want to allow src and dst to alias. Although, even then, they're still allowed to alias so long as the function accesses them both through char*, so the function signature…

This is actually pretty annoying in embedded programming in C, because you'd often really prefer to use a uint8_t buffer[] for serialization functions (e.g. to write arbitrary data on some bus etc.) over char*, but you'd actually lose the aliasing permissiveness that you need (if you are strictly sticking to the standard-- this is often ignored in practice).
Post reply on HN