Java HELP :(

[divisortheory]

Furthermore, consider you have an iterator over the fibbonacci numbers: 0,1,1,2,3,5,8... In this case your idea of "++" is totally deceptive, as it is of all iterators over a set of numbers that aren't necessarily in counting order. (0)++ gives you (1), then (1)++ gives you (1), then (1)++ again gives you (2)... later on, (8)++ gives you (13). What the fuck? At least with next() you understand that your iteration operation isn't necessarily "add one to the value".

I wouldn't expect (8)++ to return (9) anyway, because I should understand that what I have is not an integer, but an index into a sequence of integers. If I had a class called FibonacciNumber, and on that class I overloaded the ++ operator to return the next Fibonacci number, that would definitely be an abuse of operator overloading (in fact, it would be an abuse of a 'class', but that's an entirely separate debate, lol). But I wouldn't advocate that, I'd advocate overloading the ++ operator a separate object, perhaps I'd call it FibonacciSequenceIterator. Calling ++ on that object, I'd definitely expect (8)++ to return (13).

In mathematics, when you have a sequence you typically refer to the sequence with an index, like s[n] perhaps. n is your iterator, and adding 1 to it moves to the next item in the sequence. (8) isn't the number 8, it's s[5]. and (13) isn't the number 13, it's s[6]. Iterator++ simply increments the sequence index by 1. It changes the value 5 to the value 6. You don't obtain the actual value 13 until you find out what is at that index in the sequence, by looking at s[6] (or in this case, *Iterator).

The reason why C++ is so powerful is because of developer support. There are much much much better OO languages out there (Java is one of them) that beat C++ at it's own game, mostly by virtue of language designers identifying the flaws in the C++ implementation and attempting to fix them.

From a purely OO standpoint, definitely C++ isn't the best. But it never claimed to be either, and pure OO isn't the best solution to a lot of problems anyway. It does claim to be the best at providing many of the benefits of OO, while still allowing complete low level access to the machine. For the record, I think C# is better than Java from a purely object-oriented standpoint.

However, the language should be subservient to the purpose it is being used for, and not the other way around;

I think this is already the case with C++. C++'s purpose is letting you do whatever you want to the machine and assuming you're smart enough to know what you're doing. Templates and overloaded operators fit perfectly with this notion.

It's not always a flaw in the language when the programmer does something that isn't semantically correct. In Java a programmer can make a class when he shouldn't have, or use inheritance when he should have used containment. Is it Java's fault the programmer abused the language, or is it the programmer's fault that he didn't know what he was doing?

[aurik]

Furthermore, consider you have an iterator over the fibbonacci numbers: 0,1,1,2,3,5,8... In this case your idea of "++" is totally deceptive, as it is of all iterators over a set of numbers that aren't necessarily in counting order. (0)++ gives you (1), then (1)++ gives you (1), then (1)++ again gives you (2)... later on, (8)++ gives you (13). What the fuck? At least with next() you understand that your iteration operation isn't necessarily "add one to the value".

I wouldn't expect (8)++ to return (9) anyway, because I should understand that what I have is not an integer, but an index into a sequence of integers. If I had a class called FibonacciNumber, and on that class I overloaded the ++ operator to return the next Fibonacci number, that would definitely be an abuse of operator overloading (in fact, it would be an abuse of a 'class', but that's an entirely separate debate, lol). But I wouldn't advocate that, I'd advocate overloading the ++ operator a separate object, perhaps I'd call it FibonacciSequenceIterator. Calling ++ on that object, I'd definitely expect (8)++ to return (13).

When you have a sequence, you typically refer to the sequence with an index, like s[n] perhaps. n is your iterator, and adding 1 to it moves to the next item in the sequence. (8) isn't the number 8, it's s[5]. and (13) isn't the number 13, it's s[6]. Iterator++ simply increments the sequence index by 1. It changes the value 5 to the value 6. You don't obtain the actual value 13 until you find out what is at that index in the sequence, by looking at s[6] (or in this case, *Iterator).

I bolded something important. You should understand, sure, but the fact is that calling "++" on a non-sequential series of integers is just begging for misinterpretation. That's exactly the semantic flaw with overloading ++ instead of inlining ".next()" on an classed primitive to be ++.

It boils down to, looping over a sequence of integers is just one example of iterating over a series of items in a list. Why should the general implementation compromise to a specific example, when the semantics of the simple example don't fit?

The answer to why is "C++ doesn't support it [natively]". This is an excuse, not a justification.

[divisortheory]

What do you mean by it doesn't support it natively? Ability to overload the ++ operator was in the first incarnation of C++ ever. "I should understand" which instructions are for signed operations and which are for unsigned operations when I use assembly language too, but it doesn't mean the language fails. The entire x86 architecture is based on it after all! Having classes for primitive data types is less in line with C++'s philosophy than being able to overload operators, because when your primitive data types are more than just bytes in memory, you aren't working at the machine level anymore.

Anyway, it still goes back to the fact that a sequence is represented mathematically as s[n], and an Iterator is just the index into the sequence. Incrementing your iterator increments the index by 1. An iterator isnt' a value, it simply provides an indirect way to get a value. Just like a sequence index provides an indirect way to get a value from a sequence. Plus C++ isn't trying to be a purely object oriented language. That's the tradeoff you make for the extra flexibility.


Slight change of topic, but I actually figured out how to modify Deimos' absolute value solution from the previous page to require only one inner loop inside of one outer loop. I didn't think it was possible at first, but it came to me on the way home from work.

[aurik]

What do you mean by it doesn't support it natively? Ability to overload the ++ operator was in the first incarnation of C++ ever.

You misread what I said. C++ doesn't support implicit superclassing of the primitive int type, therefore this won't work:

for (x = 0; x<6; x.next())

Given that x is of type int, this should loop with x being 0,1,2,3,4,5. If x is of type fibonacciInteger, this should loop with x being 0,1,1,2,3,5.

This is one of the major reasons that STL made a concession to the C++ syntax and the default way to move to the next value is to use the increment operator "++": so that there is a stylistic consistency between looping with primitives and looping with STL iterators.

"I should understand" which instructions are for signed operations and which are for unsigned operations when I use assembly language too, but it doesn't mean the language fails. The entire x86 architecture is based on it after all!

Well, I'll leave my rant on why x86 blows chunks until later. The important point is that the function in the language doesn't make sense semantically. In fact, it's quite obviously confusing. See the example I gave above; if you were to replace "x.next()" with "++x", the code would be legal, and the loop would be confusing as hell to watch if x was of type fibonacciInteger. The semantic confusion is a deficiency that was introduced when STL's implementation bowed to the pressure of people who didn't want change for the better.

Having classes for primitive data types is less in line with C++'s philosophy than being able to overload operators, because when your primitive data types are more than just bytes in memory, you aren't working at the machine level anymore.

First off, anyone who thinks they're working at the machine level yet take C++ over C is fooling themselves. The whole idea of classes and strongly-typed data has almost zero meaning when you get down to registers and direct memory access.

In the idea of having native classed primitive types, nothing stops the you from accessing and manipulating the memory of such directly. In fact, it would be less deceptive if this was exposed because so many people don't even realize the trickery that C++ is pulling with things like virtual function table pointers and other object overhead that you rarely see. That's why so many people have problems with copy constructors and overriding inherited function definitions etc; all this info about what the language is actually doing is obscured.

Anyway, it still goes back to the fact that a sequence is represented mathematically as s[n], and an Iterator is just the index into the sequence. Incrementing your iterator increments the index by 1. An iterator isnt' a value, it simply provides an indirect way to get a value. Just like a sequence index provides an indirect way to get a value from a sequence. Plus C++ isn't trying to be a purely object oriented language. That's the tradeoff you make for the extra flexibility.

This is all just learned information, and it's going to box you in someday. An iterator doesn't have to be an index to a fixed sequence, that's just how it is most commonly used, probably because that's what the semantics of the language encourage you to think about. An iterator is really just a pointer to the current element in a set and function that can determine how to get to the next element in a set. Calling this function "increment", and enforcing it to have zero parameters, is both confusing and limiting.

For example, think about a 2-dimensional space (a grid of numbers instead of a line), or even an n-dimensional space, instead of a 1-dimensional sequence. In this case, ++ hardly even makes sense. How do you add 1 to a vector? Furthermore, how do you give it parameters like "next along axis #3"? You can...sorta...but its painful, and your code is not going to be representative of what you are actually trying to accomplish.

[divisortheory]

What do you mean by it doesn't support it natively? Ability to overload the ++ operator was in the first incarnation of C++ ever.

You misread what I said. C++ doesn't support implicit superclassing of the primitive int type, therefore this won't work:

for (x = 0; x<6; x.next())

Given that x is of type int, this should loop with x being 0,1,2,3,4,5. If x is of type fibonacciInteger, this should loop with x being 0,1,1,2,3,5.

If we're being philosophical about what makes good object oriented programming practices, a FibonacciInteger class that used that definition of a next() function would be a poor use of subclassing because it fails the Liskov Substitution Principle.

This is one of the major reasons that STL made a concession to the C++ syntax and the default way to move to the next value is to use the increment operator "++": so that there is a stylistic consistency between looping with primitives and looping with STL iterators.

That's just it though, it wasn't a "concession". It was making use of a perfectly legitimate language feature for a perfectly legitimate reason to achieve a certain level of power.

Well, I'll leave my rant on why x86 blows chunks until later. The important point is that the function in the language doesn't make sense semantically. In fact, it's quite obviously confusing. See the example I gave above; if you were to replace "x.next()" with "++x", the code would be legal, and the loop would be confusing as hell to watch if x was of type fibonacciInteger.

Which I would argue is due to poor use of inheritance since such a class would fail the Liskov Substitution Principle.

First off, anyone who thinks they're working at the machine level yet take C++ over C is fooling themselves. The whole idea of classes and strongly-typed data has almost zero meaning when you get down to registers and direct memory access.

Right, I said it's goal was to provide the advantages of object oriented programming while still working as close to the machine as possible. There is no operation you can do in C that doesn't have a corresponding operation that you can do in C++ that is equally close to the level of the machine.

This is all just learned information, and it's going to box you in someday. An iterator doesn't have to be an index to a fixed sequence, that's just how it is most commonly used, probably because that's what the semantics of the language encourage you to think about.

Sure it is. The sequence is the sequence of all numbers you get from iterating the collection however you want. Take a binary tree for example. doing a breadth first iteration or a depth first iteration is two different sequences. But for each one, the n'th item is the n'th item.

For example, think about a 2-dimensional space (a grid of numbers instead of a line), or even an n-dimensional space, instead of a 1-dimensional sequence. In this case, ++ hardly even makes sense. How do you add 1 to a vector? Furthermore, how do you give it parameters like "next along axis #3"? You can...sorta...but its painful, and your code is not going to be representative of what you are actually trying to accomplish.

Make an iterator class SpecificAxisIterator that can be configured with which axis to iterate along via the constructor. Or if you need to choose different axes with each successive iteration, then you need something other than an iterator. It wouldn't matter in that case, because a generic function wouldnt' even work no matter what method the language used, since you'd need to call different versions of the next() function under different conditions.

[aurik]

What do you mean by it doesn't support it natively? Ability to overload the ++ operator was in the first incarnation of C++ ever.

You misread what I said. C++ doesn't support implicit superclassing of the primitive int type, therefore this won't work:

for (x = 0; x<6; x.next())

Given that x is of type int, this should loop with x being 0,1,2,3,4,5. If x is of type fibonacciInteger, this should loop with x being 0,1,1,2,3,5.

If we're being philosophical about what makes good object oriented programming practices, a FibonacciInteger class that used that definition of a next() function would be a poor use of subclassing because it fails the Liskov Substitution Principle.

First off, on what grounds? Both Integer and FibonacciInteger are iterators of no particular relation. I didn't say any one was a subclass of the other.

Second off, you're getting off topic in a desperate attempt to score a point. Rummaging through old textbooks for ideas of dubious value isn't contributing to the discussion at hand.

[quote:78ba5]
This is one of the major reasons that STL made a concession to the C++ syntax and the default way to move to the next value is to use the increment operator "++": so that there is a stylistic consistency between looping with primitives and looping with STL iterators.

That's just it though, it wasn't a "concession". It was making use of a perfectly legitimate language feature for a perfectly legitimate reason to achieve a certain level of power.
[/quote:78ba5]

Yet you and I both know that functionally, there is no difference between enforcing the use of ".next()" versus allowing the use of "++" for iterators. It's just a token. Allowing people to use "++" for iterators where in a general case the idea of increment makes no sense is a concession to people who want to do it the way they've always done it, even if it doesn't make any sense from an independant point of view.

[quote:78ba5]
Well, I'll leave my rant on why x86 blows chunks until later. The important point is that the function in the language doesn't make sense semantically. In fact, it's quite obviously confusing. See the example I gave above; if you were to replace "x.next()" with "++x", the code would be legal, and the loop would be confusing as hell to watch if x was of type fibonacciInteger.

Which I would argue is due to poor use of inheritance since such a class would fail the Liskov Substitution Principle.
[/quote:78ba5]
Once again, I haven't said who inherits from who, so you're misapplying the principle.

[quote:78ba5]
First off, anyone who thinks they're working at the machine level yet take C++ over C is fooling themselves. The whole idea of classes and strongly-typed data has almost zero meaning when you get down to registers and direct memory access.

Right, I said it's goal was to provide the advantages of object oriented programming while still working as close to the machine as possible. There is no operation you can do in C that doesn't have a corresponding operation that you can do in C++ that is equally close to the level of the machine.
[/quote:78ba5]
Particularly because C++ is a superset of C. You could extern "C" {} your whole program if you wanted. Then again, I can inline-assembly in magical-aurik-superlanguage #7, that doesn't make my language close to the machine at all. Fact is, if you have a typical snippet of C++, there's a whole bunch of shit going on behind the scene with vftables, type checking, etc, that you don't see going on in your code. "Close to machine" makes me laugh.

[quote:78ba5]This is all just learned information, and it's going to box you in someday. An iterator doesn't have to be an index to a fixed sequence, that's just how it is most commonly used, probably because that's what the semantics of the language encourage you to think about.

Sure it is. The sequence is the sequence of all numbers you get from iterating the collection however you want. Take a binary tree for example. doing a breadth first iteration or a depth first iteration is two different sequences. But for each one, the n'th item is the n'th item.
[/quote:78ba5]

You're still limiting an iterator to a one-dimensional sequence. Think outside the box.

For example, think about a 2-dimensional space (a grid of numbers instead of a line), or even an n-dimensional space, instead of a 1-dimensional sequence. In this case, ++ hardly even makes sense. How do you add 1 to a vector? Furthermore, how do you give it parameters like "next along axis #3"? You can...sorta...but its painful, and your code is not going to be representative of what you are actually trying to accomplish.

Make an iterator class SpecificAxisIterator that can be configured with which axis to iterate along via the constructor. Or if you need to choose different axes with each successive iteration, then you need something other than an iterator. It wouldn't matter in that case, because a generic function wouldnt' even work no matter what method the language used, since you'd need to call different versions of the next() function under different conditions.[/quote]

No, you can use the same next() function, you just need to give it parameters.

[ divisor ] <---box
you --^

[divisortheory]

First off, on what grounds? Both Integer and FibonacciInteger are iterators of no particular relation. I didn't say any one was a subclass of the other.

You did say "since C++ doesn't support superclassing of the primitive int type....hence the following won't work". I misunderstood this to mean your FibonacciInteger derived from Integer.

Second off, you're getting off topic in a desperate attempt to score a point. Rummaging through old textbooks for ideas of dubious value isn't contributing to the discussion at hand.

Not really, I know about LSP off the top of my head actually, although I did Wikipedia it to get the precise wording of it since I don't have it memorized.

Yet you and I both know that functionally, there is no difference between enforcing the use of ".next()" versus allowing the use of "++" for iterators. It's just a token. Allowing people to use "++" for iterators where in a general case the idea of increment makes no sense is a concession to people who want to do it the way they've always done it, even if it doesn't make any sense from an independant point of view.

That's where we disagree, I think it does make perfect sense for iterators. "Move to the next item in the sequence" translates perfectly into "increment the sequence index by 1" which translates perfectly into SequenceIndex++ which translates perfectly into Iterator++. But that's just me.

Particularly because C++ is a superset of C. You could extern "C" {} your whole program if you wanted. Then again, I can inline-assembly in magical-aurik-superlanguage #7, that doesn't make my language close to the machine at all. Fact is, if you have a typical snippet of C++, there's a whole bunch of shit going on behind the scene with vftables, type checking, etc, that you don't see going on in your code. "Close to machine" makes me laugh.

It's not really a superset, but I guess it's close. There's nothing magic about vftables, btw, it's just a list of pointers. It's close to machine because for any C++ construct you name, I can tell you the exact machine code that will be generated by the compiler when you use it. I can look at a binary executable in a disassembler and tell you if for sure if it was written in C++, and if so I can tell you what C++ constructs were used to generate different blocks of assembly language. If that isn't close to machine level I don't know what is. On the other hand, tell me how a Java try/catch translates into machine language. You can't, in fact nobody can! Only a handful of people can even tell you how it translates into Java byte code, much less machine language. Also type checking was a bad example, because it has nothing to do with generated code.

You're still limiting an iterator to a one-dimensional sequence. Think outside the box.

Which is sufficient in most cases, and when it's not use something else. Why prevent myself from writing generic code that works for 9,999 data types just because it wont' work for the 10,000th data type? And how does the simple fact that n-dimensional sequences exist lead to ++ not being intuitive on one-dimensional sequences? There's a reason you can (and should) make tons of simplfiications when working in 1 dimensional mathematics. Because it's simpler! Why use vector addition when you can just add a number? Same principle applies here, why should I worry about supporting something that's outside the scope of what I'm attempting to support?

[Maguspk]

I used Eclipse today but he referred to it as an IDE, whatever that is. I want to download Eclipse though, it seems really kewl and it does all the brackets for me, and finds errors as I make them, oh boy!