5 ms·

Emoji for C++ developers: converts emoji codes in strings to unicode emojis

31 points by delvincasper 8y ago

deleted 8y ago
[deleted]
m_eiman 8y ago
Why not just use the emoji..?
- wink 8y ago
  Same discussion as when people shifted the encoding of their source code files from iso to utf-8? :) 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.
- mywittyname 8y ago
  I think emojis are less clear than plain text. Even with a good Emoji font-set, I have no clue what more than half of the emojis out there are supposed to be; on Windows, I have no clue what like 90% of them are since they are monochrome outlines. Also, inputting Emojis on most PCs is a pain. 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.
speps 8y ago
Some issues with this project: - 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
- delvincasper 8y ago
  Thanks for the feedback. I will do improvements
- mbel 8y ago
  > - non static and non namespaced global variable EMOJIS (should be inside the emojize method or at least in the namespace) 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++.
  - speps 8y ago
    > 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.
    - huhtenberg 8y ago
      > It isn't easy to follow at all You can't be serious.
      - speps 8y ago
        You just commented a suggested improvement which proves that it's not easy to follow code. Your suggestion is very good, you still had to process the previous code to understand and it wasn't clear at first.
- userbinator 8y ago
  doesn't look very "modern" at all 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.
  - jcelerier 8y ago
    > It used to be a pragmatic extension to C, now it's about trend-chasing. 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.
- yarosv 8y ago
  I'm not C++ developer, but isn't str::string STandard Library?
skocznymroczny 8y ago
Good thing the gun emoji doesn't kill people anymore.
torgoguys 8y ago
FWIW, I'd love to have a browser plugin that does the reverse, converts emojis it finds on webpages into plain text strings... (As you might have gathered, I'm not a fan of emojis. Get off my lawn!)
- thrower123 8y ago
  The automatic emoji-fying is my most hated feature in Skype for Business. If you're copying code snippets around, prepare to get mangled
- swebs 8y ago
  It seems like there are a million string replace extensions for Firefox. You could just use one of those and import the dictionary from OP's README file.
huhtenberg 8y ago
Purely in terms of code readability: - 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; :)
phuz10n 8y ago
Thanks! This is pretty cool
gumby 8y ago
Nice idea! 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; Your stream inserter/extractors could be template functions that take references to constant string-like objects -- then you wouldn't have to copy the string and could just output the appropriate data (though you'd need a lookahead buffer for stuff like these:characters).

31 points by delvincasper 8y ago

deleted 8y ago

[deleted]

m_eiman 8y ago

Why not just use the emoji..?

wink 8y ago
Same discussion as when people shifted the encoding of their source code files from iso to utf-8? :) 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.
mywittyname 8y ago
I think emojis are less clear than plain text. Even with a good Emoji font-set, I have no clue what more than half of the emojis out there are supposed to be; on Windows, I have no clue what like 90% of them are since they are monochrome outlines. Also, inputting Emojis on most PCs is a pain. 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.

speps 8y ago

Some issues with this project: - 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

delvincasper 8y ago
Thanks for the feedback. I will do improvements
mbel 8y ago
> - non static and non namespaced global variable EMOJIS (should be inside the emojize method or at least in the namespace) 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++.
- speps 8y ago
  > 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.
  - huhtenberg 8y ago
    > It isn't easy to follow at all You can't be serious.
    - speps 8y ago
      You just commented a suggested improvement which proves that it's not easy to follow code. Your suggestion is very good, you still had to process the previous code to understand and it wasn't clear at first.
userbinator 8y ago
doesn't look very "modern" at all 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.
- jcelerier 8y ago
  > It used to be a pragmatic extension to C, now it's about trend-chasing. 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.
yarosv 8y ago
I'm not C++ developer, but isn't str::string STandard Library?

skocznymroczny 8y ago

Good thing the gun emoji doesn't kill people anymore.

torgoguys 8y ago

FWIW, I'd love to have a browser plugin that does the reverse, converts emojis it finds on webpages into plain text strings... (As you might have gathered, I'm not a fan of emojis. Get off my lawn!)

thrower123 8y ago
The automatic emoji-fying is my most hated feature in Skype for Business. If you're copying code snippets around, prepare to get mangled
swebs 8y ago
It seems like there are a million string replace extensions for Firefox. You could just use one of those and import the dictionary from OP's README file.

huhtenberg 8y ago

Purely in terms of code readability: - 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; :)

phuz10n 8y ago

Thanks! This is pretty cool

gumby 8y ago

Nice idea! 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; Your stream inserter/extractors could be template functions that take references to constant string-like objects -- then you wouldn't have to copy the string and could just output the appropriate data (though you'd need a lookahead buffer for stuff like these:characters).