policy based design of "modern c++ design"

[stereoMatching]

According to "modern c++ design", "effective c++", boost and loki.
I believe that policy based design is very powerful(not mentioning about TMP yet).

The idea of policy is pretty straight forward and easy, you don't need to be
a template wizard or know TMP very well before you could use it(you don't need to
know it at all if I have no make a mistake). Yet it is not so common it the world of
C++, except of boost and haiku test unit(AFAIK).

The idea of policy based class design is very attractive, yet it is not so popular
in the real world. Whatever, every design patterns or techniques have it own
strengths and weaknesses. Policy based design do have defects, like how to make the
policies become orthogonal, how to reduce the number of the policies and so on. But
what is the major defect of policy based design which make this attractive idea
not so popular?

Is it because policy based design not a good option for large scale project?Thanks
a lot.

[Paul McKenzie]

what is the major defect of policy based design which make this attractive idea not so popular?

It may not be popular because many, if not most C++ programmers have never heard of this type of design.

Regards,

Paul McKenzie

[nuzzle]

But what is the major defect of policy based design which make this attractive idea not so popular?

Isn't the mere use of templates making a design policy based?

You maybe just don't think of it as defining a policy when you factor out a certain type and make it a template parameter. But that's what it is, at least I think so.

[D_Drmmr]

The idea of policy based class design is very attractive, yet it is not so popular
in the real world. Whatever, every design patterns or techniques have it own
strengths and weaknesses. Policy based design do have defects, like how to make the
policies become orthogonal, how to reduce the number of the policies and so on. But
what is the major defect of policy based design which make this attractive idea
not so popular?

The only real defect that I can think of is the incomplete language support for this kind of programming - i.e. concepts - and the associated difficult-to-understand compiler errors you get when you use a template class incorrectly. But I don't think that's a major reason why a lot of C++ programmers or libraries don't use these kinds of techniques. I've also seen libraries that don't use STL or RAII (not just C++ wrappers around C libraries, but real C++ libraries as well). It's simply inertia to change.

[stereoMatching]

I just found more examples about policy(if no mistake)

the desktop environment providing ui policy and the X-server providing infrastructure.
lsass.exe providing the security policy and the NT kernel providing the infrastructure.

If I am correct, it is similar to strategy pattern, I would check on it and compare the
different between them.

(not just C++ wrappers around C libraries, but real C++ libraries as well)

C is part of(not 100% conform) C++, it is ok to use C++ like that as far as it work
only the problem of coding style + how many could you dig out the advantages of C++ over C
we don't need to use all of the features provided by C++

Thanks a lot

[Khiem]

You might have been working in several companies, from small to big, have you ever heard or been told that you should have applied patterns xxxx in this case, that case or that you should have fixed it this way, that way because it would have been better ??????????

I myself have heard of it only twice, this is the second time, seriously. I'm not going to beat your policy based design to nearly death, that's rude.

[nuzzle]

The only real defect that I can think of is the incomplete language support for this kind of programming - i.e. concepts

It's an important step, but I think template based design needs more than just improved language support. There must be a "theory" behind it and guidelines and best practices like there are in OO.

C++ STL is a template based design invented by Alexander Stepanov. He's very critical of the OO paradigm.

http://en.wikipedia.org/wiki/Alexand...iticism_of_OOP

I looked forward to his book Elements of Programming. Great I thought, finally there's going to be some theory of template programming or at least a beginning. It was nothing of that kind. Just the idea that "math" should form the basis of all programming.

To me this was a typical "the emperor has no clothes" moment. When the famous critic of OO finally presented his alternative it was, well "meak". Until template programming gets a solid design foundation it can only be considered a complement to OO design.

[superbonzo]

Until template programming gets a solid design foundation it can only be considered a complement to OO design.

I wonder how can you say this ... obviously there are programming areas where one is more suitable then the other, but I fail to see how generic programming would be a "complement" to OOP but not viceversa.

You can write software components relying on GP only in the same way you can write software components relying on OOP only, you could mix them but you usually don't just because they require different mindsets, guide lines and techniques, making their mixing more complex (and hence less useful) then their separation.

Clearly, the very idea of template programming is to write generic components, that are designed to be as much indipendent as possible from the programming area they will be ultimately used for;

so, it's not surprising that when one writes a complete program within a specifc programming area and goal, GP tends to be segregated at the implementation level, leaving to OOP the design and organization of components abstracting the "macroscopic" entities of the program.

But this is not the consequence of GP being inadequate to program design, it's just that a program is made of "universal" entities ( like containers and algorthms ) and "particular" entities ( like, say, a "Customer" object in a business accounting program ).

in the former case you need a scalable, abstraction-cost-free versitile programming model, that is GP

in the latter you need a programming model suitable for abstracting human related "things", that, mainly for linguistic reasons, tends to fit into hierarchies as "real things" do ( BTW, this was recognized by Plato something like 2500 years ago ! ); it has to be simple or breakable into patterns, because the majority of the programmer workforce will deal with it; it has to gracefully map to the runtime of the program, because most programmers tends to form a picture of software entities based on how objects "behaves" at runtime, etc ...

so, I'd say that GP and OOP are complementary, instead of one being one a mere "complement" of the other.

The idea of policy based class design is very attractive, yet it is not so popular in the real world.

I think that policy programming is popular as long as one recognizes its programming area of application, that is writing generic components; the point is that most programmers simply doesn't need to write generic components, because the goal of GP is to minimize the need of writing them, isn't it ?

you cited boost ( that in turn is made of many indipendent sublibraries that do use policies whenever they make sense ), but there's also STL itself ( containers allocators, unique pointer deleters, to cite a few ... ) these alone are more or less used in possibly the majority of c++ programs, isn't this sufficient to call them popular ?

[stereoMatching]

these alone are more or less used in possibly the majority of c++ programs, isn't this sufficient to call them popular

Popular on those famous libraries, but not so popular of my environment.
Atleast there are a lot of the jobs would require the programmers should have
strong knowledge about OOP but not GP, most of the jobs not even mention
about GP at all.
When I ask them why, some of them would say "because it is only suit for small projects
and simple cases, STL and boost are small, and they are designed to solve for those simple case,
they are not big and complicated enough, GP can't handle those complex large scale project"

[D_Drmmr]

C is part of(not 100% conform) C++, it is ok to use C++ like that as far as it work
only the problem of coding style + how many could you dig out the advantages of C++ over C
we don't need to use all of the features provided by C++

The particular case I had in mind was a C++ library with lots of functions returning char*, which were allocated in a thread local pool of dynamic arrays of char. Synchronization was performed using Lock and Unlock functions. When you compare this to returning a std::string and using an RAII object for locking mutexes, the code is bloated, hard to maintain and even 'unsafe' (memory leaks). But that doesn't mean that these modern C++ techniques are unpopular or unpractical. It just means that the library developers decided the benefit of changing all the code did not outweigh the cost/risk involved.

Popular on those famous libraries, but not so popular of my environment.
Atleast there are a lot of the jobs would require the programmers should have
strong knowledge about OOP but not GP, most of the jobs not even mention
about GP at all.
When I ask them why, some of them would say "because it is only suit for small projects
and simple cases, STL and boost are small, and they are designed to solve for those simple case,
they are not big and complicated enough, GP can't handle those complex large scale project"

I can recommend reading The Boost Graph Library if you want to get a better idea of GP. Having learned how to build/use graph libraries using OO techniques in university myself, this book gave me the insight that GP can be really powerful (in the right context; totally agree with superbonzo), but it is also really hard to develop a useful library using GP techniques. So it's only worth the effort if your code will be reused a lot.

[nuzzle]

I wonder how can you say this ... obviously there are programming areas where one is more suitable then the other, but I fail to see how generic programming would be a "complement" to OOP but not viceversa.

Well, how many general (application) design books based on generic programming have you seen?

[superbonzo]

Well, how many general (application) design books based on generic programming have you seen?

none, but for the same reason I've never seen an ornithology book based on the study of mammals ...

I echo the reasoning in post #8, adding that

even if it were a general language indipendent definition of GP as a design methodology as is with OOP ( and you correctly claim there isn't ), in order to write such a book one would need to break it into patterns easily and routinarily mappable to real world problems.

this is in contrast with the very nature of GP at least in two respects

1) GP is used to write "patterns" in the form of generic components, so you would essentially need a theory of patterns of patterns; even with such a theory, program designers would continue studying how to make programs, not how to make patterns to make programs.

2) OOP places a partial relation on types, GP works with heterogeneous arbitrary relations on types; therefore, such a theory would be necessarely much more complex then the OO theory, making it suitable to experts in any case. BTW, if you think about it, the more powerful concept programming is the more it will come near to the general non-programming related idea of "concept" ... therefore, such a general theory of concept design would be applicable to general problem solving or even philosophy as well, isn't this asking too much ?

[nuzzle]

...

even if it were a general language indipendent definition of GP as a design methodology as is with OOP ( and you correctly claim there isn't ), in order to write such a book one would need to break it into patterns easily and routinarily mappable to real world problems.

this is in contrast with the very nature of GP at least in two respects

...

I don't think there's something in the nature of GP that prevents it from becoming a design methology in its own right like OOP. In fact Mr. Stepanov made a promising attempt in his book Elements of Programming. It's in the first chapter called Foundations. He opens up with: "An abstract entity is an individual thing that is eternal and unchangeable, while a concrete entity is an individual thing that comes into and out of existence in space and time". I can understand the publisher got cold feet and threw in a co-author whose main task it seems to have been to keep Mr. Stepanov on earth. The book ended up kind of a library definition very much like Modern C++ Design by Alexandrescu. Interesting but does nothing to promote GP into the mainstream as a design methology. However I'd like to see Mr. Stepanov developing his GP ideas further in a new book but without co-author this time.

I don't see anything principal standing in the way of a sound theoretical foundation for GP. It just hasn't been done. Maybe people simply have been too buzy criticising OOP to have time for GP. Or maybe people have been discouraged. After seven years of hard work Mr. Stroustrup didn't even manage to get "concepts" into C++. He must be very tired of GP now. Some people have offered GP implementations of some of the GoF Design Patterns and that's fine but copycatting OOP is not enougth.

So in my view, until GP becomes a well-founded design methology it must be considered a complement to OOP.

[stereoMatching]

So in my view, until GP becomes a well-founded design methology it must be considered a complement to OOP.

But many(maybe most) best libraries of C++ are developed based on the ideas of GP and TMP
GP could implement those libraries which could provide highest or very good efficiency +
flexibility + type safe libs just like STL an many libraries in boost. Many of the features of
C++11 also implemented by GP and TMP.
If GP only a complement to OOP, the standard of C++ would not like today, and the performance
of C++ would not be so good.

[PredicateNormative]

I've found this an interesting discussion, but I think the core of the issue has been missed.

Template programming is very powerful, but from my experience the majority of programmers don't really understand how to write templates (at least not past a basic function template or class template). Sure, the majority of programmers know how to use templates (if they are given appropriate documentation and example usage), however, for most, the action of writing a template that is even remotely complex is a positively alien to them.

I've worked for two very large companies, and in both companies, those who have a good understanding of how to write templates tend to be few and far between. To give an example, on the floor I am on there are around 80 developers, of those, approximately 15 have ever written a template; of those 15, only about 5 have written non-trivial templates and of those 5, only two of us write non-trivial templates on a regular basis. For practical reasons, the company doesn't encourage the development of non-trivial templates because the majority of developers are unable to maintain them. Having spoken with colleagues the situation is very similar at other companies for which they have worked.

I have many books on my desk, Modern C++ Design being one of them; occasionally a random developer will come along and pick that book up and take a quick look; however, so far the only response I have ever had is that without fail they quickly put it back, some even muttering something along the lines of "that would make my head explode" - they then pick another book.

So, to answer the question of the OP "But what is the major defect of policy based design which make this attractive idea not so popular?", I would say the biggest obstacle is that, in order to understand policy based design and how to apply it, a programmer needs to have a good understanding of both OOP and templates, and the fact is that programmers that have a good handle on both (especially the latter) are a minority.

The fact that few programmers truly enter the template programming world means that Paul pretty much hit the nail on the head when he stated "It may not be popular because many, if not most C++ programmers have never heard of this type of design. ".