A concern about mixing C and C++

Discussion in 'C Programming' started by ziman137, Jul 29, 2006.

  1. ziman137

    ziman137 Guest

    Hello all,

    I have a question and am seeking for some advice.

    I am currently working to implement an algorithmic library. Because
    the performance is the most important factor in later applications, I
    decide to write it in C instead of C++. However, I thought it might be
    convenient to use some C++ code at some misc places. I'm aware that, I
    could always use the C++ compiler to get it work.

    My concerns are:

    1) Would the way I mix C and C++ code have any potential drawbacks to
    the performance?
    2) Would the way I mix C and C++ code have any potential drawbacks for
    the future users to use the library?

    My intention for choosing C interface instead of C++ OOD is to gain the
    maximum performance as possible, yet I still like to use some C++
    coding features (e.g., "const", reference instead of pointers, ...).

    Thanks,

    Gary
    ziman137, Jul 29, 2006
    #1
    1. Advertising

  2. ziman137

    Ian Collins Guest

    ziman137 wrote:
    > Hello all,
    >
    > I have a question and am seeking for some advice.
    >
    > I am currently working to implement an algorithmic library. Because
    > the performance is the most important factor in later applications, I
    > decide to write it in C instead of C++.


    Why? The performance of a C++ version should be no worse than the C one
    and possibly better if you can make use of existing well tuned standard
    algorithms and containers. What did your profiling show?

    > However, I thought it might be
    > convenient to use some C++ code at some misc places. I'm aware that, I
    > could always use the C++ compiler to get it work.
    >

    You could, yes.

    > My concerns are:
    >
    > 1) Would the way I mix C and C++ code have any potential drawbacks to
    > the performance?


    None what so ever.

    > 2) Would the way I mix C and C++ code have any potential drawbacks for
    > the future users to use the library?
    >

    Yes, unless you release the source, if you expose any C++ interfaces you
    will run into all of the ABI incompatibility problems that plague C++
    libraries. You will also exclude C users from using you library. One
    compromise is to only expose a C interface.

    > My intention for choosing C interface instead of C++ OOD is to gain the
    > maximum performance as possible, yet I still like to use some C++
    > coding features (e.g., "const", reference instead of pointers, ...).
    >

    Performance has nothing to do with it, portability is the reason to
    stick with a C interface.

    --
    Ian Collins.
    Ian Collins, Jul 29, 2006
    #2
    1. Advertising

  3. ziman137

    Jack Klein Guest

    On 28 Jul 2006 22:28:52 -0700, "ziman137" <> wrote
    in comp.lang.c:

    > Hello all,
    >
    > I have a question and am seeking for some advice.


    Here's advice: don't ask here. As far as C is concerned, C++ is just
    one of many, many johnny-come-lately imitators that claim to improve
    and extend C.

    The C standard does not define an interface to any other language. Not
    at all. C++, on the other hand, defines a mechanism that is intended
    (but not guaranteed) to allow mixing code from a compatible C
    compiler.

    > I am currently working to implement an algorithmic library. Because
    > the performance is the most important factor in later applications, I
    > decide to write it in C instead of C++. However, I thought it might be
    > convenient to use some C++ code at some misc places. I'm aware that, I
    > could always use the C++ compiler to get it work.


    Absolutely astonishing. What proof do you have that C will provide
    better performance than C++? What trials have you run, and where are
    the timing comparison results?

    > My concerns are:
    >
    > 1) Would the way I mix C and C++ code have any potential drawbacks to
    > the performance?


    C does not define any way to mix C and C++.

    > 2) Would the way I mix C and C++ code have any potential drawbacks for
    > the future users to use the library?


    C does not define any way to mix C and C++.

    > My intention for choosing C interface instead of C++ OOD is to gain the
    > maximum performance as possible, yet I still like to use some C++
    > coding features (e.g., "const", reference instead of pointers, ...).


    But what evidence do you have that this choice will have any impact on
    performance?

    As for mixing C++ coding features such as "references" with C code,
    that's just plain impossible, since there are no such things as
    references in C.

    Here are some hints:

    If you want to know about mixing C++ and C, ask in a C++ newsgroup.

    If you want to know about mixing Java and C, ask in a Java group.

    If you want to know about...

    ....well, you're probably getting the point by now.

    C is far senior to many of the popular flavor of the month languages,
    and does not take any notice of their existence. And it may well
    outlast many or all of them, as it has outlasted at least the original
    Visual Basic for Windows.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Jul 29, 2006
    #3
  4. ziman137

    Malcolm Guest

    "ziman137" <> wrote in message
    > Hello all,
    >
    > I have a question and am seeking for some advice.
    >
    > I am currently working to implement an algorithmic library. Because
    > the performance is the most important factor in later applications, I
    > decide to write it in C instead of C++. However, I thought it might be
    > convenient to use some C++ code at some misc places. I'm aware that, I
    > could always use the C++ compiler to get it work.
    >
    > 1) Would the way I mix C and C++ code have any potential drawbacks to
    > the performance?
    >

    Potentially yes. It must be compiled with a C++ compiler, and it is not
    impossible that the C++ compiler on a given system is inferior to the C
    compiler. However it is not very likely, often they share substantially the
    same code.
    If you use C++ constructs in your code you will find them harder to optimise
    than the C constructs, because C++ is designed to present a nice interface
    to the programmer rather than to expose basic processor operations. However
    you are probably aware of that already.
    --
    www.personal.leeds.ac.uk/~bgy1mm
    freeware games to download.
    Malcolm, Jul 29, 2006
    #4
  5. ziman137

    Ian Collins Guest

    Malcolm wrote:
    > "ziman137" <> wrote in message
    >
    >>Hello all,
    >>
    >>I have a question and am seeking for some advice.
    >>
    >>I am currently working to implement an algorithmic library. Because
    >>the performance is the most important factor in later applications, I
    >>decide to write it in C instead of C++. However, I thought it might be
    >>convenient to use some C++ code at some misc places. I'm aware that, I
    >>could always use the C++ compiler to get it work.
    >>
    >>1) Would the way I mix C and C++ code have any potential drawbacks to
    >>the performance?
    >>

    >
    > Potentially yes. It must be compiled with a C++ compiler, and it is not
    > impossible that the C++ compiler on a given system is inferior to the C
    > compiler. However it is not very likely, often they share substantially the
    > same code.
    > If you use C++ constructs in your code you will find them harder to optimise
    > than the C constructs, because C++ is designed to present a nice interface
    > to the programmer rather than to expose basic processor operations. However
    > you are probably aware of that already.


    Eh? C++ can wrap basic processor operations in a higher level
    abstraction, but it can still expose then in the same way C does.

    --
    Ian Collins.
    Ian Collins, Jul 29, 2006
    #5
  6. ziman137

    jacob navia Guest

    Jack Klein a écrit :
    >
    > Absolutely astonishing. What proof do you have that C will provide
    > better performance than C++? What trials have you run, and where are
    > the timing comparison results?
    >


    We discussed this with an example on Saturday May 6th.
    The topic of the thread was

    strtok behavior with multiple consecutive delimiters

    and C++ came at best as twice as slow as C.

    jacob

    P.S. this is NOT a "proof" of course. There may be situations
    where C++ templates outperform assembly language, and there will
    be situations when lisp outperforms C and C++.
    jacob navia, Jul 29, 2006
    #6
  7. jacob navia said:

    > There may be situations
    > where C++ templates outperform assembly language,


    Jacob's talking through his hat again. His claim is easily disproved. All we
    have to do is tell the compiler to generate assembly language from the C++
    template code. We now have assembly language that performs exactly as well
    as the C++ template code. And, given an experienced assembly language
    programmer (to match the experienced C++ programmer who produces such
    astoundingly quick code), we can almost certainly find an optimisation,
    however trivial, that will make the assembly language version at least a
    little faster than the C++ template version from which it was generated.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Jul 29, 2006
    #7
  8. ziman137

    Malcolm Guest

    "Ian Collins" <> wrote in message
    news:...
    > Malcolm wrote:
    >> "ziman137" <> wrote in message
    >>
    >>>Hello all,
    >>>
    >>>I have a question and am seeking for some advice.
    >>>
    >>>I am currently working to implement an algorithmic library. Because
    >>>the performance is the most important factor in later applications, I
    >>>decide to write it in C instead of C++. However, I thought it might be
    >>>convenient to use some C++ code at some misc places. I'm aware that, I
    >>>could always use the C++ compiler to get it work.
    >>>
    >>>1) Would the way I mix C and C++ code have any potential drawbacks to
    >>>the performance?
    >>>

    >>
    >> Potentially yes. It must be compiled with a C++ compiler, and it is not
    >> impossible that the C++ compiler on a given system is inferior to the C
    >> compiler. However it is not very likely, often they share substantially
    >> the
    >> same code.
    >> If you use C++ constructs in your code you will find them harder to
    >> optimise
    >> than the C constructs, because C++ is designed to present a nice
    >> interface
    >> to the programmer rather than to expose basic processor operations.
    >> However
    >> you are probably aware of that already.

    >
    > Eh? C++ can wrap basic processor operations in a higher level
    > abstraction, but it can still expose then in the same way C does.
    >

    Can, yes. But Bjarne Strousup believes that malloc(), for example, should
    not be used in new C++ code.
    Modern C++ using the standard library will have set of abstracted interfaces
    to basic structures. They work well and might even be more efficient than
    hand-coded similar C structures. However it is not possible for the
    programmer to exert fine control over them. So for instance if he wants to
    interate over an array, he will use the vector class iterator. This may be a
    bare pointer, but probably it carries some run time checks with it to
    protect the pointer from going out of bounds. Generally a good thing, but
    harder to optimise.
    --
    www.personal.leeds.ac.uk/~bgy1mm
    freeware games to download.
    ..
    Malcolm, Jul 29, 2006
    #8
  9. ziman137

    Guest

    ziman137 wrote:
    > Hello all,
    >
    > I have a question and am seeking for some advice.
    >
    > I am currently working to implement an algorithmic library. Because
    > the performance is the most important factor in later applications, I
    > decide to write it in C instead of C++. However, I thought it might be
    > convenient to use some C++ code at some misc places. I'm aware that, I
    > could always use the C++ compiler to get it work.
    >
    > My concerns are:
    >
    > 1) Would the way I mix C and C++ code have any potential drawbacks to
    > the performance?
    > 2) Would the way I mix C and C++ code have any potential drawbacks for
    > the future users to use the library?
    >
    > My intention for choosing C interface instead of C++ OOD is to gain the
    > maximum performance as possible, yet I still like to use some C++
    > coding features (e.g., "const", reference instead of pointers, ...).
    >
    > Thanks,
    >
    > Gary


    Hello Gary,

    I've recently gone through the process of deciding to use C or C++ for
    a high performace "algorithmic" library.

    As far as raw performance goes, you'll find benchmarks throughout the
    net going both ways. Since C++ is more popular, you'll see more claming
    C++ is as fast/faster. At the end of the day it seems that if you just
    want to generically compare performance of C vs C++ you'll arrive at
    the answer "it depends on how well you know and understand the
    language".

    I'm much more familiar with C. I know how it works, I know how to make
    nice API's and modular code with it and I know how to avoid some issues
    that might degrade performance. But these will apply to both C++ and C
    for the most part since C++ is a superset, things like use narrow
    ranged case statements, avoid deeply nested if statements, using the
    smallest integer types isnt always beneficial etc etc.

    However, I don't know much about how templates are internally handled,
    I don't know how multiple inheritance works and I have only a small
    notion of how virtual functions work. So the problem for me is that I
    don't know how to write efficient C++ code because I don't fully
    understand how it all works. Not only that but because I've used C
    since forever, I don't have much intuition when it comes to OO
    application design. So I stick with C. Call me lazy ;)

    So my advice, either stick with what you know or learn the performance
    pitfalls.

    Cheers,
    Chris

    P.S. as for combining C++ and C in a scientific libray, check out
    openCV. It's a computer vision API written like C but with both a C and
    C++ interface.
    , Jul 29, 2006
    #9
  10. Malcolm posted:

    > Modern C++ using the standard library will have set of abstracted
    > interfaces to basic structures. They work well and might even be more
    > efficient than hand-coded similar C structures. However it is not
    > possible for the programmer to exert fine control over them. So for
    > instance if he wants to interate over an array, he will use the vector
    > class iterator. This may be a bare pointer, but probably it carries some
    > run time checks with it to protect the pointer from going out of bounds.
    > Generally a good thing, but harder to optimise.



    There is nothing stopping a C++ programmer from simply using the C features,
    i.e. normal arrays, rather than std::vector.

    I myself write C++ code with a heavy bias toward C.

    --

    Frederick Gotham
    Frederick Gotham, Jul 29, 2006
    #10
  11. ziman137

    Ian Collins Guest

    Malcolm wrote:
    > "Ian Collins" <> wrote in message
    > news:...
    >
    >>Malcolm wrote:
    >>
    >>>"ziman137" <> wrote in message
    >>>
    >>>>1) Would the way I mix C and C++ code have any potential drawbacks to
    >>>>the performance?
    >>>>
    >>>
    >>>Potentially yes. It must be compiled with a C++ compiler, and it is not
    >>>impossible that the C++ compiler on a given system is inferior to the C
    >>>compiler. However it is not very likely, often they share substantially
    >>>the
    >>>same code.
    >>>If you use C++ constructs in your code you will find them harder to
    >>>optimise
    >>>than the C constructs, because C++ is designed to present a nice
    >>>interface
    >>>to the programmer rather than to expose basic processor operations.
    >>>However
    >>>you are probably aware of that already.

    >>
    >>Eh? C++ can wrap basic processor operations in a higher level
    >>abstraction, but it can still expose then in the same way C does.
    >>

    >
    > Can, yes. But Bjarne Strousup believes that malloc(), for example, should
    > not be used in new C++ code.

    Correct, but you can provide your own version of new/delete, which puts
    the developer back in the driver's seat.

    > Modern C++ using the standard library will have set of abstracted interfaces
    > to basic structures. They work well and might even be more efficient than
    > hand-coded similar C structures. However it is not possible for the
    > programmer to exert fine control over them. So for instance if he wants to
    > interate over an array, he will use the vector class iterator. This may be a
    > bare pointer, but probably it carries some run time checks with it to
    > protect the pointer from going out of bounds. Generally a good thing, but
    > harder to optimise.


    He probably would, but if push came to shove, he could take the address
    of the first element and use a plain pointer. Iterators tend to be well
    optimised. Some implementations use raw pointers and none are required
    to do any bounds checking, although this may be available as an
    extension for testing.

    C++ gives the developer a choice between the C way of doing something
    and the C++ way.

    --
    Ian Collins.
    Ian Collins, Jul 29, 2006
    #11
  12. Richard Heathfield <> writes:
    > jacob navia said:
    >
    >> There may be situations
    >> where C++ templates outperform assembly language,

    >
    > Jacob's talking through his hat again. His claim is easily disproved. All we
    > have to do is tell the compiler to generate assembly language from the C++
    > template code. We now have assembly language that performs exactly as well
    > as the C++ template code. And, given an experienced assembly language
    > programmer (to match the experienced C++ programmer who produces such
    > astoundingly quick code), we can almost certainly find an optimisation,
    > however trivial, that will make the assembly language version at least a
    > little faster than the C++ template version from which it was generated.


    On the other hand, for any language at a higher level than assembler,
    the compiler may find opportunities for optimizations that someone
    creating hand-written assembler wouldn't find, or would choose not to
    use.

    For example, if I'm writing low-level code that I expect to be
    maintained, I'm not likely to perform a pervasive optimization that
    works only if an array size is a power of 2.

    A skilled assembly language programmer is likely to be much smarter
    than an optimizing compiler, but an optimizer has a different set of
    tradeoffs to consider. A programmer will perform optimizations over
    time as he's working on a piece of code; an optimizing compiler will
    redo all its work from scratch every time it's invoked.

    Yes, you can use an optimizing compiler as a way to generate assembly
    language -- but that argument doesn't apply to hand-written assembly
    language.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jul 29, 2006
    #12
  13. Keith Thompson said:

    <snip>
    >
    > On the other hand, for any language at a higher level than assembler,
    > the compiler may find opportunities for optimizations that someone
    > creating hand-written assembler wouldn't find, or would choose not to
    > use.


    Sure, but perhaps you missed my point, which is that the /starting point/
    for the assembly language programmer would be the super-efficient C++
    template code, expressed in assembly language form. Given that starting
    base, (a) it's bound to be as fast as the C++ template code, because it's
    the same code that the C++ template code is compiled to - which is in
    itself sufficient to destroy Mr Navia's point, and (b) it would be quite
    surprising if the skilled assembly language programmer couldn't find /one/
    hand-optimisation to make the asm form just a tiny smidgenette faster.

    <snip>

    > Yes, you can use an optimizing compiler as a way to generate assembly
    > language -- but that argument doesn't apply to hand-written assembly
    > language.


    It does if the starting point for the handwriting is the generated code.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Jul 29, 2006
    #13
  14. ziman137

    Ian Collins Guest

    Richard Heathfield wrote:
    > Keith Thompson said:
    >
    > <snip>
    >
    >>On the other hand, for any language at a higher level than assembler,
    >>the compiler may find opportunities for optimizations that someone
    >>creating hand-written assembler wouldn't find, or would choose not to
    >>use.

    >
    >
    > Sure, but perhaps you missed my point, which is that the /starting point/
    > for the assembly language programmer would be the super-efficient C++
    > template code, expressed in assembly language form. Given that starting
    > base, (a) it's bound to be as fast as the C++ template code, because it's
    > the same code that the C++ template code is compiled to - which is in
    > itself sufficient to destroy Mr Navia's point, and (b) it would be quite
    > surprising if the skilled assembly language programmer couldn't find /one/
    > hand-optimisation to make the asm form just a tiny smidgenette faster.
    >

    I don't know if you do this, but I often find I can obtain more
    productive optimisations by using the generated assembly language to
    tune the high level language code rather than hand editing the assembly.

    One area optimising compilers have an edge and will continue to improve
    is global optimisations, there is only so much code a human can retain
    in working memory. We can often do better with micro-optimisations, but
    the compiler is better equipped to see the big picture.

    --
    Ian Collins.
    Ian Collins, Jul 29, 2006
    #14
  15. Richard Heathfield <> writes:
    > Keith Thompson said:
    >
    > <snip>
    >>
    >> On the other hand, for any language at a higher level than assembler,
    >> the compiler may find opportunities for optimizations that someone
    >> creating hand-written assembler wouldn't find, or would choose not to
    >> use.

    >
    > Sure, but perhaps you missed my point, which is that the /starting point/
    > for the assembly language programmer would be the super-efficient C++
    > template code, expressed in assembly language form. Given that starting
    > base, (a) it's bound to be as fast as the C++ template code, because it's
    > the same code that the C++ template code is compiled to - which is in
    > itself sufficient to destroy Mr Navia's point, and (b) it would be quite
    > surprising if the skilled assembly language programmer couldn't find /one/
    > hand-optimisation to make the asm form just a tiny smidgenette faster.
    >
    > <snip>
    >
    >> Yes, you can use an optimizing compiler as a way to generate assembly
    >> language -- but that argument doesn't apply to hand-written assembly
    >> language.

    >
    > It does if the starting point for the handwriting is the generated code.


    If the optimizing compiler generates code that pervasively depends on
    some semantically trivial aspect of the high-level source, the
    generated assembly won't be a good basis for maintenance. For
    example, a compiler might generate radically different code if an
    array size is a power of two than if it isn't, even if there's only,
    say, a 1% advantage. If you change the array declaration, the
    compiler will happily re-write the entire application when you
    recompile it. A sane assembly language programmer would probably
    avoid such an optimization if it would hurt maintainability that much.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jul 30, 2006
    #15
  16. ziman137

    Ark Guest

    Richard Heathfield wrote:
    > Keith Thompson said:
    >
    > <snip>
    >> On the other hand, for any language at a higher level than assembler,
    >> the compiler may find opportunities for optimizations that someone
    >> creating hand-written assembler wouldn't find, or would choose not to
    >> use.

    >
    > Sure, but perhaps you missed my point, which is that the /starting point/
    > for the assembly language programmer would be the super-efficient C++
    > template code, expressed in assembly language form. Given that starting
    > base, (a) it's bound to be as fast as the C++ template code, because it's
    > the same code that the C++ template code is compiled to - which is in
    > itself sufficient to destroy Mr Navia's point, and (b) it would be quite
    > surprising if the skilled assembly language programmer couldn't find /one/
    > hand-optimisation to make the asm form just a tiny smidgenette faster.
    >
    > <snip>
    >
    >> Yes, you can use an optimizing compiler as a way to generate assembly
    >> language -- but that argument doesn't apply to hand-written assembly
    >> language.

    >
    > It does if the starting point for the handwriting is the generated code.
    >

    The real point is that the compiler-generated assembly code ain't
    necessarily a good starting point, for it perhaps takes advantages of
    accidental coincidences of data that a human programmer will not indulge
    in. So (maintainable) assembly code _may_ be worse than
    compiler-generated, the point Keith Thompson had made pretty clear.
    Example:
    The line
    int x = NUMBER;
    is compiled (for ARM) differently depending on
    #define NUMBER 1
    #define NUMBER 257
    #define NUMBER 0x101010101
    A human would stick to a single implementation.
    Ark, Jul 30, 2006
    #16
  17. ziman137

    Ark Guest

    Ian Collins wrote:
    > Malcolm wrote:
    >> "Ian Collins" <> wrote in message
    >> news:...
    >>
    >>> Malcolm wrote:
    >>>
    >>>> "ziman137" <> wrote in message
    >>>>
    >>>>> 1) Would the way I mix C and C++ code have any potential drawbacks to
    >>>>> the performance?
    >>>>>
    >>>> Potentially yes. It must be compiled with a C++ compiler, and it is not
    >>>> impossible that the C++ compiler on a given system is inferior to the C
    >>>> compiler. However it is not very likely, often they share substantially
    >>>> the
    >>>> same code.
    >>>> If you use C++ constructs in your code you will find them harder to
    >>>> optimise
    >>>> than the C constructs, because C++ is designed to present a nice
    >>>> interface
    >>>> to the programmer rather than to expose basic processor operations.
    >>>> However
    >>>> you are probably aware of that already.
    >>> Eh? C++ can wrap basic processor operations in a higher level
    >>> abstraction, but it can still expose then in the same way C does.
    >>>

    >> Can, yes. But Bjarne Strousup believes that malloc(), for example, should
    >> not be used in new C++ code.

    > Correct, but you can provide your own version of new/delete, which puts
    > the developer back in the driver's seat.
    >
    >> Modern C++ using the standard library will have set of abstracted interfaces
    >> to basic structures. They work well and might even be more efficient than
    >> hand-coded similar C structures. However it is not possible for the
    >> programmer to exert fine control over them. So for instance if he wants to
    >> interate over an array, he will use the vector class iterator. This may be a
    >> bare pointer, but probably it carries some run time checks with it to
    >> protect the pointer from going out of bounds. Generally a good thing, but
    >> harder to optimise.

    >
    > He probably would, but if push came to shove, he could take the address
    > of the first element and use a plain pointer. Iterators tend to be well
    > optimised. Some implementations use raw pointers and none are required
    > to do any bounds checking, although this may be available as an
    > extension for testing.
    >
    > C++ gives the developer a choice between the C way of doing something
    > and the C++ way.
    >

    Ehmmm... please help me here: I am not a C++ guy.
    AFAIK, C++ does not allow all the C way (example: tentative declarations).
    Then, if I write C-style in C++, at the very minimum the C++ compiler
    doesn't know e.g. about any exceptions that may be thrown in a function
    I call and which is in a different translation unit. So it just has to
    bring in the heavy machinery in just in case. Am I missing something?
    Ark, Jul 30, 2006
    #17
  18. ziman137

    Ian Collins Guest

    Ark wrote:
    > Ian Collins wrote:
    >
    >> C++ gives the developer a choice between the C way of doing something
    >> and the C++ way.
    >>

    > Ehmmm... please help me here: I am not a C++ guy.
    > AFAIK, C++ does not allow all the C way (example: tentative declarations).
    > Then, if I write C-style in C++, at the very minimum the C++ compiler
    > doesn't know e.g. about any exceptions that may be thrown in a function
    > I call and which is in a different translation unit. So it just has to
    > bring in the heavy machinery in just in case. Am I missing something?


    If my understanding of tentative declarations is correct, they are
    synonymous with forward declarations in C++ due to the differing use of
    'struct' in a declaration, that is:

    struct X;

    forward declares the type X.

    The compiler doesn't have to bother with unexpected exceptions when
    compiling idiomatic C code, any unhandled exception can be caught by
    whatever calls main().

    As a trivial example, on my platform the following generated essentially
    the same code when compiled as C or C++:

    extern int fn(void);
    extern void fn1(int);

    typedef struct { int n; } X;

    int main(void)
    {
    X x;

    x.n = fn();

    fn1( x.n );
    }

    --
    Ian Collins.
    Ian Collins, Jul 30, 2006
    #18
  19. ziman137

    Ark Guest

    Ian Collins wrote:
    > Ark wrote:
    >> Ian Collins wrote:
    >>
    >>> C++ gives the developer a choice between the C way of doing something
    >>> and the C++ way.
    >>>

    >> Ehmmm... please help me here: I am not a C++ guy.
    >> AFAIK, C++ does not allow all the C way (example: tentative declarations).
    >> Then, if I write C-style in C++, at the very minimum the C++ compiler
    >> doesn't know e.g. about any exceptions that may be thrown in a function
    >> I call and which is in a different translation unit. So it just has to
    >> bring in the heavy machinery in just in case. Am I missing something?

    >
    > If my understanding of tentative declarations is correct, they are
    > synonymous with forward declarations in C++ due to the differing use of
    > 'struct' in a declaration, that is:
    >
    > struct X;
    >
    > forward declares the type X.
    >
    > The compiler doesn't have to bother with unexpected exceptions when
    > compiling idiomatic C code, any unhandled exception can be caught by
    > whatever calls main().
    >
    > As a trivial example, on my platform the following generated essentially
    > the same code when compiled as C or C++:
    >
    > extern int fn(void);
    > extern void fn1(int);
    >
    > typedef struct { int n; } X;
    >
    > int main(void)
    > {
    > X x;
    >
    > x.n = fn();
    >
    > fn1( x.n );
    > }
    >

    1. Tentative declarations of variables are (in C) indistinguishable from
    definitions until the end of the translation unit; they AFAIK expressly
    prohibited in C++. E.g., a (const) circular data structure like
    typedef struct X {int x, const struct X *next} X;
    const X x;
    const X y;
    const X z = {5, &x};
    const X y = {6, &z};
    const X x = {7, &y};
    is a valid C but not C++.
    2. Interesting example; just curious what the differences are and
    whether it matters that your function is called main, not, say, foo.
    Ark, Jul 30, 2006
    #19
  20. ziman137

    Ian Collins Guest

    Ark wrote:
    > Ian Collins wrote:
    >
    >> Ark wrote:
    >>
    >>> Ian Collins wrote:
    >>>
    >>>> C++ gives the developer a choice between the C way of doing something
    >>>> and the C++ way.
    >>>>
    >>> Ehmmm... please help me here: I am not a C++ guy.
    >>> AFAIK, C++ does not allow all the C way (example: tentative
    >>> declarations).
    >>> Then, if I write C-style in C++, at the very minimum the C++ compiler
    >>> doesn't know e.g. about any exceptions that may be thrown in a function
    >>> I call and which is in a different translation unit. So it just has to
    >>> bring in the heavy machinery in just in case. Am I missing something?

    >>
    >>
    >> If my understanding of tentative declarations is correct, they are
    >> synonymous with forward declarations in C++ due to the differing use of
    >> 'struct' in a declaration, that is:
    >>
    >> struct X;
    >>
    >> forward declares the type X.
    >>
    >> The compiler doesn't have to bother with unexpected exceptions when
    >> compiling idiomatic C code, any unhandled exception can be caught by
    >> whatever calls main().
    >>
    >> As a trivial example, on my platform the following generated essentially
    >> the same code when compiled as C or C++:
    >>
    >> extern int fn(void);
    >> extern void fn1(int);
    >>
    >> typedef struct { int n; } X;
    >>
    >> int main(void)
    >> {
    >> X x;
    >>
    >> x.n = fn();
    >>
    >> fn1( x.n );
    >> }
    >>

    > 1. Tentative declarations of variables are (in C) indistinguishable from
    > definitions until the end of the translation unit; they AFAIK expressly
    > prohibited in C++. E.g., a (const) circular data structure like
    > typedef struct X {int x, const struct X *next} X;


    typedef struct X {int x; const struct X *next;} X;

    Is valid C but not C++.

    typedef struct X {int x; const X *next;} X;

    Is valid C++ but not C.

    typedef struct X_t {int x; const struct X_t *next;} X;

    Is valid C++ and C.

    > const X x;
    > const X y;
    > const X z = {5, &x};
    > const X y = {6, &z};
    > const X x = {7, &y};
    > is a valid C but not C++.


    Correct , C++ prohibits uninitialised consts. Easily fixed for both thus:

    extern const X x;
    extern const X y;
    const X z = {5, &x};
    const X y = {6, &z};
    const X x = {7, &y};

    > 2. Interesting example; just curious what the differences are and
    > whether it matters that your function is called main, not, say, foo.


    The C++ compiler pushed one extra register on the stack. The function
    name does not make any difference.

    --
    Ian Collins.
    Ian Collins, Jul 30, 2006
    #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.
Similar Threads
  1. Kenneth Myhra
    Replies:
    2
    Views:
    403
    Kenneth Myhra
    Feb 16, 2004
  2. David Wilding
    Replies:
    6
    Views:
    401
    Whitecrest
    Apr 3, 2004
  3. Neil Zanella
    Replies:
    49
    Views:
    1,008
    Flash Gordon
    Feb 17, 2004
  4. Replies:
    1
    Views:
    376
  5. ziman137
    Replies:
    6
    Views:
    381
    Jerry Coffin
    Jul 29, 2006
Loading...

Share This Page