[deleted]
The beauty and simplicity of the good old C-style void* in C++
61–70 of 182 posts
Re: The beauty and simplicity of the good old C-style void* in C++
#62Many years ago I remember going through the Boost library and seeing C-style casts that seemed entirely gratuitous. I tried replacing them with what I was pretty sure were the equivalent C++ reinterpret_casts, and the result didn't compile. I never did figure it out.
Re: The beauty and simplicity of the good old C-style void* in C++
#63If you know you want bytes -- A void* of unknown provenance cast to anything other than char* is UB so just skip the middleman and use char*.
Re: The beauty and simplicity of the good old C-style void* in C++
#64Earlier quoted context omitted.
Those are ABI. Unless it is inlining them, the overhead is to stay.
ABI changes do happen. gcc had an ABI change in std::string because of C++11. It was long and painful, but everyone survived, the world did not end
> ABI changes do happen
Will never happen on Windows, especially not in user-mode libraries, and especially not something this pervasive.
Re: The beauty and simplicity of the good old C-style void* in C++
#65Many years ago I remember going through the Boost library and seeing C-style casts that seemed entirely gratuitous. I tried replacing them with what I was pretty sure were the equivalent C++ reinterpret_casts, and the result didn't compile. I never did figure it out.
C style cast can be either a static_cast or reinterpret_cast, but it can also be a const_cast or a static+const or reinterpret+const. Finally, it will perform a static_cast that bypasses private inheritance (because the alternative would be to fall back to a reinterpret_cast, which is wrong if the static_cast needs to apply an offset to the pointer)
Re: The beauty and simplicity of the good old C-style void* in C++
#66I 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…
> Hey Python users: you know that in the end everything ends up as machine code, don't you?
I don't understand where you're trying to go with this call-out, especially if you're also describing yourself as a Python user.
But, like, no, not really; ordinarily, Python is bytecode-compiled and then the bytecodes are interpreted. There's machine code doing the interpretation, but that interpretation is not transformation.
Re: The beauty and simplicity of the good old C-style void* in C++
#67If you know you want bytes -- A void* of unknown provenance cast to anything other than char* is UB so just skip the middleman and use char*.
char* can also be a C-style string. std::byte has the same special treatment in the standard as char and unsigned char, with the added benefit of not being used for other purposes (i.e. ASCII character or uint8, respectively).
Re: The beauty and simplicity of the good old C-style void* in C++
#68Next realize you can just use C instead of C++ at all!
Re: The beauty and simplicity of the good old C-style void* in C++
#69Earlier quoted context omitted.
> 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 arc…
> No - if something is UB in the spec, it's UB. A compiler is still free to ignore the spec and declare that something is not UB. However, this is very much compiler based, not platform based. Windows might guarantee that aligned DWORD-sized memory accesses are atomic, but that doesn't mean Clang when compiling for Windows would respect this - but MSVC might.
No, a compiler obviously cannot do this. nothing is undefined behaviour under a known compiler, version, and settings. UB means you can't know what the code does in general not that you can't know what it does in a very specific case.
Re: The beauty and simplicity of the good old C-style void* in C++
#70I 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…
There will always be cases (like audio processing, car brakes, pace makers) where hard real-time constraints prohibit GC languages (as well as l1 cache, instruction reordering and other optimizations). Also, consider that Python's performance frequently originates in it's bindings to libraries written in C, C++, Fortran, Rust. I recently ran a few Java benchmarks and found that an array holding a bunch of objects inc…
> There will always be cases (like audio processing, car brakes, pace makers) where hard real-time constraints prohibit GC languages (as well as l1 cache, instruction reordering and other optimizations). Also, consider that Python's performance frequently originates in it's bindings to libraries written in C, C++, Fortran, Rust.
Sure. And every Python programmer who has any interest in those use cases learns about the issues quickly. Or more to the point: a big chunk of them are things you'd only do if you were employed to do them, and employers are setting the language requirements already. And Python programmers in particular are well aware of compiled-language bindings; that's the reason they're trying to use the packages that make package installation non-trivial.
Huge swaths of use cases don't require performance.
> Python, Java or TypeScript are good educational tools, but you'd be doing yourself a disservice if you'd confine yourself to them without understanding computers.
This is an extremely strange thing to say when replying to someone who just described having extensive experience with C++ and multiple flavours of assembly.
> I recently ran a few Java benchmarks and found that an array holding a bunch of objects incurred approx 3x the number of bytes compared to the expected number based on underlying class data structure.
It was also strange to say that if you also had this experience yourself. A solid "understanding of computers" would have given you a better mental model of what Java needs to allocate. Results like this are because "the expected number" was not well thought out.
> if you're building software that's meant to scale.
... And yet everyone just keeps pumping out Electron apps. Curious, that.