|
i'm sorry
i cant writing english.
my question is editing........
help me for this program......
hi......
|
|
|
|
|
"Editing" is a rather broad field. You'll have to more specific to have any hope of getting useful advice.
Steve
|
|
|
|
|
URGENT!!! I have a problem. Please post the solution.
Steve
|
|
|
|
|
I am having a difficult time understand what is really happening when I overload an operator for a class. Here is my class declaration. CC is short for CCarteseanCordinates.
class CC
{
public:
CC(void);
~CC(void);
CC operator+( CC &source );
double Query_X();
double Query_Y();
double Query_Z();
void Set_X( double value );
void Set_Y( double value );
void Set_Z( double value );
protected:
double X;
double Y;
double Z;
};
Attempting to follow format of the example in the book I have, the definition of the + operator overload is:
1 CC CC::operator+( CC &source )
2 {
3 CC result = *this;
4 double sum = source.Query_X() + X;
5 result.Set_X( sum );
6
7
8 return result;
9 };
Line 3 starts with
CCarteseanCordinates result
Which seems to create a local object of type CCarteseanCordinates.
Now adding on the = *this;, the line now seems to say assign to that object the value of the local this pointer.
That is similar to writing
Int y;
Int *z = &y;
Int x = *y
Except: The equal operator has not been overloaded so
Object1 = object2;
Is not a valid construct.
Should my declaration really be something like:
CC operator+( CC &source1, CC &source2 );
What is really going on here, and what should be going on?
Lets ignore the friend operator for the moment.
Thanks for your time
|
|
|
|
|
In a class Constructor, Copy Constructor and assignment operator are automatically generated by compiler if needed.
First and most important is the definition of operator. You should understand that operator is nothing by a function. So for CC class if you write a = b + c, where a, b, and c are objects of type CC, what it really means is a = b.operator+(c). Does this makes sense?
Another this is there is no need to use functions to access variables within the class. You can do this as:
CC CC::operator+(CC &source)
{
CC result = *this;
result.X += source.X;
result.Y += source.Y;
result.Z += source.Z;
return result;
}
Hope this helps.
-Saurabh
|
|
|
|
|
RE: what it really means is a = b.operator+(c).
No, I am missing several things here.
Lets skip around a bit. First + (the plus symbol) is a binary operator as in:
int a, b, c;
a = b + c;
That means it has two arguments. To write this in the form of a function we would use the format:
result = add( y, z );
So there should be two arguments in the declaration. But when I write this in the dot h file:
CC operator+( CC &source1, CC &source2 )
The compiler says:
error C2804: binary 'operator +' has too many parameters
That seems to be in direct contradiction of the form:
a = b + c;
The addition operator has three variables, one left and two right.
As the values are being put in x, and read from y and z, it seems that the function is being run from the perspective of object x.
What am I missing?
I have another question, but lets take this one point at a time.
Thanks for your time
|
|
|
|
|
bkelly13 wrote: That means it has two arguments
Yes, it is just written down differently.:-
a=b.operator+(c); The First argument is the object carrying out the addition, the second argument is the item being added. I.E. the Operator+ MEMBER FUNCTION adds a value to the object from which it is called, and passes the result, without modifying itself,
The form c=add(a,b) is typically a global addition function.
Answers to the other issues you raised follow directly when you grasp the concept of the above.
Regards 
Bram van Kampen
|
|
|
|
|
RE: So for CC class if you write a = b + c, where a, b, and c are objects of type CC, what it really means is a = b.operator+(c). Does this makes sense?
NO, it really does not make sense. The value being written is going into object a and the function should be called from the perspective of object a. To operate from the b perspective is counter-intuitive and just flat bad design. If we follow this up logically, a unary operation such as += should have one less argument, or zero arguments. However, that’s not my call so I had best learn to deal with it.
Regardless, lets see where this goes. The declaration looks like:
CC operator+( CC &source1 );
And the code looks like:
CC CC::operator+( CC &source1)
{
CC result = *this;
double sum = source1.X + X;
result.X = sum ;
return result;
};
And if I follow what your write, which is not certain, the code is executed from the perspective of object b. As I did not include the qualification “friend” in the declaration, code running from b does not have access to private variables in object a or in object c. That means that I should not have direct access to result.X or source1.X. So how can the compiler accept this code without error? It should force me to write:
double sum = X + source1.Get_X();
result.Set_X = sum;
in the first line, X is from the b object, source1.Get_X() gets the value from the c object, and in the third line result goes to the a object.
Given that the perspective is as you noted: a = b.operator+(c), why does the function have direct access to private members in objects a and c?
Although I have not yet figured this out, thank you for taking the time to respond.
Thanks for your time
|
|
|
|
|
I think the biggest thing you are missing is that member functions of a class have full access to all member variables. It doesnt matter which object called the function, all objects of that class can access private members in a member function of same class. Lets take an example
class Foo
{
private:
int x;
public:
Foo(int _x)
{
x = _x;
}
inline int AddX(const Foo& B)
{
return x + B.x;
}
};
Now you might think that it is a bad design to make private variable accessible - A can access B' x and vice-versa. But that is not the case. Why is it so? Because access modifies are for the classes which use this class. So for example if you want to hide member variables from other classes you will use private. These member variable will still be visible within the class definition.
Now lets see if this was not the case. Then you must have a public function to set and get value for every private variable. Well in this case the private variables are as good as public variables. Does this make sense?
Okay this is c++ side of the explanation. Lets work on intuition of how a = b + c should work. In the class definition I gave above I can do the following.
Foo f1(10);
Foo f2(2);
int y = f1.AddX(f2);
Look at it carefully it has, mathematically, same structure as a = b + c. But will you in this case say that since y is the return value the function should be called in perspective of y? And AddX should have two arguments instead of one? I hope answer to these questions in no. Now lets see how to read a = b + c in terms of c++ -> call b's member function operator+ with a single argument c and return a value a. In simpler words a = b.operator+(c). Now since a, b, and c are objects of same class the function operator+ (which is member of same class) have full access to class data. If we add operator+ to Foo it will look like.
class Foo
{
private:
int x;
public:
Foo(int _x)
{
x = _x;
}
inline int AddX(const Foo& B)
{
return x + B.x;
}
Foo& operator+(const Foo& B)
{
Foo a;
a.x = x + B.x
}
};
Only differece unary operator+ has is that it operates on same object which calls the function instead of creating a new one.
Foo& operator+(const Foo& B)
{
x = x + B.x;
return *this;
}
I hope this makes things a bit clearer now.
-Saurabh
|
|
|
|
|
After posting I realized that another example might make thinks more clearer.
class Foo
{
public:
Foo(int _x)
{
x = _x;
}
Foo& Add(const Foo& B)
{
Foo a;
a.x = x + B.x;
return a;
}
private:
int x;
};
Foo a(10);
Foo b(20);
Foo c = a.Add(b);
Now instead of Add using operator and then imagine that compiler cannot see operator word in the code using this class. You will get.
class Foo
{
public:
Foo(int _x)
{
x = _x;
}
Foo& operator+(const Foo& B)
{
Foo a;
a.x = x + B.x;
return a;
}
private:
int x;
};
Foo a(10);
Foo b(20);
Foo c = a.opeator+(b);
Foo d = a + b;
You must try to run this second example. Foo c = a.opeator+(b) is a valid c++ code and will compile just fine. b + c is provided for convenience which is automatically converted by compiler to b.operator+(c).
-Saurabh
|
|
|
|
|
Hi,
CC result= *this;
does not create anything; it declares a reference called result to a type CC and sets it equal
to *this, so now result and this are one and the same object.
IMO it was not really necessary; there must be a way to do *this.Set_X(sum) directly)
in your line 5.
modified on Sunday, July 6, 2008 5:31 PM
|
|
|
|
|
Luc Pattyn wrote: CC result= *this;
does not create anything; it declares a reference called result to a type CC and sets it equal
to *this, so now result and this are one and the same object.
Sorry, that statement is not correct.
CC result= *this;
creates an object of type CC and assigns the contents of the current object to it. To create a reference you would use CC& result = *this;
Actually the above code probably does not use the assigment operator, it may well use the copy constructor (the compiler is allowed to treat declaration and assignment in one statement as copy construction rather than default construction followed by assignment).
Graham
Librarians rule, Ook!
|
|
|
|
|
Hi,
I believe you are right, I was looking through my C# glasses once more.
|
|
|
|
|
The code is fine, the compiler will generate operator= and the copy constructor for you, it's simply implicit instead of explicit.
Rhe default implementation is a simple bitwise copy.
The way the compiler generates the copy is sort of like:
ClassA::ClassA( const ClassA &from)
:member1( from.member1 )
,member2( from.member2 )
,.... etc
{}
This is perfectly fine for this class since you don't have any pointers to worry about.
The default for operator= is functionally the same as the copy constructor.
So your code for operator+ is correct.
this is copied to result.
result is modified.
this actually remains constant.
So actually to be on the safe side you should do.
......
CC operator+( CC &source ) const;
......
CC CC::operator+( CC &source ) const
{
CC result = *this;
double sum = source.Query_X() + X;
result.Set_X( sum );
return result;
}
|
|
|
|
|
Hello Dan,
I am rather certain I agree about the const. However, I am a bit weak on exactly where the const goes to effect which part of a declaration. For the moment, I want to keep the thread as simple as I can. I will get back to the const in another thread. Thanks for the reminder.
Thanks for your time
|
|
|
|
|
Hi,
Can I know how to perform structured exception handling in Windows Vista..
I need alternatives to Isbadreadptr,IsBadWritePtr in Windows Vista.. But Vista documentation suggests to perform Structured exception handling. Can I know how to perform Structured exception handling
Thanks,
venkat
|
|
|
|
|
Using IsBadReadPtr or Structured Exception Handling (or for that matter any other method) to detect illegal memory accesses is wrong headed in the vast majority of cases. There are many issues but here are a few:
- Makes debugging harder as an exception that would have triggered a debugger or the generation of a crash dump is swallowed. I do a lot of post-mortem debugging: when you click the “Send Error Report” button, in theory, someone will look at the dump-file which is sent and actually figure out what’s going on. If you don't use the Windows Error Reporting[^] service (or something else which performs the same task) then you're doing it wrong.
- In general proper recovery is impossible and attempting to just makes things worse. An analogy is a person who continues to drive with a flat tire.
Follow link this[^] for Larry Osterman's opinion on the matter and follow this[^] link for Raymond Chen's.
Steve
|
|
|
|
|
Thanks Steve. Can I Know what could be the better substitute for detecting illegal memory access.. Can I have a sample code snippet to get an idea.
Thanks,
Venkat
|
|
|
|
|
int* x = new int[1000];
void foo(int i)
{
if(i>0 && i<1000)
{
x[i] = 0;
}
else
{
}
}
That's it!
-Saurabh
|
|
|
|
|
As I said, in general the best substitute for detecting an illegal memory access is crashing!
Steve
|
|
|
|
|
Hi,
We have a legacy code written in C. We are porting to Windows Vista. We have certain checks like IsBadReadPtr and IsBadWritePtr. These two checks donot work in Windows-Vista. Can I know how to validate a memory block before its usage in Window-Vista... I mean what could be the appropriate replacement for IsBadReadPtr and IsBadWritePtr in Windows Vista.
Thanks,
Venkat
|
|
|
|
|
Documentation [^] suggests to substitute such a function with structured exception handling.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks.. Can I have a code snippet for performing structured exception handling..
|
|
|
|
|
Possibly documentation [^] helps.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: Possibly documentation helps.
Not when left unread 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
