Hello everyone

[cppman]

Yes, to do other things you'd have to write methods, but this is to make things consistent. Instead of someone having to read through the documentation of what *, +, /, and - all do in your class, there are methods with *helpful names* that tell you what they do.

Are you honestly saying that given an object you've never worked with before, you'd prefer to see a load of operators which you instinctively think mean "multiply" then "add" yet do completely different things over a method call that was named after the operation it actually does?

First of all, I would read the documentation on the object. Second of all, what makes you assume the operation being done is something completely different? As I said, almost all operator overloads are done in an equivalent way. For example, an iterator will overload the "++" operator. That operator increments the current list node element. Nobody in their right mind is going to overload the "++" operator and make it free every resource allocated by the class. There is a relevance between the operator being used and the operation it performs - you really need to keep that in mind. Just like the "==" for the string class will check if two strings are equivalent, it isn't going to append something to your string. The dereference operator (*) for the iterator class returns a reference to the node's object, it doesn't delete the node.

What you are saying about operators is equivalent to me saying that people can label methods with names such as "add" but really do something slightly different such as incrementing a value by 2 or something completely different, like deleting itself.

It's honestly like me giving you the following sentence:

Hello( my name is Adrian& I like to program@

You say to me "That sentence is full of weird symbols", and I reply "No, I've just replaced the function of a comma with a (, a full stop with a &, and an exclamation mark with a @".

Again, you are implying that people assign random operations to random operators. There is almost always a relevance between the operator being overloaded and the operation it performs. People don't just pick random operators to overload, that does nobody any good.

It's the "almost" that scares me. You say "why would they?" yet you've just said that doing so is the great thing about C++. Why would they? Because in C++ you can...and it's apparently a great thing to do.

I was implying that the great thing about C++ was it's versatility. The option for the user to implement the operators however they wish, not that people giving random operations to random operators is a beautiful thing. It is just like the issue with pointers. People say C++ is bad because it gives users access to pointers, which can have dangerous consequences.

That ain't beauty...it's a travesty. How on earth do you read C++ code??? It must be a constant switch between the reference manuals and the code snippets.

It's common (programmer) sense, really. (and I don't mean that offensively)

You are once again ignoring consistency. It's all very well an good having == meaning comparing values, but some classes do not have specific values to compare.

Then they shouldn't overload the == operator, simple as that.

Not all classes are as simple as Points, where to work out if you have the same points, you just need to compare X and Y.

Of course not. Then they don't need to implement the == operator. As I've stated before, if you are working with pointers in C++, the == operator, the + operator, the - operator, etc. all do the same thing regardless of the type being worked with. This is equivalent to using references (objects) in Java or in C#.

In order to be consistent, the == needs to do the same thing in every class. Comparing references is actually useful sometimes, especially if you want to avoid errors. For instance, if the creation of a new object is dependant on some random event, and you have a thread that depends on the creation of the new object, then you can't have the thread trying to access a non-existent object. Thus you'd have a check (object != null) to make sure the reference existed before continuing in the thread.

Hence the use of pointers, in C++. Natively you can't compare a value-type (except for integral primitive types) to NULL anyways. So, with that said, if you are comparing against NULL in the first place, it is impossible for you to overload the != operator for that comparison.

As for the matrix class, there are far more matrix operations you can do than those. This is where overloading gets confusing. You'd have to have operators for cross product and dot product, and everything in between. Finding good operators to represent those operations would mean you have a stupid amount of operators that are non-descriptive, as opposed to the same number of methods that have *names* describing what they do. I'd love to see what operator you'd choose for "invert the matrix". I don't have that problem: invertMatrix(). Done. Why are you so afraid of decent method calls anyway?

Of course, most Matrix classes include both methods and operators, however. Generally the basic, add, subject, multiply, etc. operators are implemented.

I'm not "afraid" of method calls, I just prefer operators where operators should be used. It simplifies things, makes code more readable, and makes the code easier to debug when you come across problems.

Are you fucking kidding me? This is one of my areas of expertise; I've been working on mobile devices for the past 2 years in various university projects. The top runners for mobile devices are:

1) Symbian (uses Java / C++)
2) RIM Blackberry (uses Java / C++)
3) Apple iPhone OS (uses Objective C)

Windows Mobile have 9% of the operating system market on mobile devices, behind all those three. Additionally, Android (Java based) is suspected to be in second place by 2013. So no, I think your assertion that .NET has taken "a lot of competition from Java" on mobile devices is an outright fabrication.

Eh, sorry about that. Let me separate my statements. C# has taken a lot of competition from Java. Some of that competition taken also includes mobile phones. Symbian OS actually has (from what I've heard/read) .NET Compact Framework.

But either way, you apparently know more about mobile phone development than I do, so I can't argue it. So, point taken.

Well you were the one who brought mono up. I can't be blamed for a comparison I didn't even make...

You said,

it lacks the power of Java in terms of reliability and usability (on other platforms).

.NET only runs on Windows, so when you say "on other platforms", it implies mono.

NASM as far as I've understood from what I just read about it, is for the Intel x86 architecture...ergo it is made specifically for one architecture, so it is a low-level language.

Alright, good. Just because something is "compiled" doesn't mean it can't be a low-level language. A compiler can be specific to an instruction set (like the NES compiler - forgot the name, however).