Newbie design considerations for a C/C++ application

I'm quite new to programming "larger" applications. I have now written a command line application with a few thousand lines of code in Visual C++ 2010, which compiles and works fine. Most of the code is C-compliant (I think), however, I found it useful to use some C++ constructs here and there. E.g., sometimes I used new/delete instead of malloc/free to invoke the constructor or used a std::vector or std::set for convenience. I put all my code in around 25 .h files, except for int main(), which is currently in a .cpp file.

My specific questions are:

• I'm guessing all of my code is compiled as C++ code. Does it make sense to make some parts of the code truly C-compliant? Could I have Visual Studio compile it as C then? For large parts of the program it would be quite simple to make them C-compliant (e.g., replace new with malloc and initializer function, etc.) for some parts more hard (convert a std::vector). Or would it only make sense if everything was C? What would be the advantages? Alternatively, would it make sense to convert everything to C++? E.g., use new instead of malloc and std::string instead of char*.

• I'm guessing it is not intended to have all code in .h files. How should I put my code into files? 开发者_运维技巧Except for a few, I do not have very large classes. Most of my code is procedures and functions.

My two main concerns are efficiency and a decent standard of programming. Portability is not a concern right now.

Thank you very much!!

---

IMO, there is no need to be "C" compliant in 2010. Just use C++ and all its advantages (STL, boost, all that jazz... )

AFAIK, putting the code in header files is not normal practice, usually code goes in implementation files ( .c, .cpp, ... ).

Putting code in C/CPP files ( instead of header files) will let you optimize compile time dependencies (forward declarations, PIMPL, ... ) and limit the visibility of non-public data that you do not want "users" of some piece of code to see.

Using standard libraries will help the stability, readability and maintenance of code in the long run by reducing the potential bugs that can/will happen when dealing the complex structures and algorithms (for example, it's easier to deal with std::vector than arrays and std::string than char*)

M.

---

As far as the .h/.c/.cpp stuff goes, interfaces go in header files and things that get compiled go in .c/cpp files.

So if you have a module that calculates widgets, you'd put the calculate_widget function prototype in the .h file and the code that actually does it in the .c file. Any other module that wants to calculate widgets #includes widgetcalc.h and calls calculate_widgets. Any code not called by external modules can then be declared in static functions, which helps with optimization and keeps your namespaces from clashing.

As a general rule, if a line of code compiles to some number of processor instructions, it does not belong in a .h file.

---

If the file you compile is has a "C" extension it will be compiled as C. If it is called "CPP" it will compile as C++.

If want to use C++ features, I reccomend to make everything c++, it makes life simpler. C++ looks very much like C and does not cost anything unless you use C++ features.