C++/Java/C#

This is a discussion on C++/Java/C# within the A Brief History of Cprogramming.com forums, part of the Community Boards category; >> So much for the Standard template library.
Why? It's a standard interface, not a standard implementation....

It's quite disgusting to see that you cannot use standard library types in an interface.
Then what is the whole point of using C++? It is, maybe, the single, biggest flaw in the entire language.
Use any types except for the standard library types and it works well.
It severely limits C++ interfaces.

True, in a sense, but not as much.
They are more compatible, although may still cause some problems.
But that's just another thing to add to the list of things C++ can do better.
It's pretty inexcusable for a modern language not to be able to create a stable interface.

>> They are more compatible, although may still cause some problems.
I don't understand what you're trying to say. Any library type will cause problems if you link to different implementations of that library. The only reasons the standard library is used as an example are that it is used often and there are different library implementation available.

>> It's pretty inexcusable for a modern language not to be able to create a stable interface.
You can create a "stable" interface, just not one using all the library additions you'd like to. I'm not saying that these issues aren't a burden, but you're making things up to complain about.

>> They are more compatible, although may still cause some problems.
I don't understand what you're trying to say. Any library type will cause problems if you link to different implementations of that library. The only reasons the standard library is used as an example are that it is used often and there are different library implementation available.

Well, the idea was that in implementation X, std::string has a member called, say, m_str of type const T*, and then a size of type size_t.
In implementation Y, those are switched, so it would likely cause rubbish data or a crash when passing it through an interface between those two.
However, if it were a custom data type, this would not occur because they would always be placed at the same location.
What might cause problems may be padding or such.
Thus custom data types are not as prone to errors as standard library types. They're less error prone, but still error prone.

>> It's pretty inexcusable for a modern language not to be able to create a stable interface.
You can create a "stable" interface, just not one using all the library additions you'd like to. I'm not saying that these issues aren't a burden, but you're making things up to complain about.

No, not really. You would expect to be able to pass C++ types across boundaries, but the fact that you cannot makes this a big deal that is worth complaining about.
I haven't heard of many such issues with other languages. Especially not Java, C# and the like.
C++ cannot compare to those languages in this respect and it's a real drawback that is limiting the language's potential.

>> However, if it were a custom data type, this would not occur because they would always
>> be placed at the same location.

This is (again) missing the point. Any custom type will have a problem if you link to different implementations of it. Of course it will be less of a problem if you completely control the building of your own custom type, but that wasn't my point. My point was that all libraries have this potential issue, it is not specific to the standard library. There are many other libraries available that you do not control and you will can have the same problem with those. The problem is not with the standard C++ library, the problem is with the language itself and the lack of ability to ensure a consistent implementation.

>> You would expect to be able to pass C++ types across boundaries, but the fact that you
>> cannot makes this a big deal that is worth complaining about.

Sure, but you're complaining about the wrong thing and basing it off of (or backing it up with) erroneous information.

>> So much for the Standard template library.
Why? It's a standard interface, not a standard implementation.

The code example provided that spurred this last discussion was entirely made of built-in types and STL interfaces (an int, an std:: pair and a std:: string). Naturally I couldn't agree more with you when you mention this is necessarily a problem with any libraries that provides an interface to built-in types.

However, I think this should be addressed exclusively from the perspective of different programming languages (where the argument does make a lot of sense). Not for fear of different C++ implementations. The STL interface should be only one, the implementation however can vary.

Hence my comment. It was an alert that it shouldn't be discussed as the latter.

EDIT: In the interest of portability I'm of course happy to ignore my own comments on this. And I'm glad I was following this thread when the comment from cpjust came. I hade never thought of it before. But I cannot ignore the irony behind what now becomes lack of portability feature of the STL, according to the text.

It's not just STL objects that have problems across modules, it's any object. Even though the API of the STL (or custom) objects don't change between various compilers (or compile options), the ABI does.

Compiler vendors take great care not to change their ABI between compiler versions, especially minor compiler versions. You can safely do any micro version upgrade in GCC, for example, because the rules of development state that no such incompatibilities are allowed to exist. The same applies to minor versions, but there are a few exceptions (there was big trouble during the GCC 3.2 to 3.4 versions). Only major GCC upgrades (from 3 to 4) make no guarantees about ABI compatibility.

Pretty much the same applies to Microsoft's compilers. I don't know exactly when they break ABI compatibility, but I'll bet it's not very often.

Any vendor that breaks the ABI more than once in several years is using a completely idiotic development methodology, and that's not C++'s fault.

No, the only real problem is interoperability between different implementations.

Surprisingly, there's still a lot of companies using VC++ 6.0. If they suddenly decided to get out of the stone age and upgrade to the latest version, I'm almost certain the ABI would be different. As for minor compiler patches, sure it's unlikely they would change the ABI, but not impossible.

You never know how long a particular version of your software will be around, so unless you want to get stuck using the same compiler forever when you release product fixes, use only primitive types across DLLs...

Plus, I believe small incompatibilities can creep in even if you just change some of the compile/link settings.

Surprisingly, there's still a lot of companies using VC++ 6.0. If they suddenly decided to get out of the stone age and upgrade to the latest version.

My client is one of them. There's just no real business case to upgrade 100s of thousands of LOC to get "out of the stone age". Some of the code hasn't been touched in 10 years but it's still running in production and bringing home the bacon.

My client is one of them. There's just no real business case to upgrade 100s of thousands of LOC to get "out of the stone age". Some of the code hasn't been touched in 10 years but it's still running in production and bringing home the bacon.

Well I highly doubt you'd need to change much of the actual code itself (unless they've been compiling with really low warning levels like my company has), but definitely the project settings.

Umm, are you missing that MSVC6 is not very standards compliant?
For example, pointers to member class functions were not fixed until 2005.
(Or maybe it's that the compiler is missing a lot of stuff, like partial template specializations.)