mehrdadn

8 ms·

1.
by mehrdadn 2y ago
Do you think you could try my library [1] and let me know how it performs in comparison? I've been curious about its compile-time performance, but I've never tried to compare its performance against that of magic_enum. [1] https:
2.
by mehrdadn 2y ago
The reason I mentioned using a hierarchical bitmap was precisely the inefficiency of just having one bool per element.
3.
by mehrdadn 2y ago
Wow, thank you. Were you already aware of the name? Or if not, how did you search for it?
4.
by mehrdadn 2y ago
Wow! I independently came up with this algorithm a few years ago and wasn't even sure what to search for to find the prior art. Happy to see someone finally gave it a name and attempted to find the history. Fun fact #1 that I also real
5.
by mehrdadn 4y ago
That's supported here! You can do: for (auto const &member : enum_traits<E>::members()) { std::cout << member.name() << std::endl; }
6.
by mehrdadn 4y ago
It's indeed a lot of boilerplate that this library can hopefully reduce (which was one of my main goals). I don't know for sure, but I can guess some reasons why the standard doesn't support it: - The problem is somewhat unde
7.
by mehrdadn 4y ago
Ah sorry about that, thanks for the feedback! I can try to answer these here (and hopefully update the documentation as well when I get the chance): - The problem is basically twofold. Part (a) is that there are no facilities for dealing wi
8.
by mehrdadn 4y ago
To my knowledge magic_enum has some severe limitations; for example, it limits the range of enum values, it cannot handle duplicate enum values, it uses compiler-specific hackes, etc. There is a list of them outlined at [1]. Before writing
9.
Show HN: The Ultimate C++14 (and later) Enum Library(github.com)
38 points by mehrdadn 4y ago|20 comments
10.
by mehrdadn 5y ago
Should applicants mention if they saw this posting on HN? I just realized I neglected to do this when applying.
11.
by mehrdadn 6y ago
> 1. the lt2 definition in the paper is wrong. Would you mind providing a counterexample to illustrate what incorrect output it's producing? > A lexicographical compare is linear in the size. Indeed, lt2() also has a loop that it
12.
by mehrdadn 6y ago
> I wonder (genuinely asking, not being snarky) what it is about C/C++ that seems to make these issues more common? It's also possible my perception of "more common" has just been inflated by seeing multiple examples
13.
by mehrdadn 6y ago
C++20 doesn't quite rectify this unfortunately! The data structures still use std::less even in C++20, meaning the 2-way comparisons would happen twice. Except now each 2-way comparison is potentially implemented on top of 3-way compar
14.
by mehrdadn 6y ago
There are lots of reasons to prefer trees (and, correspondingly, lots of reasons to prefer hashtables); I just pointed out ordering isn't the only one, and I merely gave another (worst-case performance guarantee). For example, yet an
15.
by mehrdadn 6y ago
Yeah—I think I laid out the paper more like a story, but I might indeed need to change that as it appears it leaves people confused before they get to the punchline. Thanks for the feedback! Glad you found it interesting.
16.
by mehrdadn 6y ago
I think the sibling comment may have already answered your question, but if not, I think an earlier response I had might help clarify what exactly I'm comparing & why: https://news.ycombinator.com/item?id=26340952
17.
by mehrdadn 6y ago
Haha, thank you! It was pretty demotivating to see so many people immediately dismiss it as clickbait without any attempt to discuss the topic at all, so it actually means a lot to hear that you think differently now. I hope it was fun &amp
18.
by mehrdadn 6y ago
You're right!! Thanks for pointing this out! I indeed tried to hint at the DAG case in the footnote, but didn't try to explore what happens when the DAG degenerates to a linked list. The biggest obstacle here is, honestly, motivat
19.
by mehrdadn 6y ago
Sure, but this isn't a benchmarking paper.
20.
by mehrdadn 6y ago
Even more trivial: sum from 1 to n, then never use the result. It should get optimized out entirely!
21.
by mehrdadn 6y ago
Ordering is not the only concern here. std::set actually provides a logarithmic worst-case guarantee, whereas std::unordered_set does not. This is a factor to consider depending on the application, regardless of whether ordering is necessar
22.
by mehrdadn 6y ago
I'm not trying to write the most horrible comparison at all. Perhaps the most important thing to keep in mind here is that this is a general computer science paper, and my comparison of C++ and Python is just intended to serve as a f
23.
by mehrdadn 6y ago
At least GCC was (and by now Clang and probably others are) known for occasionally optimizing out certain uses of functions like strlen(), which can change the time complexity in some trivial cases. For instance, if you consider strcmp(x, y
24.
by mehrdadn 6y ago
Oh yeah I think you did find a bug, thanks for pointing it out! I need to check the lengths as well. It shouldn't affect the conclusion (in fact I think I made all comparisons equal-length in the paper?) but I should revise it when I g
25.
by mehrdadn 6y ago
If you're wondering whether this is a theoretical or practical problem: I actually observed some of this effect in practice first, and only after thinking about it for a while did the larger issue (and the complexity implications) dawn
26.
by mehrdadn 6y ago
Given everyone's interest in the topic, can I also share something I wrote under "accidentally quadratic"? I think people might enjoy reading it: https://news.ycombinator.com/item?id=26337913 It turns out tha
27.
Accidentally quadratic: When Python is faster than C++(arxiv.org)
218 points by mehrdadn 6y ago|213 comments
28.
by mehrdadn 6y ago
It might be common practice but it shouldn't be. There are lots of reasons this is a bad idea; here's just a sampling: 1. "My return type is whatever I happen to return" circumvents the ability of the type checker to e
29.
by mehrdadn 6y ago
Probably not a good idea since the caller won't know what the return type is at that point, and the return type would become dependent on the implementation, which breaks function abstraction. And imagine what would happen when you get
30.
by mehrdadn 6y ago
It's not just the latest version though? C++11 could already do what you wanted.

More ›