|
You could also define your own std::function analog that isn't copyable.
|
#
?
Feb 12, 2018 05:54
|
|
|
|
| # ? Jun 7, 2024 14:24 |
|
|
Anyone have experience dealing with an overactive Windows Defender? It's labeling one of our programs as "Trojan:Win32/Azden.B!cl" and immediately quarantines the file. We've done full scans on all our developer machines, no threats found, etc. I've audited the changes since our last release (a month ago) and nothing really jumps out at me as a red flag. The (C++) program is compiled using VS 2015, and packaged using iexpress.exe/makecab.exe with a bunch of sed files. A few minutes after packaging (or if we manually copy the file somewhere), Windows complains. We've since moved on to greener pastures re: packaging/deployment, but this legacy app is still being maintained. I guess Defender just sees some "bad" bytes in our executable? I've submitted the file to Microsoft. Anything I can do in the meantime?
|
|
#
?
Feb 12, 2018 19:54
|
|
|
Jeffrey of YOSPOS posted:Fwiw I think you have another error besides the one stated. Hint below if you want it. Hm can I ask for one more hint? Maybe like what values I should put in to a division to manifest the error you see? It appeared to be working for me after I corrected my dumb wrong overload>=.
|
|
#
?
Feb 13, 2018 18:48
|
|
|
SuperKlaus posted:Hm can I ask for one more hint? Maybe like what values I should put in to a division to manifest the error you see? It appeared to be working for me after I corrected my dumb wrong overload>=. Hint 2: What happens when "this" is much larger than op2?
|
|
#
?
Feb 13, 2018 19:23
|
|
|
epalm posted:I guess Defender just sees some "bad" bytes in our executable? I've submitted the file to Microsoft. Anything I can do in the meantime? Yes, and not really. Certain things (monitoring the cursor or keyboard input, any sort of DLL injection) will make the heuristics in Windows Defender go crazy. It's probably your use of sed doing it, if I had to guess. You'll just have to wait for MS. e: If this is for end users then you'll probably have to end up digitally signing your executable with MS eventually assuming something in the code is making Windows Defender mark it as a false positive. New releases are going to flag it all over again. The Phlegmatist fucked around with this message at 19:29 on Feb 13, 2018 |
|
#
?
Feb 13, 2018 19:25
|
|
|
I've got a sizeable game engine going in C++ in Visual Studio (2015 or 2017) and I keep butting my head up against a minor reoccurring issue: When I compile my release version, even if I do a full rebuild, certain things won't get updated. This typically includes #define or other const values that I use to hard-code things, like certain limits (#define MAX_LIGHTS_PER_SCENE, etc), or the default speed something should move at. For example, I have a header file that hard-codes default bindings for inputs in a big array, in case the user profile doesn't load properly, as well as bindings the user shouldn't be able to change (like the escape key to bring up the menu). I reference this header file in my big class that manages game input, because I didn't wanna throw all these big arrays (and other metadata) into the main class file. If I were to change some binding, say the save key, from F5 to F10, it would reflect when I rebuilt my debug build, but my release build stubbornly keeps the old binding. Similarly, the other day I defined a const at the top of a cpp file to set the max distance between to objects for a certain effect to apply. I kept changing this const to test the effect to see if it felt right. I built this in release initially (the debug version can cause slowdowns testing things in DirectX), then played with it a bit in debug, then back to release. When I rebuilt the release version, it still acted the same way as when I first built it, ie the value was stuck. Eventually I just hard-coded the final value into the logic. Finally, last night was the worst instance. I noticed an orbiting camera was able to orbit all the way above (along the y axis) and then go upside down and back the other way. The fix for this was to lock the Y axis rotation at 90 at the top, and -90 at the bottom. I initially put 180 / -180 (making the camera stop way too far after going upside down), then fixed it to 90 / -90, but didn't see any change reflected. I built it in debug and voila, worked as expected. But this wasn't even a variable / const, it was a literal if(y > 90) switch right in my code. I feel like all this is due to Visual Studio trying to be clever and not recompiling things it doesn't see as "changed", but I figured a rebuild would correct it. Any advice? fart barterer fucked around with this message at 22:49 on Feb 20, 2018 |
|
#
?
Feb 20, 2018 22:45
|
|
|
I'm assuming that since this is a sizable codebase you have multiple projects in your solution. Are your project dependencies set up correctly in Release? edit: I mean these project dependencies, not just linker paths and library dependencies. It's been a while since I've used VS so I don't actually remember if those can be different between Debug and Release but that's the first thing I'd check. csammis fucked around with this message at 23:26 on Feb 20, 2018 |
|
#
?
Feb 20, 2018 23:24
|
|
|
I have 2 projects: one for the Windows DirectX wrapper, and one for the game itself. This is to help make multiplatform development easier, as the wrapper gets sorts out some OS-specific stuff and passes the relevant info to the game engine itself. I wound up cheating in a bunch of ways, including all the input logic (with Windows-exclusive bindings) currently sitting in the game project. Actually separating it all out and porting it is for if I ever finish the damned thing. The two projects have dependencies set up properly. All of the issues I mentioned are fully contained in the game project, which actually builds when I make the changes it refuses to reflect. When I add functionality, it is reflected initially, but if I change variable values without changing the structure of the code itself it doesn't get reflected. The binary and game DLL also get updated in the file system itself. The issue with the save button not remapping has been ongoing for a while. I have updated this header with new functionality and new bindings, on multiple occasions and below and above where the save binding is specified, and they all show up and work. But the line where I only changed the string "F6" to "F3" (to give the actual example) has yet to reflect in the actual build.
|
|
#
?
Feb 20, 2018 23:41
|
|
|
Are you using precompiled headers, and how sure are you that they're set up correctly?
|
|
#
?
Feb 21, 2018 05:23
|
|
|
I have the exact same issue. In my case it's because I have multiple games, each with their own solution file, and the engine project has an include path which changes depending on the solution name so it can get game-specific values for MAX_LIGHTS or whatever. It works fine until you switch between games, at which point VS doesn't realise that one of the includes is now a different file and it should recompile affected engine code.
|
|
#
?
Feb 22, 2018 11:53
|
|
|
Rottbott posted:I have the exact same issue. In my case it's because I have multiple games, each with their own solution file, and the engine project has an include path which changes depending on the solution name so it can get game-specific values for MAX_LIGHTS or whatever. It works fine until you switch between games, at which point VS doesn't realise that one of the includes is now a different file and it should recompile affected engine code. I would say that in that case, it's better to use preprocessor definitions set up in the project configurations, rather than having a different #include paths.
|
|
#
?
Feb 22, 2018 14:25
|
|
|
My only PCH is the standard stdafx.h, which doesn't really have much in it. This is starting to apply to literal values directly in cpp files. My issue where this orbiting camera code wasn't updating in the release build: code:My solution? I just copied and pasted the right code twice: code:I guess until I have time to dig into this further, I can just do that every time 
fart barterer fucked around with this message at 18:07 on Feb 22, 2018 |
|
#
?
Feb 22, 2018 18:04
|
|
|
Preface: I have never done actual automated unit tests before. What do unit test frameworks (specifically in C++) bring to the table that justify dragging in an extra dependency? I have written some unit tests for the latest project I have been put to work on and it doesn't seem like I would benefit from using a framework to write them. I just have a function call at the end of each unit test that prints out the test description and whether it passed or failed. When all you're testing is input -> expected output, what do you need a framework for besides just printing out the result?
|
|
#
?
Feb 27, 2018 00:00
|
|
|
Captain Cappy posted:Preface: I have never done actual automated unit tests before. The unit test "framework" I use is just a header file. So its not some huge monolithic library that is somehow difficult to manage and keep up to date. https://github.com/catchorg/Catch2 xgalaxy fucked around with this message at 00:14 on Feb 27, 2018 |
|
#
?
Feb 27, 2018 00:12
|
|
|
Captain Cappy posted:Preface: I have never done actual automated unit tests before. "Printing out the result" is actually pretty useful! A good test framework will tell you exactly which assertion in your test failed, and how the actual value passed to that assertion differed from what was expected. This is hugely helpful for diagnosing test failures, but would take a lot of extra code and effort if you had to reimplement it for every test. Additionally, things like mocking frameworks are also fantastically useful for expanding the sort of tests you can write and allow you to write them more cleanly.
|
|
#
?
Feb 27, 2018 00:20
|
|
|
Captain Cappy posted:Preface: I have never done actual automated unit tests before. I would recommend reading some comparison articles: http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle . For me, the benefits of a unit test framework are: - ability to easily define a setup/teardown mechanism - expect/assert easy to see what is checked and why it failed (error reporting). - reports when i throw an exception in my code and doesn't crash - various outputs. console is one thing, but log files, different targets, see in jenkins what passed what didnt, etc. - ability to run only the tests that I want (used that in Java a lot, haven't used it in C++ to be honest) - How clear the code is, how easy it is to add new tests Mocking is another, of course, though when you need mocking it usually means that you're missing an indirection layer that probably should be there. But, if you need it is invaluable.
|
|
#
?
Feb 27, 2018 00:41
|
|
|
Things I would expect or like from a unit test library: * Fixtures for setup and tear down * comparison operators that print the expected vs actual when there is an unexpected result and work on common container types + anything with operator==, boost has severity levels for these and thats nice * help for setting up tests with timeouts * nice command line interface allowing tests to be selected, reports generated * integrates with a mocking library Basically the libraries are a pile of stuff you’ll end up writing on your own if you keep writing your own tests. I’m not sure how I feel about mocking. It is very nice sometimes but when I’ve used it I’ve often ended up feeling gross about the tests I make with it. They usually end up being pretty fragile and these days I tend towards covering things with integration tests instead.
|
|
#
?
Feb 27, 2018 02:13
|
|
|
Captain Cappy posted:Preface: I have never done actual automated unit tests before. code:code:code:
|
|
#
?
Feb 27, 2018 02:23
|
|
|
roomforthetuna posted:The down side is, using a framework has a learning curve and a setting the loving thing up curve.
|
|
#
?
Feb 27, 2018 04:13
|
|
|
Does gtest have modern c++ mocking yet or are they still weirdly resistant to modern c++
|
|
#
?
Feb 27, 2018 05:00
|
|
|
Dren posted:Does gtest have modern c++ mocking yet or are they still weirdly resistant to modern c++ I love me some modern C++, but I have no idea what "modern C++ mocking" is.
|
|
#
?
Feb 27, 2018 05:05
|
|
|
Ralith posted:I love me some modern C++, but I have no idea what "modern C++ mocking" is. Their mocking framework doesn’t, or at least didn’t, support stuff like move and lamdbas.
|
|
#
?
Feb 27, 2018 05:12
|
|
|
Dren posted:Does gtest have modern c++ mocking yet or are they still weirdly resistant to modern c++ Nope. Google Test uses bugfuck insane macro wizardry to make unit testing easy. I assume that's why they can't easily move to C++11.
|
|
#
?
Feb 27, 2018 05:31
|
|
|
This is the correct answer unless you need a lot of death tests.* I am even willing to bet that sections are a lot better set up/tear down mechanism than whatever you came up with on your own  * I might be biased tho
|
|
#
?
Feb 27, 2018 08:20
|
|
|
The Phlegmatist posted:Google Test uses bugfuck insane macro wizardry to make unit testing easy. I assume that's why they can't easily move to C++11.
|
|
#
?
Feb 27, 2018 09:11
|
|
|
Absurd Alhazred posted:I would say that in that case, it's better to use preprocessor definitions set up in the project configurations, rather than having a different #include paths.
|
|
#
?
Feb 27, 2018 09:50
|
|
|
Rottbott posted:That will only allow you to change them for the game project, not the shared engine project. Then use different solution configurations.
|
|
#
?
Feb 27, 2018 14:17
|
|
|
The Phlegmatist posted:Nope. I think they have some institutional resistance to modern c++. Last I looked at their coding standard they ban stuff like stl::thread for vague reasons.
|
|
#
?
Feb 27, 2018 16:08
|
|
|
There are very good reasons to be consistent on what threading methodology you use across a whole company - of all the ones to disallow that one seems pretty reasonable. My inference from the outside is that google definitely hasn't moved past C++11 though, for sure.
|
|
#
?
Feb 27, 2018 16:18
|
|
|
Jeffrey of YOSPOS posted:There are very good reasons to be consistent on what threading methodology you use across a whole company - of all the ones to disallow that one seems pretty reasonable. That makes sense. It used to say something like stl threads were bad or dangerous but had no qualifiers as to why. Whatever it used to say about threads is no longer in the current version so nbd I guess. The current standard is pretty c++11 friendly.
|
|
#
?
Feb 27, 2018 17:38
|
|
|
Dren posted:That makes sense. It used to say something like stl threads were bad or dangerous but had no qualifiers as to why. Whatever it used to say about threads is no longer in the current version so nbd I guess. The current standard is pretty c++11 friendly. Do they still ban exceptions and RTTI?
|
|
#
?
Feb 27, 2018 17:52
|
|
|
Yes, but that basically comes down to that once you have a google-sized codebase that isn't exception-safe it's a little too late to change your mind.
|
|
#
?
Feb 27, 2018 20:43
|
|
|
In Google's defense, they did say that banning exceptions was a horrible idea and if they had the chance to do everything over, they'd make an exception-safe codebase. e: the weirdness with std::threads wandering off and calling std::terminate if not managed correctly is probably why they banned those initially. The Phlegmatist fucked around with this message at 20:54 on Feb 27, 2018 |
|
#
?
Feb 27, 2018 20:50
|
|
|
Yeah banning exceptions sounds like exactly the sort of thing I'd do in my toy research project and then be horrified by 5 years later when I had a corporate-scale codebase and no one had unmade that decision.
|
|
#
?
Feb 27, 2018 20:53
|
|
|
The Phlegmatist posted:e: the weirdness with std::threads wandering off and calling std::terminate if not managed correctly is probably why they banned those initially. 
|
|
#
?
Feb 27, 2018 21:30
|
|
|
Jeffrey of YOSPOS posted:Yeah banning exceptions sounds like exactly the sort of thing I'd do in my toy research project and then be horrified by 5 years later when I had a corporate-scale codebase and no one had unmade that decision. I have written exception-free C++, because I was forced to (Symbian S60 pre-5th Edition had its own exception handling ABI but they could never be arsed to implement it in the C++ front-end, it was a library thing instead). Last year, it was with the greatest satisfaction that I finally upgraded that library to use exceptions, because it was forcing awkward ad-hoc conventions on the rest of the codebase, being incompatible with pretty much the entire standard library, from smart pointers to containers I wouldn't recommend exception-free C++ to anyone and in fact I will very vocally argue against it should it get brought up. It cripples the language and makes it nearly unusable. Might as well use C then, same manual error and resource handling, same lack of standard libraries, but with much lower potential for obfuscation
|
|
#
?
Feb 28, 2018 00:10
|
|
|
Something I always want to do is to use a std::unique_ptr in an object that will get stored in a vector. I feel like maybe I just shouldn't do this. I'm doing this successfully in other places, but it looks like a big verbose mess. For some reason it isn't working in this particular case. I think maybe I'm missing one thing somewhere. Half of this is magic that I don't quite understand: code:1>c:\program files (x86)\microsoft visual studio 14.0\vc\include\xmemory0(737): error C2280: 'CoolText::RenderTextInfo::RenderTextInfo(const CoolText::RenderTextInfo &)': attempting to reference a deleted function 1> c:\users\ffff\documents\mymusic\dialogscreen.h(32): note: see declaration of 'CoolText::RenderTextInfo::RenderTextInfo' I have a mind to just not do this at all, however I'm curious if there is a better pattern that I can use. I just want to store poo poo in a stupid vector. Why is it so difficult? e: I fixed it by doing this, but I still wonder if there is a nicer way to do the above, because this isn't exactly what I intended to do, but it works fine code:baby puzzle fucked around with this message at 00:54 on Feb 28, 2018 |
|
#
?
Feb 28, 2018 00:50
|
|
|
Uhh, why are you doing it that way at all? Your pattern of having a "copy constructor" that silently blows up the thing you're copying from is going to lead to a lot of pain. Just use std::move() when you're wanting to move a thing into the vector.
|
|
#
?
Feb 28, 2018 01:00
|
|
|
I don't know. I think I'm probably being stupid in this case.
|
|
#
?
Feb 28, 2018 01:01
|
|
|
|
| # ? Jun 7, 2024 14:24 |
|
|
hackbunny posted:I have written exception-free C++, because I was forced to (Symbian S60 pre-5th Edition had its own exception handling ABI but they could never be arsed to implement it in the C++ front-end, it was a library thing instead). Last year, it was with the greatest satisfaction that I finally upgraded that library to use exceptions, because it was forcing awkward ad-hoc conventions on the rest of the codebase, being incompatible with pretty much the entire standard library, from smart pointers to containers A custom exception handling library (built on something like setjmp, I assume) is not exception-free, it's just exceptions without any proper language support, meaning that unwinding is totally unsafe and there are a million gotchas. Actual exception-free C++ does not have that specific set of problems; it has other problems, depending on how the error propagation does actually work. Imperative styles where you have to remember to check otherwise-useless error code results or global error states are pretty terrible because it's so easy to just not check anything. More functional styles, where most failable functions return Optional or ErrorOr types, don't suffer from that, at least as long as the return value is otherwise something the caller is going to want to pay attention to; but they do still require a lot of boilerplate to propagate errors. I wrote a pretty long essay about all this from the language-design viewpoint a few years ago. The quick summary is that it all comes down to whether you care about recovering from allocation failure. Allocation failure is such a universal source of potential failures that, if you want to handle it as part of your language's standard error handling, you're really forced into the C++ exception design. If you don't care about recovering from allocation failure, or you're willing to use a substantially different mechanism for it (like calling a global emergency-recovery function that flushes things to disk before crashing), then the number of things in your code that can fail drops precipitously; the C++-like exception designs pretty much suck for this because you have no insight into what operations can fail and how. So if you don't care about recovering from allocation failure, exception-free C++ is not at all unreasonable as a way of getting that insight back. You can still use the standard library just fine. The biggest expressivity loss is that you can't write a failable constructor; either you have to do the failable part in some sort of factory method or you have to construct the object in an recognizable invalid state, which you then have to remember to check. In practice, the factory approach is not that terrible, especially because (in my experience) failable constructors for complex types already tend to want to do things that don't fit cleanly into the substantial limitations of the C++ constructor model.
|
|
#
?
Feb 28, 2018 01:16
|
|
