|
-Wall -Wextra -Wno-unused
|
#
?
Sep 17, 2021 19:08
|
|
|
|
| # ? Jun 1, 2024 15:27 |
|
|
Rocko Bonaparte posted:Why might g++ decide to just skip a null check? I am assigning a pointer with a helper function that instead returns NULL. I then test NULL with an if-statement. In the debugger, I can see the pointer is NULL. It then rockets right past the conditional and goes straight into trying to use it. The best part about making this mistake is that code like that sometimes just happens to work if the return value happens to be in the right register.
|
|
#
?
Sep 17, 2021 19:15
|
|
|
So I grew to like the Qt framework while using Python, through PyQt, which was easily accessible, just a pip install away. How in hell do I get a hold of the compiled Qt binaries for C++? Or is there another GUI solution for C++ that's better? (I ask...because I hate to switch away from something I'm at least passing familiar with, with a nice GUI designer.)
|
|
#
?
Sep 18, 2021 19:58
|
|
|
There is a QT online installer which supposedly gets them for you? I don't really use QT and be warned that they've been making using them more and more annoying (to get you to pay for licence).
|
|
#
?
Sep 18, 2021 20:08
|
|
|
Could you use a package manager like conan.io or vcpkg to get the QT libraries required? Genuinely curious actually because there are qt packages available for either but I know the licensing for QT is not totally free.
|
|
#
?
Sep 19, 2021 13:54
|
|
|
On Windows I generally just use the installer.
|
|
#
?
Sep 19, 2021 14:10
|
|
|
However, vcpkg provides quite a bit more packages than just Qt, should you need or use other libraries as well. Plus, the big advantage is that, if you use CMake, you can work on your project in a different OS, then with just minor changes you can adapt it to compile in Windows with vcpkg. Or viceversa.
|
|
#
?
Sep 19, 2021 19:06
|
|
|
Boy, kyou weren't kidding about making it a pain in the rear end. PyQt was like...seamless because it was just a pip install away. Using VSCode and MinGW because I don't have admin on this machine, are there any other GUI libraries? Expand my product knowledge  EDIT: vvv All of that is new to me - I come from interpreted languages, and this is my first serious foray into a compiled language in over a decade. If building from source is an option, I'll have to look at doing that. Are there any good tutorials for build-from-source/CMake for these packages? D34THROW fucked around with this message at 14:52 on Sep 20, 2021 |
|
#
?
Sep 20, 2021 14:14
|
|
|
In all my years of trying I've never found a library that could live up to Qt. GTK isn't terrible, especially in these days of Electron-everything where the old "but it doesn't look native" complaints seem downright quaint, but it doesn't have the breadth of functionality. Once you get the Qt libraries in place either through the installer, vcpkg, or even just building it from source yourself, it's really easy to get it integrated with a CMake project. No need for any of the weird qmake stuff like in the old days.
|
|
#
?
Sep 20, 2021 14:32
|
|
|
D34THROW posted:Might be an odd question, but are there any standards for C++ coding like PEP8 for Python? Things like standards for variable/class/function naming, code line length, etc. There's not any kind of standard. Google has a set of guidelines that are pretty good: https://google.github.io/styleguide/cppguide.html I don't love their naming conventions, but naming conventions are arbitrary, pick something you like and stick with it. I do a lot of work in UE4, which has its own conventions, which I also don't prefer (I like having a differentiation between members and non-members, but I don't like trailing underscores).
|
|
#
?
Sep 20, 2021 15:19
|
|
|
D34THROW posted:Boy, kyou weren't kidding about making it a pain in the rear end. PyQt was like...seamless because it was just a pip install away. Using VSCode and MinGW because I don't have admin on this machine, are there any other GUI libraries? Expand my product knowledge vcpkg seems to have pretty reasonable qt ports, so setting up vcpkg + cmake should be your next step
|
|
#
?
Sep 20, 2021 17:57
|
|
|
Xarn posted:vcpkg seems to have pretty reasonable qt ports, so setting up vcpkg + cmake should be your next step It sure does! Has a Qt5.15 port...that I can't use because I have VSCode installed to the user, not Visual Studio. Tried to run vcpkg install qt5-base and it errored out right at the end because I have VSCode, not VS. So now I'm building wxWidgets. Only reason I really wanted Qt was because of the designer and my familiarity with it. I didn't much care for building GUIs via code with Tkinter. Thanks for the help, all. I'll figure it out and be back to bug you.  EDIT: vvv Not so much don't want to as can't. Once upon a time, the IT team transmitted the admin credentials in a plaintext email to me, for some reason or other. They have since changed and I've no realistic reason of yet to ask for them again. I'll keep an eye out for those, thank you! God drat does building wxWidgets take a long time on this machine. D34THROW fucked around with this message at 18:56 on Sep 20, 2021 |
|
#
?
Sep 20, 2021 18:16
|
|
|
Might work if you install the visual studio command line build tools (I forget what the package is actually called) if you don’t want to install the full VS for some reason.
|
|
#
?
Sep 20, 2021 18:24
|
|
|
D34THROW posted:Tried to run vcpkg install qt5-base That already means you are using it wrong  I might not fit it today, but I'll write something about this tomorrow.
|
|
#
?
Sep 20, 2021 22:51
|
|
|
Hello, friends. I'm building a new C++ debugger and I'm looking for people who can help test it by using it during a screen share while looking for a bug in their code. If you have some non-NDA source code on Windows that you can screen share and do a bug search on while using the debugger please DM me 
|
|
#
?
Sep 22, 2021 19:00
|
|
|
Xarn posted:That already means you are using it wrong Bleh, I really thought I would do it the next day. Basically if you are writing something from scratch, you should be using CMake + vcpkg's manifest mode, which notably means you won't be explicitly calling the vcpkg tool. Instead you have one or two files in your project dir, vcpkg.json and optionally vcpkg-configuration.json. vcpkg.json describes basic information about your project and its dependencies. A simple one looks like this code:------------------ Sadly it seems that the qt5 port does not support mingw properly anyway: https://github.com/microsoft/vcpkg/pull/20309
|
|
#
?
Sep 23, 2021 20:14
|
|
|
I'm having an end-of-day pointer brain fart here with some goofy C pointer poo poo. Let's say I have a void* pointer voidbutt pointing to an address containing 8 bytes that itself is an address to a string. How do I properly cast that to a char* so I can do strlen and friends on it? I keep copying the pointer to the original buffer and not contained address.
|
|
#
?
Sep 24, 2021 04:11
|
|
|
well it's late and I've been drinking, but your voidbutt is a pointer to a char pointer. Just dereference with char* pcGoodPointer = *(char**)voidbutt E: oh right you have to cast it first, can't dereference void directly. E2: Or just dereference twice? char** ppcFoo = voidbutt; printf("\nfirst char in string: %c", **ppcFoo); PittTheElder fucked around with this message at 04:39 on Sep 24, 2021 |
|
#
?
Sep 24, 2021 04:20
|
|
Yes, it's like a lava lamp.
|
Hmmm... scribbles down notes "Try casting the pointers while drunk." Tomorrow's gonna be a great workday! Edit: Yes, a double dereference was the right direction to go. Somehow I got all cocked up thinking about that as soon as I started looking at the memory map. Rocko Bonaparte fucked around with this message at 16:25 on Sep 24, 2021 |
|
#
?
Sep 24, 2021 04:33
|
|
|
Xarn posted:vcpkg.json Thank you for the information, I had no idea about vcpkg.json . Before, I would always just install the needed packages (and more, like install the entire boost) with "vcpkg install ...." and go from there, but this is so much cleaner.
|
|
#
?
Sep 25, 2021 00:43
|
|
|
I just learned about this C++17 thing:code:Particularly this paragraph is confusing quote:Unsequenced execution policies are the only case where function calls are unsequenced with respect to each other, meaning they can be interleaved. In all other situations in C++, they are indeterminately-sequenced (cannot interleave). Because of that, users are not allowed to allocate or deallocate memory, acquire mutexes, use non-lockfree std::atomic specializations, or, in general, perform any vectorization-unsafe operations when using these policies (vectorization-unsafe functions are the ones that synchronize-with another function, e.g. std::mutex::unlock synchronizes-with the next std::mutex::lock) My *first* confusion is that it's unclear whether the "because of that" sentence refers to the "all other situations" or to the "unsequenced execution policies". After staring at it for a while I'm fairly sure it's the latter. So then this seems to be saying that you can't use mutexes to control unsequenced things, which perhaps makes sense for parallel unsequenced; it seems like a bit of a rude restriction but I guess if you want to do that you can use classic multithreading, and the idea here is for something where the compiler can optimize it more aggressively so it's saying get the gently caress out of here with your locks? But I don't understand how this is a constraint for "unsequenced" rather than a constraint for "parallel". Is it saying you *can* use locks for std::execution::par, and treat it like regular multithreading, but not for std::execution::par_unseq? I think maybe my confusion is that "unsequenced" sounds like it means "no order guarantee", but it looks like actually the whole thing when you use one of these means "no order guarantee" and "unsequenced" means "the compiler should refuse to allow you to use locks, and you shouldn't do any sort of writing to any structures that are not unique to each call to someFunction, optimization will assume this and if you do anything different from that then you hosed up". Is that it?
|
|
#
?
Sep 27, 2021 01:15
|
|
|
Or to put what I think it means another way, I think it's like 1. std::for_each nominally rearranges your iterator order randomly (but in reality probably does not). 2. std::execution::par is approximately equivalent to #pragma omp parallel for followed by a loop over that nominally rearranged iterator 3. std::execution::seq is approximately equivalent to a loop over that nominally rearranged iterator 4. std::execution::par_unseq is like par except it mustn't touch anything that any other thread (including those from this 'par') might be touching 5. std::execution::unseq is like seq except it mustn't touch anything that any other thread might be touching Uncertainty on 5: can calls from unseq touch stuff that is being touched by other calls from unseq, since they're not happening in parallel, e.g. code:
|
|
#
?
Sep 27, 2021 01:26
|
|
|
You can click through to find out what "unsequenced" and "indeterminately-sequenced" mean:quote:"sequenced-before" is an asymmetric, transitive, pair-wise relationship between evaluations within the same thread. "unsequenced" can interleave operations even within a single thread of execution (and even if the compiler can't prove that such interleaving will produce identical results - by using it, you the programmer are promising the compiler that it will be alright!), the restrictions on what you can reasonably do in your function flow pretty naturally from that fact. The bit at the end calling out that your function can't do any "vectorization-unsafe operations" is a big clue towards the type of optimization that it allows the compiler to make.
|
|
#
?
Sep 27, 2021 01:36
|
|
|
Jabor posted:You can click through to find out what "unsequenced" and "indeterminately-sequenced" mean: So my example would *probably* work as expected (but you still shouldn't do that with unseq), but a slightly trickier example would become clearly dangerous with unseq, e.g. doing foo = foo * 2 + 1 on a shared foo would potentially become unpredictable nonsense behavior even in a single-threaded unseq. Very interesting. vvvvv Yeah, that's why I said emphatic-probably and you shouldn't do it.
roomforthetuna fucked around with this message at 04:06 on Sep 28, 2021 |
|
#
?
Sep 27, 2021 01:41
|
|
|
I think your example is a bit sketch even in a single-threaded unseq - it's technically allowable to do, say, reading foo into the four different arms of an SSE register, doing an SSE increment, then writing back all four results, and counting that as four iterations. Which does not give the same result that an indeterminate sequencing would. If you were performing a lockfree atomic increment then it would be safe.
|
|
#
?
Sep 27, 2021 03:07
|
|
|
https://twitter.com/vamchale/status/1442192210561146883?s=21
|
|
#
?
Sep 28, 2021 01:45
|
|
|
I don't quite get how you can know enough to need to write cmake scripts but still not be able to figure it out.
|
|
#
?
Sep 28, 2021 12:47
|
|
|
Private Speech posted:I don't quite get how you can know enough to need to write cmake scripts but still not be able to figure it out.
|
|
#
?
Sep 28, 2021 13:13
|
|
|
roomforthetuna posted:There's probably a significant amount of not wanting to figure it out because it's a pain in the rear end and the makefile you already wrote mostly works so why am I even learning this new thing that sucks?
|
|
#
?
Sep 28, 2021 13:26
|
|
|
CMake is fine and good as long as your script works, but god help you if you need to debug anything.
|
|
#
?
Sep 28, 2021 13:44
|
|
|
roomforthetuna posted:There's probably a significant amount of not wanting to figure it out because it's a pain in the rear end and the makefile you already wrote mostly works so why am I even learning this new thing that sucks? fourwood posted:They’re undoubtedly academics so yeah it’s this. I was assuming it was this plus it was written by grad students so everything about it is a horror, and they aren't incredibly familiar with the thing to begin with.
|
|
#
?
Sep 28, 2021 13:54
|
|
|
leper khan posted:I was assuming it was this plus it was written by grad students so everything about it is a horror, and they aren't incredibly familiar with the thing to begin with.
|
|
#
?
Sep 28, 2021 16:24
|
|
|
CMake seems horrible until you understand that when you give programmers elegant tools to manage build processes with powerful abstractions and clearly defined semantics, they will use those tools to create inscrutable horrors that cause you to go mad just by looking at them.
|
|
#
?
Sep 28, 2021 16:46
|
|
|
CMake fits its niche well and was possibly the first cross platform modern C++ build scripting system and I give it a lot of credit for being that and being very valuable for the C++ community as a whole BUT ALSO the scripting language has historically suffered from some serious syntactical and semantic flaws that the cmake team has somewhat but not entirely dug themselves out of. For example you used to have to repeat the predicate on endif. It's like the person who originally wrote it slept through their compiler class code:code:code:code:Again, CMake is on a whole very useful and I'm glad we have it. Its generation layer I have zero complaints about. But its frontend has some glaring design problems that occasionally make me look around for a replacement.
|
|
#
?
Sep 28, 2021 17:11
|
|
|
Cmake suffers a lot from all the outdated tutorials on the internet. If you do everything the modern way and require a cmake version from the last year, even moderately complex projects can be mostly straightforward and simple. A lot of features you'd consider incredibly basic were added very recently, though, so good luck actually finding a guide that tells you the right way to do things. At best you might find something which is twice as complicated as it needs to be because it's working around a missing feature, and if you're really unlucky it might tell you do to everything incorrectly. Once you're off the happy path and trying to write your own functions or macros everything is completely insane still.
|
|
#
?
Sep 28, 2021 17:22
|
|
|
Plorkyeran posted:Cmake suffers a lot from all the outdated tutorials on the internet. If you do everything the modern way and require a cmake version from the last year, even moderately complex projects can be mostly straightforward and simple. A lot of features you'd consider incredibly basic were added very recently, though, so good luck actually finding a guide that tells you the right way to do things. At best you might find something which is twice as complicated as it needs to be because it's working around a missing feature, and if you're really unlucky it might tell you do to everything incorrectly. A basic CMake task that I expected it to be able to do trivially: Find generic Lapack on Ubuntu 20.04 in /usr/lib/x86_64-linux-gnu for static linking, which is used by OpenBLAS as well as generic BLAS and multiple other BLAS library options. It can't until a bug that was fixed in 3.21, which is too new for me to ask people to use for something distributed: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6036. So instead, I'm just going to direct people to tell it where lapack is by hand with -DLAPACK_LIBRARIES=/usr/lib/x86_64-linux-gnu/liblapack.a . I don't have an idea of how frequently cmake is releasing, but given that C build systems tend to use system packages for all of the libraries you're linking against, I was surprised to find that the Cmake version (3.16) distributed from Ubuntu 20.04 repositories is so old, and apparently too old to Just Work for basic tasks.
|
|
#
?
Sep 28, 2021 18:57
|
|
|
Plorkyeran posted:Cmake suffers a lot from all the outdated tutorials on the internet. If you do everything the modern way and require a cmake version from the last year, even moderately complex projects can be mostly straightforward and simple. A lot of features you'd consider incredibly basic were added very recently, though, so good luck actually finding a guide that tells you the right way to do things. At best you might find something which is twice as complicated as it needs to be because it's working around a missing feature, and if you're really unlucky it might tell you do to everything incorrectly. Honestly you can't post something like this and not talk extensively about these features I probably know nothing about and could probably put to good use. What have they added?
|
|
#
?
Sep 28, 2021 19:09
|
|
|
Vino posted:
The latter is you being bad at cmake, per project flags are easy and old. You absolutely do not want per-file flags. I mean it. Don't. (Honestly you don't really want per project flags that are ABI-changing either, but eh)
|
|
#
?
Sep 28, 2021 20:26
|
|
|
Vino posted:Honestly you can't post something like this and not talk extensively about these features I probably know nothing about and could probably put to good use. What have they added? Nothing exciting; just gradually filling in things that would have surprised you by their absence. Some things from cmake 3.21 that I would have expected years ago: cmake(1) gained the --install-prefix <dir> command-line option to specify the location of the install prefix. cmake(1) gained the --toolchain <path/to/file> command-line option to specify a toolchain file. CMake now supports the MSYS runtime environment, much like CYGWIN. The file(COPY_FILE) command was added to copy a single file The install() command gained a new IMPORTED_RUNTIME_ARTIFACTS mode, which can be used to install the runtime artifacts of imported targets. The add_custom_command(TARGET) command (for Build Events) gained support for resolving target-dependent generator expressions. file(COPY_FILE) is a nice example of something that was just inexplicably missing and sometimes hard to do pre-3.21 (file(COPY) runs at a different build phase). install() not copying runtime artifacts of imported targets is the latest in a long series of issues where imported targets just didn't do a thing they needed to do. Every version of cmake adds support for generator expressions in a few more places and these days it's nearly everywhere, but even just a few versions back and there was some pretty important things which didn't support them.
|
|
#
?
Sep 28, 2021 20:56
|
|
|
|
| # ? Jun 1, 2024 15:27 |
|
|
Xarn posted:You absolutely do not want per-file flags. I mean it. Don't. (Honestly you don't really want per project flags that are ABI-changing either, but eh)
|
|
#
?
Sep 28, 2021 23:39
|
|
