what are C++ABI;s

[parag_paul]

what are ABI'sin C++
-Parag

 

[Puppet_Sock]

what are ABI'sin C++
-Parag

Do you mean this?

http://en.wikipedia.org/wiki/Application_binary_interface

They are at best peripheral to this news group, as they
are not part of the language standard. How the language
connects and communicates with the OS is not defined in
any great detail for C++.
Socks

 

[James Kanze]

On May 14, 10:16 am, "(e-mail address removed)" <[email protected]>
wrote:

Do you mean this?

They are at best peripheral to this news group, as they are
not part of the language standard. How the language connects
and communicates with the OS is not defined in any great
detail for C++.

They are and they aren't relevant to the newsgroup. There have
been efforts to define a portable ABI for C++, at least for
specific platforms. (I think there is one for the Itanium
architecture.) And it's a constant source of discussion: why
can't I link code compiled with Borland with code compiled with
Microsoft (which is possible for C)? In many ways, it's a
serious problem with C++ that the question doesn't have any
answers which would be really relevant here: that if I have a
third party library which I have to use, and it is compiled with
Sun CC, I can't use g++. (See the thread on binary
compatility.) It's an issue which all C++ programmers face at
one time or another.

 

[Juha Nieminen]

And it's a constant source of discussion: why
can't I link code compiled with Borland with code compiled with
Microsoft (which is possible for C)?

A standardized ABI would allow even more than that. For example, it
would allow linking object files created by compilers of different
languages into the binary (such as for example object files created by a
pascal compiler).

Btw, isn't the .NET framework some kind of attempt to do exactly that,
ie. being able to call libraries made in any language from another language?

 

[Fernando Gómez]

And it's a constant source of discussion: why

can't I link code compiled with Borland with code compiled with
Microsoft (which is possible for C)? In many ways, it's a
serious problem with C++ that the question doesn't have any
answers which would be really relevant here

Which is why I was so damn disappointed when I knew that the TR1
didn't even consider the ABIs. Truly a shame IMO.

Regards,
Fernando.

 

[Erik Wikström]

A standardized ABI would allow even more than that. For example, it
would allow linking object files created by compilers of different
languages into the binary (such as for example object files created by a
pascal compiler).

Btw, isn't the .NET framework some kind of attempt to do exactly that,
ie. being able to call libraries made in any language from another language?

Kind of, the idea behind .Net is that you "compile" code in different
languages into a standardised byte-code format (the Common Intermediate
Language), This allows you to link to any other module compiled to the
CIL. Unfortunately the CIL is quite high-level and many existing
languages (such as C++) can not be accurately translated to CIL which is
why you get .Net versions of those languages (like C++/CLI).

 

[James Kanze]

Which is why I was so damn disappointed when I knew that the TR1
didn't even consider the ABIs. Truly a shame IMO.

The reason is simple: any API must be platform specific (at
least given current technology). There's no way code that I
compile on my Sun Sparc can be made to run on a PC. Thus,
languages which don't depend on a virtual machine can't define
a standard API. For that matter, even languages like Java,
which do define one (through JVM), tend to consider it separate
from the language standard: the specification of the Java
language doesn't specify an API, and the specification of JVM
doesn't specify the language used to compile to it.

As has been frequently pointed out, JVM is actually a platform,
like Windows on a PC. And it is the platform which should
define the API (which should apply to all of the programming
languages on the platform). The current situation is that most
platforms do define an API, but without many of the elements
needed for C++. So each compiler extends the platform API in a
different way. If I use C or Fortran, I can link code compiled
with the Sun compiler with code compiled with the GNU compiler.
If I use C++ (or Ada, I think), I can't. The problem isn't with
the C++ or Ada language standard, but with Sun's standard for
Solaris.

 

[James Kanze]

A standardized ABI would allow even more than that. For
example, it would allow linking object files created by
compilers of different languages into the binary (such as for
example object files created by a pascal compiler).

Up to a point. The supported types still have to be more or
less the same: you won't be able to pass BCD from Cobol to C++,
nor a C++ class to C, and expect it to work right.

Btw, isn't the .NET framework some kind of attempt to do
exactly that, ie. being able to call libraries made in any
language from another language?

An API depends on the platform. I'm not too familiar with .NET,
but I think it's something along the lines of JVM: a "platform"
designed to be easily and efficiently emulated on a variety of
hardware platforms. (Unlike JVM, on the other hand, I think it
does try to take a number of different languages into
consideration.)

 

[Fernando Gómez]

The reason is simple: any API must be platform specific (at
least given current technology). There's no way code that I
compile on my Sun Sparc can be made to run on a PC. Thus,
languages which don't depend on a virtual machine can't define
a standard API. For that matter, even languages like Java,
which do define one (through JVM), tend to consider it separate
from the language standard: the specification of the Java
language doesn't specify an API, and the specification of JVM
doesn't specify the language used to compile to it.

As has been frequently pointed out, JVM is actually a platform,
like Windows on a PC. And it is the platform which should
define the API (which should apply to all of the programming
languages on the platform). The current situation is that most
platforms do define an API, but without many of the elements
needed for C++. So each compiler extends the platform API in a
different way. If I use C or Fortran, I can link code compiled
with the Sun compiler with code compiled with the GNU compiler.
If I use C++ (or Ada, I think), I can't. The problem isn't with
the C++ or Ada language standard, but with Sun's standard for
Solaris.

But AFAIK, C does define an ABI.

I don't actually notice what the API has to do with the ABI, or why an
ABI has to be plataform specific.

Regards,
Fernando.

 

[Ian Collins]

But AFAIK, C does define an ABI.

I don't actually notice what the API has to do with the ABI, or why an
ABI has to be plataform specific.

Where?

The ABI is defined by the platform, not the language.

 

[James Kanze]

But AFAIK, C does define an ABI.

Since when? C has the same problem as C++: it can't define an
ABI, since it has to work on different platforms.

I don't actually notice what the API has to do with the ABI,
or why an ABI has to be plataform specific.

Well, the ABI for C on a Sparc, under Solaris, says that the
first five arguments go into the registers o0-o4, at least if
they are int's or pointers. That's going to be a little bit
hard to implement on an Intel, which doesn't have as many
registers (and above all, doesn't manage them at all in the same
manner).

 

[Fernando Gómez]

Well, the ABI for C on a Sparc, under Solaris, says that the
first five arguments go into the registers o0-o4, at least if
they are int's or pointers. That's going to be a little bit
hard to implement on an Intel, which doesn't have as many
registers (and above all, doesn't manage them at all in the same
manner).

Ok, I think then that I had a wrong concept of an ABI. I thought it
was all about mangling and calling conventions.

 

[Tim H]

Ok, I think then that I had a wrong concept of an ABI. I thought it
was all about mangling and calling conventions.

It is. ABI has nothing to do with crossing platform boundaries. It's
a standard, well-defined way of doing things like name mangling,
calling conventions, argument passing, alignment, etc. It is usually
defined per hardware platform, and smart OSes follow it. So in the
end, an object file built by g++ can be linked with an object file
built by Sun CC, on the same platform. If you do it right, you can
link objects across languages on the same platform. If you're really
good you can link objects across OSes (e.g. SCO vs BSD vs Linux).

C++ does not have that. I can't even guarantee to be able to link
against objects from a different version of the same compiler!

Any arguments about linking sparc and x86 code are red herrings.

Tim

 

[Ian Collins]

It is. ABI has nothing to do with crossing platform boundaries. It's
a standard, well-defined way of doing things like name mangling,
calling conventions, argument passing, alignment, etc. It is usually
defined per hardware platform, and smart OSes follow it. So in the
end, an object file built by g++ can be linked with an object file
built by Sun CC, on the same platform.

Er, no, you can't. Or did you mean gcc and Sun cc?

C++ does not have that. I can't even guarantee to be able to link
against objects from a different version of the same compiler!

Ah, you appear to be contradicting your earlier statement here.

 

[Fernando Gómez]

It is. ABI has nothing to do with crossing platform boundaries. It's
a standard, well-defined way of doing things like name mangling,
calling conventions, argument passing, alignment, etc. It is usually
defined per hardware platform, and smart OSes follow it. So in the
end, an object file built by g++ can be linked with an object file
built by Sun CC, on the same platform. If you do it right, you can
link objects across languages on the same platform. If you're really
good you can link objects across OSes (e.g. SCO vs BSD vs Linux).

C++ does not have that. I can't even guarantee to be able to link
against objects from a different version of the same compiler!

Any arguments about linking sparc and x86 code are red herrings.

Tim

So, if we take away all the politics surrounding the standardization
process of C++, it'll be possible to define an ABI for C++, won't it?

 

[Ian Collins]

So, if we take away all the politics surrounding the standardization
process of C++, it'll be possible to define an ABI for C++, won't it?

No, reread James' reply up-thread. It would be possible to define an
ABI for a particular platform, but that's well beyond the scope of the
language standard.

 

[James Kanze]

Ok, I think then that I had a wrong concept of an ABI. I
thought it was all about mangling and calling conventions.

It's mainly about calling conventions. (Mangling is part of the
conventions, when it comes down to it.) Where the compiler puts
the arguments is part of the calling conventions.

It's also about ensuring that the called function can do
something with the arguments: things like class layout, and how
virtual functions are implemented, for example.

 

[James Kanze]

On May 16, 3:23 pm, Fernando Gómez <[email protected]>
wrote:

It is. ABI has nothing to do with crossing platform
boundaries. It's a standard, well-defined way of doing things
like name mangling, calling conventions, argument passing,
alignment, etc. It is usually defined per hardware platform,
and smart OSes follow it. So in the end, an object file built
by g++ can be linked with an object file built by Sun CC, on
the same platform.

Or could be, if that platform defined an ABI, and both compilers
respected it. In fact, there isn't a standard ABI defined for
Sparc, so you can't link an object file compiled by Sun CC with
one compiled by g++ on a Sparc.

An ABI can be more or less complete. As I mentionned upstream,
the *only* platform I know of which defines an ABI for C++ is
Intel's Itanium.

If you do it right, you can link objects across languages on
the same platform. If you're really good you can link objects
across OSes (e.g. SCO vs BSD vs Linux).

C++ does not have that. I can't even guarantee to be able to
link against objects from a different version of the same
compiler!

Any arguments about linking sparc and x86 code are red
herrings.

Except that that's what having the ABI as part of the language
standard would require.

 

[Rolf Magnus]

Ok, I think then that I had a wrong concept of an ABI. I thought it
was all about mangling and calling conventions.

And what did you think calling conventions are? The above (passing the first
n arguments in registers) just is a calling convention.

 

[Rolf Magnus]

A standardized ABI would allow even more than that. For example, it
would allow linking object files created by compilers of different
languages into the binary (such as for example object files created by a
pascal compiler).

ABIs usually are language specific, since different languages have different
features or at least implement them differently, so it's often not possible
to find a single ABI that fits all of a set of languages.

Btw, isn't the .NET framework some kind of attempt to do exactly that,
ie. being able to call libraries made in any language from another
language?

Yes, however, the languages need to be modified to fit into the .NET
framework. That's why there is a special .NET version of C++.