locked
C++/WinRT CoreApp sample RRS feed

  • Question

  • I've been fiddling with the CoreApp sample for C++/WinRT. I'm pretty sure I had it working when it suddenly started reporting ...

    E1790  the default constructor for "App" cannot be referenced -- it is a deleted function

    Tuesday, July 17, 2018 2:35 PM

Answers

  • There is more to it than that. The E in the error code indicates that this is an intellisense error. It is tracked by a different compilation than the main compiler itself.

    It is surprisingly hard to keep the intellisense updated, since unlike the main compile which only does work whenever you tell it to build, the intellisense compiler has to recompile the source every time you edit it. This means that it will be seeing the source in a non-sensical state a lot. 

    If you are thinking, but C# or VB.NET can do this, there is the annoying fact that C++ sources tend to be much larger. The .NET languages also import information using metadata which is much more computer friendly than text includes that the compiler has to parse each time. If you are confused about sources getting big, here is a question, how big do you think the pre-processed source for:

    #include <cstdio>
    //empty line
    int main()
    {
    	printf("Hello World!\n");
    	return 0;
    } //main.cpp line 7

    ends up as? If your answer is 7 lines, then you are wrong. If your answer was 12,154 lines then congratulations. Even though most of it is whitespace, if you remove all of the blank lines, that one little program is 2,867 lines of code that it has to parse.

    So if we then look at something a bit larger:

    #include <winrt/Windows.Graphics.Imaging.h>
    #include <MemoryBuffer.h>
    
    int main()
    {
    	return 0;
    }

    which ends up pre-processing to about 7.5MB, how many lines does this work out as? If your answer was 470,974 then congratulations. If we remove blank lines, this still works out to be 181,023 lines.

    If you are wondering where I got those numbers from, well, the #include directive is a text include, so it literally copies the contents of the file that has been specified in the <> or "" and pastes it into the body of the source file, and it does this until there are no more #include statements. So it builds one really large source out of the smaller source file and included files.

    So whenever you edit this, the intellisense compiler has to recompile the entire thing fast enough to keep the intellisense as responsive as possible, it has to manage stale symbols in the database, it has to add new symbols to the database and so on.

    So you can imagine that when the source files get really large then the intellisense does start struggling to keep up. But surprisingly, it is much better than what it was years ago. But even with the current versions you still need to restart Visual Studio every now and again to clear things out or even outright delete the intellisense database.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Edited by Darran Rowe Wednesday, July 18, 2018 3:26 AM
    • Proposed as answer by Baron Bi Wednesday, July 25, 2018 6:33 AM
    • Marked as answer by Gavin..Williams Wednesday, July 25, 2018 12:39 PM
    Wednesday, July 18, 2018 3:23 AM

All replies

  • Yes, the CoreApplication class is static, in Windows runtime parlance, this means it is a class that only has static members, so you cannot create an instance of the class.

    If you look at the source for winrt::Windows::ApplicationModel::Core::CoreApplication, all of the members that you want to use are static. So to use it you need to call the static members, like:

    using namespace winrt::Windows::ApplicationModel::Core;
    CoreApplication::Run(view);
    currentview = CoreApplication::GetCurrentView();

    This should be what you want.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Edited by Darran Rowe Tuesday, July 17, 2018 3:38 PM
    • Proposed as answer by Baron Bi Wednesday, July 18, 2018 2:58 AM
    Tuesday, July 17, 2018 3:37 PM
  • This was the line giving the error  ..

        CoreApplication::Run(App());

    I think this is a VS bug. Today when i opened the app, the error isn't being reported. I think VS gets its 'parse tree' or 'semantic tree' or whatever it's called corrupted sometimes, because the error was happening after I created an error elsewhere and the error seemed to 'travel' to this line which is not actually in error. Even when the application was compiling and running, I was still getting this error.

    Wednesday, July 18, 2018 1:11 AM
  • Hi,

    thanks for posting here.

    >>I think this is a VS bug. Today when i opened the app, the error isn't being reported. I think VS gets its 'parse tree' or 'semantic tree' or whatever it's called corrupted sometimes, because the error was happening after I created an error elsewhere and the error seemed to 'travel' to this line which is not actually in error. Even when the application was compiling and running, I was still getting this error.

    What's the type of your application?

    If your app is an UWP app, please post on UWP forum below for better support.

    https://social.msdn.microsoft.com/forums/windowsapps/en-us/home?forum=wpdevelop

    If your application is a desktop application, please provide more information about how to reproduce your issue. Or you could share us a demo project to test.

    To post an issue of VS, you could post on this forum below.

    https://developercommunity.visualstudio.com/spaces/8/index.html

    Your understanding and cooperation will be grateful.

    Best Regards,

    Baron Bi


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Proposed as answer by Baron Bi Wednesday, July 25, 2018 6:33 AM
    Wednesday, July 18, 2018 2:58 AM
  • There is more to it than that. The E in the error code indicates that this is an intellisense error. It is tracked by a different compilation than the main compiler itself.

    It is surprisingly hard to keep the intellisense updated, since unlike the main compile which only does work whenever you tell it to build, the intellisense compiler has to recompile the source every time you edit it. This means that it will be seeing the source in a non-sensical state a lot. 

    If you are thinking, but C# or VB.NET can do this, there is the annoying fact that C++ sources tend to be much larger. The .NET languages also import information using metadata which is much more computer friendly than text includes that the compiler has to parse each time. If you are confused about sources getting big, here is a question, how big do you think the pre-processed source for:

    #include <cstdio>
    //empty line
    int main()
    {
    	printf("Hello World!\n");
    	return 0;
    } //main.cpp line 7

    ends up as? If your answer is 7 lines, then you are wrong. If your answer was 12,154 lines then congratulations. Even though most of it is whitespace, if you remove all of the blank lines, that one little program is 2,867 lines of code that it has to parse.

    So if we then look at something a bit larger:

    #include <winrt/Windows.Graphics.Imaging.h>
    #include <MemoryBuffer.h>
    
    int main()
    {
    	return 0;
    }

    which ends up pre-processing to about 7.5MB, how many lines does this work out as? If your answer was 470,974 then congratulations. If we remove blank lines, this still works out to be 181,023 lines.

    If you are wondering where I got those numbers from, well, the #include directive is a text include, so it literally copies the contents of the file that has been specified in the <> or "" and pastes it into the body of the source file, and it does this until there are no more #include statements. So it builds one really large source out of the smaller source file and included files.

    So whenever you edit this, the intellisense compiler has to recompile the entire thing fast enough to keep the intellisense as responsive as possible, it has to manage stale symbols in the database, it has to add new symbols to the database and so on.

    So you can imagine that when the source files get really large then the intellisense does start struggling to keep up. But surprisingly, it is much better than what it was years ago. But even with the current versions you still need to restart Visual Studio every now and again to clear things out or even outright delete the intellisense database.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Edited by Darran Rowe Wednesday, July 18, 2018 3:26 AM
    • Proposed as answer by Baron Bi Wednesday, July 25, 2018 6:33 AM
    • Marked as answer by Gavin..Williams Wednesday, July 25, 2018 12:39 PM
    Wednesday, July 18, 2018 3:23 AM
  • It's an answer but it's not very satisfying when VS is failing to parse a sample applications that opens a window and renders some squares.

    Maybe the intellisense system should be looked at. It's not something I experience much working with C#, as you pre-empted. Or perhaps more importantly .. the entire C++ framework needs to be rebuilt from scratch, using modern concepts and strategies and leaving behind the bloat.
    Wednesday, July 25, 2018 12:49 PM
  • If a rewrite was needed then this would have been fixed already. The entire project system, intellisense included, for Visual Studio 2010.

    The other thing is that the intellisense engine was updated after that too, since they did things like change the database engine that intellisense uses.

    The problems with the C++ intellisense isn't caused by tooling problem. You can find similar issues with other C++ intellisense systems. The reason why C++ has issues where C# has less is due to one thing that the CLR (.NET framework) requires but C++ doesn't. That is the metadata.

    Parsing text is much harder than reading data that is already prepared for a program to read. The fact that you mostly compile .NET framework applications for anycpu also gives another major advantage, the amount of configurations that you have to care about easily halve.

    In general, using the precompiled header (if enabled), and forcing VS to rescan the solution helps fix these errors. But while it is a pain, if you look back at Visual Studio 2008 where it took seconds to even show the list, if you were lucky, and it was really inaccurate, then it has improved a lot.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Wednesday, July 25, 2018 7:27 PM