I didn't say that. Key word in the phrase "Byzantine pointer usage" is "usage".

But for you to make a remark like that is so unlike you so as to make me believe that your login has been copped by someone else.

Alternate possibility: you have misunderstood what I said. Occam's Razor... In point of fact, however, the notation used for manipulating pointers in C is in fact Byzantine. cf. my previous comment about dealing with other people's stupidities.

However, I will note that Java *does* use pointers, as they should be used. Every object reference is a pointer. Can you do "pointer arithmetic" on them? No. Why would I need or want to, in the work that I do? Java gives you just as much control over what happens to the data (pass the reference if you want someone to be able to modify it, or pass a clone if not), just in a different manner.

I wouldn't want to write an OS in such a language.

Neither would I. But I sure as hell wouldn't want to write business logic in C++, either. Actually, if I were using an OO C language to write an OS, I'd use Objective C because it's a cleaner, more powerful object model than C++. See Todd for details if you have questions with that. I have no issues with C's ability to get down and dirty. I do have issues with the graft of OO that is called C++.

Basic point (again): C++ requires to much damn thought and code that could better be spent solving actual problems, instead of those created by the compiler.

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.

malloc, free, new, delete... the initial discussion was about C++, which inherited C's memory management and slathered on its own layer as well. Who owns the memory is a problem as well (this is a big issue with the Xerces library). There are a lot of things to track when you are dealing with code from more than one person, and the complexity multiplies from there.

It's the bit that directs how C++ names are mangled. Find me two C++ compilers that use the same ABI and then we'll talk about compatibility. The ABI is different across gcc 2.95, 2.96, 3.0, 3.1, and 3.2. It's different for Forte. It's different for Intel. It's different for any compiler you care to name.

with the notable exception of any GNU compiler before 3.0, and any Microsift compiler

Well goll-ee gee whillikers, shoot me in the head for having to use MSVC 6 and gcc 2.95.X. I guess that's my fault. All I have to do is buy a $700 C++ compiler instead of using the one that comes with my platforms, and everything is A-OK!

We're using gcc 2.95.2 on Solaris, gcc 2.95.4 on Linux, and MSVC on Windows. We've tried using Forte; the porting effort was fairly major. We've tried using gcc 3.x. The porting effort was fairly major. I'm looking at Intel C++ 7.0; I've gotten through one of our modules and already the porting effort is looking to be fairly major.

So while theoretically ANSI standards would dictate that porting would be terrifically easy, the reality (at least with the code base I'm on; cf. discussion about protecting against other people's stupidity) is that it's a nightmare. I've got about 800K lines of C++ code alone to port... and I'm not having too much fun.

There's a new ABI on 32-bit Linux that gcc 3.2 is targetting. Supposedly, other compilers on the platform are targetting it as well. The only one I've found actually claiming this is Intel's compiler, and they're actually targetting "gcc compatibility", not "standard ABI compatibility".

Regardless, by their own documentation, they aren't there quite yet.

What year is it again?

First the snide remark: So you'd want to be able to compile some of your program in Sun's Java, some in J Builder, and some in Visual J++, and have them all work together? Yeah, right.

Yes, actually, I've done exactly that with no issues whatsoever. The Java code we have here compiles flawlessly across all three platforms. I've never had issues porting Java code.

My porting problem is that

1. portions of the code may or may not be nonstandard. cf, for the THIRD or FOURTH time, this is not my code. I don't care if you are lucky enough to be able to control your code 100%; I don't have that luxury. I've believe I've made that point several times.
2. the compilers may or may not compile the same code whether it is standard or not.
3. Even when the compilers DO compile the code, it isn't always compiled correctly. gcc 3.2.1 forgets about #defines. gcc 2.95.2 has broken exception handling when throwing exceptions in shared libs. MSVC has a broken STL implementation. Now I'm trying another C++ compiler, Intel's. See other thread for new issues arising from that.

The list goes on and on. Standards will technically give compatibility; in the real world that seems not to be the case.

All of this is beside the inherent stupidities of the C++ language itself.

C, Fortran, whatever... pretty much anything OTHER than C++ that creates a .so will all work together.

C++ can be made less insane if you control all the pieces. But most 3rd party libraries on Solaris are compiled in Forte... if you don't use Forte, you're screwed.

I dunno. But then, if you don't need to do pointer arithmetic in the work that you do, why, then, would you try to do any? There is nothing in the language that compels you to do pointer arithmetic at random intervals in your code....

To bring up a point raised before, namely the use of autopointers... have they fixed the problem with using autopointers and the STL yet? I don't think so, and in fact I had to fix an issue related to that the other day.

How do you interate through a list of sequentially organized objects?

Use a List and an Iterator object. Java Iterators, unlike C++ iterators (and Java Enumerations, incidentally), are safe from side-effects as well.

Is there an STL-like collection for references to objects of like type, in which an interator object is defined?

Yes. Actually the Java collections can hold objects of any type. How do you iterate through a list of arbitrary, unrelated objects in C++? And how do you deal with the problems of equality vs. equivalence, which are handled explicitly in the Java collections?

What about the indeterminately sized array of char, that C people refer to as a string? How is that interated?

What about it? There's the String class (for constant strings) and the StringBuffer if you want to change it after you've created it. As for "lightweight", it's pretty much the same thing, internally: an array of bytes. What you're thinking of from the "proponents" is probably the fact that when you create a new String from an old one, through 'substring()' or the like, the new String instance shares the old byte array and simply uses a different begin and end index.

Without trying to be pedantic, I assume you mean problems created by the language.

Point noted, and it is an important one. (what do you mean, 'without trying to be pedantic'... in THIS crowd?? ;-) Speaking of pedantic, it's "iterator", not "interator"... ;-)

Perhaps I am more comfortable with the wild-and-wooly nature of C++ than you are; you might prefer the more politically-correct, Father-knows-best approach that Java provides. That's OK with me.

Please. [link|http://web.archive.org/web/20011116015209/http://w3.one.net/~jweirich/oostuff/awk.html|Give] [link|http://web.archive.org/web/20011116015209/http://w3.one.net/~jweirich/oostuff/psout.txt|me] [link|http://web.archive.org/web/20011116015209/http://w3.one.net/~jweirich/oostuff/dosbatch.html|a] [link|http://web.archive.org/web/20011116015209/http://w3.one.net/~jweirich/oostuff/sed.html|break]. I'm probably going to Hell for using some of the languages for OO programming that I have. Java is no more or less "wild and wooly" than C++... in some cases it is more so than C++ (think runtime loading of classes that just arrived over the wire as binary data).

I personally don't see that Java is not without its own "problems with the language".

I explicitly said that it wasn't in my original post. I said that it sucks less than C++. ;-) In fact I'll list a few for you: proliferating libraries du jour, base types aren't fully objects, and a tendency to sell Java as the cure-all for everything from code bloat to Grandma's bunions.

One that comes to mind is the handling of exceptions; it is pedantic to require the caller of a function that can raise an exception to handle all exceptions that that called function can produce.

And in my opinion it's bad practice not to explicitly catch them all.

I'm also not real pleased with the stick-both-definition-and-declaration-of-everything-in-one-file nonsense; makes for real unreadable code

Your opinion; that style was created explicitly to get rid of the stupid .h file proliferation you see in C++. I think it's asinine to have to have tons of crap all declared in the same .h file AND in the .cpp files. The Java hierarchical package system is one of the better points for the language, IMO. It helps with organizing and packaging things.

And then, there's Swing, and the other User Interfaces du jour that make trying to get anthing out of Java such a joy.

Are we talking about libraries, or the language itself now...?

I'm sure I can come up with several dozen other "problems with the language" once I becmore more familiar with it.

And I'm sure I can with C++ as well. ;-)

In fact, I'll probably be able to match you problem for problem.

Or handwave them away with "that isn't a problem for me"...? ;-)

Perhaps you're dangerous with C++ for the same reasons?

Who said I was dangerous? I've been talking about other people's code and what a pain-in-the-ass it is to work with... And this stuff was written by intelligent people (one of whom did his own port of STL to gcc 2.95.2). It's like perl: great if you're working on it by yourself, but horrible once you start to bring other people into the same code base; this sort of overly, needlessly complex crud kills large development efforts. Java protects me from other people's stupidity.

And how about that wacky template debugging fun? Whew, and we thought C-compiler error messages were incomprehensible... ;-) That's not to say that templates don't have their advantages. However, IMO the disadvantages far outweigh them.

C++ was developed as a hacked on preprocessor to C. The world has moved on to develop better object oriented C implementations since then. Unfortunately the world also runs on the "good is enough, better is worse" principle as well.

What, to simply pass them on to the next higher level, because you know there is a higher level function that is designed to handle those specific exceptions?

To explicitly note that you are passing that exception up. In case in the future your method gets called by a different method than the one you were assuming would catch it. Implicit code will always bite you given enough time.

Which would become a waste of both our times. What say we simply agree that both languages have their strengths and weaknesses, and neither are optimally suited for everything?

Except that I've never seen such a comparison ever come to anything other than "Java fixes this stuff in C++. Answer: yeah, but Java is slow," a response which says nothing about the problems pointed out in C++. As Ashton likes to say, "Now we know what your opinions of Java are. Can we talk about C++?".

I said that earlier. I don't agree that Java, or any other language protects one from other people's stupidity. I feel that way about Java especially, because every example of Java code I've seen has been an incomprehensible jumble, including the stuff that is supposed to be "really good stuff".

Would it be poor manners to point out that this is the exact converse of your "you haven't done enough C++ yet" argument...? ;-)

It is my opinion that Java itself lends itself to this, because of its pile-everything-into-the-same-file approach to writing.

Wrong. One class (and associated inner classes) per module. No headers needed. Why? Because the interface information is inscribed in the compiled object. Separating interface out in headers only creates a maintenance hassle, because you have to change TWO files when the interface changes. Not to mention all the necessary #include dependencies. If you want a readable interface document, read the Javadocs. That's what they are there for. Using .h files as interface documentation is a bad idea too.

But I doubt you'd disagree that someone who can make a complete mess of a C++ source file can (and generally will) make an equal mess of an Objective C source file, or a Java source file as well, for that matter.

An equal mess? Not at all. Poor Java code still compiles cross platform and cross compiler. And I will continue to disagree with your assertion that Java doesn't help to protect me against other people's stupidity. Case in point: the virtual keyword in conjunction with using 3rd party libraries.

Yes, Virginia, there are shitty OO languages out there... ;-)