You cannot compare apples with orange!
How many times we heard this sentence when we tried as children to do something apparently illogical?
We're here going to talk about an argument that looks like it: the overloading operation.
Despite of picture beside, the concept is indeed light: it's just a matter of definition, and programming languages usually give us all the possibility to redefine a wider set of expressions for the subject of overloading.
We surely cannot get an apple juice from only orange and vice-versa, but we surely can have one of fruit with both of them: we have just expanded the "making a juice" meaning.
So what about coding?
In this context we make the same, in the sense of a meaning addition: but which is the subject?
Generally every talk about overloading concerns a separation between the two possible macro fields of application:
i) operators overloading;
ii) functions/procedures overloading.
While this can be useful for specific differences between them two, in reality it could bring a novice to a little confusion. Overloading is the same for both of them; this is the main point, after which we can face every other aspect involved in its particularizations. ...continue reading "To Overload or not to Overload"
In previous two articles we talked about array management: copy by value and copy by pointer methods have been exposed to achieve same results but in different ways.
The former being direct and simply, the latter more powerful but danger (because of risks related to pointers).
If you get familiar with pointers you can understand their usefulness, so that they become sometimes necessary to ease some tasks; but we know their dangerousness!
Nothing stops us from building some construct, or data type thanks to which we can use pointers with a major security degree.
That's probably what people who writes TList types (for every programming language) thinks.
This is because the list is a so powerful and useful and commonly used data structure written for homogeneous elements.
Well... homogeneous! This surely recalls an array. And that's true!
In previous article Array management by value we talked about one way to grant to us access to array's items: we used a by value approach, in the sense we surely took copy of items values by dereferencing a pointer to record we defined at the top of code.
Our intention was to emphasize that a copy by value can even be made with the help of a pointer.
Pointers in that context could represent an alternative way to archive or reach the documents: instead of alphabetically (array[index]), by coordinates (for example, just like in battleship).
Result is essentially the same:
we compile an original document and copy it to our file in archive;
we fetch documents, then copy info through pointers, manipulate them.
In other words, we prepare a new record with all data, then we store these values into an array of records; so we pass values.
On the other side we create locally a new record, where to host all fetched data from array, with pointer's dereference. ...continue reading "Array management by pointer"
Suppose you have to archive some documents in a public bureau, one for every person you serve.
You fill all data, assign an identifier, and collect papers together; all is ready to be filed.
Every time you need to see these documents, the identifier shall make you find them quickly.
We know archive can be a computer file: indeed the paper scheme is well represented by bureaucratic organizer softwares, among which the most important are database managers.
Independently by the way you adopt, this matter always belongs to data's and memory's representation and management.
Talking about programming we have now a basic but enough knowledge to realize a simple manager.
What we're going to realize is a collection of records, describing hypothetical employees with just three features: name, surname and ID number.
Only records to be archived: so array is perfect.
Let's see how to deal with it and its items: in this article data will be passed by value. ...continue reading "Array management by value"
You're in troubles visiting an unknown city, having just discovered how unclear your map is.
Ask somebody the direction from where you're now, the Y position, to your X destination.
That's what you basically need.
More paths exist between Y and X, which can be fast but ugly, or long but panoramic: generally the way you reach X is not so important... and this is of worth for us too in our talk.
Indeed you only want to sign X and Y on your map.
Are you recognizing the web links surface behavior?
By starting from a web site you go to another one with a click, completely ignoring the path.
Classical example: from search engine results to a possible point of interest.