After some searching I've found that Microsoft Visual Studio does not provide the "complex.h" header file, but I have some C code that unfortunately uses it. I've tried using <complex> and compiling as C++ code; this requires changing
complex
to
_complex
I don't even know what I would need to change
long complex
to. Any ideas how I can get around this?
Have you tried this link?
If you can't use third-party libraries, then I think you're going to be compelled to re-implement complex functionality yourself. The good news is that most complex math is actually really simple to write, unless you need some fairly advanced features.
Related
I've installed OmniPascal extension in Visual Studio Code to use it for coding in Delphi and I am loving it. Code completion, parameters hint, go to declarations, all working 100%! Nonetheless, I am missing the refactor commands like rename (CTRL+SHIFT+E). Is that already implemented in OmniPascal?
There are currently no refactoring tools implemented in OmniPascal. Rename and Extract method are planned for the future but there are other features that need to be implemented before OmniPascal can turn into a reliable refactoring tool.
As long as OmniPascal doesn't handle all language features correctly (like with-blocks or class helpers) the rename command would produce wrong results. You don't want to work with such a refactoring tool.
My project is written in C++/CX on VS2015 and I am seeking a way to generate API documentation.
After googling and stackoverflow, I have tried doxygen, VSDocman,NDoc, Atomineer Pro Documentation and SandCastle, I found these tools do not support C++/CX syntax, therefore, they cannot generate correct document.
I also tried to generate XML file which VS supports. But it's hard to read XML file.
How do I generate API documentation from C++/CX? Thanks for any suggestion
There are a lot of misconceptions about the C++/CX language extension. You tried too many products that have no hope of getting you anywhere. First and foremost is that it is a native C++ extension and does not generate a .NET compatible assembly. So knock out any that try to use Reflection to parse metadata. Out goes NDoc, VSDocman, Sandcastle. Atomineer is out, it is just an editor add-in.
So all you got left is doxygen.
Sure, it doesn't know about C++/CX out of the box. The FAQ points out that in order to make it compatible with a language, you need to modify src/scanner.l
Having a look at it, I see it already supports the C++/CLI extension. That's another C++ language extension that supports generating MSIL. C++/CX syntax is very close to C++/CLI. Just some minor differences, like the gcnew keyword is too misleading and replaced by ref new. But that's not the kind of syntax that doxygen cares about, it just wants to know about declarations. Those keywords are the same.
So the only obstacle I can guess at is that you just forgot to tell it about the language. It can't guess at it correctly from just the filename extension, .cpp and .h will get it to parse plain C++. Modify or add this line in the config file:
CPP_CLI_SUPPORT = YES
And tweak scanner.l if necessary.
I use Visual Studio for development and I am quite used to Intellisense. But when writting CoffeeScript you don't really get any Syntax Checking or Intellisense.
Is there a plugin for VS that would allow this?
Thanks
You can't have more than syntax checking/coloring with coffeescript (on any IDE) AFAIK.
As an alternative, you can use TypeScript to get the full Visual Studio tooling support (and stay close to the javascript), or some transcompilers that transform code to javascript, for C# there is Saltarelle and for CIL (.NET bytecode, so compatible with any .NET language), I just found JSIL but I have no idea how well it works.
Note than the generated code "look" can be important for debugging and using external libraries get a bit of work to be included in Typed languages.
For js code readability I would recommand TypeScript (similar to coffeescript, even easier, but less powerfull as a language).
Saltarelle code looks readable (didn't tried a lot), for JSIL I have no idea.
A list of languages that compiles to JS: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
Webstorm and all of the JetBrains IDEs recently added some code completion and refactoring support. It knows what methods are in my own classes and will prompt to complete as I type. The red squiggly underline compile as you type is not quite there yet but it is coming. I bet Webstorm is the first to implement CS source map also. They have added so much in the last 11 months.
Check this out: http://visualstudiogallery.msdn.microsoft.com/2b96d16a-c986-4501-8f97-8008f9db141a
Here is another: http://chirpy.codeplex.com/
I think this should do what you want.
Many Qt classes uses pimpl, so they're very opaque to VS's debugger.
This is bothersome when I want to check some internal Qt state to see if my code is doing it wrong or if I'm having wrong expectations of how things stand.
I'm using the Qt VS add-in (1.1.0), but that doesn't seem to help.
Any ideas?
Update
My autoexp.dat file is filled with Qt stuff, but I'm still not able to look inside the heavier classes (QWidget, QTcpSocket, etc).
I can see the simpler classes contents, so the autoexp.dat below seems to be working, but trying to look inside a QWidget doesn't work.
Update 2
For some reason, after reading comments and looking more, it does work, and I can see the data stuff.
I don't know what happened in the mean time (when I just worked and ignored it), but I did have problems seeing the data before.
I'm accepting the "just works" answer, because I can't delete a bountied question and that's the closest answer available. (The autoexp-dat just pretty-formats the debug lines, using data that's already visible if one digs down)
This might help http://daniel-albuschat.blogspot.com/2008/02/qt-debugging-with-visual-studio-2005.html
IIRC the install of Qt for Windows includes an autoexp.dat file -
Correction, it's part of the the qt-vs-addin
You need to add custom dumpers for your debugger.
There are pre-built ones for GDB. You may have to roll your own for other debuggers, although for visual studio it's possible to get some decent results pretty easily by tweaking the autoexp.dat file. There are plenty of resources online for how to change this file.
Editing autoexp.dat is an option. See http://eecs.vanderbilt.edu/research/hmtl/wiki/pmwiki.php?n=Knowledge.Qt for a set of visualizers.
It seems like you might be out of luck.
Currently this page has the most complete list of macros for QT wariables that can be added to the autoexp.dat:
QT with Visual Studio 2008 (updated for Qt 4.5.2)
ActiveQt also sounds promising, but it might be a bit of an overkill for you.
Beyond this, you would have to roll your own expressions, or maybe write a Visual Studio Debugger Visualizer. (more about that is on CodeProject or MSDN)
Since there is nothing like that out there, it might be a good opportunity for development from scratch. :)
It's definitely possible to look into the pimpl when Qt is compiled with debugging information. Not sure about VS, but with gdb it Just Works™.
Visual Studio seems to want to put class contructor code and event handling code in the .h file. I have only been involved in small 1 man projects and was wondering what the general industry standard was.
For Visual C++ Application projects what code would one put in the .h file? I am used to the mode classical C++ way of declaring your class in the .h file and coding in the .cpp file. Does this still apply to Visual Studio applications?
I have a strong C background which would explain my preference for this. The VSC++ compiler doesn't seem to mind.
In short: What is one supposed to put in which type of file?
TIA
Ends
There is no widely accepted industry standard. By putting (short) function definitions in the header, you give the compiler a better chance to inline the code. The benefit is that it can make the code run faster (keep those functions short, though). However, this comes at the cost of exposing more code to the clients who include that header, making you (or your colleagues) recompile more files when you change the implementation.
You also have to take into account the cost of going against your tools. Since VC++'s wizards insist on putting the functions in the headers, you have to move them everytime if you disagree.
It's really project-specific, I would say.
If you're using MFC and you're talking about the generated code, it's best to leave it alone.
If you're trying to do 'normal' C++ development, put as little as you can get away with in the header, as it means client code doesn't depend on too many implementation details. What you can get away with depends a little on use of templates, and how much indirection your performance budget can support.
For Visual C++ Application projects
what code would one put in the .h
file? I am used to the mode classical
C++ way of declaring your class in the
.h file and coding in the .cpp file.
Does this still apply to Visual Studio
applications?
Short: Yes
Long: Depends on the person or language. In c++ the header is for declaring and cpp for the coding. For C# you have one file (or if you use interfaces, 2)
This might seem minor, but just remember: headers are #included in several places. (And headers including headers complicates things further.) Any time you change a header, a lot of files are gonna be compiled again. Keeping as little of frequently changing code in the header reduces recompilation of dependant files.
Another thing: an uncluttered header file gives you a quick overview of what a class/form has to offer.