Re: C++ library names

Discussion in 'C++' started by Jonathan de Boyne Pollard, Sep 12, 2011.

  1. > This "problem" is called "name mangling" [...]

    No it isn't. It's many programmers' simplistic statement of the
    problem, but name mangling is merely a symptom of the actual problem,
    which is a lack of binary compatibility across compilers, which
    stretches to a lot more things than just symbol names. M. Zakharevich
    hit the nail squarely on the head: DirectToSOM C++ solves this. It's a
    pity that (a) the class library wasn't compiled to SOM by the IBM
    compiler, and (b) GCC isn't capable of DirectToSOM C++.
     
    Jonathan de Boyne Pollard, Sep 12, 2011
    #1
    1. Advertising

  2. Jonathan de Boyne Pollard

    Goran Guest

    On Sep 12, 6:24 pm, Jonathan de Boyne Pollard <J.deBoynePollard-
    > wrote:
    > > This "problem" is called "name mangling" [...]

    >
    > No it isn't.  It's many programmers' simplistic statement of the
    > problem, but name mangling is merely a symptom of the actual problem,
    > which is a lack of binary compatibility across compilers, which
    > stretches to a lot more things than just symbol names.  M. Zakharevich
    > hit the nail squarely on the head:  DirectToSOM C++ solves this.  It's a
    > pity that (a) the class library wasn't compiled to SOM by the IBM
    > compiler, and (b) GCC isn't capable of DirectToSOM C++.


    Binary compatibility? Meh. C and C++ as __languages__ do not have
    that.

    I personally am not a fan of binary compatibility and I believe people
    are overrating this. If code from different toolchains or languages
    needs to speak to each other, there's integration technologies. One of
    them is called "the C interface used by the platform (OS)". That's a
    dumb one (effective, though, and any monkey gets it). There's more
    (or, rather, very) complex stuff like COM of MS. There's also "VM as
    integration technology" (Java, .NET). Finally, there's also "one
    compiler version integration" of C++. There's all this choice since
    forever.

    We would gain little with putting binary compatibility into C or C++.

    Goran.
     
    Goran, Sep 13, 2011
    #2
    1. Advertising

  3. Jonathan de Boyne Pollard

    Peter Flass Guest

    On 9/13/2011 3:24 AM, Goran wrote:
    > On Sep 12, 6:24 pm, Jonathan de Boyne Pollard<J.deBoynePollard-
    > > wrote:
    >>> This "problem" is called "name mangling" [...]

    >>
    >> No it isn't. It's many programmers' simplistic statement of the
    >> problem, but name mangling is merely a symptom of the actual problem,
    >> which is a lack of binary compatibility across compilers, which
    >> stretches to a lot more things than just symbol names. M. Zakharevich
    >> hit the nail squarely on the head: DirectToSOM C++ solves this. It's a
    >> pity that (a) the class library wasn't compiled to SOM by the IBM
    >> compiler, and (b) GCC isn't capable of DirectToSOM C++.

    >
    > Binary compatibility? Meh. C and C++ as __languages__ do not have
    > that.
    >
    > I personally am not a fan of binary compatibility and I believe people
    > are overrating this. If code from different toolchains or languages
    > needs to speak to each other, there's integration technologies. One of
    > them is called "the C interface used by the platform (OS)". That's a
    > dumb one (effective, though, and any monkey gets it). There's more
    > (or, rather, very) complex stuff like COM of MS. There's also "VM as
    > integration technology" (Java, .NET). Finally, there's also "one
    > compiler version integration" of C++. There's all this choice since
    > forever.
    >
    > We would gain little with putting binary compatibility into C or C++.
    >


    I disagree. If you're in control of all the code you use, one compiler
    is fine. If you're getting code from everywhichwhere, like so many
    projects do today, it's a real problem. Even with open source, having
    to compile everything from scratch and cope with the quirks and
    incompatibilities of several compilers is a real handicap.
     
    Peter Flass, Sep 13, 2011
    #3
  4. Jonathan de Boyne Pollard

    Goran Guest

    On Sep 13, 1:22 pm, Peter Flass <> wrote:
    > On 9/13/2011 3:24 AM, Goran wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Sep 12, 6:24 pm, Jonathan de Boyne Pollard<J.deBoynePollard-
    > > >  wrote:
    > >>> This "problem" is called "name mangling" [...]

    >
    > >> No it isn't.  It's many programmers' simplistic statement of the
    > >> problem, but name mangling is merely a symptom of the actual problem,
    > >> which is a lack of binary compatibility across compilers, which
    > >> stretches to a lot more things than just symbol names.  M. Zakharevich
    > >> hit the nail squarely on the head:  DirectToSOM C++ solves this.  It's a
    > >> pity that (a) the class library wasn't compiled to SOM by the IBM
    > >> compiler, and (b) GCC isn't capable of DirectToSOM C++.

    >
    > > Binary compatibility? Meh. C and C++ as __languages__ do not have
    > > that.

    >
    > > I personally am not a fan of binary compatibility and I believe people
    > > are overrating this. If code from different toolchains or languages
    > > needs to speak to each other, there's integration technologies. One of
    > > them is called "the C interface used by the platform (OS)". That's a
    > > dumb one (effective, though, and any monkey gets it). There's more
    > > (or, rather, very) complex stuff like COM of MS. There's also "VM as
    > > integration technology" (Java, .NET). Finally, there's also "one
    > > compiler version integration" of C++. There's all this choice since
    > > forever.

    >
    > > We would gain little with putting binary compatibility into C or C++.

    >
    > I disagree.  If you're in control of all the code you use, one compiler
    > is fine.  If you're getting code from everywhichwhere, like so many
    > projects do today, it's a real problem.  Even with open source, having
    > to compile everything from scratch and cope with the quirks and
    > incompatibilities of several compilers is a real handicap.


    Fair point.

    (Continuing from my first post, really)

    If you're not in control of all the code, OTOH, there's a bigger
    chance you'll have code in other languages, than code that runs well
    only when compiled with a single compiler. In which case, again,
    integration tech > binary compatibility between implementations.

    There's another thing: even if we did have binary compatibility on a C
    level, we'd still have to deal with versioning issues. No amount of
    binary compatibility can help you when, I dunno, std::string changes
    underlying implementation (which it just as well may, and did, in more
    than one C++ toolchain). And versioning is one of the things that your
    friendly integration tech allows for (well, should).

    Goran.
     
    Goran, Sep 13, 2011
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paddy McCarthy
    Replies:
    3
    Views:
    753
    Anthony J Bybell
    Sep 24, 2004
  2. Bob
    Replies:
    1
    Views:
    421
    Lucas Tam
    Jul 30, 2004
  3. Lewis G. Pringle, Jr.
    Replies:
    0
    Views:
    632
    Lewis G. Pringle, Jr.
    Sep 30, 2003
  4. Craig
    Replies:
    0
    Views:
    474
    Craig
    Feb 9, 2004
  5. Carl
    Replies:
    0
    Views:
    541
Loading...

Share This Page