I am trying C++/WinRT and the WinUI templates available in VisualStudio. I am confused about namespaces ::winrt::Microsoft and ::winrt::Windows. I only know about the former one because auto-generated callback functions used a type from ::winrt::Microsoft, and wouldn't compile because I passed identically named type from ::winrt::Windows namespace by mistake. I couldn't find more information about ::winrt::Microsoft, couldn't even find official documentation.
From what I can say, ::winrt::Microsoft and ::winrt::Windows have mostly identically named types, but some types are missing from ::winrt::Microsoft. For example, ::winrt::Windows::UI::Colors and ::winrt::Microsoft::UI::Colors both exist, but ::winrt::Windows::UI::Color has no "alternative" in the Microsoft namespace.
Questions:
Why do we have 2 almost the same but subtly different namespaces?
Under which circumstances do I choose one or the other?
Why ::winrt::Microsoft is missing some types?
Windows is the original namespace, where all UI-related types live. Some of those types were 'reinvented' into the Microsoft namespace as part of moving WinUI out of its UWP-only misery.
If a type is available in the (newer) Microsoft namespace then use that. The transition is not yet complete, so some types are missing.
Related
I am learning MFC. If I am not wrong, the names of all the MFC classes start with the capital letter "C" (e.g. CFrameWnd, CFile, CMenu, etc.)
I found that the code generated by the Visual Studio wizard for MFC based project gives similar names to the user-defined classes. For example, if I name my project as "Shapes" then, the classes generated for the project contains classes such as CShapesApp, CMainFrame, CChildView, etc.
In the end, you would have several classes in your project, which may look like CShapesApp, CFrameWnd, CMainFrame, CWinApp, CWnd, etc.
QUESTIONS: For me, the names of the classes (user-defined and MFC library) seem quite similar and hard to differentiate if it is a user-defined class or an MFC library class.
Why MFC based projects choose such naming conventions (i.e. why to put "C" in front of the user-defined classes)?
How can I easily differentiate between MFC library classes and user-defined classes?
UPDATE: I know that I can change the names and I have already tried that. But the general convention is to start the class names with "C" even for the user-defined classes and my question is why? and how can I differentiate easily?
Why MFC based projects choose such naming conventions (i.e. why to put "C" in front of the user-defined classes)?
That's impossible to answer. At a guess, that was just the common thing to do, back in the early 90's. Namespaces were added to C++ in 1995, i.e. years after work on MFC had started, so MFC wound up in the global namespace. Using a C prefix for classes reduces the chance for symbols to clash with the Windows API and SDK headers.
How can I easily differentiate between MFC library classes and user-defined classes?
MFC classes are user-defined classes. It is not immediately clear, why you need to differentiate between user-defined classes provided by MFC and user-defined classes provided by your code. If you find this useful, there's no shortcut. You just have to memorize which ones belong to MFC.
There are, however, 2 sets of classes in MFC, for which it is helpful to know, which set they are in: The 'original' classes, and the classes introduced with Visual Studio 2008 (I believe), that offer a wider set of functionality. You can distinguish between those sets by looking at the prefix: The 'original' classes start with C (like CButton), and the updated classes have a CMFC prefix (like CMFCButton).
The "C" prefix convention is a question of your taste. But remind, all MFC-derived classes "are" in fact MFC classes - in the sense of inheritance meaning a derived class "is" also the ancestor. So don't forget your CWnd-derived CMyWnd has everything a CWnd also has.
My personal approach for naming (which I introduced in several dev teams) is to use the "C" prefix for all MFC-derived classes and use another one (or even none) on non-MFC-derived classes.
In XCode 8.1, when working on a C++ project, I just can't get any constructor signature autocompletion when they are "obstructed" by a namespace. Which is incredibly annoying because namespaces are extremely useful and extensively used in both my code and the code my software depends on.
Let me explain in two images.
Accessing through the std namespace.
Spilling the entire stdnamespace into the source with using namespace.
My question is basically... What?
Consider a C++ API defined as a series of __options(declexport/import) classes.
Further, assume that the caller is never permitted to call the ordinary operator new(size_t) on these classes. Either a static factory method does the new-ing or there is a class-specific operator new. And ditto marks on the delete size as needed (frequently just a virtual destructor).
Now, if you compile and link a DLL and an IMPLIB of with the tools from VS2010, can you hand that implib and DLL to a user of VS2005 and expect it to work?
MFC is not involved here at all.
I'd be particularly grateful to any reference to any relatively formal Microsoft statement on the subject.
So long as the name mangling on the C++ API is identical (they are), and does not use STL-type specific parameters, such as basic_string or std::map, whose implementation may have changed between releases of the compiler (and they have), then it should just work.
Of course, you'll want to make sure you either compiled your DLL using /MT mode (static linked runtimes), or include the redistributables for VS2010 runtimes with your supplied libraries and link targets.
EDIT: Expanding on "don't pass in types that have version-specific implementations". A partial list is most easily found by looking at the output of the exports of MSVC100P.DLL.
cd %VS100COMNTOOLS%\..\VC\redist\x86\Microsoft.VC100.CRT
DUMPBIN /exports MSVCP100.DLL
The next issue will be header-only implementations of things like map or set which have changed under the hood between versions of the compiler.
This is why it's highly recommended that only scalar types be passed across boundaries between memory arenas. And thus, simple tests will pass, and be reliable.
You have not mentioned if you have used MFC to create the DLL's .If you have, regular DLL's should work , but I dont think extension shall work as the latter links to the MFC dlls .I am including links for your reference.
http://www.codeguru.com/cpp/cpp/cpp_mfc/tutorials/article.php/c4017
http://www.experts-exchange.com/Programming/System/Windows__Programming/MFC/Q_20385543.html
http://msdn.microsoft.com/en-us/library/26h8x9sy%28v=VS.100%29.aspx
EDIT
If its a normal DLL, there should not be any problem.Also depends on the linkage type.
Is there any documentation which describes all the valid elements for a Windows application manifest, which namespace they are in, and which Windows versions will use them? All the documentation I found so far describes only parts of the manifest, and I have seen different XML namespaces used for the same element.
What I have found so far:
Manifest Files Reference/Application Manifests seems to have full documentation of the urn:schemas-microsoft-com:asm.v1 namespace plus the compatibility/supportedOS stuff (from the urn:schemas-microsoft-com:compatibility.v1 namespace). It has a link to a schema file which does not have the compatibility/supportedOS stuff.
Step 6: Create and Embed an Application Manifest (UAC) documents the trustInfo/requestedExecutionLevel stuff as being in the urn:schemas-microsoft-com:asm.v2 namespace. However, I have seen other places saying it is in the urn:schemas-microsoft-com:asm.v3 namespace.
SetProcessDPIAware Function documents an application/windowsSettings/dpiAware thing as using both the urn:schemas-microsoft-com:asm.v3 namespace and a http://schemas.microsoft.com/SMI/2005/WindowsSettings namespace.
Application Manifest XML Schemas looks like a set of schema files for some of these namespaces, but it seems to contradict the other references (for instance, unless I am misreading the xsd, dependency is in the urn:schemas-microsoft-com:asm.v2 namespace, while the first reference above implies it is in the urn:schemas-microsoft-com:asm.v1 namespace).
There's no such thing. In fact I'd bet that there are still some completely undocumented parts of the manifest. Indeed, for a long time the only documentation of the DPI aware part was in Raymond Chen's blog and book!
Visual Studio includes a refactoring function called "Extract Interface" that generates an interface based on a class implementation.
The extracted interfaces are Internal by default. Problem is, we end up changing nearly all of them to Public.
Does anyone know why it's Internal by default? Better yet, is there a way to customize this to default to Public?
It might work if you change the Visual Studio template for interfaces (I haven't tried that but assume this should work).
For Visual Studio 2008 the template is stored at
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates
\CSharp\Code\1033\Interface.zip"
This is described in more detail in this answer.
I don't have a reference, but I have a wild guess as to why it is internal by default.
Let's say you have 3 projects / assemblies: log4net (a 3rd party API), MyApp.Util, and MyApp.Web (a Web project). Web references Util, which references log4net. Web does not reference log4net, and you want to keep it that way.
Inside of DAL, say you have an internal class, and one of its members references a type defined in log4net. It could be the return type or one of the parameter types of a method, or the type of a property.
Let's say you extract an interface from the aforementioned class, including the aforementioned member that references log4net. Well, if you make that member public (part of a public interface) and reference a type that implements it, you then require that the Web project reference log4net.
By making the interface internal, Web may continue to be ignorant of log4net.