(C++) operator = overloading with gcc 4.0.1
Hey there, all,
I have the following code I am trying to compile with gcc v4.0.1: Code:
struct vec3f Quote:
I know I can just write a class and overload the operator, but that's not the point. The point is I don't understand what is going on here, and now I must know why. Any insight would be delightful. Regards, Omni |
Try this:
Code:
struct vec3f |
Quote:
Quote:
Quote:
|
matthewg42 didn't read my post:
Quote:
I read the standards sections that dmail posted, and though they are indisputable, I still think they're stupid. I have a good idea, lets let the developers overload all operators as non-member functions, except the assignment operator. Let's just take consistency, and shoot it in the face! Doesn't that sound like fun? </Rant> <Semi-Rant> I suppose it's all in how one interprets "shall be" as stated in 15.5.3. Usually such terms are defined in a standard, I should look it up. But anyhow, "shall be" is not the same as "must be". </Semi-Rant> Don't mind me, I'm just pissed because I think it stupid. |
If elegance, simplicity, beauty and consistency are what you seek, C++ is the wrong language. Just my 2 pennies.
|
Quote:
Quote:
You don't need an assignment operator as it is implicitly declared and you have a POD type, in addition I think I am correct in thinking that it uses a byte for byte copy of the structure which may even be exactly the same thing you have wrote. The copy constructor, default constructor and assignment operator are some of the building blocks for the language and the standard calls them "Special member functions". Quote:
Quote:
|
dmail,
I think you just made an unwarranted jump. The example code was just that, an example. I know the implicit assignment operator will do exactly the same thing I presented in the example. But what if the data structures have pointers that need to be deep copied? Anyway, in all this thread has been a nice mental exercise. The answer to which is that the implicit operator needs to be overloaded because the existence of a non member assignment operator would introduce an ambiguous situation wherein the compiler would not be able to deduce which operator to use. I didn't think of it in those terms earlier. But thank you all who posted, --Omni |
Quote:
Quote:
|
All times are GMT -5. The time now is 11:08 PM. |