After doing one file < 500 lines Pascal programs, I jumped directly at C++. Then, two years later, after learning a lot in theory about the marvels of OOP, DirectX interfaces, and the rest, after seeing the beauty and ease of use of OpenGL, and the .c quake sources, I decided I''ve had enough, and its time for a -- down to C again. So, C people out there, what are the tricks of managing a big C program ?

The trick to managing a big C program is to switch to C++. If you will not have advantages of C++ with C then why switch?

With C you only have global, file and function scopes. All externally linked names should therefore have a package and/or file prefix to avoid collision. You''re kinda stuck with #defines for interface (i.e. .h file) constants, which is really too bad since they can''t be placed within a scope either. So a general strategy would be to give external linkage to as few names (functions, variables, structs) as possible, and be sure that only definitions that are truly needed by external clients are included in an .h file.

But I have to agree with felix here--C++ gives you much more powerful tools to manage a large project. It sounds like you''ve been put-off the language, which is too bad. Maybe someday you''ll come around to it.

Don''t switch to C. Stick with C++, but don''t use the C++ features. You will eventually get some nice extensions that are not available in plain C, besides all that OOP.

Frankly, OOP as it would be teached in school _really_ sucks big time. These computer-science types are using C++ like it was Smalltalk or some other theoretical OOP-only language. Bjarne Soustroup has invented C++, but in his mind this is an extension of the C language that supports most of the OOP stuff (so you can do it if you want to, but the compiler would implement this in an effective manner so you can write REAL-WORLD applications with it).

MODULARIZATION and put only what is really needed in the .h files.
One really neet thing is that you can put the prototype of a struct in the .h file and the body in the .c file. That way the user only gets access to through your methods and he cannot declare a instance of his own, since the compiler doesn''t have any type info outside your modules .c file. Even better, every such type has a different type and the compiler will at least give a warning if you are trying to assign a pointer of one type to another.
This is actually much better information hiding than the c++ approach where you can see all the internal information about a class even if you can''t touch it.

You know it really bugs me when people argue about C++/C..the language is a TOOL..

//bad analogy here

If someone said, "Hey I just got a claw hammer...what''s the best way to use it?"...how many people would say "You should throw it away and get a ball peen hammer"..?

//end bad analogy

I''m not going to get into a debate about which is better, because neither language is really better than the other, despite what many here would say..

The trick to managing a large project in C is the same as with any other language: GOOD SOFTWARE DESIGN

If you can''t write good, modular code to begin with, no language will help you..if you''re a moron and you speak english, learning french won''t change anything..

I''ve written some massive programs in C that are just as well organized as any C++ code I''ve seen..

Please don''t put down a language bacause you personally don''t know how to get the most out of it..granted, there are limitations in every programming language available, but straight ANSI C has got to be the most portable, flexible, and unrestrictive language out there..

I''ve written some massive OO based programs that use straight C..yes...C!!..OOP is a CONCEPT, not a LANGUAGE..just because C++ has built in data types that support OOP concepts, it doesn''t mean that you can''t do it any other way..

Keep in mind I have NO preference regarding C or C++ but I hate to see someone ask a legitimate question only to be told that they''re wasting their time..

Diodor, I can''t tell you specifically how to manage your project(that''s a matter of what you''re doing), but PLEASE don''t be discouraged by the ignorance of others..

C is great...
C++ is great..
C is great...
C++ is great..
C is great...
C++ is great..
C is great...
C++ is great..
C is great...
C++ is great..



"Like all good things, it starts with a monkey.."

Well, I personally use C++, but I''m not going to try to convince you which is better or more properly suited to something, since I''ve used straight C to do programs as well, and there''s nothing wrong with it.

Here''s how I handle my large C programs: strict naming guidelines. Like Stoffel said, pick a prefix, put it on everything . If you want to, use Hungarian Notation even. If you''re going to do straight C, remember to make a couple of preprocessor lines to define bool if it isn''t already (the C99 standard added bool to C, but many compilers aren''t updated often enough to have it). Defines can emulate (but not equal in some cases) constants and templates if used correctly.

Also, whether its C or C++, split it up into a lot of files so that it stays organized. BTW: Don''t rule out modular or procedural in the face of object orientation (which can be pulled off in C for the most part, as monkeyman pointed out).


http://druidgames.cjb.net/

First of all, realize that most of the people here are teenagers or barely twenty-somethings. If you read these boards, you will realize that C++ was their first significant language learned. Given that, it is reasonable to assume that they really don''t have much experience with C, and they assume propogated assumptions made about using C vs. C++.

I use C. The bulk of most OS APIs are written in C or made to be callable by C. There is a lot of money to be made promoting the concept that C++ is far better. One example is books available to teach C++. If you don''t know C++, then you are a potential customer of someone writing a book about C++. It''s a pity that so many actually believe that C++ is ultimately capable while C is not. The truth of the matter is, both languages accomplish virtually the same thing with the same code, relatively speaking. Now, for some problems, there are truly DIFFERENT solutions using DIFFERENT languages. Two examples might be LISP and Prolog. To accomplish what these languages accomplish with C or C++ virtually REQUIRES you to write a LISP or Prolog interpreter. I have NEVER encountered a situation where to accomplish what a C++ program does with C would require me to write a C++ compiler.

As for building large C applications, I would try to think of every section of your application as a mini API which needs to be built and then interfaced to by your application. I think this is the best advice I can give.

Implement an observable template pattern that uses strategies for each step of the template, then we''ll talk about the strengths & weaknesses OOD in C & C++.

You can bit-bang in BASIC and pop-off interupts in COBOL; but why would you want to?


For a big C program I''d use a sequence of function pointers on the main loops so that you could functions from dll''s and/or switch some functionality at runtime (easily switch between algorithms, allow mods more control, etc...). I''d manually namemangle my fuctions, pass a struct pointers to them so that there''s some modularity to it.


Magmai Kai Holmlor
- The disgruntled & disillusioned

"I''ve written some massive OO based programs that use straight C..yes...C!!"

Hmm, I''ve banged nails into a wall with a screwdriver, yes! a screwdriver!! all those silly people who go out and waste their money on hammers when screwdrivers accomplish the job just as well.

The point I''m trying to make is, there''s the right tool for the right job. Sure, you can simulate some of the features of C++ in C (and other languages), but C++ exists so those techniques can be more easily used on a wide-scale. I''ve used "object-oriented techniques" in C in order to extend an existing application, but it was that experience that made me appreciate C++ because C++ allows you to express those techniques in a manner that the compiler can take care of the plumbing, provide safety-checking, etc.

Besides, there are quite a few things you can do in C++ that you can''t in C. For example, take the whole concept of automatic construction/destruction that guarantees objects are properly initialized and destroyed, and allow for things like auto-pointers.