Searching from 2023-02-20 00:00:00 to 2023-02-20 23:59:59.999999.
Query completed in 0.40 seconds
[2023-02-20 07:42:06] --> monr0e has joined the channel
[2023-02-20 07:42:10] --> delinquent has joined the channel
[2023-02-20 13:47:42] <Z-Man> There is no right way to use strings, only different ways to get them wrong :) On Unix, your system functions use utf8, represented as char * or std::string. On Windows, you have two sets of system functions: Those accepting plain old ascii (with support for other encodings like latin1) as char * or std::string or CString. These functions end with A. Then you have unicode enabled functions ending in B that use utf16, represented as wchar *,
[2023-02-20 13:47:42] <Z-Man> std::wstring (or u16string?( or CWString (I think). Then, depending on whether you set your project to have Unicode support or not, they have, for example, a #define that maps GetObject to GetObjectA or GetObjectB. Because it's a #define, it also messes up your symbols, which is always fun, because it even breaks their "Go to definition"; use that on a GetObject call somewhere and it will always just find the stupid macro. .NET uses utf16
[2023-02-20 13:47:42] <Z-Man> consistently.
[2023-02-20 13:48:29] <Z-Man> I'm rather confused myself right now. The reference for the filesystem::path constructors https://en.cppreference.com/w/cpp/filesystem/path/path say:
[2023-02-20 13:49:08] <Z-Man> If you pass in a std::wtring, the input is interpreted as native wide and no conversion happens on Windows. However,
[2023-02-20 13:49:49] <Z-Man> if you pass in a std::u16string, the input is interpreted as UTF-16.
[2023-02-20 13:55:58] <Z-Man> Which seems to imply that Windows is not using UTF-16 at all, but just plain 16 bit unicode with higher code points just not available? I deal with those things all of the time, but I have not encountered characters requiring more than 16 bits, so I don't really know.
[2023-02-20 13:57:33] <Z-Man> Either way: If you prefer all strings to be UTF-16, just use that! Making std::u16string your default string class seems to be the way to go for that.
[2023-02-20 13:59:26] <Z-Man> You then just don't use any functions accepting plain "char const *", but "char16_t const *", probably also typedef'd to cChar or something.
[2023-02-20 14:00:45] <Z-Man> Everyone writing string literals has to use the "u" prefix: https://en.cppreference.com/w/cpp/language/string_literal on any system, so there will be no surprise compilation fails.
[2023-02-20 14:01:54] <Z-Man> And everyone who wants to convert a file path back to a string has to use the explicit u16string() conversion function, implicit conversions work for nobody. Again, no surprises when switching systems.
[2023-02-20 14:03:58] <Z-Man> "No surprises, but also maximum convenience for everyone" is only possible if you write wrappers for both file paths and strings, because only then you can define suitable implicit conversions that do the right thing.
[2023-02-20 14:06:00] <Z-Man> (Reminds me to rant some more about Windows, where there is an implicit conversion from BSTR, which is UTF-16 or whatever, to CString, which is 8 bit, and it only works if the source is representable in ASCII. Both classes are controlled by Microsoft. Also, CString is not move semantics enabled. Rant over. For now.)
[2023-02-20 15:07:19] <Z-Man> OOOH wchar_t is 32 bit on Linux, so std::wstring uses 32 bit characters there. Definitely go with u16string and char16_t for UTF-16 everywhere.
[2023-02-20 15:20:05] <Lucifer_arma> Well, I did use filesystem::path for expediency. There's no technical reason to use it, other than it has all the path operations I need built in, but that means there's no reason that code can't be rewritten and made part of Path, using cerritos' own string class
[2023-02-20 15:22:34] <Lucifer_arma> Path is required, though, because one thing I learned from Python, there's still no cross-platform way to find files on the hard drive. SO it's basically a c++ version of a python module I've been copying back and forth from one project to the next for like 15 years :)
[2023-02-20 15:25:54] <Lucifer_arma> there is a point where I may create separate python modules for cerritos stuff that can be distributed separately from cerritos, because Path is just too useful. On the other hand, there's an argument for just taking my pure python path module and turning that into a distributable package
[2023-02-20 15:28:07] <Lucifer_arma> but at some point, Path needs to be more generalized, so it can support any arbitrary directory structure. that'll be needed for android/ios support, and probably for xbox and playstation support in the future.
[2023-02-20 15:28:28] <Lucifer_arma> and of course any new gaming platforms that come out that don't use an underlying posix directory tree
[2023-02-20 17:14:51] <Z-Man> Yeah, I figured things were still in flux, it was just that the path/string issue was what broke compilation in the here and now.
[2023-02-20 17:14:51] <Z-Man> Shame about sprites being deprecated. They are the one thing explicitly game related that I saw working :) (Well, and input.) I did not bother turning up my speakers to check if sound was working...
[2023-02-20 17:14:51] <Z-Man> About testing in Wine, I'll probably try some time. Somehow, the CPU upgrade left me with all of my virtual machines inoperable. Instructions would be different, apparently winget does not work in wine, and you probably also would rather use something less bloated than Visual Studio.
[2023-02-20 17:14:51] <Z-Man> Speaking of bloat, yeah, boost can be a problem there. There is a boost package in conan with options that let you omit many sub-libraries. It still may download the whole thing first, though; I have not tried.
[2023-02-20 17:18:49] <Z-Man> Ah! I just have to disable 3D acceleration and the VMs work.
[2023-02-20 17:21:59] <Z-Man> That may even be unrelated to the CPU change. I switched to Gnome on Wayland a couple of weeks earler because FVWM and X11 suddenly got choppy as hell.
[2023-02-20 17:22:21] <Z-Man> s/earler/earlier/
[2023-02-20 19:55:20] <-- monr0e has quit (Ping timeout: 260 seconds)
[2023-02-20 19:58:54] <-- delinquent has quit (Ping timeout: 480 seconds)
View entire month
DISCLAIMER: These logs of public chat may contain some content which may not be appropriate for all audiences. Use at your own risk.
Logs from 2006-2009 pulled from wrtlprnft
Format changes at: 2015-08-25, 2017-02-20, and 2020-03-23. Times (2015 and later) should be Eastern.