Ah... But most of those AREN'T separate operating systems --- They are just incompatible varients of UNIX -- which kinda kills the premise that they are "standards-based" (if they were, they'd all be identical), and "work well together"
I always have to explain to people that 90% of the OS's out there are great, standards driven, and work well together...
"Huh?" is right. Now, since you clearly believe Windows fails that test (and Linux passes -- I could argue both points but that's for another time), that means you feel there are EIGHT other OSes which are "standards driven and work well together".
And what might they be?
MacOS?
AmigaDOS?
IBM OS/370?
OSes, by their very nature, are designed to be proprietary.
The low-level parts of the ABI... is not the problem.... The issue is obtaining compatability with the full ABI. That is really what it means to say that a compiler targets the "Windows Platform".
No, that's targeting compatibility not with the "Windows Platform", but with "Microsoft VC++".
And you are still mixing the two parts of the ABI. The COM ABI was fully described years ago, and is NOT affected by changes in C++.
You are confusing Microsoft's responibilities as OS vendor (which it had fulfilled) with it's "responsibilities" as a compiler vendor to it's competitors (which it has none, unless someone proves MS has a monopoly on C++ compilers)
The monopoly aspect is important. If one could prove that it is required that the OBJ produced by Compile X be link-compatibile with OBJs VC++ -- Not that it is a nice feature to have, but absolutely REQUIRED-- than MS could be forced to provide this information. Until then, MS could keep it an internal secret. And, since MS itself publishes several compilers which aren't fully link-compatible with each other (FoxPro for example), that would be very hard to prove.
And my original argument still stands: I claim that it is harder to achieve this on Windows than it is for most other platforms, mostly due (directly or indirectly) to actions from Microsoft themselves.
This seem to be just an argument over terms. What I'm calling an "compile object model", their are calling a "C++ ABI". Whatever. Either way, they have nothing to do with the OS ABI, which is what you are (wrongly) trying to tie it to.
You'll note that your first example (G++) refers to an compiler, not an OS.
You'll note that your third example (Sun C++) the document is published by the Sun's compiler group, not their OS division. (It's author, Steve Clamage, BTW, is (or at least, was -- he may have stepped down) also chairmain of the C++ Standardazation Committee.)
Only in your second example (Apple) is the compile ABI specified by the OS vendor, but that's only because of Apple draconian need to control every aspect of all software that runs on MacOS.
Name-mangling schemes are unique to the compiler vender. They have nothing to do with the ABI which would be language independant.
I think you are confusing the operating system's ABI with the compiler's object model. The problem is that while the ABI is shared by all compiler vendors of all languages, the object model is used only by those that need static link compatibility, and is usually unique to the compiler vendor.
The difference that while OS-vender Microsoft is required to provide an acceptable ABI in a timely fashion (which they did), compiler-vender Microsoft is under to requirement to share it's C++ object model at all. The ability to link OBJs compiled by Vendor X's C++ with OBJs compiled by Microsoft's C++ might occasionally be a nice feature to have, but it's never necessary (You just need to recompile all of your source code; if you use a third party library which was only provided as a VC OBJ without source code --- well, that was pretty foolish of you in the first place, and then doubly-foolish, in light of that, for you to switch compilers.)
Actually, between vector and std::string, there virtually no reason to ever use a pointer again. (And for the rare occasion that you do, there's boost::shared_ptr)
I use it all the time. Even at my day job, where our legacy system uses a mixture of MFC's CString, ATL's _bstr_t and Rogue Wave's RWCString, we are moving to using std::string.
It is an issue unless you have the source code to every single executable on your system, and access to that source code such that you can recompile any executable at will if a library it's based on changes. That means, basically, everyone, unless you're running Gentoo Linux and never install anything outside the package system. Even in the open source world, sometimes people like to distribute binaries.
You are tremendously overstating the problem.
It would only affect you if your base class is reissued in.OBJ form, and you choose to relink your code without recompiling it.
If you recompile your code (with the new base class's.H files) and then relink with the new.OBJs, you'll be fine.
If your vendor issues new.OBJs without issuing new.H files, they are dangerous, avoid them.
(apologies for WINtel world terminology; Linuxheads should substitute ".Os" for ".OBJs" to understand).
At least two compilers support the full Standard.
(Edison Design Group and Comeau; only Comeau's is a retail product).
However, several implement the entire standard except for one feature (export), which has a good chance of being removed from the Standard. And those "several" include the most popular ones (Microsoft Visual C++ 7.1 (aka.Net 2003), and the latest GNU).
Nothing that changed in the standard in the latter years of standardization would have effected anything you site in your message. However, many basic features of C++ would. In other words, had MS failed to provide a complete ABI, it would be impossible to have provided any form of compiler. An ABI good enough for a non-standard compiler would be good enough for a Standard compiler.
Beside, the Edison Design Group's compiler, (which they don't sell retail, but license to other compiler vendors), was the first fully-compliant C++ front-end --- and compiles to C code. So, all you really needed was an ABI good enough for C.
The C committee and the C++ committee hold "semi-joint" meetings (they are held consecutive weeks at the same location). There is also a large overlap in membership.
They are trying to bring the non-OO stuff to C, but it's a bit difficult. Is the string data type "object orient"? It's implemented as a templated class, but that's irrelevant, right?
What about the complex data type? where the template implementation is more explicit than with string.
What about the algorithm in the STL? They work on C arrays. Should they be moved to C?
Not, it's Zero-X. (though it's pronounced "oh-x").
Oxford, England was the location of the last meeting. (The committee mets twice a year, once inside North America, and once outside). Traditionally, just prior to each meeting, every member would be shipped a big package of all the papers that would be dealt with out the meeting, and afterwards, another package with all the revised papers to reflect discussions at the meeting. (I said "traditionally", as shipping paper documents became too expensive, so now it's all done in email, which negates the need for one big package of all the papers).
Anyway, these documents packages are called the "pre-(location)" and "post-(location)" mailings. The link in the opening article pointed to a document in "post-Oxford mailing".
I believe the next one (in the fall) will be in Kona, Hawaii, so those documents will be called the "pre-Kona" and the "post-Kona"
The 1994 Working draft was quite different than the final draft that was ratified four years later. First of all, the STL was added in 1995, and that caused changes rippling through the entire library. (ie, the string class was toss out and restarted from scratch to be more stl like). Also the templatizing of iostreams didn't start until 1995.
The name only reflected clarification of the target market.
".NET" is still attached to products targeted to developers. (Witness "Visual Studio.Net 2003" released a few weeks ago)
I know Linux Guys may find this hard to believe, by the people in charge of buying Operating Systems are (statistically) rarely programmers.
That comes from the NDA one signs to get access to *BETA* copies of MS software, because *BETA* releases are traditionally much slowly than the final release.
MS got burned years ago, when they passed out copies of the NT 1.0 BETA to journalists (which was a non-optimized build with lot of debugging code in it), and then they wrote (with comparisons to retail version of other OSes), how slow it was. Of course, when NT was finally released (about a year after that), it was considerably faster, but it took years for it to live down those initial ill-informed comments.
I'm not a business. I'm a person who uses computers
Actually, you are NOT just "a person who uses computers".. Considering your #4 requirement, you are a person who has the ability to modify code, which, while you may be in the majority of Linux users, puts you in a negligible small (under 1%) minority of all "people who use computers". That Linux advocates cannot understand that is the #1 hurdle preventing the widespread acceptence of Linux.
And it doesn't feature draconian licensing
um..Hello... MacOs features extreme draconian licensing.... It can only be bought when buying or upgrading Apple hardware.
VisualC++ does infact color strings. Unfortunately, the default color is black on white. It can be changed via the Tools/Options/Format dialog box. It will also highlight user-defined keywords (like DWORD, HANDLE etc), you just have to create a usertype.dat file listing the one you want highlighted.
VC6 doesn't highlight mismatched backets & such, but you can from the opening one to the closer using Ctrl-]. (and VS.Net-- ya'know, the version that's been out for NEARLY A YEAR -- does highlight mismatched []{}() in the editor; nice of you to compare a new product ("Vim (default shipped with redhat 7.3)" to one four years old (vc6))
Slashdot Mirror
Ah... But most of those AREN'T separate operating systems --- They are just incompatible varients of UNIX -- which kinda kills the premise that they are "standards-based" (if they were, they'd all be identical), and "work well together"
And what might they be?
MacOS?
AmigaDOS?
IBM OS/370?
OSes, by their very nature, are designed to be proprietary.
No, that's targeting compatibility not with the "Windows Platform", but with "Microsoft VC++".
And you are still mixing the two parts of the ABI. The COM ABI was fully described years ago, and is NOT affected by changes in C++.
You are confusing Microsoft's responibilities as OS vendor (which it had fulfilled) with it's "responsibilities" as a compiler vendor to it's competitors (which it has none, unless someone proves MS has a monopoly on C++ compilers)
The monopoly aspect is important. If one could prove that it is required that the OBJ produced by Compile X be link-compatibile with OBJs VC++ -- Not that it is a nice feature to have, but absolutely REQUIRED-- than MS could be forced to provide this information. Until then, MS could keep it an internal secret. And, since MS itself publishes several compilers which aren't fully link-compatible with each other (FoxPro for example), that would be very hard to prove. And my original argument still stands: I claim that it is harder to achieve this on Windows than it is for most other platforms, mostly due (directly or indirectly) to actions from Microsoft themselves.
You'll note that your first example (G++) refers to an compiler, not an OS.
You'll note that your third example (Sun C++) the document is published by the Sun's compiler group, not their OS division. (It's author, Steve Clamage, BTW, is (or at least, was -- he may have stepped down) also chairmain of the C++ Standardazation Committee.)
Only in your second example (Apple) is the compile ABI specified by the OS vendor, but that's only because of Apple draconian need to control every aspect of all software that runs on MacOS.
Name-mangling schemes are unique to the compiler vender. They have nothing to do with the ABI which would be language independant.
I think you are confusing the operating system's ABI with the compiler's object model. The problem is that while the ABI is shared by all compiler vendors of all languages, the object model is used only by those that need static link compatibility, and is usually unique to the compiler vendor.
The difference that while OS-vender Microsoft is required to provide an acceptable ABI in a timely fashion (which they did), compiler-vender Microsoft is under to requirement to share it's C++ object model at all. The ability to link OBJs compiled by Vendor X's C++ with OBJs compiled by Microsoft's C++ might occasionally be a nice feature to have, but it's never necessary (You just need to recompile all of your source code; if you use a third party library which was only provided as a VC OBJ without source code --- well, that was pretty foolish of you in the first place, and then doubly-foolish, in light of that, for you to switch compilers.)
Um... And how is that different than just making x public?
(OK, I guess it's a bit different if you just use one of the attributes, instead of both, but it's still doable with something like:
(definition of ReadOnly left as an exercise for the student).Actually, between vector and std::string, there virtually no reason to ever use a pointer again. (And for the rare occasion that you do, there's boost::shared_ptr)
You should met a better class of programmers....
I use it all the time. Even at my day job, where our legacy system uses a mixture of MFC's CString, ATL's _bstr_t and Rogue Wave's RWCString, we are moving to using std::string.
You are tremendously overstating the problem.
It would only affect you if your base class is reissued in .OBJ form, and you choose to relink your code without recompiling it.
If you recompile your code (with the new base class's .H files) and then relink with the new .OBJs, you'll be fine.
If your vendor issues new .OBJs without issuing new .H files, they are dangerous, avoid them.
(apologies for WINtel world terminology; Linuxheads should substitute ".Os" for ".OBJs" to understand).
However, several implement the entire standard except for one feature (export), which has a good chance of being removed from the Standard. And those "several" include the most popular ones (Microsoft Visual C++ 7.1 (aka .Net 2003), and the latest GNU).
After the first Standard was approved in 1998, the committee merely cut down from three meetings a year to two per year.
Nothing that changed in the standard in the latter years of standardization would have effected anything you site in your message. However, many basic features of C++ would. In other words, had MS failed to provide a complete ABI, it would be impossible to have provided any form of compiler. An ABI good enough for a non-standard compiler would be good enough for a Standard compiler.
Beside, the Edison Design Group's compiler, (which they don't sell retail, but license to other compiler vendors), was the first fully-compliant C++ front-end --- and compiles to C code. So, all you really needed was an ABI good enough for C.
They are trying to bring the non-OO stuff to C, but it's a bit difficult. Is the string data type "object orient"? It's implemented as a templated class, but that's irrelevant, right?
What about the complex data type? where the template implementation is more explicit than with string.
What about the algorithm in the STL? They work on C arrays. Should they be moved to C?
Not, it's Zero-X. (though it's pronounced "oh-x"). Oxford, England was the location of the last meeting. (The committee mets twice a year, once inside North America, and once outside). Traditionally, just prior to each meeting, every member would be shipped a big package of all the papers that would be dealt with out the meeting, and afterwards, another package with all the revised papers to reflect discussions at the meeting. (I said "traditionally", as shipping paper documents became too expensive, so now it's all done in email, which negates the need for one big package of all the papers). Anyway, these documents packages are called the "pre-(location)" and "post-(location)" mailings. The link in the opening article pointed to a document in "post-Oxford mailing". I believe the next one (in the fall) will be in Kona, Hawaii, so those documents will be called the "pre-Kona" and the "post-Kona"
The 1994 Working draft was quite different than the final draft that was ratified four years later. First of all, the STL was added in 1995, and that caused changes rippling through the entire library. (ie, the string class was toss out and restarted from scratch to be more stl like). Also the templatizing of iostreams didn't start until 1995.
The name only reflected clarification of the target market. ".NET" is still attached to products targeted to developers. (Witness "Visual Studio.Net 2003" released a few weeks ago) I know Linux Guys may find this hard to believe, by the people in charge of buying Operating Systems are (statistically) rarely programmers.
That comes from the NDA one signs to get access to *BETA* copies of MS software, because *BETA* releases are traditionally much slowly than the final release. MS got burned years ago, when they passed out copies of the NT 1.0 BETA to journalists (which was a non-optimized build with lot of debugging code in it), and then they wrote (with comparisons to retail version of other OSes), how slow it was. Of course, when NT was finally released (about a year after that), it was considerably faster, but it took years for it to live down those initial ill-informed comments.
Well, clearly we should not be electing them president.... (link)
Where...did Einstein, Turing and Dyson make their homes?
And let's not forget Edison....(And also remember the NJ gave as UNIX, C and C++)
I'm not a business. I'm a person who uses computers
Actually, you are NOT just "a person who uses computers".. Considering your #4 requirement, you are a person who has the ability to modify code, which, while you may be in the majority of Linux users, puts you in a negligible small (under 1%) minority of all "people who use computers". That Linux advocates cannot understand that is the #1 hurdle preventing the widespread acceptence of Linux.
And it doesn't feature draconian licensing
um..Hello... MacOs features extreme draconian licensing.... It can only be bought when buying or upgrading Apple hardware.
VisualC++ does infact color strings. Unfortunately, the default color is black on white. It can be changed via the Tools/Options/Format dialog box. It will also highlight user-defined keywords (like DWORD, HANDLE etc), you just have to create a usertype.dat file listing the one you want highlighted. VC6 doesn't highlight mismatched backets & such, but you can from the opening one to the closer using Ctrl-]. (and VS.Net-- ya'know, the version that's been out for NEARLY A YEAR -- does highlight mismatched []{}() in the editor; nice of you to compare a new product ("Vim (default shipped with redhat 7.3)" to one four years old (vc6))