0

So I am currently learning C (planning to learn C++ after) but I have hit some dilemmas.

  1. How common would it be for someone to unknowingly mix C and C++?
  2. How to avoid mixing of C and C++?
  • 4
    What does that even mean. – M.M Feb 07 '15 at 07:09
  • `How common would it be for someone to unknowingly mix C and C++?` depends on the person. `How to avoid mixing of C and C++?` again depends on the person. – deviantfan Feb 07 '15 at 07:12
  • 1
    Answer to Q1: Very common when you are transitioning from C to C++. Answer to Q2: With practice, getting bitten by bad code a few times, learning from books and online resources. – R Sahu Feb 07 '15 at 07:12
  • You could ask yourself the same question about mixing English and French. My personal answer is: what does it matter as long as people can understand what yous say. N'est-ce pas? – kuroi neko Feb 07 '15 at 07:12
  • 2
    If you want to do C++, learn C++. Don't learn C first. – Neil Kirk Feb 07 '15 at 07:21
  • 1
    The accepted answer [here](http://stackoverflow.com/questions/598552/should-i-learn-c-before-learning-c) might be helpful. – Emil Laine Feb 07 '15 at 07:40

2 Answers2

4

The first thing would be to decide which language you are going to learn. It is unnecessary to learn C before learning C++ and vice versa.

Learn your chosen language thoroughly. Very few native english speakers mix german with english, and vice versa. It is the same with programming languages - if you know your chosen language well, you're not likely to mix things in from other languages, even if they have similarities. And, over time, you will recognise dialects.

Read up on incompatibilities between C and C++. The original C++ standard explicitly listed all the compatibilities between it and the preceding standard C (ANSI C89 or ISO C90). There are a lot of good resources on the incompatibilities freely available - some focused on C developers, some focused on C++ developers.

Configure your compiler (or IDE, or build scripts) so the compiler will detect excursions from your language of choice. Also configure it to maximum warning levels (virtually no compiler is configured this way out of the box) and strive to have code that NEVER triggers even the smallest warning from your compiler. Even better, do this with multiple compilers.

Without the steps above, the rules of thumb below will be less effective. After all, rules of thumb are less effective without understanding the underlying reasoning.

Some rules of thumb, if developing in C, avoid are C++-specific features.

  • Don't use operator new or delete
  • Avoid using any standard headers that don't have a .h extension (for example, #include <stdio.h> is C, #include <iostream> is C++.
  • Don't use exceptions.
  • Don't use classes, use structs.
  • Don't specify member functions in structs.
  • Don't use access specifiers (public, private, protected) in structs
  • Don't overload functions (i.e. don't write two or more functions with the same name, but different parameter lists).
  • If you intend to use the bool type (and values true and false), then #include <stdbool.h> (C99 or later).
  • Don't use templates.
  • If a function accepts no argument, declare it with a void argument list. For example, int func(void) means the function takes no arguments.
  • Don't use namespaces.
  • Don't use the C++ style casts (const_cast, reinterpret_cast, dynamic_cast, static_cast). Use the normal C-style cast (e.g. (int *) to convert something into a pointer to int)

Some rules of thumb, if developing in C++, to avoid C-specific features.

  • Don't use malloc(), realloc(), calloc() or free() to dynamically allocate memory.
  • Avoid using any standard headers that have a .h extension (for example, #include <stdio.h> is C, #include <iostream> is C++. Make significant use of the C++ standard library.
  • If you intend to use the bool type (and values true and false), don't #include <stdbool.h>. This is because bool, true, and false are keywords in C++, but macros in standard C.
  • If a function accepts no argument, don't declare it with a void argument list.
  • Use namespaces or function overloading to resolve situations where you wish to have more than one function with a specified naming scheme.
  • Don't use the C style casts, ever. Use C++ style casts const_cast, reinterpret_cast, dynamic_cast, static_cast).
Rob
  • 1,966
  • 9
  • 13
  • Native English speakers do mix two languages together - French - Summat to do with the Norman conquest – Ed Heal Feb 07 '15 at 10:08
  • English itself is derived from a lot of languages, Ed. But a native english speaker thinks of those things as english, rather than mixing in things from french, spanish, latin, or whatever language their chosen word came from. – Rob Feb 07 '15 at 10:24
  • I know - just making an observation about your statement. – Ed Heal Feb 07 '15 at 10:25
3

C++ diverged from C in the mid-1980's, when it had already acquired most of its familiar features. It continues to incorporate features from the recent C99 and C11 revisions. The intersection of C++ and C is a perfectly reasonable and useful language.

Recently, the GCC compiler project switched from C to C++ after verifying that their many thousands (millions?) of lines of sophisticated C code were really already mostly valid C++.

You can proceed to learn C, don't get too caught up in sophisticated features or wacky tricks, and simply switch to invoking the C++ compiler when you want something more structured.

Or, just use the C++ compiler all along, with the -Wall -pedantic options. There are plenty of resources about this sort of portability:

Potatoswatter
  • 134,909
  • 25
  • 265
  • 421