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.
Related
I'm using the Visual Studio UML designer to create some class diagrams. Since I would like to generate code from the diagrams it need to be accurate.
Now I'm trying to define the type of some properties of my classes, but I can't find a way to give them a type different from bool, string, int and UmlimitedNatural (and my own types of course). I found a tutorials that claims I would have to create custom stereotypes. Really? I mean it's VS, I'm just asking for some build in reference/value types like byte or GUID.
Do I overlook a hidden switch or if there is really now way to tell VS to bring up some commonly used types does anyone know a source for UML profiles that provide it? And how I can define more complex types like generics?
UML is implementation language neutral. Since types differ by platforms it is necessary to define an implementation language profile for any UML tool. Most UML CASE tools include the option to choose the language and apply a built in profile, which should make them available.
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.
What is best practise with regard to the placement of Interface types.
Often the quickest and easiest thing to do is place the interface in the same project as the concrete instances of it - however, if I understand things correctly this means that you are more likely to end-up with project dependency issues. Is this a fair assessment of the situation and if so does this mean interfaces should be separated out into different projects?
It depends on what you want to do. You're correct that placing interfaces and classes in the same assembly will somewhat limit the usefulness of the abstraction of said interfaces. E.g. if you want to load types in an AppDomain with the purpose of unloading these again, you would typically access instances via the interfaces. However, if interfaces and classes are in the same assembly you can't load the interfaces without loading the classes as well.
Similarly if you at a later point want to supply a different set of classes for one or more interfaces you will still get all the old types if they are in the same assembly as the interfaces.
With that said I must admit that I do place interfaces and classes in the same assembly from time to time simply because I don't think that I will need the flexibility, so I prefer to keep things simple. As long as you have the option to rebuild everything you can rearrange the interfaces later if the need arises.
In a simple solution, I might have public interfaces and public factory classes, and internal implementation classes all in the same project.
In a more complicated solution, then to avoid a situation where project A depends on the interfaces in project B, and project B depends on the interfaces defined in project A, I might move the interfaces into a separate project which itself depends on nothing and which all other projects can depend on.
I practice "big systems can't be created from scratch: big systems which work are invariable found to have evolved from small systems which worked." So I might well start with a small and simple solution with the interfaces in the same project as the implementation, and then later (if and when it's found to be necessary) refactor that to move the interfaces into a separate assembly.
Then again there's packaging; you might develop separate projects, and repackage everything into a single assembly when you ship it.
It is a deployment detail. There are a few cases where you have to put an interface type in its own assembly. Definitely when using them in plug-in development or any other kind of code that runs in multiple AppDomains. Almost definitely when Remoting or any other kind of connected architecture.
Beyond that, it doesn't matter so much anymore. An interface type is just like another class, you can add an assembly reference if you need it in another project. Keeping them separate can help controlling versioning. It is a good idea to keep them separate if a change in an interface type can lead to wide-spread changes in the classes that implement them. The act of changing the [AssemblyVersion] when you do so now helps troubleshooting deployment issues where you forgot to update a client assembly.
My question isn't so much about use of interfaces but more of a project organization nature.
Note: I am using VisualStudio in a multi-layered application.
Should my Interface files live in a separate project from their implementations? My initial thought is that it would be useful to separate out all my service interfaces into their own project (and a project for my initial implementations) so that down the road the implementation/concrete project may be removed and replaced with a new one if necessary.
To clarify with an example: Suppose I have a business layer Interface called IBusinessService which lives in the MyApp.Business.Services namespace. My implementation FooBusinessService would exist in the same namespace, but a different project in VisualStudio. If later on the implementation needed to be reworked, a developer could remove the reference to the FooService.proj and replace it with a reference to BarService.proj.
This seems like it would declutter the app solution by allowing you to reference a project with only interfaces without also acquiring concrete implementations (which may be obsolete or of no use to you), but am I missing something?
I'm with you. I prefer to put my interfaces in a separate project AND in a different namespace. The classic example is with data access classes. You want to be able to code an MSSQL version and a MySQL version, both implementing the same interface. As such, I prefer that the interface definition be in a separate assembly/project. Here's an example of how I lay out assemblies and namespaces:
Elder.DataAccess.Core - contains the interfaces and common utilities
Elder.DataAccess.MSSQL - specific MSSQL implementations of the interfaces
Elder.DataAccess.MySQL - specific MySQL implementations of the interfaces
This allows me to modify the implementations without touching the project that contains the interface definitions. This helps me with version control and change tracking, too. There might be other ways to skin this cat, so I'll be eager to see other folks' answers.
For example, if writing a shell extension, is it necessary to register the typelib with CComModule::RegisterServer (i.e., I'm wondering if calling it with FALSE will cause some issues).
Hardly ever.
In theory typelibs would be used by IDEs that wan't to display lists of properties and methods on an object. OleSpy++ or whatever the tool is called can use typelibs to generate quite a lot of important information about the ActiveX
In MSVC you can use #import on a ActiveX with embedded typelib and header files describing the interfaces and types will be automatically generated.
When dealing with well-known interfaces - published in the platform sdk - or if the header files are already supplied for C & C++ bindings, then typelibs are a tad useless.
Even when used from script languages, IDispatchEx now seems to be preferred as a discovery mechanism for the IDE or code to query an IDispatch supporting object at runtime for its methods.
In general, it's fine to say FALSE unless you need a typelib because someone is going to be calling your IDispatch implementation. For most shell extensions I don't think you need a typelib.