Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #10056 > unrolled thread

Re: C++ library names

Back to article view | Back to comp.lang.c++

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: C++ library names Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-09-12 17:24 +0100
    Re: C++ library names Goran <goran.pusic@gmail.com> - 2011-09-13 00:24 -0700
      Re: C++ library names Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-13 07:22 -0400
        Re: C++ library names Goran <goran.pusic@gmail.com> - 2011-09-13 05:06 -0700

#10056 — Re: C++ library names

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

[toc] | [next] | [standalone]

#10068

On Sep 12, 6:24 pm, Jonathan de Boyne Pollard <J.deBoynePollard-
newsgro...@NTLWorld.COM> 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.

[toc] | [prev] | [next] | [standalone]

#10073

On 9/13/2011 3:24 AM, Goran wrote:
> On Sep 12, 6:24 pm, Jonathan de Boyne Pollard<J.deBoynePollard-
> newsgro...@NTLWorld.COM>  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.

[toc] | [prev] | [next] | [standalone]

#10074

On Sep 13, 1:22 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
> On 9/13/2011 3:24 AM, Goran wrote:
>
>
>
>
>
>
>
>
>
> > On Sep 12, 6:24 pm, Jonathan de Boyne Pollard<J.deBoynePollard-
> > newsgro...@NTLWorld.COM>  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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web