Hacker News Reader

Comment by uxcn | Hacker News Reader

I was recently bit using a similar technique to the original code for an intrusive type in C. Using manual non-typesafe raw offsets for things can definitely lead to nasty bugs.

Automating the calculation of offsets and assigning pointers definitely eliminates a lot of potential bugs, but I do wonder if this isn't a bigger deficiency in C++. Why force storing an extra pointer per array? I am still not sure why C++ doesn't allow FAMs [1].

There's probably a question of which would be more efficient, storing pointers in the object and calculating the offset from the pointer, or dynamically calculating the offset within the object. Still, it doesn't seem like a problem developers should need to solve.

[1] https://en.wikipedia.org/wiki/Flexible_array_member

View on HN

It's not really an extra pointer, unless you assume there are no alignment issues. If you assume that there's zero padding between members, then yes, you can do 1 pointer for storage + 1 per view. In the follow-up post, I plan to either do one pointer per view, or one integer per view, haven't decided which.

The thing is, who should solve it? The different approaches you listed have different advantages, there isn't one right answer. If the language itself solves it for you, you are stuck with whatever solution the language picked. This would be fine in a higher level language, but not in C++.

You're right though that individual devs shouldn't be solving it, it should be in a library. If there's enough interest in these posts, I'm happy to put up my work (fully fleshed out and documented) on a github for people to use.

I suspect the compiler will be better able to optimize offsets than pointers just because of the semantics required by the language, but I think you're right that it isn't necessarily one size fits all. Another possible solution might even be storing static bounds at specific intervals. Without numbers, I can only guess which would give optimal performance though.

I think the library approach is right. It would be nice to see the language transparently support contiguous array members, but supporting it in a library will allow more people to use it regardless of compiler. It avoids the standards approval process and implementation as well, which take non-trivial amounts of time. The 0x/1y features definitely make it a lot more feasible.

It would probably give people a better chance to play with the source if you could post a link to it somewhere. I'm not sure what you plan to license it under.

I'll keep an eye out for the next post.

I imagine C++ doesn't allow FAMs because it wouldn't know how to call the destructors/constructors on the members of the array (or how many to call).

To allow FAMs for non-trivially constructible/destructible types would be slightly more complicated than C FAMs, but it doesn't seem like an unreasonable thing to expect from the language/library, or intractable from a standard or compiler perspective.

Regardless, I'm still not sure what the justification is requiring it be UB even for just primitive types.

Reply on news.ycombinator.com