next »

[Problem Machine]

I just applied for a programmer position without paying too close attention to the description, and it turns out it's a C programming position. They sent me a link to a programming test thing I'm supposed to take to apply for the position, and I have a little bit of time to study up before I actually take it.

Now, I've been spending a lot of time brushing up on my C++, but I don't really know a lot about C. I got a lot of the basics from this article, which is a good start; but stuff like this is only good for the basic differences in language, and not so much for the best practices expected of a programmer using it. So basically, uh, what do you guys think I should know?

edit: This article is also useful, for anyone else trying to do the same thing.

[mirosurabu]

Various data-types/structures which are commonly not used in C++. Arrays, structs, unions, linked lists and so on.

Dynamic memory allocation. Malloc, realloc, free and bunch of other stuff.

C strings. Pain in the ass. Get to know that standard C library for string manipulation.

[Problem Machine]

I'm familiar with most of this stuff, but what are unions?

[mirosurabu]

Sorry for my post, I actually realized I was missing your point after the post was approved, but oh well.

Anyways, unions are like structs except members share same address space. They act like variant data type. It's less used but I thought it's worth a mention.

As for best practices, procedural programming practices apply here.

[Crackerblocks]

That article is a good.

I'd probably also make sure to know about function pointers. And for a design pattern: how to do OO programming techniques in C using function pointers, unions, void*, type ids, etc.

Best practices: I found that I used asserts a lot more in C. With all the pointers flying around, you get less compile time code validation.

That's all I can think of for now.

I'm curious what the job description is. Some kind of firmware programming?

[Problem Machine]

I'd probably also make sure to know about function pointers.

Are they the same in C as in C++?

I'm curious what the job description is. Some kind of firmware programming?

No it's just gameplay programming for an MMO. No idea why they decided to go with C instead of C++.

[Overkill]

Function pointers are exactly the same in C++ as C. Except there's obviously no method pointers, since there is no object orientation.

Also, you should learn to mimic the class-style organization that C++ gives you by using functions that take a pointer as their first argument. It kept a lot of my C code organized, and it's always better to avoid global state when you can avoid it.

So in C++ you might have:

Code:

class Monster
{
    public:
        Monster(int x, int y);
        ~Monster()

        void Update();
        void Render();
        void Teleport(int x, int y);
    private:
        int x, y;
}

Translating this to C:

Code:

typedef struct Monster
{
    int x, y;
} Monster;

Monster* MonsterNew(int x, int y);
void MonsterFree(Monster* monster);

void MonsterRender(Monster* monster);
void MonsterUpdate(Monster* monster);
void MonsterTeleport(Monster* monster, int x, int y);

[Problem Machine]

It just all seems so silly, if you're gonna be doing all that why not just use C++ in the first place 

[Crackerblocks]

Are they the same in C as in C++?

err yup.

It just all seems so silly, if you're gonna be doing all that why not just use C++ in the first place 

Pretty much sums up why this is a confusing conversation.

Maybe it actually is a C++ job, but they want to make sure you have a good grasp of lower level concepts.

[Overkill]

It just all seems so silly, if you're gonna be doing all that why not just use C++ in the first place 

Well, I definitely agree that C++ is a much better way to go. Sadly, some people are wankers and consider some of C++ flexibilities "dangerous" and horrible, like operator overloading and templates and stuff.

On the other hand, C++ provides better opportunity for compile-time error checking, inlining, private/public scoping, object-oriented virtual dispatch (can be mimicked in C, but very very unrecommended), type-safe polymorphism, built-in data structures with way nicer time/memory constraints.

C is littered with bad design decisions.

C strings are terrible. Getting the length of a string is an O(n) operation, and buffer overflow is very easy to have happen due to all char* operations looking for a \0, instead of length-delimiting which is much more friendly. C++ fixes this with std::string.

malloc is lame because it's not typesafe, you just get a void*. So, if you refactor, and somehow misspecify the size of the data you're allocating, you're boned. C++ has new instead, which resolves to a type at compile-time and figures out the size for you!

printf/scanf are admittedly handy, but they're plagued with problems too.

The way I see it, you only use C when you're system-level code (or job mandate, as in this case), or writing for some sort of platform that doesn't have a good C++ compiler. Otherwise, use C++ code, mixing in C only when full-on C++ becomes cumbersome.

[mcc]

Unless you really make a lot of use of either the STL, templates, or object polymorphism, you're going to find C and C++ mostly indistinguishable. C++ is a superset of C, remember. As Overkill says you're mostly going to find yourself just saying monster_iterate(monsterstruct) instead of monster->iterate() a lot and malloc instead of new. The theory that this is really a C++ job but they just listed it as C (either by accident or because they don't make heavy use of C++ features) is believable.

Use of unions in the real world is pretty rare. Function pointers get used in some development teams but not others, but they're still a good thing to know about going into a job interview. Although they're the same in C as C++ pure-C houses are more likely to use them because when you don't have polymorphism you wind up more tempted to use callbacks. Do be familiar with void *.

The interviewer might not even mind you outright saying "well my experience is mostly with C++, but that leaves me well equipped to do C" etc.

[Problem Machine]

Unless you really make a lot of use of either the STL, templates, or object polymorphism

Ech, I do use a fair amount of STL and polymorphism. STL is no big deal, because it's really not too difficult to implement one's own linked list or use an array instead of a vector, but polymorphism is a pain. I guess I just need to get the feel for more procedural style programming...

[Schtee]

God. Hope for your sake that their HR department just used C as short-hand for C++. I saw your code

[Average Software]

C++ is a superset of C, remember.

Actually it isn't, and knowing this might be important for a job interview.  There are many examples of C89 code that are not legal C++ code, and the C99 standard deviates significantly from C++.  The upcoming C1X standard will likely increase the divide even further.

[Problem Machine]

God. Hope for your sake that their HR department just used C as short-hand for C++. I saw your code

Now that's not a very nice thing to say! 
I'm hoping I'm flexible enough to write C++ like C++ and write C like C, but obviously I'm a lot more used to the former than the latter.

Hey, does anyone have some exemplary examples of C code I could look at? I think that's the missing piece here for me.

[Glaiel-Gamer]

C++ is a superset of C, remember.

Actually it isn't, and knowing this might be important for a job interview.  There are many examples of C89 code that are not legal C++ code, and the C99 standard deviates significantly from C++.  The upcoming C1X standard will likely increase the divide even further.

I'm a bit curious about this too... the only C i remember that isn't compatible with c++ is stuff that's a bad idea in the first place (calling a function before defining it, etc)

[Gold Cray]

C++ is a superset of C, remember.

Actually it isn't, and knowing this might be important for a job interview.  There are many examples of C89 code that are not legal C++ code, and the C99 standard deviates significantly from C++.  The upcoming C1X standard will likely increase the divide even further.

I'm a bit curious about this too... the only C i remember that isn't compatible with c++ is stuff that's a bad idea in the first place (calling a function before defining it, etc)

Stroustrup has a website full of information.

[Average Software]

C++ is a superset of C, remember.

Actually it isn't, and knowing this might be important for a job interview.  There are many examples of C89 code that are not legal C++ code, and the C99 standard deviates significantly from C++.  The upcoming C1X standard will likely increase the divide even further.

I'm a bit curious about this too... the only C i remember that isn't compatible with c++ is stuff that's a bad idea in the first place (calling a function before defining it, etc)

Common C89 "C that is not C++" things I run into:

C allows implicit conversions from void* to any other pointer type.  C++ requires a reinterpret_cast.

Code:

void f(void)
{
    /* Legal C, C++ requires a cast. */
    int *p = malloc(sizeof(int));
}

The behavior of const is slightly different in C and C++.  C++ const is much more useful and flexible.

Code:

const int n = 5;

void f(int x)
{
    switch (x)
    {
        case n: /* C++ can do this, C cannot */
            break;
    }
}

Other minor things:

C enum types freely convert back and forth with int.  C++ enums do not.
A C function requires a parameter list of (void) to indicate that it takes no parameters, C++ does not.

C99 adds a number of new features that C++ does not have.  These include variable length arrays:

Code:

void f(unsigned size)
{
    int array[size]; /* variable length array */
}

Designated initializers for structs: (I may have this syntax wrong)

Code:

struct point
{
    int x;
    int y;
};

void f(void)
{
    struct point p = { .x = 3, .y = 4};
}

C99 adds the restrict keyword, which indicates that a group a pointers all refer to different objects.  This aids in compiler optimization.  For example, C99's fopen is declared like so:

Code:

FILE *fopen(const char *restrict filename, const char *restrict mode);

There are other things too, but that all I can remember off the top of my head.

[Problem Machine]

Good stuff! Thanks!

[Ann Ishman]

It just all seems so silly, if you're gonna be doing all that why not just use C++ in the first place

Two most common reasons:

• Person calling the technical shots is stubborn and has way too much power. (Commonly surrounded by a bunch of underlings convinced he is a genius.)
• Dependency on old code/hardware that the people who call the shots on budgets refuse to pony up the cash to upgrade. (Despite probably losing tons of money keeping the old stuff running.)