On Sun, Jan 11, 2004 at 04:36:03PM -0800, john fleming wrote: > Joseph I vaguely remember a conversation that you ,neil and I had about > problems with the classes in C++ . It had something to do with the > impossibility of new classes of certain types, like C++ has boxed itself > into a corner ? Do you remember what that was about?
Yes. > John > PS. If so please elaborate a bit instead of answering yes to a long > question like neil likes to do, thnx Oh, damn. Basically, there hasn't really been any coherent agreed-upon standard for C++ ABIs until fairly recently. That's ABI, the Application Binary Interface, the thing which allows you to link to a library and read its function table. Short explanation.. In C, a function in an object file is referenced by its symbol name. If the function's name is do_something, its symbol name may be _do_something, for example. (In fact, that's what it should be for C.) C++ is a little more complex because a function named doSomething would not be named _doSomething in the object file because there can be multiple functions with the same name in C++. Some people decry this as one of the things about C++ that is evil, but I for one think it's actually a good idea. You can doSomething(i) or doSomething(str) as long as you have a version of doSomething that can take an int and another that can take a string. It's possible these functions could do different things, but that is just bad coding style. The thing is, if they have the same name, you can't have the same symbol name. The only way to tell them apart is by what parameters they take (and also what namespace they're in, but we're assuming the simple case that they're both global..) Let's say, since I don't know C++ name mangling, that they are stored as _doSomething_Int and _doSomething_Charptr. As long you're consistent with this pattern of mangling the symbol name, everything works fine. I just said that there was no widely accepted standard, didn't I? gcc 2.7 had one way. egcs had at least one other. gcc 2.8 used that, but I think gcc 2.9 may have changed that again (I'm not sure..) What I am sure of is that gcc 3.0, 3.1, and 3.2 have all used completely different and incompatible symbol name mangling for C++. Each time you change this, every single C++ thing on the system MUST be recompiled or the linker will break when it tries to look up functions according to the new mangling scheme. What gcc 3.2 used, if it was not somehow broken, is the now agreed upon standard. 3.3 should work with it, and now that gcc adheres to a standard, I expect they won't break the ABI again for no good reason. Now the language, on the other hand.. Let's put it this way, the C++ focus groups and committees are so anal that they feel it is their duty to engineer and re-engineer C++ so that it can "remain competitive" while correcting for "bad programming practices". ie, things that used to work tend to suddenly stop working. gcc does its best to remain current with the latast standard, and the gcc C++ people are about as anal as the committee. It is not uncommon to write some code, upgrade your compiler, and find that things which were not even warnings previously are now errors. Additionally, a whole bunch of silly things are now glaring multiline warnings telling you that the next gcc will disallow these too. So nowadays, the real problem with C++ is not in the ABI, it's in the strict adherence to the C++ standard (which is basically a moving target.) While it's fair to say that, for example, C99 is more recent than the latest C++ standard, C99's designers refused to consider any ammendment which made code which compiled under previous standards suddenly not. Even Java is such that code written for the original release still runs on the latest JVM, though Sun did do a bad when they made 1.4.1 refuse to bytecompile code that was technically an error, but silently ignored in 1.4.. 1.4.1 should have warned and 1.4.2 should have refused. That's just my opinion though--at least the stuff that broke was already an error, even if a silently ignored one. Ask a C++ old-timer about the introduction of namespaces and how little code was broken by that change. Better yet, make it a Linux C++ old-timer because it's much more likely that you'll ask someone using MSVC and they'll tell you that there was no problem: If the code doesn't use namespaces at all, it compiles. If it does, then the specified rules for namespaces are enforced. Old code doesn't break, but new code follows the new standard. With gcc, it was a forced march to the new way of doing things. _______________________________________________ EuG-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
