Menu
▾
▴
RE: even more macro problems with vxWorks: m_*
|
From: <dav...@di...> - 2012-03-29 10:33:34
|
One common practice for member variables is a trailing underscore e.g. m_next -> next_ instead of a leading underscore, which marks variables as member but avoids the reserved identifiers. Dave. Dr David Hickin Software Systems Engineer, Controls Group Diamond Light Source Ltd Diamond House Harwell Science & Innovation Campus Didcot, Oxfordshire, OX11 0DE -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom -----Original Message----- From: White, Greg [mailto:gr...@sl...] Sent: 29 March 2012 11:18 To: Ralph Lange Cc: EPICS V4 Developers Subject: Re: even more macro problems with vxWorks: m_* Ok Cool, I stand corrected. Still, if I have any credibility left I'd like to vote that Matej does not spend time changing all m_* to anything else. m_* is the only common practice I've seen, and I've found it useful. Greg On 29 Mar 2012, at 12:13, Ralph Lange wrote: > On 29.03.2012 12:04, Ralph Lange wrote: >> On 29.03.2012 11:56, White, Greg wrote: >>> Maybe use _* instead of m_*? >>> >> >> That would be worse. From the 1999 C standard: >> >> 7.1.3 Reserved identifiers >> >> Each header declares or defines all identifiers listed in its associated subclause, and optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers. >> >> . All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use. >> . All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces. >> . [...] > > Forgot the other snippet. From the 2003 C++ standard: > > 17.4.3.2.1 Global names [lib.global.names] > > Certain sets of names and function signatures are always reserved to the implementation: > > . Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use. > . Each name that begins with an underscore is reserved to the > implementation for use as a name in the global namespace.165 > 165) Such names are also reserved in namespace ::std (17.4.3.1). > > > ---------------------------------------------------------------------- > -------- > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |