Click here to Skip to main content
16,016,894 members
Articles / Programming Languages / C++
Article

The Microsoft VC++ Virtual Property feature

Rate me:
Please Sign up or sign in to vote.
3.80/5 (4 votes)
6 Jan 2000 164.8K   34   28
Using the __declspec(property) method to enhance legacy code

A lot of legacy C++ code exists wherein member variables are directly exposed using the public or protected keywords instead of simple accessor / mutator functions. For example consider the following simple structure definition

typedef struct tagMyStruct 
{ 
   long m_lValue1; 
   ...             // Rest of the structure definition. 
} SMyStruct; 

Scattered throughout the client code that uses this structure will be code like the following:

SMyStruct       MyStruct; 
long            lTempValue; 

MyStruct.m_lValue1 = 100;       // Or any other value that is to be assigned to it. 
... 
lTempValue = MyStruct.m_lValue1; 

Now if the module that has all the above code is suddenly required to be used in a thread safe environment, you run into a problem. Because no accessor or mutator functions exist, you cannot just put a critical section (or mutex) within the definition of SMyStruct and protect m_lValue1 or any of the other public member variables.

If it is guaranteed that you will be using the Microsoft Visual C++ compiler then there is an easy solution at hand.

Just enhance the structure as follows:

typedef struct tagMyStruct 
{ 
   __declspec(property(get=GetValue1, put=PutValue1))

   long  m_lValue1; 
   ...                // Rest of the structure definition. 

   long GetValue1() 
   { 
      // Lock critical section 

      return m_lInternalValue1; 

      // Unlock critical section. 
   } 

   void PutValue1(long lValue) 
   { 
      // Lock critical section 

      m_lInternalValue = lValue; 

      // Unlock critical section 
   } 

private: 
        long m_lInternalValue1; 

        // Define critical section member variable. 
} SMyStruct; 
That's all.

For code such as

MyStruct.m_lValue1 = 100
the compiler will automatically substitute
MyStruct.PutValue1(100)

For code like

lTempValue = MyStruct.m_lValue1
the compiler will substitute
lTempValue = MyStruct.GetValue1()

The possibilities this opens up are many. You can even use this to add reference counting to legacy structures and classes.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


Written By
United States United States
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
GeneralAnybody help pls Pin
beatselva14-Dec-04 20:02
beatselva14-Dec-04 20:02 
Generalmore info on __declspec(property) Pin
TemplMetaProg3-Jul-02 10:56
TemplMetaProg3-Jul-02 10:56 
GeneralInfinte Array Pin
22-Jul-01 15:16
suss22-Jul-01 15:16 
GeneralRe: Infinte Array Pin
TemplMetaProg3-Jul-02 10:54
TemplMetaProg3-Jul-02 10:54 
GeneralRe: Infinte Array Pin
dhumalswati23-Aug-03 0:08
dhumalswati23-Aug-03 0:08 
GeneralThere is a second way to do it Pin
mh2x24-Aug-00 14:42
mh2x24-Aug-00 14:42 
GeneralRe: There is a second way to do it Pin
8-Jan-01 22:41
suss8-Jan-01 22:41 
GeneralRe: There is a second way to do it Pin
27-Aug-01 2:13
suss27-Aug-01 2:13 
GeneralA set of questions about this code -> Pin
Asaf Karass15-Jul-00 2:14
sussAsaf Karass15-Jul-00 2:14 
GeneralRe: A set of questions about this code -> Pin
Jeremiah S. Talkar17-Jul-00 4:57
Jeremiah S. Talkar17-Jul-00 4:57 
GeneralRE: Do not use this if possible Pin
lg20-Jan-00 7:56
lg20-Jan-00 7:56 
Dear Jeremiah,

Lest there be any misunderstanding, let me explain that I think this is a useful technique you have outlined, particularly for the purpose you proposed, i.e. of maintaining legacy code.

Nevertheless, it is part and parcel of C++ that some programmers will not hestitate to use techniques of last resort as part of the primary everyday toolkit. They are the ones to whom I directed my comment (i.e. not "do not use this" but "do not use this if possible"). I also understand that these sorts of properties will become more integrated in the everyday life in upcoming versions of VC++. To good or ill we shall see.

A good rule of thumb, I think, is that structs exposing data members should be PODs. The problem is what can one do when in retrospect one (or more usually the previous programmer one put the blame on :-> ) has made a bad design decision.

The better programming option is to bite the bullet, for example, to hide the data members, provide inline functions. The advantage in this case is that the transition is sharp, all the client code will break and will have to be fixed. This is in contrast to code
changes causing silent breaks in client or dependent code which really cannot be safely propagated. (Which is
why I understand but do not sympathisize with MS's reluctance to embrace some aspects of ISO std compliance).

Of course, if more than say ten angry programmers who outweigh one depend on these structs then it may be practically impossible to do anything other than what you suggest.

Another alternative is to encapsulate the whole struct, i.e. provide struct level locking/ protection reference counting or the like.

One just has to evaluate all the pros and cons. Programming is about compromises and sensible decisions rather than alas perfection. The technique you outline will no doubt provide an additional option to us poor beleaguered VC++ users
GeneralRe: RE: Do not use this if possible Pin
Jeremiah S. Talkar21-Jan-00 8:46
Jeremiah S. Talkar21-Jan-00 8:46 
GeneralRe: RE: Do not use this if possible Pin
Phil Harding14-Mar-05 22:09
Phil Harding14-Mar-05 22:09 
GeneralDo not use this if possible Pin
lg17-Jan-00 23:47
lg17-Jan-00 23:47 
GeneralRe: Do not use this if possible Pin
Chris Maunder18-Jan-00 12:36
cofounderChris Maunder18-Jan-00 12:36 
GeneralRe: Do not use this if possible Pin
Jeremiah S. Talkar19-Jan-00 18:17
Jeremiah S. Talkar19-Jan-00 18:17 
Generala doubt on The Microsoft VC++ Virtual Property feature Pin
vivek medhekar17-Jan-00 22:00
vivek medhekar17-Jan-00 22:00 
GeneralRe: a doubt on The Microsoft VC++ Virtual Property feature Pin
Jeremiah S. Talkar19-Jan-00 17:33
Jeremiah S. Talkar19-Jan-00 17:33 
GeneralRe: a doubt on The Microsoft VC++ Virtual Property feature Pin
Vitali Brusentsev19-Jan-00 22:31
Vitali Brusentsev19-Jan-00 22:31 
GeneralRe: a doubt on The Microsoft VC++ Virtual Property feature Pin
Jeremiah S. Talkar21-Jan-00 8:56
Jeremiah S. Talkar21-Jan-00 8:56 
GeneralRe: a doubt on The Microsoft VC++ Virtual Property feature Pin
Jeremiah S. Talkar22-Jan-00 9:54
Jeremiah S. Talkar22-Jan-00 9:54 
GeneralRe: a doubt on The Microsoft VC++ Virtual Property feature Pin
Jeremiah Talkar9-Apr-01 8:05
Jeremiah Talkar9-Apr-01 8:05 
GeneralRe: a doubt on The Microsoft VC++ Virtual Property feature Pin
9-Jun-02 8:32
suss9-Jun-02 8:32 
GeneralMessage Closed Pin
11-Jan-00 16:51
G Poulose11-Jan-00 16:51 
GeneralI have a question about VC++ Pin
5-Jul-01 5:08
suss5-Jul-01 5:08 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.