Mixing C And C++ Code

This is a discussion on Mixing C And C++ Code within the C++ Programming forums, part of the General Programming Boards category; I'm primarily a vanilla C programmer, so I never really thought about this before, but when programming in C++, should ...

  1. #1
    Registered User
    Join Date
    Sep 2006
    Posts
    27

    Mixing C And C++ Code

    I'm primarily a vanilla C programmer, so I never really thought about this before, but when programming in C++, should you attempt to remain as C++-only as possible? Or is the use of C functions in C++ perfectly ok?

    For example, I'm rather used to explicitly declaring my char arrays and using strcpy etc on them, as opposed to using the C++ strings library, and have much disdain against the inefficiency of the IOStream namespace compared to the C Standard IO functions >_>

    Anything I should note specifically?

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,968
    On a related note, you could read Stroustrup's essay on Learning Standard C++ as a New Language (PDF document).
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Dark Dude View Post
    I'm primarily a vanilla C programmer
    Me too, also just started C++.

    but when programming in C++, should you attempt to remain as C++-only as possible? Or is the use of C functions in C++ perfectly ok?
    If they compile and work I'm gonna say the choice is yours. The STL seems to make extensive use of C strings, so often they are necessary anyway.

    Quote Originally Posted by laserlight View Post
    On a related note, you could read Stroustrup's essay on Learning Standard C++ as a New Language (PDF document).
    Looks interesting -- esp. since he includes some examples of when a C++ function is more optimal than a C version of the same thing, and vice versa.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #4
    The larch
    Join Date
    May 2006
    Posts
    3,573
    C++ strings are quite a bit more convenient and do some serious grunt work from you. (Memory management, making sure you don't get buffer overflows, making sure the string is "null-terminated" etc)

    As to IO, one crucial difference is type safety. For example, it would be quite impossible or hard to use type unsafe parts of the C library in templates.

    The STL seems to make extensive use of C strings, so often they are necessary anyway.
    Where? I'd say the rest of the standard C++ libraries barely support C strings at all. You'd rather find that things don't work.

    May-be you've seen them used under the hood, e.g std::string might well take advantage of C string library in its implementation, but that's an implementation detail. C libraries have their place but that's normally for very low-level code to implement higher abstractions.
    Last edited by anon; 03-05-2010 at 10:00 AM.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  5. #5
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,335
    > and have much disdain against the inefficiency of the IOStream namespace compared to the C Standard IO functions
    Based on what?
    Some apocryphal tale from yester-year?

    Have you compared the "efficiency" of a std::string just working, compared to the weeks of debugging that say mis-allocating the amount of space for a char pointer, or running off the end of an array can cause?

    If you want to micro-optimise, why are you using ANY high level language?

    Also see:
    [32] How to mix C and C++, C++ FAQ Lite
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  6. #6
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by anon View Post
    Where? I'd say the rest of the standard C++ libraries barely support C strings at all. You'd rather find that things don't work.
    Perhaps I shouldn't have said "STL" -- just glancing at the prototypes for <iostream> derived classes reveals lots and lots of char* parameters. I suppose I meant "the C++ standard library"...I've noticed this because I'd rather use a string object too but often there is no choice when the parameter is one passed in to be set, eg. with the fstream getline().

    Vis, saftey, if the OP is already competent with C this shouldn't matter much.
    Last edited by MK27; 03-05-2010 at 10:20 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  7. #7
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    3,798
    Vis, saftey, if the OP is already competent with C this shouldn't matter much.
    Programmer competence is a poor excuse for better tools. (I'm only going to briefly mention that some of the best C programmers in the world have only managed to produce "safe" code by ignoring the C string handling routines.)

    I've noticed this because I'd rather use a string object too but often there is no choice when the parameter is one passed in to be set, eg. with the fstream getline().
    1): std::getline(std::istream &, std::string &);
    2): std::string::cstr();

    There are great reasons for this design. You can use `std::string' virtually everywhere. You just need to use the correct function. Use the first to read a line of input (with a potentially different delimiter.) Use the second to convert a `std::string' to a C style string for those few functions that do require them.

    [Edit]
    I got those numbers backwards. ^_^;
    [/Edit]

    Soma
    Last edited by phantomotap; 03-05-2010 at 10:30 AM.

  8. #8
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Well, yes, IO and string class need to work with C-style strings, if not because string literals are C-style strings. But the rest of the library just treats them as pointers like any other.

    Vis, saftey, if the OP is already competent with C this shouldn't matter much.
    It's still much more work, and still makes it much harder to use the services of the rest of the library.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  9. #9
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by phantomotap View Post
    1): std::getline(std::istream &, std::string &);
    Yeah, that probably is a better option, altho I was only intending to present an example. If y'all say it's uncommon, I'll take that to be true.

    Why isn't that "std::string::getline", to differentiate between that and "std::fstream::getline"?
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  10. #10
    Registered User
    Join Date
    Sep 2006
    Posts
    27
    Quote Originally Posted by Salem View Post
    > and have much disdain against the inefficiency of the IOStream namespace compared to the C Standard IO functions
    Based on what?
    Some apocryphal tale from yester-year?

    Have you compared the "efficiency" of a std::string just working, compared to the weeks of debugging that say mis-allocating the amount of space for a char pointer, or running off the end of an array can cause?
    Well, I more meant that if I so-much as #include <iostream>, my few-kilobytes executable suddenly booms to several-hundred-kilobytes in size. I have no idea why that is, tbh >.>


    @Rest: Thank you for the above replies, most particularly the essay, which opened my eyes a lot. Seems like I should just stick to (mostly) pure-C++, seeing as a lot of C code is needed to work as effectively as single-line C++ equivalents. I always hated reinventing the wheel every time I started a new project, so... thanks o_q

  11. #11
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    3,798
    Why isn't that "std::string::getline", to differentiate between that and "std::fstream::getline"?
    I submit that a string should not be able to "get" itself.

    The mechanical answer: there is no reason to bind (tightly couple) the design of `std::string' and `std::istream'. Using the public interface of both classes one can write `std::getline(std::istream &, std::string &)'. This is a superior design.*

    Soma

    * If your were to ask why `std::string' has so many other methods... I just don't know.

  12. #12
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    3,798
    Well, I more meant that if I so-much as #include <iostream>, my few-kilobytes executable suddenly booms to several-hundred-kilobytes in size.
    That depends on the platform, compiler, and standard library. If a few hundred kilobytes is a legitimate issue, seek out other options. (Using the now ancient "Golden Road" compiler for embedded devices, `iostream' is only about 3800 bytes.)

    Soma

  13. #13
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by phantomotap View Post
    The mechanical answer: there is no reason to bind (tightly couple) the design of `std::string' and `std::istream'. Using the public interface of both classes one can write `std::getline(std::istream &, std::string &)'. This is a superior design.*

    Soma

    * If your were to ask why `std::string' has so many other methods... I just don't know.
    Yeah, I guess std::getline is not really a conventional object method. I hadn't really noticed these kinds of functions do to the structure of this:

    C++ Reference

    Which groups everything under a library, and I have gotten to think of them as purely classes.

    Thanks.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  14. #14
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,335
    Remember, this is just ONE compiler, your mileage may vary:
    Code:
    $ g++ -static foo.cpp
    $ ls -l a.out 
    -rwxr-xr-x 1 forum forum 1260949 2010-03-05 17:53 a.out
    $ strip a.out 
    $ ls -l a.out 
    -rwxr-xr-x 1 forum forum 1029308 2010-03-05 17:54 a.out
    $ 
    $ gcc -static foo.c
    $ ls -l a.out 
    -rwxr-xr-x 1 forum forum 584420 2010-03-05 17:55 a.out
    $ strip a.out 
    $ ls -l a.out 
    -rwxr-xr-x 1 forum forum 521428 2010-03-05 17:55 a.out
    $ 
    $ g++ foo.cpp
    $ ls -l a.out 
    -rwxr-xr-x 1 forum forum 9787 2010-03-05 17:55 a.out
    $ gcc foo.c
    $ ls -l a.out 
    -rwxr-xr-x 1 forum forum 9143 2010-03-05 17:55 a.out
    There's a difference between static and dynamic linking.
    There's a difference in not having symbol tables.

    > Well, I more meant that if I so-much as #include <iostream>, my few-kilobytes executable suddenly booms to several-hundred-kilobytes in size.
    The benefit of C++ is in larger programs. Yes there is a big up-front hit, but you'll find that there are a lot of goodies to play with. The incremental cost of adding more functionality to your code (that uses the existing libraries) results in a much shallower gradient.

    C starts with a lot less. Every bit of functionality you add has to add the whole thing. The delta increment is more because you're writing more code (and debugging it, and testing it).

    With RAM and disks measured in GB, why stress over +/- 1MB?

    Customers don't care that it's 100K bigger.
    They WILL care if it has more bugs and is 3 months late!.

    If YOU still care at the end, then you can tinker with micro-optimisations with the foundation of a known working program to test against. If you add bugs at that stage, all you lost was the time to add the bugs.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21