Emoji for C++ developers: converts emoji codes in strings to unicode emojis
github.com
github.com
- non static and non namespaced global variable EMOJIS (should be inside the emojize method or at least in the namespace)
- lack of STL use, that std::string replacing code doesn't look very "modern" at all
- complete lack of unit tests
- README has unsupported emojis under the "supported" header
The implementation honestly should be put in .cpp file, not a header. Currently it will define both the gigantic statically-initialized map and a function in each module where it's used. Compared to consequences of this lack of unit tests looks like nit-picking.
And yeah, the logic of the function is easy to follow, so it's definitely not modern C++.
It isn't easy to follow at all, count how many "+1" had to be added just to get indices working right, it's a mine field of off by one errors.
You can't be serious.
This is the sort of thing that turns me off C++ completely. It used to be a pragmatic extension to C, now it's about trend-chasing.
The code could be simpler (the extra "index" which is essentially a state variable is odd), but IMHO it is otherwise perfectly fine. Useless superficial criticism like this is just another form of cargo-culting.
no, it's about maximizing performance, because C++ libs are what countless software build upon. Maybe someone will want to use this to display a 4*4k mural screen with 2000000 of those displayed and changing in real-time. Just using a <map> instead of a hash-container (there's a compile-time one just on top of HN right now which would fit the bill perfectly since these are known at compile time) is already a fairly big smell.
- for (int i = 0; i < sLen; i++) {
+ for (int i = 0; i < s.size(); i++) {
- int goBack = i - index + 1 - emo.size();
- sLen -= goBack;
- i -= goBack;
- index = -1;
+ i = index + emo.size();
+ index = -1;
(As you might have gathered, I'm not a fan of emojis. Get off my lawn!)
You might want to make emojize a template which could handle string, wstring, string_view, etc.
A fun extension would be to add a flag to istream and ostream that told it to emojify/demojify output. I.e. use case would be:
std::cout << emojicpp::emojify << "here is a string. :smile: !" << std::endl;
std::cin >> emojicpp::demojify >> some_string;
I think it's good that you have the most popular encoding for your source and don't have non-printable characters in there. I'm pretty sure the majority of fonts won't display them correctly. So I'd absolutely prefer to not have emojis in my code.
There's also no drawback to doing this, since emojis all have unicode names anyway. So it's not like you're creating an entirely new standard.