Full-Spectral

There's a pattern I've tried a few times and never get it to work. It comes up a lot for me, and the solutions seems obvious , but I always run into issues.

The basic deal is something like a state machine that you use to get through the states required to connect to something, get various bits of required data, do handshaking exchanges, until you get to a ready state, handle loss of connection and cleanup. Pretty obvious stuff. It's in a loop since that connection can be gotten and lost over time.

It seems blindingly obvious that a sum type state enum would be the way to do this, with each step holding the data gotten up to that point. It means you don't have to have any mutable temps to

I am at a complete loss to get ASAN working in VC++. I've done everything I can think of. I'm on the latest VS19 version (16.11.35.)

1. I have the /fsanitize=address option of course
2. I have turned off any conflicting options
3. ASAN is installed and the libs are visible to VC and the DLLs are in the path.
4. I removed the per-project ASAN path that it adds automatically, which some folks said would cause problems.

But I get absolutely nothing. It doesn't load any of the DLLs. I can manually add the libs (though it says that's not required) and it does load the DLLs so clearly they are in the right place, but it still does nothing.

It claims that SANITIZE_ADDRESS will be defined if

The default insertion of a value when std::map [] doesn't find a value for the key has to be one of the worst decisions in STL history (which is kind of impressive.) At work over the last year or so, we've had at least four, maybe five, bugs caused by this. It's so easy to do without thinking about it, and so easy to miss in a code review. And some of them had been there for many years and finally caused an issue, so no one was even looking for them.

Is there any way to prevent its use, or at least to warn on its use in MSVC? We use the built in static analyzer, and I don't see any warning related to that, though there are a lot of them and I may have missed something.

While doing some abuse testing of our system, we have discovered that, if we run a simple CPU pegging program (which makes our product have to really struggle so that we can find places where it doesn't protect itself), we've found that some moderately extended periods of substantial CPU overcommit (like running 8 always busy threads, just at normal priority, on a four core system) can seemingly somehow corrupt the System task, which then goes into this 30% to 60% usage mode and seems to just stay there indefinitely. We've not watched it for days or anything, but it seems to just be stuck in that mode.

This is Windows 10, and has been seen over the last year or so, so it doesn't seem to be

So I have a acyclic dependency graph. I can easily create a 'single threaded' list of the entries such that all dependencies are before the things they depend on, just a simple topological sort does that.

But, I also want to generate a 'parallel' list, where I can break it into separate layers (list of lists), the entries of each of which can be processed in parallel (because they are unrelated and all of their dependencies have been taken care of by the underlying lists.) And optimally so, i.e. every entry is at the lowest level it technically can be.

AFAIK, topological sorts aren't going to provide that. I can think of some somewhat brute force methods involving generating the single thr

That just doesn't seem right to me. I.e. If I have a method in the header:

void SomeFunc(const bool bTest);

In the cpp file, it's perfectly happy without the const:

void MyClass::SomeFunc(bool bTest)
{
}

I understand that the constness of the value doesn't matter to the caller of the method for fundamental types, but why wouldn't there at least be the requirement that the definition and declaration be consistent? Otherwise the const in the header is really a completely meaningless artifact and it doesn't even make sense to support it.

And just in general it seems like a completely arbitrary inconsistency. The declaration of the class limits the definition, so it's n

So we have some nmake configuration type projects that just run a batch file. Suddenly, for no apparently reason, VS started failing some of these projects because it can't file a [projectname].exe file to copy to Debug/Release, as though it now thinks the project is supposed to be building an executable. There's no output target set at all and it's clearly still marked as an nmake style project, and the command line is just invoking the batch file.

I'm on 16.7.7, which is pretty close to the most recent if not the most.

Any ideas of why that might have happened? I checked the .vcxproj file and nothing looked out of whack in there. And the same stuff in 2012 works ok. And I should say it

It would ever so nice if the regex match result had an alternative at() to use instead of the index operator. Some linting/analysis tools assume that this is an unchecked array operation and complain about it. This requires either lots of suppressions, or a lot of bogus warnings that hide real indexing operations that might be an issue.

It would be trivial to provide an at() that just turned around called the operator. Those who have this concern could avoid it and there would approximately zero cost to the implementors.

This is a stripped down version of what I'm doing. It gives the same error as the real one.

constexpr uint32_t AFlag = 0x01;
struct AStruct 
{
    const uint32_t m_AMember;
};
const AStruct Xyz
{
    0x03
};
static_assert((Xyz.m_AMember & AFlag) != 0);

It seems like everything in there could be evaluated at compile time, since it's all const and constexpr. But Visual C++ complains that it didn't evaluate to a constant.

It's obviously related to it being a structure member. Does static_assert just not work on structure members even in this simple type of scenario in 17?

So, I'm trying to get a custom task to work in Visual Studio. I can get this to work with a custom build tool, but that's not viable because (for really stupid reason) you cannot indicate a build target for a custom build tool that I can see. There's only a project level build target and all custom steps and tools use the same one. So if you also need custom build steps on other targets that's not workable.

I'm on 2019. Here is what I have (one of an ~infinite set of variations I've tried)

    <Target Name="SpidlGen" BeforeTargets="BeforeBuild"
            Inputs="$(ProjectDir)SpidlGen_Gen.Spidl"
            Outputs="$(ProjectDir)SpidlGen_Gen.cpp;$(ProjectDir)SpidlGen_Gen.h

This is driving me to distraction. I have a custom tool, that generates two output files from a source file. I have the this set on the properties of the source file.

Command: $(SolutionDir)Tools\Spidl.exe %(FullPath) .%(Filename).cpp .%(Filename).h

The Outputs is this, also per the instructions: .%(Filename).cpp; .%(Filename).h

The Execute Before is set to Build (or BuildCompiler as another option I've tried)

The output files are added to the project. I have a build description step so I'll see if it even tries to run it.

I'm going by this: [https://docs.microsoft.com/en-us/cpp/build/specifying-custom-build-tools?view=vs-2019](https://docs.microsoft.com/en-us/cpp/build/specifying-cu

I.e. could you create your own threading system or does the language only understand how to enforce the thread interaction scheme with its own threads, because it knows that they are threads? I poked around and didn't really see any answer to this.

I poked around and couldn't find anything on this. Of course it's hard to search for something like !! and find useful answers. I don't know if it's something VC++ specific or some corner of C++ I've not run into.

Their assert expands the test expression x to "(void)(!!(x))"

Is that suppressing or modifying expansion of the expression in order to avoid syntax that would otherwise confuse the macro parameter parsing?