Quote:Original post by Kest

Quote:Flip a coin then. They're never going to be exactly the same in terms of effort and readability, so the answer doesn't matter [lol].

You're saying one or more of my examples were difficult in some way to type or understand?

Difficult? No. Comparatively slower? Yes.

#1 I grok intuitively.
#2 I can quickly reason that third ends up being the sum of first and second, but it's still a minor distraction from the problem at hand.
#3 Would cause me to look up the function implementation of "AsSum". "As____" is not a C++ idiom, and the phrase would not appear in any english sentence for the actual effect that I'd ever construct, leaving me less than confident that my educated guess as to what it did (assuming I even had one) was on the mark. I would then rename the function "AssignToSumOf", and try to remember what I was working on before being derailed into sanity checking.

Quote:Original post by Kest
That's actually useful information. But several helpful posters beat you to it while you were micro-optimizing my usage of time.

Except I explicitly mentioned return value optimization (RVO -- maybe you just didn't make the connection?) in the very first reply to this topic, and stated that this would cause that version of operator+ to perform on par with the += version within the listed constraints. I guess I beat myself?

And micro optimizing your time usage would be where I simply shat out the answer "no." to the original question, however inaccurate, and we moved on. Instead, I am (attempting to) steer not just you, but anyone else who might be taking advice from this thread, away from the large time sink that we see here on gdnet time and time again of newbies sinking their time into the question of "which is faster of these two int-adding methods or similarly trivial operation which end up compiling identically in 99.99% of cases and isn't going to be the bottleneck" instead of, say, actually learning programming, learning big-O notation, or learning how to write a search that doesn't operate in O(n3).

If that truely falls into your conception of micro-optimizing your time, well, I'd invite you to give an example of something that would qualify as a macro optimization. I'm more than willing to better optimize my time spent optimizing the time spent by others spent optimizing (or, hell, performing other tasks as well [lol])

Quote:Original post by MaulingMonkey
#3 Would cause me to look up the function implementation of "AsSum". "As____" is not a C++ idiom, and the phrase would not appear in any english sentence for the actual effect that I'd ever construct, leaving me less than confident that my educated guess as to what it did (assuming I even had one) was on the mark. I would then rename the function "AssignToSumOf", and try to remember what I was working on before being derailed into sanity checking.

It looks like you're trying pretty hard to find reasons to complain. It's difficult to imagine even a non-programmer having trouble understanding the meaning behind that function name. Regardless, you can change the syntax to Third.AssignTheThingOnTheLeftSideOfThisLongFunctionNameToTheSumOfTheTwoParamsInTheFollowingParenthesis(First,Second), and it's still just as easy to use with modern IDEs. It's a little bulky, but we have more important things to worry about than optimizing function names, right?

Quote:Except I explicitly mentioned return value optimization (RVO -- maybe you just didn't make the connection?) in the very first reply to this topic, and stated that this would cause that version of operator+ to perform on par with the += version within the listed constraints. I guess I beat myself?

Honestly, I appreciate every bit of your help. But you're spending more time complaining and antagonizing than helping.

Quote:Instead, I am (attempting to) steer not just you, but anyone else who might be taking advice from this thread, away from the large time sink that we see here on gdnet time and time again of newbies sinking their time into the question of "which is faster of these two int-adding methods or similarly trivial operation which end up compiling identically in 99.99% of cases and isn't going to be the bottleneck" instead of, say, actually learning programming, learning big-O notation, or learning how to write a search that doesn't operate in O(n3).

You do realize that I wasn't asking which adding operation was faster, right? The adding operation was just a stand-in. I was asking about how to best go about constructing objects and assigning them the result of an operation - any operation.

For many operations, functions would have to be used rather than operators. That means example 1, as it is, wouldn't work at all. That is, unless there's some way to perform a specific member-function task on construction, which is my main reason for posting. That's what I'd like. But I definitely wouldn't go so far out of my way as to create specific constructors for each specific operation, which is the type of micro-optimization you should be complaining about.

Quote:Original post by Kest

Quote:Original post by MaulingMonkey
#3 Would cause me to look up the function implementation of "AsSum". "As____" is not a C++ idiom, and the phrase would not appear in any english sentence for the actual effect that I'd ever construct, leaving me less than confident that my educated guess as to what it did (assuming I even had one) was on the mark. I would then rename the function "AssignToSumOf", and try to remember what I was working on before being derailed into sanity checking.

It looks like you're trying pretty hard to find reasons to complain.

No, he isn't. I am very much a programmer, and the name doesn't even make sense to me. AsX isn't a common idiom, and from the few times I've seen a function like that, I would expect it to take no arguments and perform an explicit conversion, with X being the converted-to type. Converting a Thing to a Sum doesn't make any sense to me, and isn't remotely what happens, anyway.

It's just plain not idiomatic to have a function with the described semantics. At strangest, you'd have a named function that does the same thing that operator+ does, but then I would curse the implementor for writing non-C++ in C++ and neglecting a perfectly good application of operator overloading.

(I would leave out 'To' - which implies assignment in the other direction, to me - and 'Of' - which doesn't add information - and just call it 'AssignSum'.)

Quote:Original post by Zahlman

Quote:Original post by Kest

Quote:Original post by MaulingMonkey
#3 Would cause me to look up the function implementation of "AsSum". "As____" is not a C++ idiom, and the phrase would not appear in any english sentence for the actual effect that I'd ever construct, leaving me less than confident that my educated guess as to what it did (assuming I even had one) was on the mark. I would then rename the function "AssignToSumOf", and try to remember what I was working on before being derailed into sanity checking.

It looks like you're trying pretty hard to find reasons to complain.

No, he isn't. I am very much a programmer, and the name doesn't even make sense to me.

AsSum? As in "as the sum of"? That doesn't make sense? Even though I find that odd, I don't have a ton of motivation to understand it.

Feel free to name the function whatever makes us freak out the least, as long as it leads to something more constructive.

Quote:It's just plain not idiomatic to have a function with the described semantics.

Man, I'm the kind of guy that would hang a floor fan from his ceiling, as long as it's practical, and it doesn't cause other problems. But this isn't really like that. This is more like the color of the fan clashing with the drapes. It's far below my tolerance level.

Quote:At strangest, you'd have a named function that does the same thing that operator+ does, but then I would curse the implementor for writing non-C++ in C++ and neglecting a perfectly good application of operator overloading.

I guess I really should have picked a non-standard operation for the example. I was trying to make the situation as obvious as possible, but I forgot how sensitive you guys are.

Quote:Original post by Codeka

Quote:Original post by Kest
I guess I really should have picked a non-standard operation for the example. I was trying to make the situation as obvious as possible, but I forgot how sensitive you guys are.

I think you need to either provide an example of exactly what you're actually thinking of, or provide a less concrete write-up. The problem with addition is that operator + is such an idomatic concept, that doing it any other way is a bad idea, regardless of any performance benefits.

It can by anything. For instance, thing can be a vector, and the operation can store the result of one vector being rotated around another vector. What I'd like to have is some example 1 way of doing that. Example 2 would be something like..
Vector rotated = original_vector;
rotated.RotateAxis( axis_vector, angle );

I could just completely avoid member functions altogether, and I would pretty much have a solution:

Vector rotated = VectorRotateAxis( original_vector, axis_vector, angle );

But that would also turn something friendly like..

forward.RotateAxis( axis, angle );

into..

forward = VectorRotateAxis( forward, axis, angle );

I don't see how gaining one is any better or worse than gaining the other. I came here because I thought it would be swell to have both.

Quote:Original post by Codeka

Quote:Original post by Kest
I don't see how gaining one is any better or worse than gaining the other. I came here because I thought it would be swell to have both.

Well, when designing an API, I believe it is important not to include multiple ways to do the same thing.

Essentially, if a programmer wants to use member functions to perform operations, then they can't assign the results of those operations on construction of the object (such as Object x = Function(a,b)). It's either member functions, or assignment on construction. Only one can be had. That's what I mean by wanting both, not that I want two ways of doing the same thing.

Oh well. I wanted to throw it out there to see if anything existed. Since it doesn't, my quest is complete. I appreciate your help.