Re: anyway to run c++ code with out a laggy editer like vs or CodeBlocks?
You can't decompile cython. Source: all of Synthizer is Cython and I've literally read the generated C code for debugging.
But what you don't know is that you *can* decompile any .net language. You can also decompile any language on the JVM. Just like with Python, there are ways to protect your code more, but the point stands. You can also probably decompile Go, though I've never looked into it (it compiles to assembly, but the Go compiler does little to no optimization by design).
If you care about decompiling so much that it's literally going to guide your language choice, your options are C++ or Rust. If you go C++, we might see a game or something out of you in a couple years, but probably you'll give up before then. If you go Rust you'll have to deal with the lack of an accessible UI library and also you can't design games using the standard programming methods for designing games because reasons.
But I just have to say I'm massively facepalming, because yet again the forum is back on "but I need to protect my code". Right on schedule, has been about a month since the last one.
@23
I have a decent amount of Rust code in prod and have contributed a big set of changes to their compiler as well. It's easier than C++, but is different in a lot of ways and not suitable for every project, though I intend to use it for some personal stuff as well in the mid-term future (why Synthizer isn't Rust is complicated).
But for your case, the real problem is wchar_t. I deal with this by designing my C++ interfaces to always take UTF8 at the boundary, which addresses the "oops, it's not a char" problem. But there's no need to switch languages to deal with it. In Python, both Cffi and Ctypes have support for it, and every other language I've seen an FFI in also has some support for it as well. If it doesn't, you can just find the type definition and match it; in this case, I'm pretty sure wchar_t is either int16_t or uint16_t, and you might even be able to get away with short.
That just leaves converting the string to the right encoding. In this case, the missing piece of information that you need is that Windows uses utf16, so in Python, just mystring.encode("utf-16") to get a buffer of bytes and a little bit of pointer casting and you're done.
No language (not even Rust) is going to make this that much easier. The problem here is that Windows is the odd one out and everyone else uses utf8 and char. Basically, your real problem is "c++ unicode sucks and everyone hates it".
@27
Here's a page on template specialization: https://en.cppreference.com/w/cpp/langu … ialization
And try this one on constraints which I can't wait for MSVC to fully support: https://en.cppreference.com/w/cpp/language/constraints
The problem with C++ is that the tutorials for learning it show you how to use it, but don't talk about the edge cases. But as soon as you do anything serious, the edge cases just show up until you learn them all and figure out how to read things like cppreference. Do it long enough and you begin to see the method to the madness and the edge cases actually start making sense, and a bit after that you can abuse them for fun, profit, and most importantly performance and clean and safe interfaces. But I think it took me 2-3 years of serious C++ coding to be able to write good software in it and an additional 1-2 beyond that to become an expert, and the reason camlorn_audio died is in part me making the mistake I warn everyone off of, that being assuming it's as easy as it seems when you're a newbie.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
