C For The C++ Programmer
Author
Does anyone know a resource for learning C as a C++ Programmer? My university teaches using C++, but there is an awesome intership opportunity I learned about recently, but they want someone who knows C. I know that they are similar, but is there a resource out there that teaches C to C++ people quickly?
Thanks
James
C is basically C++ with everything good ripped out. Here's what you'd want to focus on:
1) No member functions. This is okay, everything is public, so just make them free functions with the first parameter as the "self".
2) No namespaces or overloading. You will be in wart central. ProjectSpecificPrefix_Verb_NounsDescribingTheOperationTarget tends to be a common pattern.
3) No virtual functions. Instead you have to roll your own using function pointers (and writing/maintaining your own vtables where appropriate), or switch()-hell.
4) No exceptions or RAII. Focusing on mantaining a single exit point -- and thus single cleanup section -- will help a lot for C. You can use goto to skip ahead to cleanup early on where you'd throw in C++. Get experienced with a leak detector, you're bound to miss things. All initialization and deinitialization will be manual, and error codes are going to be your error reporting mechanism.
5) No container classes or templates. Knowing how common data structures are immplemented is probably going to be needed -- you'll run into a lot of (re)implementations of it to maintain, chances are.
6) No single line comments, typedef struct { ... } name; instead of class name { ... };.
7) No new, only malloc. non-compile-time-constant-expression integral consts, get comfortable with enum as your replacement.
8) Chances are you're going to deal with ugly macros too. Know their common associated problems, since you'll run into those too.
9) Conversion errors are demoted to warnings for all sorts of henious shit. Know your compiler's "treat warnings as errors" flag, and pray your existing codebases will compile with it.
10) Know your bitwise operations. C programmers love em to death.
Since C++ started out as a strict superset of C (and still largely is), the specific alternatives you'll be using will actually work in both languages.
1) No member functions. This is okay, everything is public, so just make them free functions with the first parameter as the "self".
2) No namespaces or overloading. You will be in wart central. ProjectSpecificPrefix_Verb_NounsDescribingTheOperationTarget tends to be a common pattern.
3) No virtual functions. Instead you have to roll your own using function pointers (and writing/maintaining your own vtables where appropriate), or switch()-hell.
4) No exceptions or RAII. Focusing on mantaining a single exit point -- and thus single cleanup section -- will help a lot for C. You can use goto to skip ahead to cleanup early on where you'd throw in C++. Get experienced with a leak detector, you're bound to miss things. All initialization and deinitialization will be manual, and error codes are going to be your error reporting mechanism.
5) No container classes or templates. Knowing how common data structures are immplemented is probably going to be needed -- you'll run into a lot of (re)implementations of it to maintain, chances are.
6) No single line comments, typedef struct { ... } name; instead of class name { ... };.
7) No new, only malloc. non-compile-time-constant-expression integral consts, get comfortable with enum as your replacement.
8) Chances are you're going to deal with ugly macros too. Know their common associated problems, since you'll run into those too.
9) Conversion errors are demoted to warnings for all sorts of henious shit. Know your compiler's "treat warnings as errors" flag, and pray your existing codebases will compile with it.
10) Know your bitwise operations. C programmers love em to death.
Since C++ started out as a strict superset of C (and still largely is), the specific alternatives you'll be using will actually work in both languages.
I would add:
- In particular, no std::string, but an entire string.h header for handling functions, and all the idioms involved in writing decently fast and well-behaved non-trivial code with C-style strings (definitely not easy).
- The callback-and-void* paradigm, where you provide a void* pointer to something along with a callback in order to simulate a closure.
- No references, you have to pass pointers instead. Possibly use T* p and T p[] to distinguish pass-by-reference arguments from array arguments.
- Massively procedural code. Writing object-oriented code is possible in C, but definitely not easy, so it might sometimes be far better to achieve modularity through procedural means instead.
C has got realloc, allowing you to resize the size of a buffer or array. AFAIK, C++ has no equivalent in its new/delete syntax to do this as easily.
But C++ has the std::containers so it's not really a problem either.
So to the above list to add:
But C++ has the std::containers so it's not really a problem either.
So to the above list to add:
- No std::containers
// This is malloced by func_alloc, and released by // func_dealloc, unless we encounter an error func_a, func_b, // func_c, then you need to release it manually. You need to re-allocate // it manually by calling func_realloc if you switch the mgm_data_file_c // on linux, but not on Solaris.Of course, pray that such comments will actually be in the code. And reflect what needs to be done.
Lots of pointer magic.
Lots of conditional allocations.
Completely unsafe memory and array access. What? Programmer should know that p_data_28_bytes will always alocate 17 bytes.
C is evil. And then you enter the world of embedded programming and drivers.
That better be one helluva job.
Quote:Original post by MaulingMonkey
C is basically C++ with everything good ripped out. Here's what you'd want to focus on:
1) No member functions. This is okay, everything is public, so just make them free functions with the first parameter as the "self".
Can be emulated with some pointer magic + static function definitions.
Quote:
3) No virtual functions. Instead you have to roll your own using function pointers (and writing/maintaining your own vtables where appropriate), or switch()-hell.
See above (that's why you can compile DirectX on C). But I agree, this can be a hard trip if you're not familiar with this (I make usage of that in my ray tracer. Not that I can't use c++, writing the whole thing in C in an object oriented manner was just one thing I always wanted to do, yay :D )Quote:
6) No single line comments, typedef struct { ... } name; instead of class name { ... };.
oh oh, C99Quote:
10) Know your bitwise operations. C programmers love em to death.
yes :D
Why not just tell him to skip the internship :p As opposed to doing this roundabout (yet effective) way of saying it.
Quote:Original post by ToohrVyk
I would add:
- In particular, no std::string, but an entire string.h header for handling functions, and all the idioms involved in writing decently fast and well-behaved non-trivial code with C-style strings (definitely not easy).
- The callback-and-void* paradigm, where you provide a void* pointer to something along with a callback in order to simulate a closure.
- No references, you have to pass pointers instead. Possibly use T* p and T p[] to distinguish pass-by-reference arguments from array arguments.
- Massively procedural code. Writing object-oriented code is possible in C, but definitely not easy, so it might sometimes be far better to achieve modularity through procedural means instead.
Good points.
Quote:Original post by Lode
So to the above list to add:
- No std::containers
This is what I meant with #5.
Quote:Original post by greenhybridQuote:Original post by MaulingMonkey
C is basically C++ with everything good ripped out. Here's what you'd want to focus on:
1) No member functions. This is okay, everything is public, so just make them free functions with the first parameter as the "self".
Can be emulated with some pointer magic + static function definitions.
No need for pointer "magic" (just a normal pointer for an explicit "this" argument for the aforementioned static/free function), unless you meant for implementing virtual functions, in which case given I give two example emulation mechanisms right in #3, well, yeah. I can't say I disagree.
Your C99 link also indirectly raises a couple extra points to add to the list though:
N) Predeclaring your variables instead of declaring them at use point.
N+1) va_args. No operator chaining to bail you out from this in C. (Reminded from the mention of vardaric macros, even if unrelated). Hope your compiler can warn with format string/argument list mismatches...
N+2) Be ready to cry a lot whenever you think of any other language and all the wonderful tools they have that you can't use.
Quote:Original post by MaulingMonkey
4) No exceptions or RAII. Focusing on mantaining a single exit point -- and thus single cleanup section -- will help a lot for C. You can use goto to skip ahead to cleanup early on where you'd throw in C++. Get experienced with a leak detector, you're bound to miss things. All initialization and deinitialization will be manual, and error codes are going to be your error reporting mechanism.
That's not quite accurate with regard to exceptions. While the standard doesn't stipulate an exception mechanism, various compilers do. For example, Microsoft provides "try-except" and "try-finally" forms under the grouping of "Structured Exception Handling" and many other vendors follow that pattern. However, no vendor provides exception objects that can be thrown and caught ala C++.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
