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....

  1. #31
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> So much for the Standard template library.
    Why? It's a standard interface, not a standard implementation.

  2. #32
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #33
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> Use any types except for the standard library types and it works well.

    This is wrong. The problem exists for any non-primitive type.

  4. #34
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #35
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> 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.

  6. #36
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    Quote Originally Posted by Daved View Post
    >> 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.

    Am I overreacting?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #37
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> 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.

  8. #38
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    Quote Originally Posted by Daved View Post
    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.
    Ah well, in the end it boils down to that. And that is the problem, indeed.
    And that is the problem they really must address.
    The End
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #39
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    Quote Originally Posted by Daved View Post
    >> 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.
    Last edited by Mario F.; 06-26-2008 at 03:58 PM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  10. #40
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    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.

  11. #41
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    FUD.

    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #42
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    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.

  13. #43
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by cpjust View Post
    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.

  14. #44
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by medievalelks View Post
    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.

  15. #45
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    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.)
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 3 of 8 FirstFirst 12345678 LastLast
Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21