macOS friends in C++...

Sean7512 · Mar 1, 2006

Yesterday in my C++ class, we were talking about overloading operators so we can use them with our own classes. So our teacher says "Now, what is a friend?....Well, according to C++, a friend is someone who has access to your private parts!"

I thought this was hilarious, what do you guys think?

I'm sure everyone will understand the joke.

cube · Mar 1, 2006

Friends don't let friends program in C++.

ChrisBrightwell · Mar 1, 2006

Sean7512 said:
Yesterday in my C++ class, we were talking about overloading operators [...] what do you guys think?

I think they need to quit teaching how to overload operators.

jeremy.king · Mar 1, 2006

I thought they were called friends with benefits

bousozoku · Mar 1, 2006

ChrisBrightwell said:
I think they need to quit teaching how to overload operators.

It's certainly ugly and they were considering adding it to Java.

Friends is an interesting idea and I've had to use it on occasion but I think a lot of people use it to avoid designing something properly.

You have to be careful in C++. It lets you do your worst and compiles it usually.

zimv20 · Mar 1, 2006

ChrisBrightwell said:
I think they need to quit teaching how to overload operators.

what wrong with operator overloading? operator<< is great for testing and debugging.

netytan · Mar 1, 2006

zimv20 said:
what wrong with operator overloading? operator<< is great for testing and debugging.

I don't use C++, it's more than a little too ugly for me to want to be `that' close a friend with it

.

Operator overloading isn't inherently bad but when every tom dick or jane overload every operator for every single class like they do things become very hard to follow very fast.

The sad thing is that C++ programmers think it's oh so powerful but in reality it's next to useless; it serves no practical use and it's a hopeless way of developing an abstraction.

If you get wet for operator overloading that way then you should look at macros in Lisp

.

Take care,

Mark.

zimv20 · Mar 1, 2006

netytan said:
The sad thing is that C++ programmers think it's oh so powerful but in reality it's next to useless; it serves no practical use and it's a hopeless way of developing an abstraction.

Code:

BBThread* thread = new BBThread("https://forums.macrumors.com/showthread.php?p=2190373");

BBUser* user1 = new BBUser("zimv20", "#jdie$oLL4");

thread->login(user1);
thread->postNew("i disagree");

cout << thread << endl;

BBUser* user2 = new BBUser("netytan");

user1->addToFriends(user2);

cout << user1 << user2 << endl;

in my years of coding C++ professionally, this is an example of how i might write a unit test file. i'd overload << in order to facilitate testing.

and since i was a server tier guy, i'd write a command-line program to test all the CORBA interfaces. operator<< was extremely useful in that, too.

so i disagree that overloading is useless, and i must admit i don't know what you mean about using overloading to "develop an abstraction".

and i'll never agree that a language should be dumbed down to try to avoid programmer abuse. that's what coding standards and lead developers are for.

notjustjay · Mar 1, 2006

Sean7512 said:
a friend is someone who has access to your private parts!

I think technically it's access to your private members.

therevolution · Mar 1, 2006

zimv20 said:
Code:

cout << user1 << user2 << endl;

In that situation, why can't you just write:

Code:

cout << user1.toString() << user2.toString() << endl;

Overloading << doesn't really have any advantages, save slightly more terse code (which isn't necessarily a good thing). If you prefer the style of your way, then okay, but style isn't a great reason to argue for a feature's usefulness.

zimv20 · Mar 1, 2006

therevolution said:
Overloading << doesn't really have any advantages, save slightly more terse code

i understand your point, but i believe it goes beyond the convenience of the shorthand (which i do find convenient).

one of the things i like about class-based languages is this idea of extensible data types. i like that C++ allows me to define a class which has access to +, ==, <<, et. al., just as an int does.

so it goes beyond practicality and towards ideology.

that said, of course operators should be overloaded only when it makes sense for an object of that class.

so far, the objections to overloading have been about confusing code* and programmer abuse. but i seem to be the only one who appreciates what a well-defined operator can add to the simplicity of the project. is this the case of the good outweighing the bad? frankly, i'm not used to programmers who want less from their tools.

* defining an operater really isn't all that difficult. yeah, it clutters up the class a little bit, but, c'mon, we're programmers and pattern matchers to boot. once you get used to seeing the class code, what's the worry? plus, my classes have always been quite easy to grok and support, as are the classes of those working for me. i see to that. and it makes the code using those objects more elegant, imnsho.

i'm a bit concerned by this "we can't understand it" crap. if one of my programmers complained to me that simple language constructs were too difficult to understand, well.... they'd get themselves reassigned pretty quickly. no room for such whinging on my projects.

netytan · Mar 1, 2006

zimv20 said:
...in my years of coding C++ professionally, this is an example of how i might write a unit test file. i'd overload << in order to facilitate testing.

and since i was a server tier guy, i'd write a command-line program to test all the CORBA interfaces. operator<< was extremely useful in that, too.

so i disagree that overloading is useless, and i must admit i don't know what you mean about using overloading to "develop an abstraction".

and i'll never agree that a language should be dumbed down to try to avoid programmer abuse. that's what coding standards and lead developers are for.

I have to say it; quasi-typical C++ programmer attitude with the language being dumbed down comment

.

You should be aware that C++ was developed to make programming in C easier and more abstracted by moving up a tier.

Ultimately the misguided belief of most programmers that there language of choice is as good as it gets is what turns the learning curve upside down the dumbing down of the industry though this effect is in my honest opinion the reason you need "lead developers".

I'm not saying everyone should be a programmer, quite the contrary I have amazingly high standards and don't think 80-90% of programmers are good programmers (it's also known as being opinionated

).

Operator overloading is generally in my experience is most commonly used to build up a more abstract syntax for interaction between class instances. Using + to concatenate two strings together for instance is very common in a lot of languages that support overloading and I can say without doubt that this has been implemented for C++ somewhere

.

The problems come when you're trying to read code that looks like this:

Code:

#include "Place.h"

Place n = 2, d = 1;

printf("%s", a / b);

The problem should be very clear. If the class overloads operators then how are you supposed to know what this does? At a glance you wouldn't have a clue, i'd be inclined to think division, and that's when the trouble starts.

This is done ALOT from what I've seen and heard, it's a very common annoyance

. Why is it so bad? Because operator oversloading isn't powerful enough to make a usable abstraction, instead take this code:

Code:

#import "Place.h"

Place *n, *d;

*n = [Place initWithI: 2];
*d = [Place initWithI: 1];

NSLog(@"%@", [place the:n over:d]);

Objective-C is hardly the most beautiful language but it should be immediately more clear what the codes doing. This is only touching the iceburg of what can be done in some languages for instance recently I added the foreach loop to a language I was using for a project in 5 lines. This is a usable abstraction.

There very silly examples that would never be seen in the real world; in the real world things are worse! I think C++ users enjoy nothing more than overloading this and that just for the hell of it and the result isn't pretty

.

I'm not trying to be offensive so please don't take it that way. I just find it amusing that the masses love such a deficinent language and featured abstraction

.

Take care,

Mark.

therevolution · Mar 1, 2006

zimv20 said:
i seem to be the only one who appreciates what a well-defined operator can add to the simplicity of the project.

Maybe you are.

I just don't see a compelling use for it that isn't a matter of style. And as anyone who has maintained someone else's code knows, beautiful code is in the eye of the beholder.

Personally, I don't mind being a little more verbose (as with 'cout << user.toString()' vs. 'cout << user') to remove a possible point of ambiguity - to me, that is what makes elegant code. I will admit that this particular example probably isn't the most compelling piece of evidence for my point of view - '<<' is pretty straightforward and obvious - but with different operators, that might not be the case.

netytan · Mar 1, 2006

zimv20 said:
so far, the objections to overloading have been about confusing code* and programmer abuse. but i seem to be the only one who appreciates what a well-defined operator can add to the simplicity of the project. is this the case of the good outweighing the bad? frankly, i'm not used to programmers who want less from their tools.

* defining an operater really isn't all that difficult. yeah, it clutters up the class a little bit, but, c'mon, we're programmers and pattern matchers to boot. once you get used to seeing the class code, what's the worry? plus, my classes have always been quite easy to grok and support, as are the classes of those working for me. i see to that. and it makes the code using those objects more elegant, imnsho.

i'm a bit concerned by this "we can't understand it" crap. if one of my programmers complained to me that simple language constructs were too difficult to understand, well.... they'd get themselves reassigned pretty quickly. no room for such whinging on my projects.

Lol, awesome

.

But it's not about misunderstanding, its about inelegance. It's about being able to read code from a large project without having to crawl though the definitions of each class to figure out wtf it's doing when you see x operator.

It's about not wasting valuable time that could be spent auditing producing less buggy code. On the occasions were you make the assumption that you KNOW what's going on... and you're wrong you can end up causing a lot of problems. Confusion is contagious.

I'm all for abstraction, I love it! It makes programs more beautiful to look at, easier to read, easy to debug, shorter. What I have a problem with is such a weak method for adding abstraction to programs being drool over by a whole culture who don't know any better.

Give me a good method for implementing abstraction and I'll give you code you wouldn't believe; give me operator overloading and i'll laugh and hand you my resignation it's just that simple. No need for reassignment

.

I will agree that they can make trivial code simpler on occasion.

Mark.

zimv20 · Mar 1, 2006

netytan said:
I have to say it; quasi-typical C++ programmer attitude with the language being dumbed down comment .

i am arrogant. then again, most good programmers are.

C++ was developed to make programming in C easier and more abstracted by moving up a tier.

from what i've read, stroustrup never intended for C++ to replace C. C is reserved for its strength -- highly efficient, lower-level coding, while C++ was intended to add user-defined datatypes and provide for higher quality libraries (both OTS and custom). so i agree with the "more abstracted" bit.

Ultimately the misguided belief of most programmers that there language of choice is as good as it gets is what turns the learning curve upside down

i don't want to imply that i think C++ is the end-all and be-all of languages. it's not. it excels at my area of expertise, and that's server-tier OO services.

for GUI, i'd rather use something else. for 2-tier web development, i like php. languages are made for specific purposes, and no one language excels at them all.

what bristles me are people designating C++ a poor language for the wrong reasons. yes, it has its quirks and issues, but the availability of operator overloading is not one of them. indeed, it goes a long way towards the goal of creating high-quality libraries.

no one seems to complain that string classes overload operator== and operator=, for example.

I have amazingly high standards and don't think 80-90% of programmers are good programmers

put me in the 98-99% range. (more arrogance

The problems come when you're trying to read code that looks like this:

check your code, a and b are undefined. but i know what you're getting at.

there is no excuse for creating a class with a confusing interface. when i'm creating classes, libraries and services, my number one goal is to make the API logical and easy for the users of my API to understand and program to.

if i have a choice between making the interface better or the code easier to implement, i will always choose the former.

my number two goal is to make my implemenation code as easy to support as possible.

C++ gives me the tools to make that possible. disallowing operator overloading would hinder that. that's really the only point i'm making.

I'm not trying to be offensive so please don't take it that way. I just find it amusing that the masses love such a deficinent language and featured abstraction .

you're not being offensive at all, no worries. regarding C++ being deficient, i'm curious as to what you mean by that beyond granting the ability for developers to write bad code.

i'm also interested in knowing the criteria for a language being deficient. is it as compared to other languages in vogue at the same time? is it looking at how well the language supports its design goals? or is a comparison between languages which work in the same solution space?

zimv20 · Mar 1, 2006

netytan said:
it's not about misunderstanding, its about inelegance. It's about being able to read code from a large project without having to crawl though the definitions of each class to figure out wtf it's doing when you see x operator.

indeed. as i stated above, there's no excuse for a confusing interface. i hope we can all agree that granting a string class these operators makes sense: +, =, ==, <<

but i haven't seen a string class that supports the % operator. why not? it makes no sense.

if one of my developers added operator+ to a StreetAddress class, i'd ask him what he was on about. but operator= and operator== make sense, imo.

operator overloading is really no different than any other interface concern. ALL methods must make sense in the context of the class. otherwise, i've got an issue.

zimv20 · Mar 1, 2006

therevolution said:
I don't mind being a little more verbose (as with 'cout << user.toString()' vs. 'cout << user') to remove a possible point of ambiguity

that won't cover all situations, though. let's say i'm writing a music app and i find it useful to add together notes and chords. i suspect that in doing so, i'll want to check for duplicate notes and determine if the new chord is greater than the sum of its parts. for example:

Code:

Note a3(A3);
Note e4(E4);

Chord chord1 = a3 + e4;

Note c4(C4);

Chord chord2 = chord1 + c4;

cout << chord2 << endl;

Note f3(F3);

chord2 += f3;

cout << chord2 << endl;

i'd get output something like this:

Code:

Am
Fmaj7

(musicians please check my chord nomenclature)

i think the sample code above is intuitive and easy to read. disagreements?

netytan · Mar 1, 2006

zimv20 said:
indeed. as i stated above, there's no excuse for a confusing interface. i hope we can all agree that granting a string class these operators makes sense: +, =, ==, <<

but i haven't seen a string class that supports the % operator. why not? it makes no sense.

if one of my developers added operator+ to a StreetAddress class, i'd ask him what he was on about. but operator= and operator== make sense, imo.

operator overloading is really no different than any other interface concern. ALL methods must make sense in the context of the class. otherwise, i've got an issue.

Of course I agree with that however the fact remains that the vast majority of C++ classes aren't so tidy or idealistic. Would you overload anything for a Mortgage class? Can you think of any operators that might be useful for that? You may not but thousands would

.

Classes with operator overloading become inconvenient when you're reading someone else's code because without first reading and remembering the code for all the classes being used you don't have the information you need yes there is usually documentation but the point stands.

Unless you have a very small context and are using descriptive variable names operator overloading will have detrimental effect on how easy the code is to understand, and so how quickly you'll be able to work on it (to put things into terms industry is concerned with) and how many bugs there'll be at the end (something the industry isn't so concerned with).

What I was trying to impart is that operator overloading is a poor excuse for abstraction at any level and serves little use for 99% of classes IMPS

.

I would take the fact that people want to use operator overloading so much as a hint that we need to be using more expressive languages that provide ways of producing highly abstracted and understandable code.

I guess it comes down to this: giving you're programmers a hammer to work with and telling him/her to fix a super computer isn't going to lead to any result you'll like

.

Take care,

Mark.

zimv20 · Mar 1, 2006

netytan said:
Classes with operator overloading become inconvenient when you're reading someone else's code

are we talking about class implementation or code using that class?

the fact remains that the vast majority of C++ classes aren't so tidy or idealistic.

i think we're agreeing on just about everything. i'll suggest that we're spending too much time blaming the tool and not the developers. no language is going to be idiot-proof.

Would you overload anything for a Mortgage class? Can you think of any operators that might be useful for that?

to start, i'd overload operator<< for unit test purposes. it would do nothing more than dump the values of the object vars in human readable format. i wouldn't expect anyone else to use it, though.

depending on the project, i'd consider operator= and operator== (and operator!= to complement ==). it may be useful to compare the terms of two mortgages to determine if they're the same offer. operator= would be handy for copying mortgage terms for a new offer.

nothing else jumps to mind.

Sean7512 · Mar 1, 2006

My simple, easy to understand joke turned into a huge debate at which i am confused on a lot of? Haha, I guess thats because I'm only a freshman in college, in my 2nd C++ class.

Too add to the debate, we wrote a class that reads in Cereal information (name, amt of ounces, price, and cost per ounce) from a data file. We had to then overload the << operator, so you can easily print all of the cereals information (Ex. cout << CerealA; ) We also looked at all of the other operators, >,<,=,==,!=, etc. Since I was just taught, obviously I do not know much, but I think for what we did, it was alot easter instead of including a "Print function" in our class. (CerealA.print(); vs. cout << CerealA; )

That is all I know on this topic, haha....

Edit: For our unrealistic example, I could see using the <,> operators to compare the cost per ounce, so one would know which brand Cereal gives you the most for your money. As long as your code is well commented, it should not be THAT hard for someone else to interpret, correct???

zimv20 · Mar 1, 2006

Sean7512 said:
we wrote a class that holds Cereal information (name, amt of ounces, price, and cost per ounce).[...] We also looked at all of the other operators, >,<,=,==,!=, etc.

some of those don't make sense for a Cereal class. i don't know what it means to ask:

Code:

Cereal lucky("Lucky Charms");
Cereal ccrunch("Cap'n Crunch");

if (lucky > ccrunch)
    ....

it's nice that you're learning some domain-type design, though.

therevolution · Mar 1, 2006

zimv20 said:
i think the sample code above is intuitive and easy to read. disagreements?

No, I won't disagree. But I don't think it's better than:

Code:

Note a3(A3);
Note e4(E4);

Chord chord1(a3);
chord1.addNote(e4);

Note c4(C4);

Chord chord2(chord1);
chord2.addNote(c4);

cout << chord2.toString() << endl;

Note f3(F3);

chord2.addNote(f3);

cout << chord2.toString() << endl;

Your code is more terse and two lines shorter, sure. That's kind of nice, I suppose, but IMO not nice enough to warrant the existence of operator overloading. Is my version really that much worse?

zimv20 · Mar 1, 2006

therevolution said:
Is my version really that much worse?

no. it's perfectly readable and understandable. i do feel mine is more elegant, and probably more accessible to non-coders (for whatever that's worth).

these are really fine details about readability. looks like we'll just have to disagree. no worries.

Sean7512 · Mar 1, 2006

zimv20 said:
some of those don't make sense for a Cereal class. i don't know what it means to ask:

Code:

Cereal lucky("Lucky Charms"); Cereal ccrunch("Cap'n Crunch"); if (lucky > ccrunch) ....

it's nice that you're learning some domain-type design, though.

I agree that they don't make sense, I think the teacher was just introducing us to the concept.

What is domain-type design?

therevolution · Mar 1, 2006

zimv20 said:
these are really fine details about readability. looks like we'll just have to disagree. no worries.

Yep, no worries.

I don't mean to come across as argumentative just to hassle you. I think it's an interesting debate. I certainly see why people would choose to use them; I just question their ultimate usefulness. But I suppose we agree that "usefulness" isn't why you use them - you think it makes for more elegant code, which is fine.

I just hope I never have to maintain the code written by the guy who thought it would be a good idea to say 'chord1 *= chord2'

macOS friends in C++...

macrumors 6502a

Suspended

macrumors 68020

macrumors 603

Moderator emeritus

macrumors 601

macrumors 6502

macrumors 601

macrumors 603

macrumors 6502

macrumors 601

macrumors 6502

macrumors 6502

macrumors 6502

macrumors 601

macrumors 601

macrumors 601

macrumors 6502

macrumors 601

macrumors 6502a

macrumors 601

macrumors 6502

macrumors 601

macrumors 6502a

macrumors 6502

Our Staff