In the course of implementing a class in a Visual C++ project, I encountered an error (documented as a warning) that I couldn't resolve by any of the methods discussed elsewhere. Thankfully, the solution that I developed, though slightly novel, is quite straightforward; move the typedef directly into the class definition header.
Having worked more in straight C than C++, and implemented C interfaces for most of my custom APIs, I was accustomed to declaring a structure and a pointer to one of its kind as follows.
typedef struct _PVT_SAFER_MUTEX
HANDLE ThisMutex ;
DWORD OwnerThread ;
} PVT_SAFER_MUTEX , * LPPVT_SAFER_MUTEX ;
It was a matter of habit to define structures and pointers to structures in this way in a header, include that header within another header, then declare functions that return the pointer type.
LPPVT_SAFER_MUTEX MyFunction ( SAFEER_MUTEX_HANDLE pHandle ) ;
This works like a champ in straight C code.
Now comes a need to do something similar in the header that declares a class.
LPPVT_SAFER_MUTEX CHandleManager::GetMutexInfo ( SAFEER_MUTEX_HANDLE pHandle ) ;
Try this with the structure typedef in a separate header, and you get Compiler Warning (level 1) C4183, 'identifier': missing return type; assumed to be a member function returning 'int'.
Points of Interest
After about an hour of studying numerous articles about compiler warnning/error C4183, I decided to move the typedef from the external header into the header that declares the C++ class that contains methods that return pointers to the structure.
On reflection, putting the typedef in the header that defines the class that uses it is a cleaner design, because it makes the class declaration more self-contained.
Friday, 11 November 2016 is the initial publication of this tip.
I deliver robust, clean, adaptable, future-ready applications that are properly documented for users and maintainers. I have deep knowledge in multiple technologies and broad familiarity with computer and software technologies of yesterday, today, and tomorrow.
While it isn't perceived as sexy, my focus has always been the back end of the application stack, where data arrives from a multitude of sources, and is converted into reports that express my interpretation of The Fundamental Principle of Tabular Reporting, and are the most visible aspect of the system to senior executives who approve the projects and sign the checks.
While I can design a front end, I prefer to work at the back end, getting data into the system from outside sources, such as other computers, electronic sensors, and so forth, and getting it out of the system, as reports to IDENTIFY and SOLVE problems.
When presented with a problem, I focus on identifying and solving the root problem for the long term.
Specialties: Design: Relational data base design, focusing on reporting; organization and presentation of large document collections such as MSDS libraries
Development: Powerful, imaginative utility programs and scripts for automated systems management and maintenance
Industries: Property management, Employee Health and Safety, Services
Outside Interests: Great music (mostly, but by no means limited to, classical), viewing and photographing sunsets and clouds, traveling by car on small country roads, attending museum exhibits (fine art, history, science, technology), long walks, especially where there is little or no motor traffic, reading, especially nonfiction and thoughtfully written, thought provoking science fiction