acceptable to mix C/C++?

L

Lindon

I've been bouncing back between my studies in C/C++ and have found
that I like parts of both languages... I find that pointer arithmetics
and arrays in C come extremely naturally to me, yet I can't get passed
the fact that C structures don't even compare to C++ classes (no
constructors, no member functions, of course no inheritance), there's
no function overloading, and the good GUI tools (and other library)
seem to be all for C++. But I don't really want to move to C++ and
use the iostreams instead of the stdio, or vectors and strings instead
of arrays and char*'s, (although I do find template/generic
programming interesting, I've decided to learn it as if it were
another language and treat it as such because using arrays and low
level C with it would be self defeating).

So my quesiton: is it acceptable to, say, have a char* class member
instead of a string? using MyClass* instead of a vector<MyClass>?
Writing C with structures that derive from other structures? Sneaking
in a const instead of a #define in a C prog?
And would mixing the two be a bad thing for larger programs?
The fact is that modern c++ compilers don't seem to care if I mix and
match so its rather tempting...
thanks, insightful advice would be appreciated
lin
 
C

crashnburn

Hi there,

I've been bouncing back between my studies in C/C++ and have found
that I like parts of both languages... I find that pointer arithmetics
and arrays in C come extremely naturally to me, yet I can't get passed
the fact that C structures don't even compare to C++ classes (no
constructors, no member functions, of course no inheritance), there's
no function overloading, and the good GUI tools (and other library)
seem to be all for C++. But I don't really want to move to C++ and
use the iostreams instead of the stdio, or vectors and strings instead
of arrays and char*'s, (although I do find template/generic
programming interesting, I've decided to learn it as if it were
another language and treat it as such because using arrays and low
level C with it would be self defeating).

If you don't want to move to iostream, then simply don't. You can still
use stdio, but use an #include <cstdio> (the latest ANSI C++ - I guess not
all compilers support it yet, so be warned that cstdio header may not
exist).
So my quesiton: is it acceptable to, say, have a char* class member
instead of a string? using MyClass* instead of a vector<MyClass>?

It's perfectly acceptable to use have a char * instead of a string.
Anyway, I wouldn't do that, since the std::string class is easier to use
than char * when we're using strings. char * is more useful for pointer
arithmetic operations. As far as the vector is concerned, I can't tell you
anything about it, since I didn't know that reserved word.
Writing C with structures that derive from other structures? Sneaking
in a const instead of a #define in a C prog?
And would mixing the two be a bad thing for larger programs?

Your are supposed to use both classes and structures when each one is
need. A struct can be a parameter to a setDate function of a class, for
example. We just don't set it directly, using normal attribution to filter
the number of days of a month and the month number for example.

It's all right to use both #define and const, but keep in mind that
#defined "constants" will be replaced by their real value during
compiling. What I mean is that:

#define PI 3.14
if (PI == 3.14) blah

if the same as:

if (3.14 == 3.14) blah

after the program is compiled (you can think of it as after being
"converted to assembly", if you know what I mean).

Now const. const reserves space in the .data section in memory (the
#defined values too, but so does a string). Anyway, I usually use const
when I want to do something like using a char* as a parameter without
altering it. Google a bit more about const, since I guess this isn't
accurate info.
The fact is that modern c++ compilers don't seem to care if I mix and
match so its rather tempting...
thanks, insightful advice would be appreciated
lin

Regards
(and sorry for the long text)
 
B

bd

I've been bouncing back between my studies in C/C++ and have found
that I like parts of both languages...

[snip]

C++ is off-topic in comp.lang.c - we only discuss pure C here. Followups
set.
 
M

Malcolm

Lindon said:
I've been bouncing back between my studies in C/C++ and have found
that I like parts of both languages...

So my quesiton: is it acceptable to, say, have a char* class member
instead of a string? using MyClass* instead of a vector<MyClass>?
In the world of games programming, at least, it is extremely common to find
programs written in a mixture of procedural, C style and object-oriented C++
style code.

In my opinion this is a bad thing - it makes code harder to understand and
to maintain, and it isn't logical. Also, you don't get a lot of the benefits
of C++ unless you use the whole of the language. A C++ constructor cannot
fail, for instance, unless it throws an exception. However it is extremely
common to find C++ code which uses constructors but avoids the
exception-handling mechanism.

C is the language that uses pointers to access memory directly. In C++ you
should normally use either a reference or a container class where in C you
would use a pointer. This gives you a lot more safety at the cost of a
slight speed penalty, considerable extra complexity in the compiler, and
loss of an intuitive feel for what is happening at machine level.

So no, it is not generally a good idea to have a char * in a C++ class
definition - you should use a string instead, and you should use a vector
for an array of MyClasses. This means that it is very hard to forget to
destroy the objects properly, and that you will have bounds checking. Also
you can use C++ library functions that work on strings, or on containers.
 
C

Cy Edmunds

Lindon said:
I've been bouncing back between my studies in C/C++ and have found
that I like parts of both languages... I find that pointer arithmetics
and arrays in C come extremely naturally to me, yet I can't get passed
the fact that C structures don't even compare to C++ classes (no
constructors, no member functions, of course no inheritance), there's
no function overloading, and the good GUI tools (and other library)
seem to be all for C++. But I don't really want to move to C++ and
use the iostreams instead of the stdio, or vectors and strings instead
of arrays and char*'s, (although I do find template/generic
programming interesting, I've decided to learn it as if it were
another language and treat it as such because using arrays and low
level C with it would be self defeating).

So my quesiton: is it acceptable to, say, have a char* class member
instead of a string? using MyClass* instead of a vector<MyClass>?
Writing C with structures that derive from other structures? Sneaking
in a const instead of a #define in a C prog?
And would mixing the two be a bad thing for larger programs?
The fact is that modern c++ compilers don't seem to care if I mix and
match so its rather tempting...
thanks, insightful advice would be appreciated
lin

Sure you can mix the two. But IMHO you are really missing the boat if you
don't use std::vector and std::string. Let me show you an example:

class Disaster
{
private:
char *m_cstring;
public:
Disaster(int n) : m_cstring(new char[n]) {m_string[0] = '\0';}
~Disaster() {delete [] m_c_string;}
char *cstring() {return m_cstring;}
};

That may look OK but if you do the following:

Disaster d1(100);
Disaster d2 = d1;

you will eventually delete the same pointer twice -- a serious error. You
need to add a special copy constructor and an assignment operator to
Disaster to avoid these problems, and that is a tedious and somewhat tricky
business.

But:

class NoProblem
{
private:
std::string m_astring;
public:
NoProblem(int n) : m_astring(n) {}
std::string &astring() {return m_astring;}
};

No destructor, copy constructor, or assignment operator. std::string takes
care of all those things for you. The same logic pertains to std::vector
compared to C arrays. Plus, of course, they keep track of their own length,
can be easily resized, etc. But the major benefit is that they fit into the
language better.

I don't feel nearly as strongly about iostream vs. stdio. They both work OK
as class members.

BTW I mix C and C++ all the time in one particular application: making
Windows DLL's. I write the DLL in C++ and the interface in C. That makes the
DLL available to C or C++ programmers and is also easier to use by a client
using a different compiler.
 
M

Michiel Salters

I've been bouncing back between my studies in C/C++ and have found
that I like parts of both languages...
[snip]
(ANSI) C is almost completely upward compatable with C++. Thus you can
take almost any C construct and plop it into a C++ program and it'll
work fine.

Explanation correct, but you got the terms reversed. ISO C++98 is
upwards compatible with ISO C90. C++98 is not upwards compatible
with the new C99 features. C++0x can't fix that (e.g the name
clog was claimed in C++98 and in C99, for different things),
but it will be closer.
printf in a C++ program? Works just as well as in C.
Pointers? Built-in arrays? C strings? They are still used a lot in
many C++ programs. Even inheriting structs from other structs will
work.

Of course inheriting never worked in C. The remainder works almost
the same.
(There are some things that won't work, but they are rare. I've seen a
link to things that have been broken, but I don't have it off the top
of my head.)

Annex C in the C++ standard. There are other changes, but they're
designed to make things work. e.g. qsort can accept C and C++
functions (overloaded on linkage) and it can propagate an
exception in C++.
 
U

Unforgiven

Lindon said:
I've been bouncing back between my studies in C/C++ and have found
that I like parts of both languages... I find that pointer arithmetics
and arrays in C come extremely naturally to me, yet I can't get passed
the fact that C structures don't even compare to C++ classes (no
constructors, no member functions, of course no inheritance), there's
no function overloading, and the good GUI tools (and other library)
seem to be all for C++. But I don't really want to move to C++ and
use the iostreams instead of the stdio, or vectors and strings instead
of arrays and char*'s, (although I do find template/generic
programming interesting, I've decided to learn it as if it were
another language and treat it as such because using arrays and low
level C with it would be self defeating).

C++ is in most aspects a superset of C, which means that whatever you can do
in C, you can do in C++ (I'm sure there's some exception, but I rarely use
pure C, so I can't think of one)
All the things you mention, std::string and std::vector and whatever, are
part of the Standard Template Library, which is part of the C++ standard,
but it is just a library, it doesn't define the language. In fact, the STL
is implemented, using C++, using such things as pointer arithmic and
'normal' arrays. All a std::vector is in essence is a wrapper around a
normal dynamically allocated array, providing some additional robustness
(such as bounds-checking) and ease of use. Same goes for std::string.
So my quesiton: is it acceptable to, say, have a char* class member
instead of a string? using MyClass* instead of a vector<MyClass>?
Sure.

Writing C with structures that derive from other structures? Sneaking
in a const instead of a #define in a C prog?
And would mixing the two be a bad thing for larger programs?
The fact is that modern c++ compilers don't seem to care if I mix and
match so its rather tempting...

I'm not entirely sure what you mean by 'mixing'. If there is some feature of
C that C++ doesn't support, you wouldn't be able to use it from a file
compiled as C++, no matter what the compiler. Neither can you use C++
features in files compiled as C. You can with most compilers link object
files generated from both C and C++ files together. Is that what you want to
do?

--
Unforgiven

"Not only do I not know the answer
I don't even know what the question is"
My world - Metallica
 
M

Micah Cowan

C++ is not topical in C, even when you (speaking to OP) think you're
talking about mixing them (you really aren't: you're talking about
different portions of the C++ language). Followup-To set to c.l.c++ only.
Hi there,



If you don't want to move to iostream, then simply don't. You can still
use stdio, but use an #include <cstdio> (the latest ANSI C++ - I guess not
all compilers support it yet, so be warned that cstdio header may not
exist).

#include <stdio.h> is legal, but obsolescent (it may be disallowed in
future versions of the C++ standard). There is a difference in their
meaning: if you #include <cstdio>, you must refer to functions using
(e.g.) std::printf(), as the global namespace isn't supposed to be
corrupted (however, since many libraries also include macro versions,
and/or illegally clutter up the global namespace as well, you shouldn't
assume you can use them for your own purposes).
It's perfectly acceptable to use have a char * instead of a string.
Anyway, I wouldn't do that, since the std::string class is easier to use
than char * when we're using strings. char * is more useful for pointer
arithmetic operations. As far as the vector is concerned, I can't tell you
anything about it, since I didn't know that reserved word.

Also, the std::string class does a lot of the work you would normally
have to do yourself with C strings, helping reduce drastically the
risk of buffer-overflows; bounds-checking errors.
Your are supposed to use both classes and structures when each one is
need.

In C++ there is no difference between a class and a structure: or,
more accurately, there is no such thing as a "structure": there are
"class" and "struct", which both declare classes, with slightly
different semantics ("struct" declares all of its members "public" by
default).
A struct can be a parameter to a setDate function of a class, for
example. We just don't set it directly, using normal attribution to filter
the number of days of a month and the month number for example.

It's all right to use both #define and const, but keep in mind that
#defined "constants" will be replaced by their real value during
compiling. What I mean is that:

#define PI 3.14
if (PI == 3.14) blah

if the same as:

if (3.14 == 3.14) blah

after the program is compiled (you can think of it as after being
"converted to assembly", if you know what I mean).

Now const. const reserves space in the .data section in memory (the
#defined values too, but so does a string).

In C, at the global scope, it may; in C++, it needn't, provided it's
address is never used. Also, C++ allows const-defined objects to have
internal linkage unless you specifically ask for external linkage,
which allows them to be defined in header files (not possible in C, if
the header file is included in multiple translation units).
Anyway, I usually use const
when I want to do something like using a char* as a parameter without
altering it. Google a bit more about const, since I guess this isn't
accurate info.

In general, I use const-defined definitions, since they have a type
strongly associated with them. However, there can be distinct
advantages to using macros: to take advantage of string literal
concatenation, or the "stringization" of expanded macros by the
preprocessor.

They never will. There are good reasons for having included much of
the C legacy that exists in C++. And there are some minor but
occasionally important features which exist in the C library
facilities which are lacking in their OO equivalents.

-Micah
 
L

Lew Pitcher

Without hesitation, Unforgiven asserted (on or about 07/03/03 06:52) that:
C++ is in most aspects a superset of C, which means that whatever you can do
in C, you can do in C++ (I'm sure there's some exception, but I rarely use
pure C, so I can't think of one)

So, let me give you an example of one of those exceptions...

int catch(int try)
{
return try + 1;
}

int main(void)
{
int try, catch, new;

for (try = 0; try < 10; ++try)
new = catch(try);

return 0;
}

Welcome to comp.lang.c

--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top