www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - extern(C++) no intellisense VD

reply Adam Sansier <Adam.Sansier gmail.com> writes:
When specifying a class or struct to be extern(C++), intellisense 
breaks.
Jul 12 2016
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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++)".
Jul 14 2016
parent reply Adam Sansier <Adam.Sansier gmail.com> writes:
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 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?
Jul 16 2016
next sibling parent Adam Sansier <Adam.Sansier gmail.com> writes:
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.
Jul 16 2016
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
 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

 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.
Jul 18 2016