C++

Discussion in 'C++' started by chambu, Feb 23, 2008.

  1. chambu

    chambu Guest

    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
    chambu, Feb 23, 2008
    #1
    1. Advertising

  2. chambu

    James Kanze Guest

    On Feb 23, 5:28 am, chambu <> wrote:

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

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Feb 23, 2008
    #2
    1. Advertising

  3. James Kanze wrote:
    >> 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.


    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.
    Juha Nieminen, Feb 23, 2008
    #3
  4. chambu

    Rolf Magnus Guest

    Juha Nieminen wrote:

    > James Kanze wrote:
    >>> 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.

    >
    > 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.
    Rolf Magnus, Feb 23, 2008
    #4
  5. chambu

    Pete Becker Guest

    On 2008-02-23 07:14:51 -0500, Juha Nieminen <> said:

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

    --
    Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
    Standard C++ Library Extensions: a Tutorial and Reference
    (www.petebecker.com/tr1book)
    Pete Becker, Feb 23, 2008
    #5
  6. chambu

    Jeff Schwab Guest

    Rolf Magnus wrote:
    > Juha Nieminen wrote:

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


    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.
    Jeff Schwab, Feb 23, 2008
    #6
  7. chambu

    Rolf Magnus Guest

    Jeff Schwab wrote:

    > Rolf Magnus wrote:
    >> Juha Nieminen wrote:

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

    >
    > 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.
    Rolf Magnus, Feb 23, 2008
    #7
  8. chambu

    Rolf Magnus Guest

    Pete Becker wrote:

    > On 2008-02-23 07:14:51 -0500, Juha Nieminen <> said:
    >
    >>
    >> 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.


    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.
    Rolf Magnus, Feb 23, 2008
    #8
  9. Pete Becker wrote:
    > On 2008-02-23 07:14:51 -0500, Juha Nieminen <> said:
    >> 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.


    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.
    Juha Nieminen, Feb 23, 2008
    #9
  10. chambu

    Jeff Schwab Guest

    Rolf Magnus wrote:
    > Jeff Schwab wrote:
    >
    >> Rolf Magnus wrote:
    >>> Juha Nieminen wrote:

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

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


    Thanks for the link. Good to know!
    Jeff Schwab, Feb 23, 2008
    #10
  11. chambu

    Bo Persson Guest

    Juha Nieminen wrote:
    > Pete Becker wrote:
    >> On 2008-02-23 07:14:51 -0500, Juha Nieminen
    >> <> said:
    >>> 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.

    >
    > 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
    Bo Persson, Feb 23, 2008
    #11
  12. chambu

    Pete Becker Guest

    On 2008-02-23 09:56:14 -0500, Rolf Magnus <> said:

    > Pete Becker wrote:
    >
    >> On 2008-02-23 07:14:51 -0500, Juha Nieminen <> said:
    >>
    >>>
    >>> 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.

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

    --
    Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
    Standard C++ Library Extensions: a Tutorial and Reference
    (www.petebecker.com/tr1book)
    Pete Becker, Feb 23, 2008
    #12
  13. chambu

    Pete Becker Guest

    On 2008-02-23 10:31:42 -0500, Juha Nieminen <> said:

    > Pete Becker wrote:
    >> On 2008-02-23 07:14:51 -0500, Juha Nieminen <> said:
    >>> 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.

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

    --
    Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
    Standard C++ Library Extensions: a Tutorial and Reference
    (www.petebecker.com/tr1book)
    Pete Becker, Feb 23, 2008
    #13
  14. chambu

    James Kanze Guest

    On Feb 23, 1:14 pm, Juha Nieminen <> wrote:
    > James Kanze wrote:
    > >> 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.


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

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Feb 23, 2008
    #14
  15. chambu

    James Kanze Guest

    On Feb 23, 3:56 pm, Rolf Magnus <> wrote:
    > Pete Becker wrote:
    > > On 2008-02-23 07:14:51 -0500, Juha Nieminen
    > > <> said:


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


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

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


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

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Feb 23, 2008
    #15
  16. * 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

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Feb 24, 2008
    #16
  17. chambu

    Rolf Magnus Guest

    Alf P. Steinbach wrote:

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

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

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


    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.
    Rolf Magnus, Feb 24, 2008
    #17
  18. * Rolf Magnus:
    > Alf P. Steinbach wrote:
    >
    >> * James Kanze:
    >>> There is a standard ABI for one platform, I think.

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

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


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


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


    Cheers, & hth.,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Feb 24, 2008
    #18
  19. chambu

    James Kanze Guest

    On Feb 24, 6:50 am, "Alf P. Steinbach" <> wrote:
    > * James Kanze:
    > > There is a standard ABI for one platform, I think.


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

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


    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?)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Feb 24, 2008
    #19
  20. In message <fprp8f$jl2$02$-online.com>, Rolf Magnus
    <> writes
    >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 .
    >
    >> 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.
    >

    Exactly. The CLI abstract machine doesn't provide efficient ways of
    doing some things that C++ takes for granted.

    --
    Richard Herring
    Richard Herring, Feb 25, 2008
    #20
    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.

Share This Page