My Opinion on the good C ++ code style-and the practical value of boost Engineering

On toplanguage, a discussion about "Boost concepts and engineering practical value" (http://groups.google.com/group/pongba/browse_thread/thread/7501f6ff39b7ff0) attracted a lot of people. Here I will talk about my views.

 

Undoubtedly, boost is an excellent library (specifically, it is a collection of libraries ). But when I introduced the reason for my stdext library, I did not say that boost went wrong. The reason for this lies in my opinion on what is a good C ++ code style.

 

First, beauty is simple. If one thing can be done in a simple way, do not just make great effort to create syntactic sugar. There are many examples in boost, such as boost: Lambda, boost: shared_ptr, and boost_foreach. For boost: Lambda and boost_foreach, I prefer to introduce relevant mechanisms at the language level. Without a language mechanism, writing a few more lines of code is not difficult at all (boost: Lambda can be done by writing a function-like class, and it is easy to debug. Although Lambda has few code lines, but without the convenience of debugging, it is not worth the candle; boost_foreach can use the standard for (IT = Cont. begin (); it! = Cont. End (); ++ it ). As for Boost: shared_ptr is not a syntactic sugar, but an effective memory management mechanism, which is highly controversial. I never think that smart pointers can solve the memory leakage problem (it works effectively in a relatively simple and closed engineering environment, but it cannot adapt to more complex environments ), in fact, I will use smart pointers in addition to COM, which is rarely used in other cases.

 

Of course, syntactic sugar may sometimes be the only option, such as boost spirit and boost xpressive. These two libraries are designed to achieve a static regular syntax (3rd Similar libraries are tpl I wrote ). Syntactic sugar is elegant in describing regular grammar. For another example, if we want to implement a matrix library, although the Add function can also be used for addition, it seems much more elegant to use operator + for matrix addition.

 

Second, the project should form a functional closure. Any project should have a clear goal and problem domain. As a result, the function set of the project should have a limit, rather than continuing to expand. From the perspective of boost sub-databases, there is no problem. But from the overall perspective of boost, It is very problematic because it is just a theme-free hodgedge. There is no physical sub-database division and target limitation, which is the most failed point in my opinion.

 

Third, the principle of minimum external dependency. When implementing a project, we need to carefully evaluate which external libraries we will depend on and minimize such dependencies as much as possible. If the components we need have a very high degree of overlap with a library, we say that we need this library. On the contrary, if we only need a helper class in a library, we may wish to introduce this library without thinking about it.

 

The principle of minimum external dependency is not only applicable to projects, but also to the implementation of a single source code file (CPP. In fact, we also need to be cautious about the header files that a CPP contains and whether these header files are actually the normal dependencies of the CPP. It may not be as serious as engineering dependencies, but taking this seriously will improve your design level.

 

The principle of minimum external dependency is an important reason why boost cannot be widely adopted and used. Or is it because boost is a hodgedge with no sub-database division or target limitation, which leaves people who want to use boost out of the box and cannot clearly assess whether boost is suitable for their own projects.