Thread: another way for "this" pointer

  1. #1
    Registered User
    Join Date
    Jan 2008
    Posts
    18

    another way for "this" pointer

    here is my code for a .cpp of a header file. My question is: is there another way to write this than using "this" pointer?

    Code:
    #include "Integer.h"
    
    Integer::Integer() //once Integer object is made it will be initialized to 0
    {
    	this->number=0;
    }
    
    Integer::Integer(int num) //once an Integer object is made it will be initialized to num
    {
    	this->number=num;
    }
    
    Integer::~Integer()
    {
    //nothing
    }
    
    int Integer::getInt()
    {
    	return this->number;
    }
    
    bool Integer::operator<(Integer i) // overload < operator
    {
    	if(this->number<i.number)
    		return true;
    	else
    		return false;
    }
    
    bool Integer::operator>(Integer i) //overload > operator
    {
    	if(this->number>i.number)
    		return true;
    	else
    		return false;
    }
    
    int Integer::operator++() //overload ++ operator
    {
    	return this->number++;
    }
    
    int Integer::operator--() //overload -- operator
    {
    	return this->number--;
    }
    just editited my code...this is the correct one
    Last edited by dukebdx12; 06-22-2008 at 12:05 AM.

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    If there is no conflict in names, you can usually omit the use of the this pointer when writing a member variable name:
    Code:
    int Integer::getInt() const
    {
    	return number;
    }
    Note that I added the const keyword because getInt() should be a const member function. This change should be reflected in your class definition.

    Also, try to initialise member variables in the constructor initialisation list instead of assigning to them in the constructor body:
    Code:
    Integer::Integer(int num) : number(num) {}
    Incidentally, your implementation of operator++ and operator-- is semantically incorrect. For one thing, they should probably return a reference to an Integer instead of an int by value, then they should implement the operation as a pre-increment since you overload the prefix operator.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    In addition to what laserlight said:

    Don't write empty constructors. If you have nothing to manually destruct then writing a destructor is unnecessary and just makes extra code that can hold extra bugs.

    Operator < and > should really be overloaded as the two-parameter friend version.

    The pattern:
    Code:
    if (x) return true; else return false;
    is always redundant. the expression x is already a boolean expression so just return it. I.e.
    return x;
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  4. #4
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    Or, if you prefer:
    Code:
    return x != 0;
    (That way it doesn't look like you're returning an int from a function with a bool return type, for example.)
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by dwks View Post
    Or, if you prefer:
    Code:
    return x != 0;
    (That way it doesn't look like you're returning an int from a function with a bool return type, for example.)
    Or, if you want to do awkward looking code:
    Code:
    return !!x;
    That will force a non-bool variable into a bool - the first ! will make it into a bool, the second converts it back to "normal polarity".

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    The != 0 will prevent the warning from VC++. The other, I think, will not.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by CornedBee View Post
    The != 0 will prevent the warning from VC++. The other, I think, will not.
    So you mean you can't write return !x where x is a pointer for example? (So you have to write x == 0? That would be quite a severe "warnings where other compilers won't warn" issue, in my mind.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #8
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    I think it's the C4800 warning you're talking about:
    'type' : forcing value to bool 'true' or 'false' (performance warning)
    http://msdn.microsoft.com/en-us/libr...cy(VS.71).aspx

  9. #9
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    To get rid of the warning, you must express the expression in boolean form. Say if it's an integer, do you can int != 0 to create a boolean expression.
    However, I'm pretty sure !!expr also works.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    I prefer to be more explicit with: if ( iVal != 0 ) or if ( bVal == true )...
    That way it's harder to miss the meaning when you're really tired and the screen is a bit blurry.

  11. #11
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Sorry I actually meant where x was an expression, not just a variable. I should have written if (<expression>)
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  12. #12
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Quote Originally Posted by iMalc View Post
    Don't write empty constructors. If you have nothing to manually destruct then writing a destructor is unnecessary and just makes extra code that can hold extra bugs.
    An empty destructor may be necessary if the value is potentially polymorphic. This is probably not the case with a class named Integer, though. OTOH, it is not a bad habit to always include a virtual destructor where performance is not a concern.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  13. #13
    Registered User
    Join Date
    May 2008
    Location
    Paris
    Posts
    248
    Operator < and > should really be overloaded as the two-parameter friend version.
    Or simply non-friend, non-member operators (use the 'get' functions).

    Tip: Change 'getInt()' in simply 'get()' , if you change the type of some variable somewhere in client code of your library, you don't want to change all getters and setters. An operator '<' is called '<' for every type, you don't implement a '<int' either. Types should be determined in the argument list, not in the function name!

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Following CTools
    By EstateMatt in forum C Programming
    Replies: 5
    Last Post: 06-26-2008, 10:10 AM
  2. Quick Pointer Question
    By gwarf420 in forum C Programming
    Replies: 15
    Last Post: 06-01-2008, 03:47 PM
  3. Parameter passing with pointer to pointer
    By notsure in forum C++ Programming
    Replies: 15
    Last Post: 08-12-2006, 07:12 AM
  4. Direct3D problem
    By cboard_member in forum Game Programming
    Replies: 10
    Last Post: 04-09-2006, 03:36 AM
  5. Struct *** initialization
    By Saravanan in forum C Programming
    Replies: 20
    Last Post: 10-09-2003, 12:04 PM