But why??

Pointers do not spoil platform independence; however, they do allow you to write non-portable code in some instances .

Here is a listing of the operations that you can perform on a pointer in C++, and whether or not they are guaranteed by the language standard to work on any implementation (in other words, whether or not they are portable).

portable: ->, +, -, ==, !=, --, ++
non-portable: <, >, <=, >=

You can find more detailed information near the end of the recent "c++ vs. java" thread.

I would like to add that the preceding was not strictly accurate. You can still write stupid code snippets that are not portable. However, when used as they were intended - with arrays, sizeof operator, etc. - they can be completely portable.

Here is a snippet that will work on any C++ implementation:

int main()
{
  int a[10]; // declare an array of 10 integers, from 0...9

  *(a + 5) = 0; // works fine, sets sixth element regardless of element size

  int* p1 = a  + 7; // p1 now points to eighth element
  int* p2 = p1 - 3; // p2 now points to fifth  element

  while( p2 != p1 ) *p2++ == 0; // set integers from p2...p1-1 to zero
}  

Note also that all casting of pointers is non-portable, except to and from void* and when navigating within an inheritance hierarchy.

Edited by - null_pointer on December 21, 2001 1:59:16 PM

The amateur again...

Well... as far as i know every operating system (platform) has got itz own VM. And the primary work of allllll JAVA compilers are to compile the codes into general BYTE CODES which are then compiled to NATIVE CODES by the VM prior to running. And the kind of NATIVE CODE the VM generates depends of what platform it''s lying on. Hence, if java had pointers; the pointer related codes could have been tranlated into a general BYTE CODE when then could further be translated to NATIVE CODES depending on the machine/platform itz working on.

any comments ?

Sorry for the offtopic but:

quote:

---

But I do know that a lack of pointers pretty much ruins Java for me.

---

It is a different programming language, if all programming languages presented the same tools and commands and so on just with a different syntax, then they are really just the same language.

Trying is the first step towards failure.

Java choose to avoid letting the user have "free access" to pointers. I think in the earlier versions or in a visual dev enviroment, Pointers were allowed but through a function to minimize the usage of them... But then lm a newbie too so whut do l kno?!?!?!?!?!

Java references are basically the same thing as C pointers with a couple of exceptions: you get no pointer arithmetic & you do not have to call delete.

As for platform independence, Java can run on anything from smart cards to mainframes. These memory architectures can be vastly different. The Java VM guarantees a standard, uniform way to allocate, track, and release memory.

"So crucify the ego, before it''s far too late. To leave behind this place so negative and blind and cynical, and you will come to find that we are all one mind. Capable of all that''s imagined and all conceivable."
- Tool
------------------------------

quote:

---

Original post by WayfarerX

As for platform independence, Java can run on anything from smart cards to mainframes. These memory architectures can be vastly different. The Java VM guarantees a standard, uniform way to allocate, track, and release memory.

---

As for platform independence, C can run on anything from smart cards to mainframes. These memory architectures can be vastly different. C guarantees a standard, uniform way to allocate, track, and release memory.

As for platform independence, C++ can run on anything from smart cards to mainframes. These memory architectures can be vastly different. C++ guarantees a standard, uniform way to allocate, track, and release memory.

As for platform independence, <insert favorite programming language here> can run on anything from smart cards to mainframes. These memory architectures can be vastly different. <insert favorite programming language here> guarantees a standard, uniform way to allocate, track, and release memory.

quote:

---

Original post by browny

Well... as far as i know every operating system (platform) has got itz own VM. And the primary work of allllll JAVA compilers are to compile the codes into general BYTE CODES which are then compiled to NATIVE CODES by the VM prior to running. And the kind of NATIVE CODE the VM generates depends of what platform it's lying on. Hence, if java had pointers; the pointer related codes could have been tranlated into a general BYTE CODE when then could further be translated to NATIVE CODES depending on the machine/platform itz working on.

---

You are correct: the existance of pointers in the language does not make the language non-portable. Remember, though, that some operations involving pointers are not guaranteed to work (i.e., they may not be portable).

Look at the following code snippet:

struct data
{
  int x;
  short n;
  float f;
  char c;
};

int main()
{
  data d;

  d.x = 10;
  d.n = 5;
  d.f = 1.25f;
  d.c = '?';

  data* p = new data;

  p->x = 10;
  p->n = 5;
  p->f = 1.25f;
  p->c = '?';

  delete p;

  return 0;
} 

...and now we will dissect each section and you will learn how the language standard says that code should interpreted. First up is the data structure.

struct data
{
  int x;
  short n;
  float f;
  char c;
}; 

Question #1: How large are the members?

The language does not guarantee any particular bit size for int, short, float, or char. It does guarantee that sizeof(char) == 1 and that other types are multiples of char, but it does not define what "1 byte" means. On some machines, 1 byte is not 8 bits.

Now, when the language does not guarantee something, that means that how it is implemented depends entirely on the implementation (i.e., the compiler, platform, etc.). In other words, the compiler is free to assign whatever sizes it wishes to assign.

Question #2: What is the memory layout of the structure?

The language does not guarantee a particular memory layout. It does not guarantee that the members will be stored in order, or how large they will be, or whether the size of the members is equal to the size of the struct. Some machines assign padding bytes to align the members of the struct on certain memory boundaries for faster access.

Now we will look at the first line of the function:

int main()
{
  data d; 

Question #3: How is this memory allocated?

The language does not guarantee the location of the memory that is allocated for the struct. The language says that such a declaration d is of storage-class "auto", which means that the system will manage the memory in whatever way seems fit. On most systems this is through the system stack, but it could just as well be allocated using some other method on systems that do not have a stack.

To reiterate: the only thing that the language says is that the system will manage the memory for you. That is the only fundamental difference between instantiating variables and objects normally and using new/delete: with new you must manage the memory yourself.

  d.x = 10;
  d.n = 5;
  d.f = 1.25f;
  d.c = '?'; 

Question #4: How does a program access the members of a struct?

On most systems, the struct's name is basically a pointer to the beginning of the struct's memory. Members are accessed by calculating their offsets from the beginning, based upon the sizes of the members and padding bytes, and whatever else the compiler cares to throw in there.

The point is, since the memory layout and storage are not guaranteed, the compiler is the only one who is guaranteed to know how to access the struct, and so the compiler must specify how these operations are to be performed in machine code. In other words, it is portable.

Let us look at the final snippet:

  data* p = new data;

  p->x = 10;
  p->n = 5;
  p->f = 1.25f;
  p->c = '?';

  delete p; 

Question #5: What is the difference between d and p?

The only real difference here is that p refers to memory that is managed manually, whereas d refers to memory that is managed automatically. From the programmer's perspective, both d and p accomplish the same thing:

"Allocate memory to hold a struct containing an int named x, a short named n, a float named f, and a char named c. Set x to 10, set n to 5, set f to 1.25, and set c to ?."


Edited by - null_pointer on December 22, 2001 12:44:48 PM

um doesnt java handle pointers automatically for you?

quote:

---

Original post by null_pointer
On some machines, 1 byte is not 8 bits.

---

A byte is always 8 bits. What you probably meant to say is that the system wordsize is not fixed; ie, it varies from platform to platform (4-bit on some ancient processors; 8-bit on others; 16-bit on 80x86 real mode; 32-bit on IA-32, Sparc32, MIPS32, etc; 64-bit on IA-64, Alpha, Sparc64, Tru64, etc)

Pointers are not considered portable because of two things: wordsize and "endian-ness." (This is also the reason why pointer manipulation code must be specifically written for Windows vs Mac machines - different byte order of Intel and PowerPC chips). The size of a pointer is the size of a system word - 4 bytes on 32-bit platforms, 8 bytes on 64-bit platforms and so on. Any operations dependent on the size of the operand (which occurs frequently in pointer arithmetic) must be implemented per-platform.

Personally, I think Java could easily have implemented portable pointers by maintaining a logical byte order (the VM would translate per-platform) and a logical size. But pointers are complex entities for many to deal with, and apparently didn''t mesh with the Java design point and were therefore omitted. Big deal. Tons of languages don''t have pointers.

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!

Thanks null_pointer. Your ID says it well that u deal with pointers more than anyone else do i guess :p. Anywayz... but i still haven''t got my answer.... although i learnt a lotttt from this discussion... special thanks goes to Mr. null_pointer.

Just say YES/NO

Whether the inclusion of pointers in JAVA would have made it platform dependent or not ? ( although i guess i got my answer, its just that something is still poking at the back of my mind )

And what did u actually mean by PORTABLE and PLATFORM cuz i guess this dicussion is getting a lil confusing. Some pplz are saying POINTER codes could be portable but PLATFORM dependent. Could someone make me clear at this point.

Remember: the original purpose of Java was "write once, run anywhere." Part of that philosophy was to create a sandbox for the program to run in for security purposes.

Now, pointers are OK as long as everything runs inside the sandbox (addresses within sandbox, etc.), but thanks to JIT compilers, Java runs in native code.

So, here''s a good example why Java doesn''t have pointers:

I create a web applet, and specifically set up code so that a pointer in my code will point to a PC''s interrupt table, and have an data field in my applet which I fill with code I want to run on outside of the sandbox on a PC. My code writes out the address of my unsafe code to the interrupt table so that it will run next system refresh.

On machines running a JVM instead of a JIT compiler, it would cause an error. On machines running a JIT compiler (most systems now), instant security breach.

Even Microsoft is thinking the same way with Microsoft.NET. Pointer arithmetic is considered an "unsafe" operation, so for it to be allowed, you have to specify in your manifest that your code acts in an unsafe manner.

RomSteady - Able to leap off tall buildings in a single bound

Another issue with pointer arithmetic is that it really hurts the compiler''s ability to optimize code. Pointer arithmetic makes aliasing FAR harder to compute.

It''s really rather amazing how much optimization is possible when aliasing doesn''t occur. Basically, a compiler can convert indexed array operations to pointer arithmetic quite easily, if it can determine that aliasing isn''t a problem.

quote:

---

Original post by Oluseyi

A byte is always 8 bits.

---

Try doing a google search on the following strings (quotes included):

"4-bit byte"
"12-bit byte"
"16-bit byte"

etc.

There are two basic conventions: byte and word. A byte is the smallest quantity of data to which the processor can refer, and a word is the most common or most efficient quantity of data. On a PC, a byte is 8 bits and a word is 32 bits.

If you work with Microsoft Windows then you should be familiar with the macros: BYTE, WORD, and DWORD. These are leftovers from an unwise decision in the days of 16-bit computing; someone decided that it would be a good idea to define API functions whose types were named according to the attributes of a 16-bit x86 processor. So on Win32 the types BYTE, WORD, and DWORD refer to 8, 16, and 32 bits, respectively; whereas, on a 32-bit machine a word is 32 bits.

quote:

---

Original post by Oluseyi

Any operations dependent on the size of the operand (which occurs frequently in pointer arithmetic) must be implemented per-platform.

---

I thought I made that quite clear...

Pointer arithmetic is portable:

int main()
{
  int a[10];
  *(p + 5) = 0;
}

In C++, the following two statements are equivalent:

*(p + n);
p[n];

Unguaranteed casts are not portable:

int main()
{
  int a[10];
  // These two statements are not guaranteed to work
  char* p   = reinterpret_cast(a);
  char* end = reinterpret_cast(a + sizeof(a)) - (sizeof(int) - sizeof(char));
  // This statement is guaranteed to work (barring my bugs) if p and end are valid
  while( p != end ) *p++ = 0;
}

The problem lies with the casts , not the pointer arithmetic. The first problem with the casts is that a''s memory is allocated for int''s, and it is not guaranteed to be properly aligned for char access. Second, reinterpret_cast copies bit patterns, and C++ makes no guarantee as to the bit patterns of pointers! So, p and end might not even be valid char pointers depending on the platform.

If the casts work as expected, then the pointer arithmetic will also function as expected. Pointer arithmetic is portable , except when subtracting two pointers (which most programmers have absolutely no need for, anyway).

quote:

---

Original post by Oluseyi

Personally, I think Java could easily have implemented portable pointers by maintaining a logical byte order (the VM would translate per-platform) and a logical size.

---

What do pointer formats have to do with bytecode? Why would anyone be storing pointer values in bytecode?

quote:

---

Original post by Oluseyi

Whether the inclusion of pointers in JAVA would have made it platform dependent or not?

---

No. This is something that people simply do not understand. All that the Java designers would have to have done to make pointers portable would have been to limit the operations that can be performed on the pointers. In most cases, the non-portable pointer operations are casts, finding the difference between two pointers (p1-p2), and comparing two pointers (p1 < p2, p1 > p2, p1 <= p2, p1 >= p2), except for testing whether a pointer is equal to zero and or to another pointer.

quote:

---

Original post by browny

And what did u actually mean by PORTABLE and PLATFORM cuz i guess this dicussion is getting a lil confusing. Some pplz are saying POINTER codes could be portable but PLATFORM dependent. Could someone make me clear at this point.

---

A "platform" is a combination of operating system and machine architecture; a lot of people here use Windows/x86, but there are also other operating systems, such as Linux, MacOS, BeOS, FreeBSD, etc. that support other architectures, like PowerPC, SPARC, Alpha, etc. So you have a lot of different combinations.

When I use the word "portable" to describe code, it means that the C++ language standard guarantees that code will run on any platform. You should be able to take portable code and compile it anywhere, with absolutely no changes.

Platforms may have the following differences:

1. The sizes of types may be different.
2. The byte order may be different.

#1 is true because processors find it convenient to work with data of a certain size. Back near the infancy of the PC, processors were 8-bit or 16-bit. That is, they could work with numbers, pointers, etc. most efficiently in groups of 8 or 16 bits.

A compiler for an 8-bit processor would make "int" 8 bits, while a compiler for a 16-bit processor would make "int" 16 bits in size, because "int" is supposed to be a fast, efficient, general purpose type. Now most processors are 32-bit, with some being 64-bit, and so "int" may be 32 bits or 64 bits in size depending on the compiler and architecture.

To remain portable, you cannot make assumptions about the sizes of types. Most programmers shoot for highly portable code, where they make only a few assumptions when necessary.

#2 is true because processors operate internally on a very very low level. Storing the bytes in a certain byte order may make some internal calculations faster, speeding up the operation of the processor. So different processor designers chose different byte orders.

For example, here is the number 256 in x86:

binary: 1111 0000 0000 0000 0000 0000 0000 0000
hex:    0xFF000000

...while this is in PowerPC:

binary: 0000 0000 0000 0000 0000 0000 0000 1111
hex:    0x000000FF

This matters any time you have to treat the bit patterns of the numbers as raw (or untyped) memory. So, if you do binary (raw) output to a file or network stream, you are copying the bit patterns of the number, not the actual number. If you then read from that stream using a machine with a different byte order, the same binary data will be interpreted as referring to different numbers; your data will get scrambled.

quote:

---

Original post by RomSteady

I create a web applet, and specifically set up code so that a pointer in my code will point to a PC''s interrupt table...

---

How do you do that?

quote:

---

Original post by c_wraith

Another issue with pointer arithmetic is that it really hurts the compiler''s ability to optimize code. Pointer arithmetic makes aliasing FAR harder to compute.

It''s really rather amazing how much optimization is possible when aliasing doesn''t occur. Basically, a compiler can convert indexed array operations to pointer arithmetic quite easily, if it can determine that aliasing isn''t a problem.

---

Could you give some examples?

I must have been tired when I posted - 256 uses 8 bits, not 4. Here are the correct numbers:

1111 1111 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 1111 1111