I am new to NGXS and can't find an answer to my question.
Is it possible to strongly type Selectors in NGXS so that intellisense works in Visual Studio Code and and errors can be caught at compile time?
Yep, you need to use something like a state token.
Here's an example
The basics are that you need to use something in your selector that is typed, a string is not typed, ie:
#Select(TODOS_STATE_TOKEN) good$: Observable<TodosStateModel>;
// Uncomment the next line, it won't compile
// #Select(TODOS_STATE_TOKEN) bad$: Observable<string[]>;
// this is typed as any still
#Select(TODOS_STATE_TOKEN) any$;
Related
I'm trying to replace the global new operator in Visual Studio and C++. This is my code (only one new operator shown for simplicity):
void* operator new(size_t _Size)
{
// Do something
}
It works fine, however Visual Studio is giving me a warning when running Code-Analysis for my project:
warning C28251: Inconsistent annotation for 'new': this instance has no annotations. The first user-provided annotation on this built-in function is at line vcruntime_new.h(48).
Using the annotations from vcruntime_new.h for my operator new replacement, as suggested in the warning from IntelliSense, resolves the warning:
_NODISCARD _Ret_notnull_ _Post_writable_byte_size_(_Size) _VCRT_ALLOCATOR
void* __cdecl operator new(size_t _Size)
{
// Do something
}
Is it safe to use the annotations inside vcruntime_new.h for my own replacement code like shown above?
What are the consequences of this change?
Are there special use cases were the "new operator" cannot be used anymore like before because of the annotations?
And why is that change necessary?
EDIT:
Am I correct, that the annotations won't change anything in the resulting binary, and are simply for static code analysis? (Except __cdecl, which changes the assembler, but it should be standard anyway I guess?)
This applies to _Ret_notnull_ and _Post_writable_byte_size_(_Size):
Is it safe to use the annotations inside vcruntime_new.h for my own replacement code like shown above?
Yes, as long as your operator new actually follow these rules in annotation. It might not follow _Ret_notnull_ (for example non-throwing new returns nullptr), tough normally will. But it should follow _Post_writable_byte_size_(_Size), since operator new is required so.
What are the consequences of this change?
Annotations will probably help Visual Studio Code Analysis pinpoint errors, but will make you using non-standard stuff, making your program less portable and less clear.
Are there special use cases were the "new operator" cannot be used anymore like before because of the annotations?
No.
And why is that change necessary?
Because you want to avoid that warning instead of silencing it.
Am I correct, that the annotations won't change anything in the resulting binary, and are simply for static code analysis? (Except __cdecl, which changes the assembler, but it should be standard anyway I guess?)
Correct. Not even optimizer would use that (optimizer would use __assume, __restrict, and other annotations separate from static analysis).
I remember seeing somewhere that you can specify which dll to get the address of symbols so that one can use that variable in the watch window. I can't for the life of me remember where I saw this. The best that I can come up with is Format Specifiers in C++.
The reason I want this is so that I can see the visibility status of a window and MSVS keeps saying that identifier "IsWindowVisible" is undefined.
I was trying to use something like the following in the watch window:
::IsWindowVisible(m_hWnd),user32.dll
Using:
this->IsWindowVisible()
results in Function CWnd::IsWindowVisible has no address, possibly due to compiler optimizations. which is why I'm trying to use the win32 call. Ideas?
http://msdn.microsoft.com/en-nz/library/y2t7ahxk.aspx
Haven't tried it, but it seems to me that IsWindowVisible(m_hWnd) should work, or maybe IsWindowVisible(this->m_hWnd).
Is there any way to get generation of switch statements by enum?
For example if I have big enum and I have method with has parameter enum, then I need to code switch statements for each case, but is there a way to generate this switch statement by enum?
If I have a lot of other enums if my enums wide range and if I have 10-100 methods with different enums parameters in that case switch coding became a hell.
Probably it is good idea to create t4 template, anyway I am happy to hear any suggestions about enum switch generation.
Looking for solution without any additional software like Resharper.
Visual Studio already does this.
Type switch, tab to complete that snippet, type the enum name and you'll get the case statement autogenerated.
Visual Studio does this with a snippet.
Type switch, press Tab and then enter the name of your enum variable, and press Enter.
You should get a switch statement with each enum member case'd.
Tried messing with both of the above answers and couldn't get it to work for me. The big difference I found is that you have to double tap Tab after you start typing switch.
A single tab will complete the switch statement but won't open up parentheses. By double tapping it will open up paratheses and leave your cursor in the middle, so when you start typing the enum variable and tab to autocomplete it, you will generate all of the switch statements.
What I like to do is remove all functions which has specific word for example, if the word is 'apple':
void eatapple()
{
// blah
// blah
}
I'd like to delete all code from 'void' to '}'.
What I tried is:
^void.*apple(.|\n)*}
But it took very long time I think something is wrong here.
I'm using Visual Studio. Thank you.
To clarify jeong's eventual solution, which I think is pretty clever: it works, but it depends on the code being formatted in a very particular way. But that's OK, because most IDE's can enforce a particular formatting standard anyway. If I may give a related example - the problem that brought me here - I was looking to find expressions of the form (in Java)
if (DEBUG) {
// possibly arbitrary statements or blocks
}
which, yes, isn't technically regular, but I ran the Eclispe code formatter on the files to make sure they all necessarily looked like this (our company's usual preferred code style):
if (DEBUG) {
statement();
while (whatever) {
blahblahblah(etc);
}
// ...
}
and then looking for this (this is Java regex syntax, of course)
^(\s*)if \(DEBUG.*(?:\n\1 .*)*\n\1\}
did the trick.
Finally did it.
^void.*(a|A)pple\(\)\n\{\n((\t.*\n)|(^$\n))*^\}
Function blocks aren't regular, so using a regular expression in this situation is a bad idea.
If you really have a huge number of functions that you need to delete (more than you can delete by hand (suggesting there's something wrong with your codebase — but I digress)) then you should write a quick brace-counting parser instead of trying to use regular expressions in this situation.
It should be pretty easy, especially if you can assume the braces are already balanced. Read in tokens, find one that matches "apple", then keep going until you reach the brace that matches with the one immediately after the "apple" token. Delete everything between.
In theory, regular language is not able to express a sentence described by context free grammar. If it is a one time job, why don't you just do it manually.
Switch to VI. Then you can select the opening brace and press d% to delete the section.
I'm looking into writing an addin (or package, if necessary) for Visual Studio 2005 that needs watch window type functionality -- evaluation of expressions and examination of the types. The automation facilities provide
Debugger::GetExpression, which is useful enough, but the information
provided is a bit crude.
From looking through the docs, it sounds like an
IDebugExpressionContext2 would be more useful. With one of these it
looks as if I can get more information from an expression -- detailed
information about the type and any members and so on and so forth, without having everything come through as strings.
I can't find any way of actually getting a IDebugExpressionContext2,
though! IDebugProgramProvider2 sort of looks relevant, in that I
could start with IDebugProgramProvider2::GetProviderProcessData and
then slowly drill down until reaching something that can supply my
expression context -- but I'll need to supply a port to this, and it's
not clear how to retrieve the port corresponding to the current debug
session. (Even if I tried every port, it's not obvious how to tell
which port is the right one...)
I'm becoming suspicious that this simply isn't a supported use case, but with any luck I've simply missed something crashingly obvious.
Can anybody help?
By using IDebugExpressionContext you'll ultamitely end up getting ahold of an instance of IDebugProperty. This interface is implemented by the Expression Evaluator service. This is, typically, a language specific service. It's designed to abstract out the language specific details of evaluating an expression. It understands much higher level commands like "Evaluate", and inspection.
I don't think you're going to get what you're looking for though because you can't get ahold of any kind of type object this way. Nearly all of the inspection methods return their results in String form. For example you won't get the type Int32 but instead the string "int". This makes type inspection next to impossible.
I don't believe what you're trying is a supported case. The type system being evaluated doesn't exist in the current process. It exists in the debuggee process and is fairly difficult to get access to.
There's a hack you could do to get more information about the type of a variable you've evaluated using Debugger::GetExpression method.
You could evaluate "AppDomain.CurrentDomain.GetAssemblies()" to get all the assemblies loaded into the debugee, and cache them in your add-in. You may also need to listen for new assemblies being loaded onto the AppDomain.
Then, run the following:
Expression myExpression = Debugger.GetExpression(...);
Expression typeRefExpression = Debugger.GetExpression("typeof(" + myExpression.Type + ").FullName"
once you have the TypeFullName, you can search inside your assemblies cache for a matching System.Type, and once you have that, you can dig into it all you want using the standart Reflection API.
Note that this will only work in C#, because of its "typeof" keyword. You'll have to use a different keyword for VB.Net, for example.