I would like to implement a version of c++, it is understandable that this might have been discussed before. Thus I would like to open this up for discussion.
Please do not let this topic devolved into flame wars about why c is better than c++, vice versa.
Can’t hurt to have more implementations. There is quite a few already being developed for various languages. e.g. commonmark implementations
The biggest concerns is how to get everyone in lockstep with specification.
Also, will there be any non-standard extensions? And if so, how will various implementations at least stay in touch with other implementations to ensure that non-standard syntax do not diverge too much (making it easier to introduce into official spec eventually) here is a page tracking non-standard extensions
Yes, I was searching for various implementation and there seems to have the missing c++ implementation.
I completely understand this getting everyone involved with the specification.
No, I do not plan to develop for non-standard implementation which is the next topic which I would like to raise separately. My personal feeling is that the official specs should be fulfilled and the specs itself should be supportive of all extensions.
Not saying either way. But there is already a C implementation, which you can use in C++ projects as well.
Maybe a clean C++ wrapper around the C implementation would be good. This way at least these two libraries would give identical results.
Is there any potential advantages to a pure C++ lib, as opposed to a wrapped C lib? E.g. do we get any speed benefits? Is it more flexible for string sizes?
No speed benefits (what you do in C++ you can do in C if is not templates, and an commonmark doesn’t fit that much).
The possible benefit (but also a cons) is to work on C++ streams natively.
In general C++ for libraries constraints the audience if it uses C+±only types so it is usually not done.
Again, the more independent implementation and languages the merrier!
Please go ahead! No need to discuss. Implementations in
any and all languages are welcome, just be aware that the
spec is still a work in progress and will change.
Ethan_Lim. Basically, what it seems like, is that a C wrapper is the best choice for your C++ implementation. Not everyone wants to recode the wrapper again and again, so coding one up will save some ease and time for C++ users.
I don’t agree with basing your code on C to do this because it would prevent very helpful facilities only available in recent C++.
I have found several times a need for such library in my applications where I didn’t want to load a webview just to have markdown working in a (custom) textarea.
Also it might help making more Jekyll-like tools that don’t force you to install a specific programming language to be used.
Unfortunately I couldn’t start such a library mysefl because of lack of time (which is taken by my projects and dayjob) but I think I could participate sometime to such a library to help my own projects.
So, you are proposing more work (instead of just writing a nice adapter) to use features in C++ which should help to implement something which wasn’t necessary in the first place (since it is already done). And for that more work, of course, you have no time. That’s quite efficient… But hey, it would use (not necessarily have) better features…
By experience, I don’t believe a “nice wrapper” is less work in this specific case (that’s what I initially assumed, though, but it will be hell to maintain or even make efficient enough for my use case) and it was not already been done last time I checked (not in a way that I could use at least).
But that’s my personal opinion after having considered how to make such library, I might be wrong, but still disagree. I think all approaches are valid for such library and in my mind the wrapper approach is problematic at least for my use case.
But of course it might work for others. 
As someone else pointed, the more implementations we have (even in the same language) the better.
Okay let’s be harmonious here.
Realistically, I don’t think C++ is gonna be more efficient to the current implementation. Kudos to the people who did it.
On the other hand, since this is a c++ implementation, without regards to the whichever already being done. We can make use of traditional class, oop for this evolving standard.
I do have one question though, would it be possible in future to merge into this official repo. The reason is of choice for adopters to choose from.
No, having the js and the C implementation in a single repo isn’t that useful beside to keep in sync the specification.
Would be nice have the org keep a mirror of the known-to-be-good implementations across languages to help people get a known-compatibile implementation across languages.
Those that are vocal but with no time should try to figure out a mean to pool a bit of time since otherwise they do not help at all =/
Yes, I agree having a set of implementation by others in the repo as submodules is a great idea.
Not submodule but just clones of the original repos to provide additional visibility.
Here’s a list that can be added to: https://github.com/jgm/CommonMark/wiki/List-of-CommonMark-Implementations