When specifying a class or struct to be extern(C++), intellisense breaks.

On 13.07.2016 01:13, Adam Sansier wrote:
> When specifying a class or struct to be extern(C++), intellisense breaks.
>

Could you give a concrete example? This works for me:

extern(C++) class CC
{
	void foo() {}

	int xyz;
}

void fun()
{
	CC cc;
	cc.f // expansion here
}

I think the parser more or less ignores the "extern(C++)".

On Friday, 15 July 2016 at 06:23:11 UTC, Rainer Schuetze wrote:
>
>
> On 13.07.2016 01:13, Adam Sansier wrote:
>> When specifying a class or struct to be extern(C++), intellisense breaks.
>>
>
> Could you give a concrete example? This works for me:
>
> extern(C++) class CC
> {
> 	void foo() {}
>
> 	int xyz;
> }
>
> void fun()
> {
> 	CC cc;
> 	cc.f // expansion here
> }
>
> I think the parser more or less ignores the "extern(C++)".

I might have been wrong on this. I think it simply didn't show it for modifier and moved on past the problem.

There are so many issues with debugging that I feel like I will lose all my hair if I continue. I am so used to the elegance(relatively) of VS's C++ debugger with all it's helpful and accurate features that D feels like I'm drowning(spending literally 10x as long to debug code). So much obfuscation like effects. Cannot use registers in memory windows. EAX is invalid. C++ works. I have to make locals in code, rerun the program just to be able to get at a variable so it makes sense in the debugger. (e.g., if it's static, I have to make a non-static local variable and assign it just to see the contents). I have to copy addresses manually, If I leave a space, doesn't work. "e.g., `34245 ` is invalid. No debugsense over source code like C++ and C# have now. Even if it just showed the addresses, it would be better. Cannot copy more than one line of the disassembly, etc.

It would be nice, also, if all addresses could be set to be relative to base frame of app. This way different program executions do not show different addresses(which are pretty much all addresses). This would help debugging because it it would provide more consistency. Since sometimes we need absolute address view so the ability to toggle would be best.

Are there any plans to improve Visual D/Mago or is it just in the maintenance/limbo stage?

On Saturday, 16 July 2016 at 22:01:03 UTC, Adam Sansier wrote:
> On Friday, 15 July 2016 at 06:23:11 UTC, Rainer Schuetze wrote:
>> [...]
>
> I might have been wrong on this. I think it simply didn't show it for modifier and moved on past the problem.
>
> [...]

It's also rather annoying that the disassembly window doesn't take addresses without 0x like the memory windows do. Not sure if you can do anything about this or not. Happens on the C++ side too.

>
> Are there any plans to improve Visual D/Mago or is it just in the
> maintenance/limbo stage?

The latest (beta) version of Visual D contains a version of mago that integrates much better with VS2015, as it is just an expression evaluator for the stack frames that are marked as "D". C/C++ code still uses the native VS debug engine. More features work, e.g. expressions in conditional breakpoints and data breakpoints. This needs a recent nightly build of dmd, though.

On 17.07.2016 00:01, Adam Sansier wrote:
> There are so many issues with debugging that I feel like I will lose all
> my hair if I continue. I am so used to the elegance(relatively) of VS's
> C++ debugger with all it's helpful and accurate features that D feels
> like I'm drowning(spending literally 10x as long to debug code).

Maybe I'm just used to it but I don't think it is so bad. There are some quirks, but C++ has them, too.

Most troubles come from inaccuracte debug information emitted by dmd, but there are also issues with mago for sure.

> So much
> obfuscation like effects. Cannot use registers in memory windows. EAX is
> invalid. C++ works.

I agree, it should work. I've put it on my todo list.

> I have to make locals in code, rerun the program
> just to be able to get at a variable so it makes sense in the debugger.
> (e.g., if it's static, I have to make a non-static local variable and
> assign it just to see the contents).

Function local statics should work in extern(D) functions. For others, there is no symbol lookup information in the debug info, so the debugger would have to guess. You can use fully qualified names, though.

Please note that C++ has the same issue if you are using namespaces, you have to specify them in watch windows, too.

> I have to copy addresses manually,
> If I leave a space, doesn't work. "e.g., `34245 ` is invalid.

Works for me, will check.

> No
> debugsense over source code like C++ and C# have now. Even if it just
> showed the addresses, it would be better.

Do you mean data tooltips? These work for me.

> Cannot copy more than one line of the disassembly, etc.

With the new integration, the disassembly window is the same as for C++, so this works.

>
> It would be nice, also, if all addresses could be set to be relative to
> base frame of app. This way different program executions do not show
> different addresses(which are pretty much all addresses). This would
> help debugging because it it would provide more consistency. Since
> sometimes we need absolute address view so the ability to toggle would
> be best.

Due to address randomization this would work for code offsets, only. With the new integration, there is little we can do about this from within mago, that would need support by the VS debug engine.

> It's also rather annoying that the disassembly window doesn't take
> addresses without 0x like the memory windows do. Not sure if you can
> do anything about this or not. Happens on the C++ side too.

C++ accept the "h" suffix, mago could support that, too. As the address line is just a regular expression, I'm hesitant to add an ambiguity for a constant being decimal or hexadecimal.