Post #79,273
2/4/03 2:57:39 PM
|
Re: There is NOTHING wrong with pointers!
This argument reminds me of a project I was working on back in college (those were the days, right?). I was manipulating a structure in memory directly from disk. The structure was just a bunch of pointers that mapped to the data when it was read it IIRC. Anyway, some of those pointers were to bytes, I believe. We were doing most of our coding (it was me and another guy doing the coding) on Intel boxes, and it was working fine. However, when we tried to run on the unix boxes (I believe they were HP boxes, but I'm not sure), we'd core all the time. It turned out that byte-referencing using pointers works fine on Intel, but doesn't work well on certain unix boxes (because of the way word boundaries are handled). Or something like that.
Anyway, the point was that because of our use of pointers to direct memory, we weren't cross platform (not sure if it was an operating system issue or a hardware issue, though I believe it had to do with the way the CPU handled memory access). We had to basically rewrite how we handled the situation (I think we got away with it by just reordering the structure, but I don't remember exactly).
It never would have been a problem in Java or another language that didn't deal with memory directly (using references). Of course, I don't remember it being that difficult to get around once I'd figured out the problem, anyway.
Dan
|
Post #79,285
2/4/03 3:38:34 PM
|
Cross-platform can be nasty.
Which is what I'm involved in right now with C++.
Cross-platform issues:
1) endian problems
2) word boundaries (ask me about -malign-double sometime, *sigh*)
3) C++ differences between compilers (STL, mangling, pickiness, etc.)
4) Signals, threading, select, non-blocking sockets, etc.
5) all the other little things I've fixed that I've forgotten
Note that only #3 is specific to C++. But #3 is an ongoing, huge issue in my porting efforts.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #79,321
2/4/03 6:47:07 PM
|
Er,...really?
It never would have been a problem in Java or another language that didn't deal with memory directly (using references). Actually it would have. As Scott points out, Java "references" are really pointers, probably "smart pointers", with the inard hidden to protect the illiterati. A "Reference" in Java would have had the same problem that pointers in C++ had. The problem was the memory model; your Intel box used 16-bit code, and a small pointer model, allowing for 16-bit pointers. Your 'nix box used a 32-bit pointer model, which was incompatible with the 16-bit poitners stored in your file. (I am assuming that you did not try to read pointers generated on the Intel system with your 'nix system, or vice versa....) If your 'nix box were to have been an Intel device, and your 'nix supported small pointer models, your code would probably have worked just fine. jb4
"They lead. They don't manage. The carrot always wins over the stick. Ask your horse. You can lead your horse to water, but you can't manage him to drink."
Richard Kerr, United Technologies Corporation, 1990
|
Post #79,363
2/4/03 9:32:06 PM
|
Java pointer problems
Not that I really want to jump into the fray.... A "Reference" in Java would have had the same problem that pointers in C++ had. Java code is compiled into a common bytecode for all machines - not compiled per machine. The JVM is the machine that is running the compiled code - not the underlying cpu. Assuming the VM implementor took care of their business, the differences in hardware and OS are abstracted away from the programming chore. You don't program Java for Sparc, Risc, or Intel CPUs - you program them to the Java Virtual Machine. Not that this is always perfect. Sometimes the Java specs are ragged around the edges - for example threading has quite different results on the various OS's. Also, there's the problem that the JVM is not optimized for any particular cpu, making the code unoptimized.
|
Post #79,366
2/4/03 9:36:29 PM
|
OT: threading
Threading variations are probably more a result of the underlying thread library than the Java spec.
As an example, Linux posix threads use a single process per thread, which means that each thread also gets a different pid (via getpid()). Even worse, the signal handling gets all screwed up, and you can't task a single thread to receive signals for all the threads in a process (which is how you should do it).
The Solaris and Win32 thread libraries do not have these problems.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #80,163
2/7/03 1:13:26 PM
|
Just a nit
Just a quick nit... The JVM *can* be optimized for the particular OS/hardware. There's nothing that prevents it (I think what you meant was that the bytecode couldn't be optimized for a particular hardware/OS...which is true, but isn't particularly interesting, as it can be modified on the fly and be optimized for a particular hardware CPU, etc.). And the optimization can be done at runtime, which (in some cases) can be faster than a compiled optimization. Remember, I said "can."
Dan
|
