4 ms·
Lots of reasons: The code is not portable between architectures. You can’t actually define your data structure. You can pretend with your compiler’s version
by amluto 8mo ago
Lots of reasons:
The code is not portable between architectures.
You can’t actually define your data structure. You can pretend with your compiler’s version of “pack” with regrettable results.
You probably have multiple kinds of undefined behavior.
Dealing with compatibility between versions of your software is awkward at best.
You might not even get amazing performance. mmap is not a panacea. Page faults and TLB flushing are not free.
You can’t use any sort of advanced data types — you get exactly what C gives you.
Forget about enforcing any sort of invariant at the language level.
- Negitivefrags 8mo agoI've written a lot of code using that method, and never had any portability issues. You use types with number of bits in them. Hell, I've slung C structs across the network between 3 CPU architectures. And I didn't even use htons! Maybe it's not portable to some ancient architecture, but none that I have experienced. If there is undefined behavior, it's certainly never been a problem either. And I've seen a lot of talk about TLB shootdown, so I tried to reproduce those problems but even with over 32 threads, mmap was still faster than fread into memory in the tests I ran. Look, obviously there are use cases for libraries like that, but a lot of the time you just need something simple, and writing some structs to disk can go a long way.
- ddtaylor 8mo agoC allows most of this, whereas C++ doesn't allow pointer aliasing without a compiler flag, tricks and problems. I agree you can certainly just use bytes of the correct sizes, but often to get the coverage you need for the data structure you end up writing some form of wrapper or fixup code, which is still easier and gives you the control versus most of the protobuf like stuff that introduces a lot of complexity and tons of code.
- nly 8mo ago__attribute__((may_alias, packed)) right on the struct.
- johannes1234321 8mo agoThat is not C, but a non-standard extension and thus not portable.
- josefx 8mo ago> non-standard extension and thus not portable Modern versions of standard C aren't very portable either, unless you plan to stick to the original version of K&R C you have to pick and choose which implementations you plan to support.
- ddtaylor 8mo agoI disagree. Modern C with C17 and C23 make this less of an issue. Sure, some vendors suck and some people take shortcuts with embedded systems, but the standard is there and adopted by GCC, Clang and even MSVC has shaped up a bit.
- josefx 8mo ago> GCC, Clang and even MSVC Well, if that is the standard for portability then may_alias might as well be standard. GCC and Clang support it and MSVC doesn't implement the affected optimization as far as I can find.
- ddtaylor 8mo agoWhat do you think the standard is for standardization?
- josefx 8mo agoWithin the context of this discussion portability was mentioned as key feature of the standard. If C23 adoption is as limited as the, possibly outdated, tables on cppreference and your comments about gcc, clang and msvc suggest then the functionality provided by the gcc attribute would be more portable than C23 conformant code. You could call it a de facto standard, as opposed to C23 which is a standard in the sense someone said so.
- pjmlp 8mo agoSome people also don't use protective gear when going downhill biking, it is a matter of feeling lucky.
- benj111 8mo agoOn the other hand some people have things to ward off evil demons, and aren't bothered by evil demons. The parent has actually done the thing, and found no issues, I don't think you can hand wave that away with a biased metaphor. Otherwise you get 'Goto considered harmful' and people not using it even when it fits.
- pjmlp 8mo agoAs proven by many languages without native support for plain old goto, it isn't really required when proper structured programming constructs are available, even if it happens to be a goto under the hood, managed by the compiler.
- benj111 8mo agoMy point is it's bad debating style. 'Everyone knows C is bad for all kinds of reasons ergo, even when someone presents their own actual experience, I can respond with a refrain that sounds good' Not using goto because you've heard it's always bad is the same kind of thing. Yes it has issues, but that isn't a reason to brush anyone off that have actual valid uses for it.
- pjmlp 8mo agoSince I am coding since 1986, lets say I have plenty of experience with goto in various places myself.
- lionkor 8mo agoThat seems highly unlikely. Let's assume that all compilers use the exact same padding in C structs, that all architectures use the same alignment, and that endianness is made up, that types are the same size across 64 and 32 bit platforms, and also pretend that pointers inside a struct will work fine when sent across the network; the question remains still: Why? Is THIS your bottleneck? Will a couple memcpy() operations that are likely no-op if your structs happen to line up kill your perf?
- zadikian 8mo agoI guess to not have to set up protobuf or asn1. Those preconditions of both platforms using the same padding and endianness aren't that hard to satisfy if you own it all. But do you really have such a complex struct where everything inside is fixed-size? I wouldn't be surprised if it happens, but this isn't so general-purpose like the article suggests.
- lionkor 8mo agoThere are at least 10 steps between protobuf and casting a struct to a char*.
- direwolf20 8mo ago"Portable" has originally meant "able to be ported" and not "is already ported"