I am experimenting with the Shared Items projects in VS2017 (Community Edition). (The goal is to create a non-visual library running on Windows and Linux.)
I added a C++ class, and the most standard of include directives for some reason fail. E.g. #include <iostream> results in an error. There are some headers in the automatic completion list but they look like proprietary Microsoft stuff.
I had the impression this stuff should work out of the box. For some reason, the Project properties also don't have much going about them, no place to tweak the libraries.
Thanks to #RichardCritten, I found that indeed some components were missing (Clang, I believe, although I installed some others). They were not called "standard components" though.
Bad, bad Visual Studio.
Related
It looks like std::string is a header only file at Community/VC/Tools/MSVC/?/include/xstring, and all generated code should be included inside a build target.
If I'm correct, how does Microsoft guarantee that the next Visual Studio version doesn't change xstring and the std::string internal structure?
Update 1:
I got many downvotes for this question so let me explain why I decided to ask it.
I'm faced with strange crash, and I can not understand why this happen.
I use latest Qt 5.13.0 (MSVC2017_x64) and also I have some external libraries compiled with Visual Studio 2017. All have /MDd, I checked this with dumpbin util.
When I try to run any code that invokes Qt library and std::string, I'm getting wrong result (and crash at the end).
Here is very simple example:
#include <QApplication.h>
int main(int argc, char** argv) {
QString s1("Test");
std::string s2 = s1.toStdString(); // here we have s2 variable with wrong internal structure
return 0;
}
My idea was that QtCore DLL library has std::string with internal structure not compatible with std::string from Visual Studio 2017. But Qt was created with Visual Studio 2017 (maybe not same as my current Visual Studio, because there was several minor releases), so I decided to ask here if they are compatible or not.
Update 2:
Problem was in _ITERATOR_DEBUG_LEVEL. Looks like Qt was compiled with level 2 and all my external libraries and application were compiled with level 0.
This option affects internal structure of many C++ standard library classes and introduce such side effects. So when we are inside toStdString() and create std::string, we have level 2 and one internal structure. When we are in application code, we have level 0 and another internal structure. We assign object with one internal structure to object with another.
Anyway now I have better understanding of some internals.
how does Microsoft guarantee that the next Visual Studio version doesn't change xstring and the std::string internal structure?
Because they make a decision to guarantee that, or to not guarantee that.
For example, Visual Studio 2015 to 2019 are binary compatible.
That's a decision that was made, to do that. The result, if what you say is true, is that some of the implementation specifics of std::string on that platform are frozen. This is not unusual for libraries. libstdc++'s std::list::size was non-compliant to C++11 for many years, because they could not add a needed member variable without breaking binary compatibility.
In short, this is basically a project management decision, and if they ever change the header in a way that breaks things, they will tell you that binary compatibility has been broken and you need to rebuild and relink things accordingly.
As for your Qt issue, it does smell like a binary compatibility issue. But you say that both Qt and your application have been built in Visual Studio 2017 with /MDd, which would appear to rule that out. I would ask the Qt community for further help, possibly with slightly more information about your environment and about where you obtained Qt. Also ensure that you're using the version of Qt that's intended — perhaps there are multiple installations? Which one's on your include path?
Is std::string header only in Visual Studio?
Not entirely, it also depends on parts of the Standard C++ library that are implemented in Microsoft's Visual C++ Runtime. Building a binary with MSVC requires the VC++ runtimes to be linked. Only static libraries may be built without linking to a runtime, and then you must be careful to include none of the headers that require the runtime.
Is the std::string header only in Visual Studio?
(I originally read the headline this way.)
std::string is part of the C++ standard.
To use std::string on any platform that supports standard C++, you should use #include <string>. It is a standard header available with pretty much any C++ compiler.
Every compiler or platform may implement the standard in its own way though. For example with MSVC you can see that xstring is how Microsoft implements std::string under the hood. If you include xstring.h directly you are writing code that depends on the version of MSVC that provides that header. That code would not be portable to other compilers.
If I'm correct, how does Microsoft guarantee that the next Visual Studio version doesn't change xstring and the std::string internal structure?
Microsoft does not guarantee that the next Visual Studio version will have the same std::string internal structure. In the past the implementation of the standard library has changed with every VC++ runtime release, which is why Windows users end up having dozens of VC++ runtime versions installed in their Add/Remove programs list.
Thankfully Microsoft has given us a guarantee that Visual Studio 2015, 2017, and 2019 all use a binary-compatible C++ runtime. This means that binaries built using the standard library provided in Visual Studio 2015 are compatible with binaries built using 2017 and 2019 too. There is no guarantee (yet) that a future version of Visual Studio will not change the VC++ runtime implemenation again.
I've been looking around to see how I'd accomplish that which is described in the title. That is, I'd like to create a C++ GUI application that:
is portable (no installer)
is cross-platform (Qt solves this)
is open source
works out of the box (i.e. no C++ redistributable installs needed)
I've run into several issues trying to accomplish this. I've narrowed it down to using Qt and NOT using the Visual Studio compiler. Let me explain.
Using Qt would fulfill the cross-platform requirement; it's also highly acclaimed in regard to C++ GUI applications. The issue lies with portability and not having a ton of dependency packages to install before being able to use the application. My goal would be for someone to download a .zip file containing an .exe (and I'd be willing to include other support files e.g. DLLs if necessary) and be able to extract and run that exe out of the box without having to do anything else.
And here's another kicker: as much as I'd like to use Visual Studio (with the Qt Visual Studio Add-in), it just doesn't seem feasible given my requirements. This post covers my issues pretty nicely. Simply put, if I use the Visual Studio compiler, I'd need to either create an installer (no longer a portable app), redistribute some Microsoft DLLs with the app (possible licensing and redist issues here?), or statically link the Visual C++ libraries into the executable (frowned upon technique).
Is there any way to be able to use Visual Studio and fulfill the requirements listed above? Visual Studio is just too fully-featured to pass up. If it's not possible, I think the only other alternatives would be to use a different IDE and/or compiler. For example, I could use QtCreator with MinGW, but then I'd be losing out on some awesome VS debugging features.
My main questions:
Is there any way I can fulfill the requirements above and still use Visual Studio?
Am I wrong about QtCreator not being as fully functional as Visual Studio?
What would be the best way to approach fulfilling my application requirements?
Thanks in advance.
I think your best bet would be to use QT with the MinGW environment. It allows you to create a portable application that supplies runtime DLLs by itself, with added bonus of being completely open source. The QT online installer gives you the option to install the complete MinGW system, and it will work out of the box, not much setup needed.
You could still use Visual Studio for development; there even is a QT plugin for it (I am not sure if VS2015 is supported, but if not that should only take some time).
QTCreator is actually a quite nice IDE, but it cannot stand up to Visual Studio. It is obviously optimized to cater to the needs of QT programmers, but I found that it is quite clunky from time to time. If your project is small it could be a viable choice, but since Visual Studio 2015 Community is basically free I would opt for that. The VS plugin will still use QTCreator's GUI editor though (which is really good)
I want to list properties and functions present in c++ classes. Is that functionality already implemented in any library ? Does visual studio intellisense use any library ? Is that library available publicly from Microsoft?
Visual Studio parses your code, so that's how it knows. You would need to do the same.
The Visual C++ team maintains a blog that has had several very nice articles about how IntelliSense has worked in the past and how it will work in the future:
IntelliSense History, Part 1
IntelliSense, Part 2 (The Future)
Visual C++ Code Model
Rebuilding Intellisense
Visual C++ Code Model in Visual Studio 2010
Essentially they build their own 'reflection' database (the .ncb file in current and past version sof VS, using a compact SQL database starting with VS2010) by parsing the headers and other source files - using both custom parsers and parsing that's done with the cooperation of the compiler.
Apparently at least some of that information is available in the VCCodeModel and related interfaces that the Visual Studio extensibility model provides. I have no idea how well the extensibility model works or how easy it is to use.
They use a propriety format to store intellisense information (they are saved as NCB files). You can delete these files to force VS to recreate its intellisense database if things go wrong.
They then scan header files for class information as well as dependencies, then build the NCB file for future reference.
No, this library is not available for personal use.
Intellisense in C# is lots better than the one in C++
VS2010 will see C++ have the same intellisense features as C# currently enjoys.
I would imagine that Visual Studio uses the header files to provide Intellisense.
I searched around for the answers to these questions, but I have had little luck. So, I thought I would post them here to get some clarification. If this is a duplicate, please let me know, and I will close this.
Okay, with that said, I would like to begin learning C++. I come from a C# background and I have a great respect for Visual Studio and what it can do. Now, my question is. How well does Visual Studio's compiler work for C++ as opposed to a non-Microsoft version (such as MinGW)?
My thing is this. I have nothing wrong with Microsoft, but I would really like to learn C++ in a "pure" form and not scewed by any particular implementation. How reliant is Visual C++ on the .NET Framework? Can a "pure" C++ application be created through Visual Studio without any .NET usage or overhead? Does the Visual Studio compiler compile C++ into CIL like it does with C#/VB, or does it compile it all the way down as others do?
Thanks for any help anyone can provide!
The Visual C++ compiler will compile C++ code into standalone EXEs that have nothing to do with the .NET framework.
The only way to get the .NET baggage thrown in is to compile the C++ as "managed".
If you create a new project (File|New|New Project) Then choose "Win32" from the Visual C++ submenu in the project types and choose "Win32 Console Application" Visual studio will create a simple project with a couple of source files that will compile to a little executable.
Most of the time, Visual C++ is very similar to other compilers. Avoid #pragmas, microsoft libraries (MFC, ATL) and you should be fine.
Edit (thanks Cheeso) - Documentation of where Visual C++ diverges from standard.
In general I would advise using boost libraries for threads and networking because they work on many platforms (i.e linux). Also if your code can compile in GCC and Visual Studio then you are doing a good job keeping it portable.
The most recent versions of VC++ have become significantly more compliant to the C++ standard, so it's not really an issue to write "pure" C++ using Visual Studio, presuming that you stay out of the Windows API, COM+ and ATL. In fact, the documentation with Visual Studio is very rich, with details on the standard libraries and the STL, so it can help you learn a great deal. It can't teach you everything, but it's certainly loaded up with a wealth of information that is portable to any compiler and it is very easily accessbible inside the IDE.
If you create a new solution you should choose new Win32 Project, or Win32 Console Application, and check the 'Empty Project' option. Then you can add a main.cpp file, and add your standard C++ code.
If you like Visual Studio, go ahead and use it to learn C++ -- I haven't used the very latest version, but even the previous one was pretty standards-compliant, C++-wise, and I assume the latest one can only have gotten better. You can have many different kinds of project in Visual Studio, including "console apps", which are the "plain vanilla" kind you could make on any platform, and also many other kinds, such as, windows apps using the good old win32 api, ones made with MFC or other frameworks older than .NET, .NET ones using "managed code", etc.
Just make sure you always work in a "console app" project, and you'll be operating pretty closely to how you would be on other platforms and/or with other C++ IDEs.
If you limit yourself to writing ANSI C++ compliant code then what you write in VS will work in other compilers, until you have to interact with a graphic interface or IO. Then you need to make certain that you are using something that is portable, such as OpenGL, and not DirectX.
To set your project the steps here may be useful:
http://bytes.com/topic/net/answers/447572-strict-ansi-c
Microsoft Visual Studio 2005 comes with a very good, C++98 standard compliant pure C++ compiler. If you are interested in pure C++, don't forget to disable language extensions in project settings and you are good to go. Nobody is going to force you to use .NET framework, MFC or anyting like that. Just pure core C++ language and C++ standard library.
Of course, just like any other compiler, it has known non-compliance issues, but in general it is, again, surprisingly good. Older versions of their compiler (MS VS 6.0 specifically) suffered from many non-compliance problems and could not even compile its own header files with language extensions disabled. In 2005 version they fixed a lot of these issues.
After creating a standard Win32 project, you can turn up the compliance a bit more. On the project properties sheet, there's a C/C++ category, with a Language entry. This lists a number of cases where VC++ can differ from the standard. Here, you'd want to turn OFF language extensions, and turn ON "wchar_t as built-in type", "for-loop conformance" and "RTTI support".
I'm trying to port an old program I wrote for class from KDev in Ubuntu to Windows Visual Studio 2008 using Cygwin as a personal learning exercise. I have the include path configured to include C:\cygwin\usr\include but it doesn't read the .h files properly.
Namely I'm curious as to how one would go about using unix sockets.h functionality in a Visual Studio environment using Cygwin. Has anybody ever got this working or have an easier way to go about doing this?
There are several ways to go about this that could be made to work, depending upon your exact goals. The simplest way is probably just to create a Visual Studio "makefile" project that fires off a custom build command to run a makefile you've built. But that keeps you away from a lot of the nice benefits of Visual Studio as an IDE, so I'm guessing that's not really what you're after.
If you want a more fully integrated solution, you're going to need to do two things. First of all, you're going to need to change out all of your include/library paths to avoid the Microsoft ones and go after the Cygwin ones instead. You can do this by selecting "Tools->Options" from the menu, then choosing "Projects and Solutions->VC++ Directories" from the tree on the left hand side of the window that comes up. You'll have options to change the search directories for executables, headers, libraries, etc. For what you're trying to do, I'd suggest removing everything and adding in just the cygwin directories.
Second, you'll have to tell Visual Studio to use the gcc/g++ compiler. This is a bit trickier. VS supports custom build rules for custom file types... but it seems to have C++ hardwired in for the Microsoft compiler. I don't really know a great way around that except to use your own custom file extension. You can try the standard unix extensions of .c (C files) and .cc (C++ files), but I suspect Visual Studio will automatically pick up on those. You may have to go with something totally foreign.
If you right click on your project in the Solution Explorer and select "Custom Build Rules" you'll be given an interface that will let you create your custom build rules for the file extension you've chosen. The interface is relatively straightforward from there.
This might not get you exactly what you wanted, but it's probably about as close as you're going to get with Visual Studio.
Simply speaking, don't do that. It would be just waste of time. I tried it several times, but always failed. Mostly, I was frustrated by many linking errors, and also was unable to use VS as a debugger.
You can use Visual Studio for editing and browsing source code. It is nice because VS provides the best C/C++ intellisense features (e.g., Auto completion, fast go to definition/declaration). But, it is very hard to use cygwin tool chains with Visual Studio 2008. Visual Studio 2008 is not designed to work with other tool chains. Specifically, you need to change (1) headers, (2) libraries, (3) compiler and (4) linker. However, it is generally very hard, or you need to trade off with the nice features of Visual Studio.
The strongest feature of Visual Studio is its debugging ability such as fully integrated debugging environment and very easy watch windows (e.g., you can see STL vector's element directly in watch windows). However, you can't do this if you would change fundamental tool chain (although I am very suspicious it is even possible to safely build with Visual Studio and cygwin tool chains).
Unfortunately, current Visual Studio 2008 is not for cygwin/MinGW.
This is an old question, but since it comes up first (for SO) on a Google search I wanted to share that it looks like the latest Visual Studio versions do support this.
For instructions, refer to this blog post:
https://blogs.msdn.microsoft.com/vcblog/2017/07/19/using-mingw-and-cygwin-with-visual-cpp-and-open-folder/