Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: C++ library names

Reply
Thread Tools

Re: C++ library names

 
 
Jonathan de Boyne Pollard
Guest
Posts: n/a
 
      09-12-2011
> 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++.
 
Reply With Quote
 
 
 
 
Goran
Guest
Posts: n/a
 
      09-13-2011
On Sep 12, 6:24*pm, Jonathan de Boyne Pollard <J.deBoynePollard-
(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
Peter Flass
Guest
Posts: n/a
 
      09-13-2011
On 9/13/2011 3:24 AM, Goran wrote:
> On Sep 12, 6:24 pm, Jonathan de Boyne Pollard<J.deBoynePollard-
> (E-Mail Removed)> 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.

 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      09-13-2011
On Sep 13, 1:22*pm, Peter Flass <(E-Mail Removed)> wrote:
> On 9/13/2011 3:24 AM, Goran wrote:
>
>
>
>
>
>
>
>
>
> > On Sep 12, 6:24 pm, Jonathan de Boyne Pollard<J.deBoynePollard-
> > (E-Mail Removed)> *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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Converting 'flat' gate level names to hierarchical names Paddy McCarthy VHDL 3 09-24-2004 05:34 PM
table field names vs. display names Bob ASP .Net 1 07-30-2004 05:06 PM
Matching attribute names to element names in a different path Carl XML 0 04-01-2004 01:15 PM
WSDL- Mapping Application Defined Names to XML Names Craig XML 0 02-09-2004 04:14 PM
XSL rules applying to XSD (XML schema) defined type names (as opposed to node names) Lewis G. Pringle, Jr. XML 0 09-30-2003 10:34 PM



Advertisments