Thread: Mixing C And C++ Code

On a related note, you could read Stroustrup's essay on Learning Standard C++ as a New Language (PDF document).

Originally Posted by Dark Dude

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.

Originally Posted by laserlight

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

> 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

Originally Posted by anon

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.

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

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.

Originally Posted by phantomotap

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

Originally Posted by phantomotap

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.

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.