Should I Learn C Before Learning C++

Should I learn C before learning C++?

There is no need to learn C before learning C++.

They are different languages. It is a common misconception that C++ is in some way dependent on C and not a fully specified language on its own.

Just because C++ shares a lot of the same syntax and a lot of the same semantics, does not mean you need to learn C first.

If you learn C++ you will eventually learn most of C with some differences between the languages that you will learn over time. In fact its a very hard thing to write proper C++ because intermediate C++ programmers tend to write C/C++.That is true whether or not you started with C or started with C++.

If you know C first, then that is good plus to learning C++. You will start with knowing a chunk of the language. If you do not know C first then there is no point focusing on a different language. There are plenty of good books and tutorials available that start you from knowing nothing and will cover anything you would learn from C which applies to C++ as well.

Please see further reasoning in this answer.

Should I learn C before learning Javascript?

No.

JavaScript may be one of the klunkiest languages ever, but it has one huge advantage over C: You can play with it. (I spent 10+ years coding in C. I had some fun, but I'd never call what I did "playing".)

My suggestion: Open up your favorite Web page, save it to disk, open up the JavaScript (or download it, if need be), and play. You'll learn a lot that way.

EDIT: Downvoters: Yes, there is a lot to like about JavaScript. But there's also a lot not to like.

What should I learn first before heading to C++?

First you should learn that C++ is not a superior language. C has its uses as more than a stepping stone into C++. C, and "C-style" C++ are used because they:

  • Generate smaller binaries
  • Use less memory
  • Compile faster
  • Do not require OS-support
  • Are simpler, and easier to implement

Data structures are by far the most useful of the listed to learn, followed by algorithms. If you intend to go into C++, it's also useful (mandatory?) to have good design skills.

You should not necessarily learn Win32 at all. Consider learning the POSIX APIs, GTK+ and Boost, as they're more portable, and work on platforms other than Windows.

The best decision you can make is to learn C thoroughly as a separate skill on a Unix platform, before crutching yourself by not being able to see the difference between C and C++.

Of the listed Mathematics disciplines, I've only used discrete mathematics. Linear algebra is also useful, but by far and away the best discipline for programming is set and number theory.

Enjoy your time in C, don't become dependent on Windows/Visual Studio, and don't rush into C++.

Update0

Almost forgot! You absolutely must use a decent C compiler. A central reason to C++'s wide use in enterprise, and the bad reputation C has among Windows developers is Visual Studio. Visual Studio is easily the best C++ IDE, however it's also the worst C compiler I know of. Be sure to use a C compiler with C99 support, such as GCC, mingw or Clang. My first experience with C was using LCC, which was very easy to use on Windows, but I haven't used it since moving to Linux, so I can't comment on its C99 status.

Learn C first before learning Objective-C

I would learn C first. I learned C (and did a lot in C) before moving to Obj-C. I have many colleagues who never were real C programmers, they started with Obj-C and learned only as much C as necessary.

Every now and then I see how they solve a problem entirely in Obj-C, sometimes resulting in a very clumsy solutions. Usually I then replace some Obj-C code with pure C code (after all you can mix them as much as you like, the content of an Obj-C method can be entirely, pure C code). Without any intention to insult any Obj-C programmer, there are solutions that are very elegant in Obj-C, these are solutions that just work (and look) a lot better thanks to objects (OOP programming can make complex programs much more lovely than functional programming; polymorphism for example is a brilliant feature)... and I really like Obj-C (much more than C++! I hate the C++ syntax and some language features are plain overkill and lead to bad development patterns IMHO); however, when I sometimes re-write Obj-C code of my colleagues (and I really only do so, if I think this is absolutely necessary), the resulting code is usually 50% smaller, needs only 25% of the memory it used before and is about 400% faster at runtime.

What I'm trying to say here: Every language has its pros and cons. C has pros and cons and so does Obj-C. However, the really great feature of Obj-C (that's why I even like it more than Java) is that you can jump to plain C at will and back again. Why this is such a great feature? Because just like Obj-C fixes many of the cons of pure C, pure C can fix some of the cons of Obj-C. If you mix them together you'll receive a very powerful team.

If you only learn Obj-C and have no idea of C or only know the very basics of it and never tried how elegantly it can solve some common problems, you actually learned only half of Obj-C. C is a fundamental part of Obj-C. The ability to use C at any time and everywhere is a fundamental feature of it.

A typical example was some code we used that had to encode data in base64, but we could not use an external library for that (no OpenSSL lib). We used a base64 encoder, entirely written using Cocoa classes. It was working okay, but when we made it encode 200 MB of binary data, it took an eternity and the memory overhead was unacceptable. I replaced it with a tiny, ultra compact base64 encoder written entirely as one C function (I copied the function body into the method body, method took NSData as input and returned NSString as output, however inside the function everything was C). The C encoder was so much more compact, it beat the pure Cocoa encoder by the factor 8 in speed and the memory overhead was also much less. Encoding/Decoding data, playing around with bits and similar low level tasks are just the strong points of C.

Another example was some UI code that drew a lot of graphs. For storing the data necessary to paint the graphs, we used NSArray's. Actually NSMutableArray's, since the graph was animated. Result: Very slow graph animation. We replaced all NSArray's with normal C arrays, objects with structs (after all graph coordinate information is nothing you must have in objects), enumerator access with simple for loops and started moving data between the arrays with memcopy instead of taking data from one array to the other one, index for index. The result: A speed up by the factor 4. The graph animated smoothly, even on older PPC systems.

The weakness of C is that every more complex program gets ugly in the long run. Keeping C applications readable, extensible and manageable demands a lot of discipline of a programmer. Many projects fail because this discipline is missing. Obj-C makes it easy for you to structure your application using classes, inheritance, protocols and so on. That said, I would not use pure C functionality across the borders of a method unless necessary. I prefer to keep all code in an Objective-C app within the method of an object; everything else defeats the purpose of an OO application. However within the method I sometimes use pure C exclusively.

Should I still learn C if I already know Assembly?

Often one of the main reasons given for learning C is that it brings you closer to programming at a low level

Well, scratch that one off, look at the others and decide for yourself. If you want to:

  • remain close to low level but gain portability
  • be able to work with the huge codebase that C has already
  • just learn something new

then you might want to learn C.

Learning C when you already know C++?

There's a lot here already, so maybe this is just a minor addition but here's what I find to be the biggest differences.

Library:

  • I put this first, because this in my opinion this is the biggest difference in practice. The C standard library is very(!) sparse. It offers a bare minimum of services. For everything else you have to roll your own or find a library to use (and many people do). You have file I/O and some very basic string functions and math. For everything else you have to roll your own or find a library to use. I find I miss extended containers (especially maps) heavily when moving from C++ to C, but there are a lot of other ones.

Idioms:

  • Both languages have manual memory (resource) management, but C++ gives you some tools to hide the need. In C you will find yourself tracking resources by hand much more often, and you have to get used to that. Particular examples are arrays and strings (C++ vector and string save you a lot of work), smart pointers (you can't really do "smart pointers" as such in C. You can do reference counting, but you have to up and down the reference counts yourself, which is very error prone -- the reason smart pointers were added to C++ in the first place), and the lack of RAII generally which you will notice everywhere if you are used to the modern style of C++ programming.

    • You have to be explicit about construction and destruction. You can argue about the merits of flaws of this, but there's a lot more explicit code as a result.
  • Error handling. C++ exceptions can be tricky to get right so not everyone uses them, but if you do use them you will find you have to pay a lot of attention to how you do error notification. Needing to check for return values on all important calls (some would argue all calls) takes a lot of discipline and a lot of C code out there doesn't do it.
  • Strings (and arrays in general) don't carry their sizes around. You have to pass a lot of extra parameters in C to deal with this.
  • Without namespaces you have to manage your global namespace carefully.

    • There's no explicit tying of functions to types as there is with class in C++. You have to maintain a convention of prefixing everything you want associated with a type.
  • You will see a lot more macros. Macros are used in C in many places where C++ has language features to do the same, especially symbolic constants (C has enum but lots of older code uses #define instead), and for generics (where C++ uses templates).

Advice:

  • Consider finding an extended library for general use. Take a look at GLib or APR.

    • Even if you don't want a full library consider finding a map / dictionary / hashtable for general use. Also consider bundling up a bare bones "string" type that contains a size.
  • Get used to putting module or "class" prefixes on all public names. This is a little tedious but it will save you a lot of headaches.
  • Make heavy use of forward declaration to make types opaque. Where in C++ you might have private data in a header and rely on private is preventing access, in C you want to push implementation details into the source files as much as possible. (You actually want to do this in C++ too in my opinion, but C makes it easier, so more people do it.)

    C++ reveals the implementation in the header, even though it technically hides it from access outside the class.

    // C.hh
    class C
    {
    public:
    void method1();
    int method2();

    private:
    int value1;
    char * value2;
    };

    C pushes the 'class' definition into the source file. The header is all forward declarations.

    // C.h
    typedef struct C C; // forward declaration

    void c_method1(C *);
    int c_method2(C *);

    // C.c
    struct C
    {
    int value1;
    char * value2;
    };

Is it true that there is no need to learn C because C++ contains everything?

Overview:

It is almost true that C++ is a superset of C, and your professor is correct in that there is no need to learn C separately.

C++ adds the whole object oriented aspect, generic programming aspect, as well as having less strict rules (like variables needing to be declared at the top of each function). C++ does change the definition of some terms in C such as structs, although still in a superset way.

Examples of why it is not a strict superset:

This Wikipedia article has a couple good examples of such a differences:

One commonly encountered difference is
that C allows implicit conversion from
void* to other pointer types, but C++
does not. So, the following is valid C
code:

int *i = malloc(sizeof(int) * 5);  

... but to make it work in both C and
C++ one would need to use an explicit
cast:

int *i = (int *) malloc(sizeof(int) * 5)

Another common portability issue is
that C++ defines many new keywords,
such as new and class, that may be
used as identifiers (e.g. variable
names) in a C program.

This wikipedia article has further differences as well:

C++ compilers prohibit goto from crossing an initialization, as in the following C99 code:

 void fn(void)
{
goto flack;
int i = 1;
flack:
;
}

What should you learn first?

You should learn C++ first, not because learning C first will hurt you, not because you will have to unlearn anything (you won't), but because there is no benefit in learning C first. You will eventually learn just about everything about C anyway because it is more or less contained in C++.

What if any, programming fundamentals are better learned in C as opposed to C++?

If all you've ever used is object-oriented programming languages like C++ then it would be worthwhile to practice a little C. I find that many OO programmers tend to use objects like a crutch and don't know what to do once you take them away. C will give you the clarity to understand why OO programming emerged in the first place and help you to understand when its useful versus when its just overkill.

In the same vein, you'll learn what it's like to not rely on libraries to do things for you. By noting what features C++ developers turned into libraries, you get a better sense of how to abstract your own code when the time comes. It would be bad to just feel like you need to abstract everything in every situation.

That said, you don't have to learn C. If you know C++ you can drag yourself through most projects. However, by looking at the lower-level languages, you will improve your programming style, even in the higher-level ones.



Related Topics



Leave a reply



Submit