macOS friends in C++...

[netytan]

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


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.


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.

Ok I can see what your saying and in these cases operator overloading is a handy way of applying polymorphism to objects you've created – but only because of the syntax of the language that you don't have any power over.

I guess the major problem is when you do something unusual like overload = to be used in the same was as == or anything you wouldn't expect right off and ues programmers do stuff like this. Especially those who like other languages such as BASIC *shudders*.

I believe programmers should write good, clean, concise code or leave me alone but I do feel that the language used is a big factor in this because they're more than just tools. There mediums for expressing thought and the more clearly and precisely you can do that in a language the more challenging projects you'll be able to take head on easily.

Much as I like to blame the developers and the "tools" separately I think it's probably a mixture of the two. I've found that I can write code as a newbie to any language I've used (and I've used more than I can name) that would be on par with a medium level developer or in some cases even higher.

So I think it has a lot to do with the mindset you have at your disposal – the more you ideas you're exposed to the larger the mindset you can use to solve a problem.

You should try programming in Lisp and if you like it recommend it for your next big project. I think you'll find the level of abstraction that is accessible to the developer far outstrips any other language and even if it doesn't its worth learning because it'll twist your brain inside out lol.

Once you've been exposed to this you should be able to understand what I mean when I say it's a poor excuse for an abstraction method.

It did mine, take care man.

Mark.

 

[zimv20]

What is domain-type design?

modeling realworld concepts. C++ is much more interesting when doing class and OO stuff than, say, generating a fibonacci sequence.

 

[netytan]

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'

I agree entirely with this and I can flat out say I'd refuse to work on that project. The moment you see that kind of weird thinking you should know it's going to be bad and walk away – lest you do permanent damage .

 

[zimv20]

You should try programming in Lisp and if you like it recommend it for your next big project.

i did a small bit of Lisp programming nearly 20 years ago and really liked it. haven't looked at it since, though.

funny thing about the industries i've worked in, Lisp would be a nearly impossible sell. on one java project, after being commanded to think outside the box, i suggested Prolog for doing some business rule stuff.

i was nearly run out of the building. in the end, the "thinking out of the box" people decided to stick with java for that part, even though they'd spent a year on it and couldn't get it to work.

people are funny.

 

[zimv20]

I don't mean to come across as argumentative just to hassle you.

i know, no worries.

I certainly see why people would choose to use them; I just question their ultimate usefulness.

i could make the argument that they're not needed at all for classes. after all, you demonstrated that with Chords and Notes. but they're still a part of the language, so i'll assume they remain solely for purposes of expression.

 

[netytan]

i did a small bit of Lisp programming nearly 20 years ago and really liked it. haven't looked at it since, though.

funny thing about the industries i've worked in, Lisp would be a nearly impossible sell. on one java project, after being commanded to think outside the box, i suggested Prolog for doing some business rule stuff.

i was nearly run out of the building. in the end, the "thinking out of the box" people decided to stick with java for that part, even though they'd spent a year on it and couldn't get it to work.

people are funny.

LOL nice work, next time you should run them out of the business. They're obviously not qualified to be making decisions like this . If I ever decide to set up a business you'd be just the type of programming I'd be looking for, maybe have to outlaw the use of C++ though I'm really not a fan .

I've read a little on prolog but I haven't used it, I will eventually it's just not something I have a use for for the most part.

Mark.

 

[zimv20]

LOL nice work, next time you should run them out of the business. They're obviously not qualified to be making decisions like this

it's a difficult industry because of soooo many constraints: budgetary, skill levels, risk management, ass-covering, biases, egos, vendettas, time constraints...

most of my career has been as a consultant, so playing nice is as important as delivering the goods. while i wished i could have enforced my will to try the prolog route, i really didn't have a choice.

If I ever decide to set up a business you'd be just the type of programming I'd be looking for

ha, thanks for that.

I've read a little on prolog but I haven't used it

like Lisp, it's something i tried in the 80's but never got a chance to use in the industry. neat language. i really thought it'd work well in the situation i described above.

 

[Soulstorm]

I am not a proffessional programmer (yet) but I am not a beginner either. I still have much to learn, but as far as I have been involved with C++, I see that the lat thing that one should complain about, iis operator overloading.

Operator overloading exists for a reason. And it may has many cons, but it seems that the pros were many enough to have the creator/maintainers of C++ implement it in the language.

For me, it has proven useful in sone occassions. For instance:

I have a vector, full of objects of a class which contains many viariables. I want to output the contents of this vector into a file. So, I overload the operator "<<". Now, I can use it: 1)To display the private variables I want, through "cout << v" and 2) To output the contents of the vector with only a statement of a kind of

for(i=0; i<v.size(); i++){
    myfile << v[i];
}

and that's about it. (my vector is named "v" and every place holds obbjects of a class). If it hadn't been for operator overloading, I would be forced to write many more lines of code.

I'm not trying to lecture anyone here, don't get me wrong, nor I believe that I am more experienced as a programmer as most of you probably are.

But I think that as most things in C++ operator overloading exists because there was the need for it. And it seems that many people think so, otherwise iit would have been abandoned long ago. If anyone thinks that code with operator overloadings is inefficient, then do not use it, and use what your expertise tells you. For me, operator overloading was handy in the above example...

 

[ChrisBrightwell]

Operator overloading exists for a reason. And it may has many cons, but it seems that the pros were many enough to have the creator/maintainers of C++ implement it in the language.

I have been of the opinion, for a long time, that C and C++ go above and beyond the call of duty to let you do just about anything. They're so busy talking about the fact that they could that they never bothered to ask if they should.

Operator overloading, IMO, breaks one of my first rules of programming: Write code that is self-commenting. If that means writing more code, so be it. At least the poor guy who comes along behind you will be able to read your mess.

I have a vector, full of objects of a class which contains many viariables. I want to output the contents of this vector into a file. So, I overload the operator "<<". Now, I can use it: 1)To display the private variables I want, through "cout << v" and 2) To output the contents of the vector with only a statement of a kind of

for(i=0; i<v.size(); i++){
    myfile << v[i];
}

and that's about it. (my vector is named "v" and every place holds obbjects of a class). If it hadn't been for operator overloading, I would be forced to write many more lines of code.

Why not implement a toString() or buildOutput() function for the objects being written?

Then you have something like this ...

for(i = 0, j = v.size() ; i < j ; i++)
{
    myfile << v[i].toString();
}

Sure, the difference is subtle, but at least it's easier to read at first-glance.

 

[zimv20]

They're so busy talking about the fact that they could that they never bothered to ask if they should.

damn you! my C++ dinosaur-cloning program was almost complete!

 

[ChrisBrightwell]

damn you! my C++ dinosaur-cloning program was almost complete!

Hah, you got me.

 

[SamMiller0]

for(i=0; i<v.size(); i++){
    myfile << v[i];
}

Item #84 from Sutter & Alexandrescu's C++ Coding Standards: "Prefer algorithm calls to handwritten loops." I would change your code to look like this, or something similar. I can't remember the exact format.

This idea is from one of Herb Sutter's other excellent books, and his Guru of the Week usenet posting:
http://www.gotw.ca/gotw/074.htm

std::vector<Widget> v;
//fill the widget vector
std::copy(v.begin(), v.end(), std::ostream_iterator<Widget>(myfile));

 

[netytan]

...
Operator overloading exists for a reason. And it may has many cons, but it seems that the pros were many enough to have the creator/maintainers of C++ implement it in the language.
...
If it hadn't been for operator overloading, I would be forced to write many more lines of code.
...
But I think that as most things in C++ operator overloading exists because there was the need for it. And it seems that many people think so, otherwise iit would have been abandoned long ago.

Would you not find that all you've done is move the code you would have written into a method that overloads the operator rather than having it in a more versos method name i.e. toString().

Language design is a tricky thing, once you provide a feature it has to live on for compatibility. Even if overloading is only used by 5% of applications (it's not, but thats about as many as use it well) then it needs to be there .

The benefits visible in operator overloading really depend on who you ask, what looks good to one person might look terrible to someone else.

For instance I really love this piece of code here. It's clear to anyone who knows the language, it's elegant in size and flow; there's no duplicated code or variables to get in the way or cause bugs that are hard to track down.

Added to that you can see that the naming used makes a lot of sense even if you can't follow whats going on.

(define tree?
  (lambda (lst)
    (and (pair? lst) (or (pair? (car lst))
                         (tree? (cdr lst))))))

(define sum
  (lambda (numbers)
    "Adds the numbers in the numbers list and any sub-lists. If numbers is
    a tree? then call sum recursively until there are only numbers and flat
    lists left."
    (apply + (if (tree? numbers)
               (map (lambda (n)
                      (if (pair? n) (sum n) n))
                    numbers)
               numbers))))

...
> (sum '(1 2 3 (1 2 3) 1 2 3 (1 (2 (3)))))
24
>

I included this code as an example because I'm sure looking at it will make just about all of you turning over in disgust . Look at all the parenthesis .

If this same code were produced using the style that operator overloading implies then it would be nearly impossible to follow – this is an extreme case but it also proves unreadable in C++ code now and again.

It's all personal preference when it comes down to it, but I wont be using operator overloading any time soon simply because it's useless everywhere except in a few in very restricted languages.

As soon as things become more flexible operator overloading isn't used nearly as much. Or so the case studies would suggest .

I'm by no means an expert, just have very strong opinions on what I like and what I don't either way just use whatever you think makes for better code .

Take care,

Mark.