C++

C

chambu

Hi,
can somebody explore me more on Concept of Name Mangling used by C+
+ compilers.Also what is is the concept of UNICODES & what are
TRIGRAPH SEQUENCES.

Regards,

Chambu
 
J

James Kanze

can somebody explore me more on Concept of Name Mangling
used by C++ compilers.

An implementation detail, which varies from one compiler to the
next.
Also what is is the concept of UNICODES

www.unicode.org. Also the first five chapters of _Fontes_ _et_
_codages_, by Yannis Haralambous. (An English translation, and
probably others, is available.)
& what are
TRIGRAPH SEQUENCES.

Something you don't want to know about. A solution to a problem
that had ceased to exist by the time they were implemented.
(See http://www.gotw.ca/gotw/086.htm, for example.)
 
J

Juha Nieminen

James said:
An implementation detail, which varies from one compiler to the
next.

Which is a shame, really. It hinders C++'s capabilities at creating
shared and precompiled libraries. Either all C++ shared/precompiled
libraries and C++ programs in a system must be compiled with the same
compiler, or if several different compilers are used, they all must use
the exact same name mangling system which, as you say, is often not the
case.

If name mangling was standardized, it would greatly increase the
usability of C++ to create shared and precompiled libraries usable among
different compilers.

If I'm not mistaken, in the C world name mangling has been long ago
"standardized" (if not de jure, at least de facto), which is why C is so
much more usable for precompiled libraries: A library created by any C
compiler is usable by any another C (and even C++) compiler.
 
R

Rolf Magnus

Juha said:
Which is a shame, really. It hinders C++'s capabilities at creating
shared and precompiled libraries.

There are a lot more things to consider for that than just name mangling.
Either all C++ shared/precompiled libraries and C++ programs in a system
must be compiled with the same compiler, or if several different compilers
are used, they all must use the exact same name mangling system which, as
you say, is often not the case.

If name mangling was standardized, it would greatly increase the
usability of C++ to create shared and precompiled libraries usable among
different compilers.

If I'm not mistaken, in the C world name mangling has been long ago
"standardized" (if not de jure, at least de facto),

Even though C wouldn't actually need any name mangling at all, it is in fact
not "standardized", at least not under all systems. I have found that out
lately when I needed to write a DLL for Windows that can be used as a
drop-in replacement for an old one.
 
P

Pete Becker

If name mangling was standardized, it would greatly increase the
usability of C++ to create shared and precompiled libraries usable among
different compilers.

Name mangling is one of several problems in getting different compilers
to work together. You also need to agree on object layout, calling
conventions, and, perhaps, register usage. These are all platform
specific, so there's no universal solution that handles all of them.
If I'm not mistaken, in the C world name mangling has been long ago
"standardized" (if not de jure, at least de facto), which is why C is so
much more usable for precompiled libraries: A library created by any C
compiler is usable by any another C (and even C++) compiler.

Back when I was paying attention to it, many C compilers mangled names
by putting an underscore at the beginning of the name. Some put it at
the end. Some just used the name itself. And libraries created by any C
compiler could be used by any other C compiler only to the extent that
vendors agreed on name mangling, object layout, and calling conventions.
 
J

Jeff Schwab

Rolf said:
Juha Nieminen wrote: ....

Even though C wouldn't actually need any name mangling at all it is in fact
not "standardized", at least not under all systems. I have found that out
lately when I needed to write a DLL for Windows that can be used as a
drop-in replacement for an old one.

What kind of mismatch did you see? I though each externally linked C
identifiers in Windows object files had exactly one leading underscore,
followed by the C identifier.
 
R

Rolf Magnus

Jeff said:
What kind of mismatch did you see?

About what is described here: http://www.geocities.com/yongweiwu/stdcall.htm
I though each externally linked C identifiers in Windows object files had
exactly one leading underscore, followed by the C identifier.

It seems that this is the case only as long as you don't use dynamically
linked libraries, and even then you can't be sure of that, considering the
comment below the table on that web page.
 
R

Rolf Magnus

Pete said:
Name mangling is one of several problems in getting different compilers
to work together. You also need to agree on object layout, calling
conventions, and, perhaps, register usage.

Don't forget things like exception handling and details like dynamic
initialization of global objects or NRVO. And then, there is the standard
library. If name mangling is the same, you can't link standard libraries of
two different compilers together, but each compiler uses its own headers,
so I wouldn't expect code compiled to run with one standard library
implementation to work with another.
These are all platform specific, so there's no universal solution that
handles all of them.

I'd say most parts don't really need to be different for different
platforms. There even is a more-or-less-standard ABI, but there are just a
lot of compilers that don't support it.
 
J

Juha Nieminen

Pete said:
Name mangling is one of several problems in getting different compilers
to work together. You also need to agree on object layout, calling
conventions, and, perhaps, register usage. These are all platform
specific, so there's no universal solution that handles all of them.

Precompiled libraries are platform specific. That wasn't the point.

What I meant was that I can create a precompiled or even a dynamically
loadable shared library in C with gcc and use it in code I'm compiling
using icc (or basically any other C compiler for the same system).

C++ has this problem that a precompiled library created with one
compiler may not be usable with another. In some cases it might not even
be usable with the next version of the *same* compiler! This is because
compilers don't seem to yet agree on which name mangling convention to use.
 
B

Bo Persson

Juha said:
Precompiled libraries are platform specific. That wasn't the point.

What I meant was that I can create a precompiled or even a
dynamically loadable shared library in C with gcc and use it in
code I'm compiling using icc (or basically any other C compiler for
the same system).

C++ has this problem that a precompiled library created with one
compiler may not be usable with another. In some cases it might not
even be usable with the next version of the *same* compiler! This
is because compilers don't seem to yet agree on which name mangling
convention to use.

That might be so because the name mangling is just a minor part of the
interface. "Fixing" that doesn't help, unless you also specify how to
handle class layout, construction and destruction, how new[] and
delete[] should be implemented, or virtual inheritance, or...

Nobody wants to do that.


Bo Persson
 
P

Pete Becker

Don't forget things like exception handling and details like dynamic
initialization of global objects or NRVO. And then, there is the standard
library. If name mangling is the same, you can't link standard libraries of
two different compilers together, but each compiler uses its own headers,
so I wouldn't expect code compiled to run with one standard library
implementation to work with another.

I *knew* there were things that I hadn't thought of. Thanks for filling
in more details.
 
P

Pete Becker

Precompiled libraries are platform specific. That wasn't the point.

What I meant was that I can create a precompiled or even a dynamically
loadable shared library in C with gcc and use it in code I'm compiling
using icc (or basically any other C compiler for the same system).

And that's because the vendors of gcc and icc, through some process
outside the C++ standard, agreed on all the details that are needed to
make that happen. Having the C++ standard define name mangling wouldn't
do that.
C++ has this problem that a precompiled library created with one
compiler may not be usable with another. In some cases it might not even
be usable with the next version of the *same* compiler! This is because
compilers don't seem to yet agree on which name mangling convention to use.

Again: it's not name mangling. In fact, differences in name mangling
are a good thing here: if everyone mangled names the same way, you'd be
able to link libraries that were not, in fact, compatible.
 
J

James Kanze

Which is a shame, really. It hinders C++'s capabilities at creating
shared and precompiled libraries.

Not really. What hinders C++'s capabilities here is the lack of
platform standard API's. The reason you can't link code
compiled with Sun CC with that compiled with g++ is because Sun
CC and g++ lay out vtables, virtual inheritance, etc.,
differently.

All that the different name manglings mean is that you'll get an
error at link time, rather than a core dump at run time.
Either all C++ shared/precompiled libraries and C++ programs
in a system must be compiled with the same compiler, or if
several different compilers are used, they all must use the
exact same name mangling system which, as you say, is often
not the case.

Not just the same name mangling system, but the same conventions
throughout. Class layout, exception handling, calling
conventions, etc., etc.
If name mangling was standardized, it would greatly increase
the usability of C++ to create shared and precompiled
libraries usable among different compilers.

Not really. It would greatly increase the time spent in finding
errors because two libraries were compiled using different
conventions.

(Note that even today, both Sun CC and g++ use somewhat
different layouts for some of the standard classes, depending on
compiler options. Without changing mangling. I've already lost
a fair amount of time because of it: one library being compiled
with different options than the client code.)
If I'm not mistaken, in the C world name mangling has been
long ago "standardized" (if not de jure, at least de facto),
which is why C is so much more usable for precompiled
libraries: A library created by any C compiler is usable by
any another C (and even C++) compiler.

The reason why C works in this case is because most platforms
define a standard C API, to which all C compilers adher. There
have been efforts in this direction for C++, at least on some
platforms, but on the whole, not nearly as much as one would
like.
 
J

James Kanze

Don't forget things like exception handling and details like
dynamic initialization of global objects or NRVO. And then,
there is the standard library. If name mangling is the same,
you can't link standard libraries of two different compilers
together, but each compiler uses its own headers, so I
wouldn't expect code compiled to run with one standard library
implementation to work with another.

Note that both of the compilers I regularly use (Sun CC and
g++) have two variants of the standard library; which one gets
used depends on invocation options. And the variants aren't
compatible. And don't affect name mangling. (I've already
spent some time tracking down errors in programs compiled with
g++ because the main code was compiled with -D_GLIBCXX_DEBUG et
al., but one of the libraries wasn't; I suspect that you would
get the same problems with Sun CC using -library=stlport4 or
not. (And I think VC++ has similar problems.)
I'd say most parts don't really need to be different for
different platforms. There even is a more-or-less-standard
ABI, but there are just a lot of compilers that don't support
it.

There is a standard ABI for one platform, I think. There's
certainly not one for Sparc, nor for Windows. (And for Windows
on a PC, there's only an informal one: what g++ uses.)
 
A

Alf P. Steinbach

* James Kanze:
There is a standard ABI for one platform, I think.

Not sure which one you're referring to.

There's
certainly not one for Sparc, nor for Windows. (And for Windows
on a PC, there's only an informal one: what g++ uses.)

Windows has two (platform-) standard ABIs, namely COM and .NET. These
are language-independent ABIs, but COM was mainly designed for C++, with
extensions (called "OLE Automation", essentially the interface IDispatch
plus associated types) for Visual Basic and scripting languages.
Neither COM nor .NET supports C++ templates, so, essentially, the C++
standard library can only be used internally by components.

The cost of providing a component as a COM component is high, with
technical impact on three main areas. First, for the interface,
foregoing all use of the C++ standard library and all use of templates.
Second, for the interface, designing all exposed classes with default
construction and init-method (required by COM) -- even though this is
technically only a question of wrapping a soundly designed class in an
unsound one, that wrapping is in practice so costly itself that it isn't
done, so that COM impacts directly on the design level. Third, adding a
lot of COM-specific machinery (in particular, the support for use of the
component from scripting languages), which must be sprinkled at all
levels of the code. To help with that Visual C++ provides a lot of
language extensions, in particular an #import directive, UUID-support
and so called "attribute" programming, attributes in square brackets
that in general serve to automatically generate COM support code.

With the cost so high one may may wonder whether COM is used at all.
The answer is that COM is so entrenched at all levels of Windows (like
DOS was... ;-)) that there's no way around. E.g., if you're scripting a
web page, then with execution of that script in Internet Explorer nearly
all the objects you're handling are COM objects (some made in C++), and
the scripting engine itself is a collection of COM objects (which would
likely have been written in C and/or C++). And for other platforms, the
basic COM design has been adopted in other ABIs, such the ABIs of
Mozilla software (XCOM) and in Linux GUI (I don't recall the name).
This means that COM's happily making a lot of both Windows and
non-Windows software extremely complex in order to provide a little bit
of interoperability, so little that generally you don't notice...

For .NET the situation isn't quite that bad because .NET is a more
modern VM-based ABI. However, also for .NET, language extensions are
key to managing the inherent complexity as seen from the C++ level. And
Microsoft defines 2 sets of such language extensions: "Managed
Extensions" for .NET is the older one, and "C++/CLI", essentially a new
/language/ that is a superset of C++, is the currently favored one.

In addition to having two different .NET specific C++-derived languages
(or language extension sets) to deal with, interfacing with the Windows
API generally requires involving COM, the older ABI...

It's about the same as going down to C in other C++ programming.

The C++/CLI language is essentially the brainchild of the chair of the
international C++ standardization committee Herb Sutter (he was the lead
architect), plus, .NET isn't completely restricted to Windows (the Mono
project, sponsored by Novell, "provides the necessary software to
develop and run .NET client and server applications on Linux, Solaris,
Mac OS X, Windows, and Unix"), so I don't think we should forget .NET as
C++ ABI, even though .NET is language independent.

Cheers,

- Alf
 
R

Rolf Magnus

Alf said:
* James Kanze:

Not sure which one you're referring to.

Probably this one: http://www.codesourcery.com/cxx-abi/abi.html
AFAIK, g++ (and probably other compilers) uses this as basis on other
platforms too.
Windows has two (platform-) standard ABIs, namely COM and .NET.

Is COM a C++ ABI? I thought it's just an object model based on C.
For .NET the situation isn't quite that bad because .NET is a more
modern VM-based ABI. However, also for .NET, language extensions are
key to managing the inherent complexity as seen from the C++ level. And
Microsoft defines 2 sets of such language extensions: "Managed
Extensions" for .NET is the older one, and "C++/CLI", essentially a new
/language/ that is a superset of C++, is the currently favored one.

I have no idea why anyone would use "C++/CLI". Either use real C++, or use
C#. Essentially "C++/CLI" looks to me like C# pressed into a syntax that is
closer to C++, but isn't really C++.
The C++/CLI language is essentially the brainchild of the chair of the
international C++ standardization committee Herb Sutter (he was the lead
architect), plus, .NET isn't completely restricted to Windows (the Mono
project, sponsored by Novell, "provides the necessary software to
develop and run .NET client and server applications on Linux, Solaris,
Mac OS X, Windows, and Unix"), so I don't think we should forget .NET as
C++ ABI, even though .NET is language independent.

It will never become "the single C++ ABI", considering that it's not based
on translating the C++ source code directly to native code.
 
A

Alf P. Steinbach

* Rolf Magnus:
Probably this one: http://www.codesourcery.com/cxx-abi/abi.html
AFAIK, g++ (and probably other compilers) uses this as basis on other
platforms too.


Is COM a C++ ABI?

It has served as one since 1991 or so (I forget these dates).

I thought it's just an object model based on C.

No, although technically language-independent, it was originally
designed primarily for (16-bits, but very soon upgraded to 32-bits) C++,
with C++ vtable layout.

It's a hassle to use from C.

I have no idea why anyone would use "C++/CLI". Either use real C++, or use
C#. Essentially "C++/CLI" looks to me like C# pressed into a syntax that is
closer to C++, but isn't really C++.


It will never become "the single C++ ABI", considering that it's not based
on translating the C++ source code directly to native code.

I doubt that there will ever be any "the" ABI for C++. ;-)


Cheers, & hth.,

- Alf
 
J

James Kanze

* James Kanze:
Not sure which one you're referring to.

Not to sure myself. It's not one I actually use, at any rate.
(Seriously, I think it is the 64 bit Intel architecture.)

That's a typo. I should have said "for Linux on a PC".
Obviously, what g++ is not a de facto standard in the PC world.
Windows has two (platform-) standard ABIs, namely COM and .NET. These
are language-independent ABIs, but COM was mainly designed for C++, with
extensions (called "OLE Automation", essentially the interface IDispatch
plus associated types) for Visual Basic and scripting languages.
Neither COM nor .NET supports C++ templates, so, essentially, the C++
standard library can only be used internally by components.

And both, I think, require some additional explicit
declarations. If I just write standard C++, and compile it, I
won't end up with either. (Or will I?)
 
R

Richard Herring

Rolf Magnus said:
Alf P. Steinbach wrote:
[...]
For .NET the situation isn't quite that bad because .NET is a more
modern VM-based ABI. However, also for .NET, language extensions are
key to managing the inherent complexity as seen from the C++ level. And
Microsoft defines 2 sets of such language extensions: "Managed
Extensions" for .NET is the older one, and "C++/CLI", essentially a new
/language/ that is a superset of C++, is the currently favored one.

I have no idea why anyone would use "C++/CLI".

If you need to provide a .NET interface layer wrapping existing C++
code, it's the only option.
Either use real C++, or use
C#. Essentially "C++/CLI" looks to me like C# pressed into a syntax that is
closer to C++, but isn't really C++.

But you can use it as a glue to bind .NET classes and "real" C++. It's a
mess, but sometimes it's the only way .
It will never become "the single C++ ABI", considering that it's not based
on translating the C++ source code directly to native code.
Exactly. The CLI abstract machine doesn't provide efficient ways of
doing some things that C++ takes for granted.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top