Just renaming "pointers" to "references" doesn't make them disappear, neither does preventing to have access to anything else than through pointers.

Kindly elaborate? :)

Perhaps you could edit your question to show an example from a language that "has pointers" and ask how that would be implemented in a language that "does not have pointers." Even better, if you're familiar with the languages, show examples for both and explain how the "pointers" version is simpler/easier/better/whatever than the "non-pointers" version.

I contest the fact that "pointers are not included in modern languages". I'm ready to bet that for any language you can cite and for which I'd agree that there is no pointer, I'll cite several for which there are pointers under one guise or another. Be warned: you'll have an hard time convincing me that any language which tout its GC has no pointers.

@kdgregory I am not comparing pointers/non pointers language here. All I am asking is why it is not included in modern languages anymore. Hope this simplifies my question.

I was wondering why pointers are not included in modern languages now-a-days <-- what do you mean? Do you mean that the languages don't use the concept of pointers in implementation or that they hide it from the user? those are very different questions with very different answers.

My comment was to get you thinking about what, exactly, a "pointer" is. To be more blunt: it appears to me that you don't have a good understanding of what a pointer is, and therefore your question is based on a false premise. And as such, is unanswerable.

@AProgrammer While it's not really wrong that GC references are implemented as pointers, and fulfill some of the same use cases, there are also significant differences (no pointer arithmetic, restrictions on interior pointers, fully automatic memory management) that make it definitely wrong to equate the two. So at most you can object to the term "pointer", not to the concept and the fact that it doesn't exist in most modern languages.

Pointers (the real, dangerous, arithmetic-allowing ones) are thinly veiled memory addresses. That's appropriate if you're programming assembler and manage your own RAM. Since the clock speed and memory density explosion, it makes much less sense to do that, so newer languages tend to use less powerful but safer mechanisms.

@kdgregory If you have such good knowledge about pointers why not share it with others? Let me know what pointers really are? How they are used in modern languages? It might help me a lot. Thanks

@KilianFoth That is some useful comment +1. :)

Manual memory management turns writing a program into two problems - writing the program, and making sure memory was managed correctly. And when you inevitably make a mistake with memory, absolutely anything could happen, including corrupting data or security vulnerabilities. Given enough memory, a garbage collector will perform just as well and you avoid the second problem altogether.

@Doval Thank you. But is it true that using pointers decreases execution time?

@FaizanRabbani That is too vague a question to answer.

I read it somewhere on internet @Doval.

Then it must be true. Everything on the Internet is true. Abraham Lincoln said that.

@JörgWMittag That is why I asked this question here. :)

@delnan, I've used Algol68, Ada, Pascal before I touched C. I've never though that what they called references, access types or pointers were not fundamentally languages specific variants of the notion which is the one underlying C pointers. They are used with the same techniques. And that's true for Java and C# references as well. And it's true even in languages like Lisp and other functional languages which hide the notion so well that they have no name for it. Some restrictions or having a GC ease somewhat the use of the notion, it doesn't change its nature.

@AProgrammer How am I suppose to identify pointers/references?

@FaizanRabbani, look at this answer for my POV, and others answers of the same question for some others.

@Doval, while I consider a GC a valuable tool (I'm on record having said that allowing GCs to leave their niche is one of the important things Java has brought), I don't see how a GC does allow you to ignore memory management. You still have to ensure that there is no pointers kept to an object which has outlived its usefulness. GCs ease the implementation when there is no non-owning pointers or when those can be reset to NULL, but if my experience is meaningful, the common case is that there are non-owning pointers which have to be updated to something else.

@AProgrammer I read your answer and others as well. It helped a lot :) thank you

@FaizanRabbani: Here is also on the Internet. ;-)

@Giorgio but its a community on internet ;)

@AProgrammer I didn't say garbage collection frees you from optimizing programs for space usage, I said it frees you from making sure it's used correctly. Holding on to memory for longer than necessary is an inefficiency but doesn't make the program incorrect. It's not terribly different from choosing an O(n^2) algorithm instead of an O(n) or O(1).

@Doval But holding memory for too long might make application/program unsustainable in long term usage?

@Doval, the issue is not holding memory, the issue is referencing an object which should be dead. Without GC, you often have a more or less quick crash, more or less tied to the root cause, with a GC the same error gives you a defined but unwanted behavior, often more difficult to detect than a crash, often as difficult to to trace to the root cause. That's better for security but you still have a bug. I've often argued for GCs, but they don't remove the need to think about memory management. They provide an easy implementation of a MM policy, they don't help when another is needed.

@AProgrammer I have no idea what you mean by "should be dead". Unless you're doing stupid things with finalizers, an object being tracked by a GC can only be alive or dead; there's no in-between that a programmer can observe.