acceptable to mix C/C++?

Discussion in 'C Programming' started by Lindon, Jul 2, 2003.

  1. Lindon

    Lindon Guest

    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
     
    Lindon, Jul 2, 2003
    #1
    1. Advertising

  2. Lindon

    crashnburn Guest

    Hi there,

    On Wed, 02 Jul 2003 12:56:46 -0700, Lindon wrote:

    > 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)
     
    crashnburn, Jul 2, 2003
    #2
    1. Advertising

  3. Lindon

    bd Guest

    On Wed, 02 Jul 2003 11:56:46 -0700, Lindon wrote:

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

    --
    Freenet distribution not available
    I have often regretted my speech, never my silence.
    -- Publilius Syrus
     
    bd, Jul 2, 2003
    #3
  4. Lindon

    Malcolm Guest

    "Lindon" <> wrote in message
    >
    > 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.
     
    Malcolm, Jul 2, 2003
    #4
  5. Lindon

    Cy Edmunds Guest

    "Lindon" <> wrote in message
    news:...
    > 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.

    --
    Cy
    http://home.rochester.rr.com/cyhome/
     
    Cy Edmunds, Jul 2, 2003
    #5
  6. (Evan) wrote in message news:<>...
    > (Lindon) wrote in message news:<>...
    > > 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++.
     
    Michiel Salters, Jul 3, 2003
    #6
  7. bd wrote:
    [...]
    > C++ is off-topic in comp.lang.c - we only discuss pure C here. Followups
    > set.


    Thanks.

    [...]
    > I have often regretted my speech, never my silence.


    I see.

    regards,
    alexander.
     
    Alexander Terekhov, Jul 3, 2003
    #7
  8. Alexander Terekhov, Jul 3, 2003
    #8
  9. Lindon

    Unforgiven Guest

    Lindon wrote:
    > 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
     
    Unforgiven, Jul 3, 2003
    #9
  10. Lindon

    Micah Cowan Guest

    crashnburn <> writes:

    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,
    >
    > On Wed, 02 Jul 2003 12:56:46 -0700, Lindon wrote:
    >
    > > 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).


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

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


    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.

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


    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.

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


    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
     
    Micah Cowan, Jul 4, 2003
    #10
  11. Lindon

    Lew Pitcher Guest

    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.
     
    Lew Pitcher, Jul 6, 2003
    #11
  12. Lindon

    Giuseppe Guest

    On Thu, 03 Jul 2003 11:31:24 +0200, Alexander Terekhov
    <> wrote:
    >
    >bd wrote:
    >[...]
    >> C++ is off-topic in comp.lang.c - we only discuss pure C here. Followups
    >> set.

    >
    >Thanks.
    >
    >[...]
    >> I have often regretted my speech, never my silence.

    >
    >I see.


    Where are his errors?
     
    Giuseppe, Jul 7, 2003
    #12
  13. Giuseppe wrote:
    >
    > On Thu, 03 Jul 2003 11:31:24 +0200, Alexander Terekhov
    > <> wrote:
    > >
    > >bd wrote:
    > >[...]
    > >> C++ is off-topic in comp.lang.c - we only discuss pure C here. Followups
    > >> set.

    > >
    > >Thanks.
    > >
    > >[...]
    > >> I have often regretted my speech, never my silence.

    > >
    > >I see.

    >
    > Where are his errors?


    In his std::cerr and/or std::wcerr, I guess.

    regards,
    alexander.
     
    Alexander Terekhov, Jul 7, 2003
    #13
    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. valentin tihomirov

    Is this trick with reset acceptable?

    valentin tihomirov, Apr 11, 2004, in forum: VHDL
    Replies:
    6
    Views:
    564
    Jim Lewis
    Apr 14, 2004
  2. .Net Sports
    Replies:
    2
    Views:
    908
    Craig Deelsnyder
    May 3, 2005
  3. steve

    acceptable way to program

    steve, Dec 31, 2004, in forum: Java
    Replies:
    34
    Views:
    1,036
    Haximus
    Feb 20, 2005
  4. (Pete Cresswell)
    Replies:
    8
    Views:
    465
    Duende
    Dec 23, 2004
  5. Lindon

    acceptable to mix C/C++?

    Lindon, Jul 2, 2003, in forum: C++
    Replies:
    16
    Views:
    537
    Alexander Terekhov
    Jul 7, 2003
Loading...

Share This Page