Question on Syntax

I have a question on this syntax... what does the underscore mean on some of this code

_legs
_bark
_dogSize

why not just say legs or bark ? is there anything special ? to do with this ?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
// class.cpp
// compile with: /EHsc
// Example of the class keyword
// Exhibits polymorphism/virtual functions.

#include <iostream>
#include <string>
#define TRUE = 1
using namespace std;

class dog
{
public:
   dog()
   {
      _legs = 4;
      _bark = true;
   }

   void setDogSize(string dogSize)
   {
      _dogSize = dogSize;
   }
   virtual void setEars(string type)      // virtual function
   {
      _earType = type;
   }

private:
   string _dogSize, _earType;
   int _legs;
   bool _bark;

};

class breed : public dog
{
public:
   breed( string color, string size)
   {
      _color = color;
      setDogSize(size);
   }

   string getColor()
   {
      return _color;
   }

   // virtual function redefined
   void setEars(string length, string type)
   {
      _earLength = length;
      _earType = type;
   }

protected:
   string _color, _earLength, _earType;
};

int main()
{
   dog mongrel;
   breed labrador("yellow", "large");
   mongrel.setEars("pointy");
   labrador.setEars("long", "floppy");
   cout << "Cody is a " << labrador.getColor() << " labrador" << endl;
}
The underscore is just to differentiate between the member variable and the function parameter.
Variable names with a leading underscore followed by a capital letter are reserved, compilers shouldn't let you use them. It's the same for leading double underscore variable names.
I believe leading single underscore followed by a lowercase letter names are reserved for variables with file scope, though I'm not certain of this and assuming I am, I don't know how strongly compilers enforce it.

Here's what the C++ Standard says (17.4.3.1.2): "Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter is reserved to the implementation" and "Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace."

http://pkisensee.spaces.live.com/blog/cns!3C84486A9D832EB7!246.entry

They are "reserved," but not "restricted," meaning you can use them if you like. The danger (as indicated in the link) is that your particular compiler may just happen to use it as part of its "implementation," and you'll get a bug that'll keep you up late for weeks.

I personally tend to follow a convention used in Delphi programming and that is to prefix private data with the letter F, as:
1
2
3
4
  private:
    int         f_age;
    std::string f_name;
    ...

(BTW, IDislikeClumpedUpVariableNames.)
I've also seen stuff beginning with a lowercase M, as in:
1
2
3
4
  private:
    int         mAge;
    std::string mName;
    ...


Personally, I think that a leading underscore looks funny and hokey, so I avoid it whenever possible (but that doesn't mean I haven't been known to use them in weak moments).

A better convention would be to set your arguments to begin with underscores (or in the Delphi convention, the letter A):
1
2
3
4
5
void setEars( std::string _length, std::string _type )
  {
  earLength = _length;
  earType   = _type;
  }

or
1
2
3
4
5
void setEars( std::string aLength, std::string aType )
  {
  earLength = aLength;
  earType   = aType;
  }

This is perfectly safe and acceptable, since arguments are temporary variables in a local scope... so long as you don't do some magic that will cause your compiler to invade the local scope with "its" stuff (using templates and the like).

Also personally, I think it is not much grief to simply use the same names:
1
2
3
4
5
void setEars( std::string earLength, std::string earType )
  {
  this->earLength = earLength;
  this->earType   = earType;
  }

Such usage avoids all ambiguity and has the benefit of unadorned names everywhere. The only place it is a potential clash is in the setEars() method, and it wasn't even a problem.

/end dump
Topic archived. No new replies allowed.