|
Twerk from Home posted:I'm excited about the idea of a "linux from 2003" docker image, but also concerned because these things now need more than 4GB of RAM because of how much bigger DNA chips have gotten since then and I'm worried that 64-bit linux stability was not good until some time after that. 64-bit Linux has been a thing since the DEC Alpha port in the mid 90s. This isnt Windows we're talking about here.
|
#
?
Feb 15, 2020 20:21
|
|
|
|
| # ? Jun 8, 2024 23:58 |
|
|
I’m sorry Microsoft, but no matter what the nag warnings you’ve added to the latest version of Visual Studio 2019 say, I cannot change vulkan.h to use enum class instead of enum  “VkResult is unscoped. Prefer ‘enum class’ over ‘enum’” etc etc etc x1000
|
|
#
?
Feb 16, 2020 02:54
|
|
|
VS has a mechanism that lets you define external headers according to some criteria and set a different warning level for these. See blogpost for excessive detail, short version isLe Microsoft posted:We offer a new compiler switch group: /external:* dealing with “external” headers. We chose the notion of “external header” over “system header” that other compilers use as it better represents the variety of 3rd party libraries in existence. Besides, the standard already refers to external headers in [lex.header], so it was only natural. We define a group instead of just new switches to ease discoverability by users, which would be able to guess the full syntax of the switch based on the switches they already know. For now, this group consists of 5 switches split into 2 categories (each described in its own section below): That was in 2017, I don't know if /experimental:external is still required. I've never used this, we manually push/pop warning levels around "bad" header includes at work. Consequences of include being a fancy copy-paste function, really.
|
|
#
?
Feb 16, 2020 03:09
|
|
|
I’ve already done the push/pop warnings around the includes thing, but the warning still randomly comes back. Like, I’ll have some code that’s like “VkResult result = vkDoSomething();” and VS will complain about VkResult not being enum class for that line. Doing it around the whole source file makes the warning permanently go away, but that’s not really ideal, even though in this case it’s harmless.
|
|
#
?
Feb 16, 2020 03:36
|
|
|
Huh. That shouldn't happen. Is it possible VkResult is first encountered as a transitive include from some other header, internal or external, that's outside of your push/pop pragma? Is vkDoSomething() a macro?
|
|
#
?
Feb 16, 2020 03:44
|
|
|
rjmccall posted:I assume Xarn went to the committee meeting and discovered that they’re somehow even more dysfunctional in person. Standards, like laws and sausage, are things that you’re better off not knowing how they are made.
|
|
#
?
Feb 16, 2020 03:53
|
|
|
Xerophyte posted:Huh. That shouldn't happen. Is it possible VkResult is first encountered as a transitive include from some other header, internal or external, that's outside of your push/pop pragma? Is vkDoSomething() a macro? I won’t be at home to look at my PC until this afternoon, but I don’t think so. Typically, vulkan.h needs to be included before any other headers related to Vulkan:
|
|
#
?
Feb 16, 2020 14:51
|
|
|
Zopotantor posted:Standards, like laws and sausage, are things that you’re better off not knowing how they are made. And not unlike spectacular crashes, where you cannot help but stare and wonder what series of unfortunate events led to that point.
|
|
#
?
Feb 17, 2020 12:36
|
|
|
Since the OP is outdated by over 10 years: What are some good resources to learn C++ nowadays? I'm looking at some junior-level jobs that require some knowledge of C++, but the only C++ code I've ever written was during my Master's thesis project and I feel like I don't know anything about the language. I picked up the other programming languages I know mostly by just working with them, but somehow that seems to be much harder with C++.
|
|
#
?
Feb 18, 2020 00:46
|
|
|
I've heard that Tour of C++ should get you up to speed on the latest language features. Core Guidelines may also be helpful. qsvui fucked around with this message at 05:16 on Feb 18, 2020 |
|
#
?
Feb 18, 2020 04:57
|
|
|
Tour of C++ is exactly what I was looking for. Thank you.
|
|
#
?
Feb 18, 2020 21:44
|
|
|
Does anyone know of good container/algorithm library that implements something similar to Java streams or the C# equivalent (I want to say LINQ but iirc that's a DSL kindof?)
|
|
#
?
Feb 26, 2020 03:57
|
|
|
Never used Java but if by C# LINQ you mean some functional/declarative way of manipulating sequences, then I guess range-v3 sounds the closest
|
|
#
?
Feb 26, 2020 05:51
|
|
|
Is there a modern and correct way to add a library to my Visual Studio 2019 project? I'm interested in using fmt https://github.com/fmtlib/fmt In the past I've had to: clone the source, completely re-learn how to run the CMake gui and run it, point it at the folder, generate the Visual Studio project files (if it fails for any reason then I'm just SOL), then open the visual studio projects and try to build (again, if it fails.. I just give up) and then edit about half a dozen settings in my project to link the libarary. Is there an easier way?
|
|
#
?
Feb 27, 2020 19:21
|
|
|
Yes, write your CMakeLists.txt properly 
|
|
#
?
Feb 27, 2020 21:53
|
|
|
Checkout vcpkg, it's amazing. I rarely use windows, but when I had to port something to it, vcpkg was a life saver. Then yes, write your cmake properly , don't forget to account for the little VS,/cmake/windows idiosyncrasies, and if you have any hair left after all of this, your project will compile buttery smooth.
|
|
#
?
Feb 27, 2020 22:34
|
|
|
There's little they can do to make cmake and some 3rd party library's usage thereof friendlier. Also I'm pretty sure no one has ever written a CMakeLists.txt properly, cmake seems almost purposefully designed to provide so many equally shite ways of doing something that the officially recommended one doesn't stand out. Anyhow, options: 1) Embrace cmake and all it stands for. This wont make building fmt any easier, but it may make linking it simpler since there are cmake modules for fmt floating around. This one seems mostly sane from a quick scan, but the windows section might need some tweaking. To use it you'd set CMAKE_MODULE_PATH for your project to point to wherever you keep FindFmt.cmake and other module files for the project, then write code:2) Shun cmake and all it stands for. fmt is, far as I can tell, two source files and a half dozen headers. Just grab that source for whatever release you want and build it as part of your VS solution, as a normal VS library project. Or as a cmake library if you prefer that, but it doesn't sound like it. I've never tried one of the VS package management solutions. My immediate reaction is mild skepticism since MSVC can be pretty particular about things like library type flags and debug info format for static linking but maybe they work great, damned if I know. Personally I'd always include something that tiny as source rather than set up any sort of binary external, but possibly I have been drinking the cool-aid.
|
|
#
?
Feb 27, 2020 22:50
|
|
|
baby puzzle posted:Is there a modern and correct way to add a library to my Visual Studio 2019 project? VS 2019 has integrated support for CMake so you can just open your folder that has the root CMakeLists.txt. This link should explain more: https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019
|
|
#
?
Feb 28, 2020 04:24
|
|
|
The simplest thing to do is to add a submodule ref to fmtlib/fmt at whichever commit you like, then add_subdirectory the dir where you keep it, and then just target_link_libraries(MyProject PRIVATE fmt::fmt) (or PUBLIC if you export your own headers that mention fmt...). This will work because it provides an aliased target, see https://github.com/fmtlib/fmt/blob/bed134a4aad3de93b2ba0e1a59a51b662243b7e8/CMakeLists.txt#L166
|
|
#
?
Feb 28, 2020 11:11
|
|
|
If you don't wanna use submodules, then you can get CMake to grab projects using FetchContent
|
|
#
?
Feb 29, 2020 03:53
|
|
|
nvm i'm not into this today
baby puzzle fucked around with this message at 16:22 on Mar 5, 2020 |
|
#
?
Mar 5, 2020 16:18
|
|
|
Just stumbled upon this function in a repo and I'm utterly befuddled:code:The (void)status; is probably to satisfy some sort of "you're not using the argument, dummy", but the last line...
|
|
#
?
Mar 6, 2020 14:51
|
|
|
bolind posted:Just stumbled upon this function in a repo and I'm utterly befuddled:
|
|
#
?
Mar 6, 2020 15:00
|
|
|
pseudorandom name posted:... crashes the program. Seems to be taken from one of the shittier answers to the stackoverflow question "what is the easiest way to make a C++ program crash?". It's an approach used in popular applications. Unfortunately.
|
|
#
?
Mar 6, 2020 15:28
|
|
|
Xerophyte posted:Seems to be taken from one of the shittier answers to the stackoverflow question "what is the easiest way to make a C++ program crash?". It's an approach used in popular applications. Unfortunately. I use it to test my crash handlers because abort() doesn't work for that. Which solution isn't lovely?
|
|
#
?
Mar 6, 2020 21:14
|
|
|
Does raise(SIGSEGV) not work?
|
|
#
?
Mar 6, 2020 21:18
|
|
|
I don't know. I guess I stopped at the first thing I tried that worked.
|
|
#
?
Mar 6, 2020 21:26
|
|
|
baby puzzle posted:I use it to test my crash handlers because abort() doesn't work for that. Get an aligned pointer, memprotect it unwriteable, write to it.
|
|
#
?
Mar 6, 2020 21:34
|
|
|
Xarn posted:Does raise(SIGSEGV) not work? Not every platform is Unix. Basically every platform (not all!) will crash if you write to address 0.
|
|
#
?
Mar 6, 2020 21:53
|
|
|
baby puzzle posted:I use it to test my crash handlers because abort() doesn't work for that. raise is intended for that sort of thing and will guarantee that a specific signal handler is called. I'm sure there's a lot of fun OS-specific behavior around this so maybe it's not always sufficient, I don't honestly know. It's not the end of the world to cause a crash in some other way of course, the problem is that it's surprisingly hard to write crashing code that doesn't rely on undefined behavior. *((unsigned volatile int *)0) = 0xDEAD specifically is undefined so your compiler may decide that it's unreachable and optimize it away or otherwise pull your rug out from under you in interesting ways. It probably wont, but it's still a pretty brittle approach.
|
|
#
?
Mar 6, 2020 21:54
|
|
|
Hmm, what are semantics for integer divide by zero at the language level?
|
|
#
?
Mar 6, 2020 22:07
|
|
|
OddObserver posted:Hmm, what are semantics for integer divide by zero at the language level? In C, it's undefined. Also in C++ I think.
|
|
#
?
Mar 6, 2020 22:12
|
|
|
From the latest draft in glorious standardese:https://github.com/cplusplus/draft/releases/tag/n4849 posted:7.1.4 If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined. [Note: Treatment of division by zero, forming a remainder using a zero divisor, and all floating-point exceptions varies among machines, and is sometimes adjustable by a library function. — end note]" So, yeah, undefined in the language.
|
|
#
?
Mar 6, 2020 22:18
|
|
|
I strongly recommend eel.is (e.g. https://eel.is/c++draft/expr.pre#4) and non-numbered links for referring to standardese more falafel please posted:Not every platform is Unix. Basically every platform (not all!) will crash if you write to address 0. raise is part of the C (and thus C++) standard library, and while the implementations are allowed some latitude in dealing with it (namely, the default handler is allowed to plain ignore the signal), it is much saner way to ask for SIGSEGV on most platforms that support C++ than to invoke UB and cross your fingers that optimizer will not do stupid poo poo with it. (And yes, raise works on Windows by default)
|
|
#
?
Mar 6, 2020 23:43
|
|
|
more falafel please posted:Not every platform is Unix. Basically every platform (not all!) will crash if you write to address 0. signal() and raise() are part of the C standard.
|
|
#
?
Mar 6, 2020 23:54
|
|
|
Even putting formal semantics aside, some architectures define integer division by zero to yield zero instead of trapping, including MIPS and ARM64.
|
|
#
?
Mar 7, 2020 02:44
|
|
|
Right. Not all CPUs were originally designed as calculators.
|
|
#
?
Mar 7, 2020 17:21
|
|
|
pseudorandom name posted:signal() and raise() are part of the C standard. This is true, but it’s not clear to me that the semantics of raise(SIGSEGV) are standardized to have the effect that’s desired here. It reads to me (though I can’t seem to copy from the PDF in my browser; 7.14.2.1 and 7.14.1.1 in C11) that it basically just calls the established signal handler, and not that it would necessarily and portably result in program termination or similar. It certainly seems permissible that SIGSEGV could be ignored by default, at the implementation’s discretion. POSIX seems to be where the desired semantics are specified, rather than C11.
|
|
#
?
Mar 7, 2020 18:42
|
|
|
I think you're right that SIGSEGV can be ignored by default, but that's because the standards don't require an implementation to detect or have any invalid memory access errors at all. They can only require that explicitly raising a SIGSEGV signal calls your SIGSEGV handler if you have defined one, since that places no requirements on the platform. On platforms with advanced features like interrupts and memory access failures I think you may expect that calling the handler is in fact equivalent to forcing an actual error, same as POSIX specifies. I may also be horribly wrong about that and about to be annoyed as someone informs me that windows does this stupidly in some fun way. Anyhow, for the purpose of checking that your bespoke diagnostic signal callback works, explicitly calling the signal handler with raise should to my knowledge be as good as forcing an actual invalid memory access. For the purpose of forcing the CPU to trap raise is less useful, but then you're well outside of things defined by C and C++ language semantics. I don't know exactly what the purpose was for the wtfunction thing that spawned this discussion. Odds are that if the objective is to terminate uncleanly on some specific platform then there's a better way to do that than trying to wrangle a write to a null address in an undefined way.
|
|
#
?
Mar 7, 2020 19:51
|
|
|
|
| # ? Jun 8, 2024 23:58 |
|
|
Didn't some embedded systems put the interrupt vector at address 0? :p
|
|
#
?
Mar 7, 2020 22:18
|
|