Quote:
|
Quote:
What C++ does do is save some of the work that would otherwise go into modifying a module. If you wanted to "extend" a structure in C (ie add new members to it) you would first need to make a copy of the original structure to do so. Any function that took the original structure as a parameter would have to be re-written for the new structure even if it did nothing different. If both structures are present in the same program then you would need to give the new functions different names (there is no "method overloading" in C). For a single programmer, this would mainly be just a copy and paste exercise and no great hardship. However, in a multi-programmer environment, there would be considerable scope for mis-communication. In C++ none of the foregoing is necessary. If you don't like the way a team mate has written a class, you can just make a derived class from it that is more to your liking. You can even make any instances of that derived class private to avoid making waves. |
Quote:
I define types in separate files and then include them into the code doing processing. So, if I initially have in separate file (say, 'foo_struct.h') : Code:
typedef struct Code:
typedef struct ... The horror and beauty of C++ is template engine, and C++ is overall more strictly typed language. |
As a single programmer working on a single program, what you have done is fine. However, if a team mate was in charge of that section of code, he might not appreciate you modifying his header file.
|
Quote:
Conceptually header files are derived from spec. |
Quote:
Kevin Barry |
Quote:
Quote:
EDIT: I see that you have clarified your post. |
Quote:
For example, I used to be VLSI project integrator, and part of my job duties was to maintain the project level header files. Designers did not change project level header files, I did not change block level header file. ... It is possible to have per developer extensions in "C", with some textual overhead, e.g. to begin with Code:
// contents of 'foo_body' include file Code:
// contents of 'foo_struct.h' include file Then "derived class" can be implemented as Code:
// contents of 'foo_struct.h' include file |
OK, so not impossible but it has definitely become more complicated than you originally made out.
Is there any reason why you would prefer your programmers to use C instead of C++ in the scenario you have outlined? |
Quote:
I reiterate: the two real IMO advantages of C++ is templates (with all their debugability horror) and overall better type strictness. IIRC, in 2011 stndard threads are part of C++ standard library, there is some lambda-calculus, better enums, etc. |
Quote:
|
Quote:
|
Quote:
If the other person hasn't gone to that trouble then you are back to copy and paste. Also, in either case, you can not use the other person's object file - you have to re-compile his source in order for the functions to use the extended structure. Method overriding is not possible in C. Code:
class A |
Quote:
What is impossible in "C" is to create a number of functions with the same name, but different signatures, and let the compiler choose the needed one according to number of arguments and their type. |
Quote:
If keeping the same names is not a matter of life and death, you can extend a struct and its "methods" in C without recompiling the original source in the following way: Code:
struct base_struct |
All times are GMT -5. The time now is 08:02 PM. |