Is it possible to get comments on c++11 std methods and classes in VS2012 ? Currently i'm only seeing parameters and return types - and they're a mouthful to interpret for someone learning cpp.
Only if comments are written before the function declaration, which they are not for VS2012 STL implementation, unfortunately (maybe for parsing speed reasons though, maybe not).
Always refer to either the MSDN (type F1 while having the cursor on the name of the function or type), or refer to the standard. I often use http://en.cppreference.com as a reference for everything in the standard.
Related
I'm just starting off with C++, setting up an environment in Visual Studio 2019. As I got used to coding in C# with intellisense, I thought it'd work the same way with C++, however it seems to be broken for me.
as you can see, it doesn't provide detailed information about methods (or anything at all) like it does with C#. In fact, it doesn't even display all of the overloads.
I don't even know if it's supposed to be like that or if its a problem on my end...
as you can see, it doesn't provide detailed information about methods
It doesn't appear to be broken, c++ intellisense with Visual Studio just doesn't offer the documentation style descriptions that C# may. Though you can provide you own descriptions for methods by adding a comment just before their declaration and it should appear where you want in intellisense.
(or anything at all)
c++ intellisense does give all of the method names and method declarations for the class, which isn't nothing and can be useful when you know generally what kind of method you need but don't know the specific method name, ( ex. .size() vs .count() vs .length() ) but I understand your frustration as I went from C# to c++ myself with Visual Studio
In fact, it doesn't even display all of the overloads.
All you need to do to display overloads should be to type the first parenthesis as if you were calling the method and it should display the overloads.
As used in this answer, I'm looking for a C++11 compatible code for the same but the usage of std::quoted prevents me from achieving that. Can anyone suggest an alternative solution?
I give my answer assuming that you expect to find a generic approach to handle such situations. The main question that defines the guideline for me is:
"How long am I supposed to maintain this code for an older compiler version?"
If I'm certain that it will be migrated to the newer toolset along with the rest of the code base (even though in a few years time, but it will inevitably happen), then I just copy-paste implementation from the standard headers of the next target version of my compiler and put it into namespace std in a separate header within my code base. Even though it's a very rude hack, it ensures that I have exactly the same code version as the one I'll get after migration. As I start using newer (in this case C++14-compatible) compiler, I will just remove my own "quoted.h", and that's it.
Important Caveat: Barry suggested to copy-paste gcc's implementation, and I agree as long as the gcc is your main target compiler. If that's not the case, then I'd take the one from your compiler. I'm making this statement explicitly because I had troubles when I tried to copy gcc's std::nested_exception into my code base and, having switched from Visual Studio 2013 to 2017, noticed several differences. Also, in the case of gcc, pay attention to its license.
If I'm in a situation where I'll have to maintain compatibility with this older compiler for quite a while (for instance, if my product targets multiple compiler version), then it's more preferable first of all to look if there's a similar functionality available in Boost. And there is, in most cases. So check out at Boost website. Even though it states
"Quoted" I/O Manipulators for Strings are not yet accepted into Boost
as public components. Thus the header file is currently located in
you are able to use it from "boost/detail". And, I strongly believe that it's still better than writing your own version (despite the advice from Synxis), even though the latter can be quite simple.
If you're obliged to maintain the old toolset and you cannot use Boost, well...then it's maybe indeed worth thinking of putting your own implementation in.
In our cross-platform Open Source library we derive from std::exception in order to define custom exceptions that can be caught in library-code as well as user-code. I saw that this is actually a recommended procedure, but in Visual Studio 2015 (or rather, the accompanying new MSVC version?) a warning is thrown in the implementation class ( warning C4275 ) - see also here: How to dllexport a class derived from std::runtime_error?
Of course we could just ignore the error, but this seems wrong to me.
The reason for the appearance of the warning, as compared to older Visual Studio versions, seems to be that std::exception used to be exported in older MSVC version but meanwhile is not exported anymore. In either case, I feel like it was never "the right way" to go on about this in the form of compiling it into the library.
From what I read in the answers, a better way to do this is to "inline" the class, since exporting the base class (std::exception) may lead to more complications. If I understand correctly, "inlining" here means not using the "inline" keyword but moving the definition into the header and to not export it. Is that even correct?
Assuming this is what is meant: My question is if the compiled library that throws the exceptions, which are definied in one of its headers, will allow to catch the exceptions correctly in the executable linking this library dynamically. But what if the compilers are different? The runtime type information (RTTI) seems relevant here, so is this guaranteed to work in said way even when using different compiler versions or even different compilers? If this does not work, how to solve this in the "right" way?
Quoting from the Microsoft Connect issue (webarchive) in the post linked in the question;
... putting STL types in your DLL's interface forces you to play by the STL's rules (specifically, you can't mix different major versions of VC, and your IDL settings must match). However, there is a workaround. C4251 is essentially noise and can be silenced...
Mixing compiler versions and options could (and probably will at some point) cause problems and unpredictable behavior of the application. So, there are no guarantees it will work, quiet possibly the opposite, it won't work.
When using the inline technique mentioned above (i.e. a header only implementation) and making sure that the settings and compilers are consistent across the projects allows for a work around given the constraints of the dll exports.
Given that it is an open source project, it can easily be built for the clients environment, so any of the techniques mentioned should be suitable because the client will be able to build the code given their compiler and options they desire.
I've always loved IntelliSense in C# in Visual Studio 2013. I'm not only talking about autocomplete function but also about those methods' descriptions (documentation's excerpts I suppose) viewed in autocomplete box. For example when I write:
List<int> l = new List<int>();
l.Add
Then I get a nice explanation:
Adds an object to the end of the System.Collections.Generic.List.
Also hints when calling some method are very useful (how many overloads, types of parameters).
But lately I decided to write some C++ code in Visual Studio 2013 and I see that those methods' descriptions are not visible. For example when I write:
string s;
s.length
all I get is autocomplete + function definition (return type and types of parameters). No information about what does this function do whatsoever. It's not something I can't live with. I know what .length() does :-) but collections in STL have many functions and it would be very very nice to have their descriptions (I know they can't replace whole documentation, but some comment on applications would be very nice) in Visual Studio, not only on www.cplusplus.com/reference/
So my question is this: is it possible in Microsoft Visual Studio to make IntelliSense work with C++ exactly as it works with C#?
Unfortunately, I have never seen any code hinting tool which works with C++ with as much detail as IntelliSense works with C#. There certainly are tools which can provide you with basic code hinting for std:: elements, but nowhere as detailed. Ive used codelite 2.0 in the past and its ok, but thats an entire IDE and provides basic code completion, probably the same as using VS2013
You could add extensive comments to the std header files MSVC ships with.
In my experience comments directly beside a method show up.
This would be a big project, and ideally you'd want to fold it back to MSVC sources and then to their sources so it would persist between versions.
Visual Studio 2010 features a number of extensions (activated by default) / discrepancies with regard to the C++ Standard.
Such discrepancies can be surprising, and elicit a different behavior than other behavior. VS is notably famous for being extremely lax in template code validation, and template code that was accepted and compiled by VS will often be rejected outright by more compliant compilers (CLang, Comeau, icc, gcc, ... to name a few).
The goal of this question is to provide a reference (thus the FAQ tag) for these discrepancies.
Please provide one answer per discrepancy (check for duplicate) and for each:
Explain the discrepancy
Tell us if it is possible to disable this (and if so, how)
Explain the consequences (apart from the mere rejection)
Note: C++0x is the next standard, so avoid listing C++0x extensions, since they'll be standard soon
From #Matteo Italia: Visual Studio Compliance Page
First of all, I'd link Microsoft's take on this topic.
All the Microsoft language extensions can be found here; there's also a page where the areas of the language where VC++ is not compliant to the standard are listed.
By default the compiler allows binding a temporary to a non-const reference.
Remedy: use warning level 4
Visual C++ does not fully support value initialization (or rather, there are bugs in all current versions of Visual C++, from Visual C++ 2005 through Visual C++ 2010 SP1).
There are several reported bugs about this (see also this answer to another question).
Consequence: some forms of code that should value initialize an object leave the object or some part of the object uninitialized.
Workaround: do not rely on value initialization.
Discrepancy: Visual Studio does not bind non-dependent names in templates during first evaluation.
The Standard requires two-phases evaluation:
First: check basic templates well-formedness, bind non-dependent names (which comprises overload resolution)
Second: Instantiation proper
Disable ? It is not subject to any option or switch, it is simply not implemented.
Consequences:
Visual Studio only does the second phase, which affects:
Errors in template code are detected at instantiation only, so you'd better instantiate all the templates you write early (think of it as compilation unit test).
Missing template or typename keywords are not detected by VS
Overloads declared after the`template may be picked up by overload resolution. Not so much of an issue since reverting the include order would produce the same result.
I use a blog as a notebook for non-complicance issues I find in VS2005. I don't see a point in reposting the whole thing here
http://atarasevich.blogspot.com/2008/02/microsoft-vs2005-c-non-compliance.html
http://atarasevich.blogspot.com/2008/02/microsoft-vs2005-c-non-compliance_07.html
http://atarasevich.blogspot.com/2008/02/microsoft-vs2005-c-non-compliance_08.html