In a C++ project, compilation dependencies can make a software project difficult to maintain. What are some of the best practices for limiting dependencies, both within a module and across modules?
相关问题
- Sorting 3 numbers without branching [closed]
- How to compile C++ code in GDB?
- Why does const allow implicit conversion of refere
- thread_local variables initialization
- What uses more memory in c++? An 2 ints or 2 funct
相关文章
- Class layout in C++: Why are members sometimes ord
- How to mock methods return object with deleted cop
- Which is the best way to multiply a large and spar
- C++ default constructor does not initialize pointe
- Selecting only the first few characters in a strin
- What exactly do pointers store? (C++)
- Converting glm::lookat matrix to quaternion and ba
- What is the correct way to declare and use a FILE
Herb Sutter has a great treatment of this exact topic in Items 26, 27 and 28, "Minimizing Compile-time Dependencies, Parts 1, 2 and 3", in his excellent book Exceptional C++, ISBN: 0201615622.
alt text http://ak.buy.com/db_assets/prod_images/489/30611489.jpg
IMHO, this is one of the best C++ programming books available.
Also take a look at:
Large-Scale C++ Software Design (Addison-Wesley Professional Computing Series)
I think you need to be very careful and considerate about this. Generally, you can limit dependencies by separating the code and using abstract interfaces (eg: function pointers or an object equivalent), but separation generally adds fragility. For example, you can call a module through a generic abstract interface to reduce the dependency on the actual object implementation, but you have to update the interface in sync with the object itself, or the code will fail at run-time.
I would say it's important to structure large projects in modules with a well-defined hierarchy, but within each module don't go overboard with breaking apart code to limit dependencies. If you're going for improved maintenance, you have to balance reducing dependencies with reducing code fragility.