policy based design of "modern c++ design"

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.

Quote:

---

Originally Posted by stereoMatching

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

Quote:

---

Originally Posted by stereoMatching

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.

Quote:

---

Originally Posted by stereoMatching

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.

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.

Quote:

---

(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

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.

Quote:

---

Originally Posted by D_Drmmr

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.

Quote:

---

Originally Posted by nuzzle

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 ! :eek: ); 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.

Quote:

---

Originally Posted by stereoMatching

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 ?

Quote:

---

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"

Quote:

---

Originally Posted by stereoMatching

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.

Quote:

---

Originally Posted by stereoMatching

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.

Quote:

---

Originally Posted by superbonzo

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?

Quote:

---

Originally Posted by nuzzle

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 ?

Quote:

---

Originally Posted by superbonzo

...

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.

Code:

---

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.

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. ".

Quote:

---

Originally Posted by stereoMatching

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"

---

Whoever has said the above to you is missing the point of template programming and has made an incorrect and misguided statement. Many large projects use a combination of OOP and templates in harmony to solve complex problems. Generally, templates are not a complete solution, but can used be a very powerful means to an end.

In addition, the person who made the above statement has little understanding of scalable architecture. The reason why I state this is that at the end of the day, a properly architected large project can be broken down into a hierarchy of smaller resuable sub-components. Thus, it can be argued that large projects are made of many smaller (simple) projects. Thus, the argument that "because [GP] 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" clearly misses the point of how larger projects are constructed.

Quote:

---

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.

---

Do that means I am learning a powerful design philosophy but can't be used or better don't
use it in the real case?

I was finding a way to produce better abstraction codes without any performance degrade, when
I found GP and TMP, they make me very excited.

Quote:

---

a programmer needs to have a good understanding of both OOP and templates

---

Looks like I have some mistakes about policy based design if policy based design is so difficult.
I am not very good at OOP or template, only know the basic ideas of them and study a few of
design patterns. Please correct me if I get the wrong idea of it.

For me, policy based design only try to composite different strategies(could be everything) into
a body, you don't need to(but could) inherits those policy(or policies)
you could just composite them(treat them as private data member) to generate
different types or even apply those policy(s) on function.

Each of them have their own advantages and weakness, the main idea is extract those "polymorphic"
actions from the body and make them become orthogonal policy(s) as best as you can.
The idea is a little bit different than the "is a" relationship of OOP(more like "has a" or "is
implemented by") when you try to combine those policy(s). It is a small "compiler" which help you
generate codes same as those handcrafted codes.

Quote:

---

Originally Posted by superbonzo

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 ?

---

I don't think it's as hard as you make it. OOP and GP are based on two different kinds of polymorphism namely inclusion (or subtype) polymorphism and parametric polymorphism respectively. The latter is sometimes also called generics hence GP (and templates is a static form of generics).

Now what programming paradigm corresponds best to parametric polymorphism? That's right, it's functional programming. So a theory of GP design must approach program design from a functional point of view. It must convey a view of the world based on functional concepts.

This thread has helped me organize my thought on this matter and I've somewhat changed my mind. I now think that GP may be an alternative to OOP as a design methology for C++ if it's approached in the broader context of functional programming and not limited to just templates.

Quote:

---

Originally Posted by stereoMatching

Do that means I am learning a powerful design philosophy but can't be used or better don't
use it in the real case?

---

No, all it means is that the majority of programmers will not be able to easily maintain the code - that does not necessarily mean you will be discouraged from writing templates and taking advantage of policy based design. All I am saying is, that the fact that most programmers will not be able to maintain that code is the reason why companies in general do not encourage template programming.

The company I currently work for does not generally encourage template programming, however, it is very happy for complex templates to be written where there is good justification as long as they are well documented.

Quote:

---

Originally Posted by stereoMatching

I was finding a way to produce better abstraction codes without any performance degrade, when
I found GP and TMP, they make me very excited.

---

That is where templates can really come into their own. I use policy based design and TMP in code that I develop for a number of in-house libraries. The end result is that I can push a large number of decisions down to compile-time, and thus levy a good run-time performance benefit. However, I would give a word of caution, if you are writing code for a company, then I would advise that you don't get too elaborate with TMP - a little bit is fine, but it should be well documented and well justified. In addition, avoid complex template declarations on classes that you intend to be used by the user of your library; firstly, it will scare prospective users away, and secondly it is good practice to ensure that libraries are easy to use, even if that means that making the interface easy makes the library harder to write.

Quote:

---

Originally Posted by stereoMatching

Looks like I have some mistakes about policy based design if policy based design is so difficult.
I am not very good at OOP or template, only know the basic ideas of them and study a few of
design patterns. Please correct me if I get the wrong idea of it.

---

Only having a basic understanding of OOP and templates should not stop you from getting into policy based design. As you make mistakes, then out of necessity you will learn a lot, both in respect to object orientation and template programming.

Here is a reason, why a lot of companies will not encourage their employees to write non-trivial templates. If you ever get into policy based design with a bit of MTP mixed in, then expect to get some relatively crazy template errors. This is a single error from some of my code that I am developing (my own personal library that I was considering open sourcing at one point - hence the name). There are plenty more errors of equal length generated (61 to be precise) as a result of the root of this error. Although the last few words of the error state what the reason is, they don't state the cause... that's hopefully wrapped up in the three pages of trace output for the error. What I mean by "it doesn't state the cause" is that there is an appropriate operator+ function defined (at least as far as intention goes), but it is probably being messed up by an incorrect typedef somewhere. The Microsoft compiler fails on the same line, but it expresses the error in a different way, stating that it cannot deduce template arguments and attempts to match against types that shouldn't even come into the equation (around different 100 types, about 90 of which are from the STL which is a little strange). Anyway, it's always good to have more than one compiler at hand when something like this happens, since sometimes one tracks the error down in a more concise manner than the other (although in this case both are pretty verbose)! :)

Code:

---

/home/andrew/projects/OpenTemplateLibrary/otl/ip/detail/image/assignable_pixel.hpp:  In function ‘void otl::ip::detail::image::assign_iterators(Iterator,
otl::ip::detail::image::data_type::configuration_category::interleaved,  const otl::ip::detail::dimensions&,  otl::ip::detail::image::data_type::triplet_block,
Iterator2&, Iterator2&, Iterator2&) [with Iterator =  otl::detail::random_access_iterator<const unsigned char>,  Iterator2 = otl::iterator::pattern_iterator<
otl::detail::random_access_iterator<const unsigned char>, 1u,  3>, otl::ip::detail::image::data_type::triplet_block =  otl::ip::detail::image::data_type::block<
3u, 1u, 3u, 3u, otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>]’:
/home/andrew/projects/OpenTemplateLibrary/otl/ip/detail/image/pixel_iterator_impl.hpp:195:7:    instantiated from ‘otl::ip::detail::image::pixel_iterator_impl<
Iterator, DataType,  otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>::pixel_iterator_impl(Iterator,  const otl::ip::detail::dimensions&)
[with Iterator = otl::detail::random_access_iterator<const unsigned  char>, DataType =  otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<
otl::ip::detail::image::data_type::block<3u, 1u, 3u, 3u,  otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>, 
otl::ip::detail::image::data_type::configuration_category::interleaved> >]’
/home/andrew/projects/OpenTemplateLibrary/otl/ip/detail/image/pixel_iterator.hpp:48:48:    instantiated from  ‘otl::ip::detail::image::pixel_iterator<Iterator,
DataType>::pixel_iterator(Iterator, const  otl::ip::detail::dimensions&) [with Iterator =  otl::detail::random_access_iterator<const unsigned char>, DataType  =
otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<otl::ip::detail::image::data_type::block<3u,  1u, 3u, 3u,
otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>,  otl::ip::detail::image::data_type::configuration_category::interleaved>  >]’
/home/andrew/projects/OpenTemplateLibrary/otl/ip/image.hpp:93:97:    instantiated from ‘otl::ip::image<T, DataType,  Container>::const_pixel_iterator otl::ip::image<T, DataType,
Container>::pixel_begin() const [with T = unsigned char, DataType =  otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<
otl::ip::detail::image::data_type::block<3u, 1u, 3u, 3u,  otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>, 
otl::ip::detail::image::data_type::configuration_category::interleaved>  >, Container = otl::buffer<unsigned char>,  otl::ip::image<T, DataType, Container>::const_pixel_iterator
=  otl::ip::detail::image::pixel_iterator<otl::detail::random_access_iterator<const  unsigned char>, otl::ip::detail::image::data_type::rgb_type<
otl::ip::detail::image::data_type::data_layout<otl::ip::detail::image::data_type::block<3u, 1u, 3u, 3u,
otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>,  otl::ip::detail::image::data_type::configuration_category::interleaved>  > >,
typename otl::ip::detail::image::header<DataType>::data_type =  otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<
otl::ip::detail::image::data_type::block<3u, 1u, 3u, 3u,  otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>, 
otl::ip::detail::image::data_type::configuration_category::interleaved>  >, typename Container::const_iterator =  otl::detail::random_access_iterator<const unsigned char>]’
/home/andrew/projects/OpenTemplateLibrary/otl/ip/algorithm/detail/cpu_colour_conversion/change_configuration.hpp:24:8:    instantiated from
‘static void  otl::ip::algorithm::detail::cpu_colour_conversion::change_configuration::run(const  otl::ip::image<Ty1, BaseDataType<ConfigurationCategory1>,  Container1>&,
otl::ip::image<Ty2, BaseDataType<ConfigurationCategory2>,  Container2>&) [with Ty1 = unsigned char, Ty2 = unsigned char,  ConfigurationCategory1 =
otl::ip::detail::image::data_type::data_layout<otl::ip::detail::image::data_type::block<3u, 1u, 3u, 3u,
otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>,  otl::ip::detail::image::data_type::configuration_category::interleaved>, 
ConfigurationCategory2 =  otl::ip::detail::image::data_type::data_layout<otl::ip::detail::image::data_type::block<3u,  1u, 3u, 3u,
otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>,  otl::ip::detail::image::data_type::configuration_category::interleaved>,  Container1 =
otl::buffer<unsigned char>, Container2 = otl::buffer<unsigned  char>, BaseDataType = otl::ip::detail::image::data_type::rgb_type]’
/home/andrew/projects/OpenTemplateLibrary/otl/ip/algorithm/detail/translate.hpp:312:5:    instantiated from ‘void otl::ip::algorithm::detail::translate_impl(
const otl::ip::image<Ty1, BaseDataType<ConfigurationCategory1>,  Container1>&, otl::ip::image<Ty2,  BaseDataType<ConfigurationCategory2>, Container2>&)
[with ConversionDefinition = otl::ip::cpu_colour_conversion, Ty1 =  unsigned char, ConfigurationCategory1 =  otl::ip::detail::image::data_type::data_layout<
otl::ip::detail::image::data_type::block<3u, 1u, 3u, 3u,  otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>, 
otl::ip::detail::image::data_type::configuration_category::interleaved>,  Container1 = otl::buffer<unsigned char>, Ty2 = unsigned char,  ConfigurationCategory2 =
otl::ip::detail::image::data_type::data_layout<otl::ip::detail::image::data_type::block<3u, 1u, 3u, 3u,
otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>,  otl::ip::detail::image::data_type::configuration_category::interleaved>, 
Container2 = otl::buffer<unsigned char>, BaseDataType = otl::ip::detail::image::data_type::rgb_type]’
/home/andrew/projects/OpenTemplateLibrary/otl/ip/algorithm/translate.hpp:15:5:    instantiated from ‘void otl::ip::algorithm::translate(const  SourceImageType&,
DestinationImageType&) [with ConversionDefinition =  otl::ip::cpu_colour_conversion, SourceImageType =  otl::ip::image<unsigned char,
otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<otl::ip::detail::image::data_type::block<3u,  1u, 3u, 3u,
otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>,  otl::ip::detail::image::data_type::configuration_category::interleaved>  > >,
DestinationImageType = otl::ip::image<unsigned char,  otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<
otl::ip::detail::image::data_type::block<3u, 1u, 3u, 3u,  otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>, 
otl::ip::detail::image::data_type::configuration_category::interleaved> > >]’
/home/andrew/projects/OpenTemplateLibrary/otl/ip/detail/file/pnm.hpp:167:7:    instantiated from ‘static void  otl::ip::detail::file::pnm<ConversionDefinition>::load_data_(
std::istream&, const otl::ip::detail::file::pnm_detail::header&,  otl::ip::image<T, DataType, Container>&) [with  DestinationValueType = unsigned char, DestinationDataType =
otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<otl::ip::detail::image::data_type::block<3u,  1u, 3u, 3u,
otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>,  otl::ip::detail::image::data_type::configuration_category::interleaved>  >,
T = unsigned char, DataType =  otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<otl::ip::detail::image::data_type::block<
3u, 1u, 3u, 3u, otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>,
otl::ip::detail::image::data_type::configuration_category::interleaved>  >, Container = otl::buffer<unsigned char>,  ConversionDefinition = otl::ip::cpu_colour_conversion,
std::istream = std::basic_istream<char>]’
/home/andrew/projects/OpenTemplateLibrary/otl/ip/detail/file/pnm.hpp:153:9:    instantiated from ‘static void  otl::ip::detail::file::pnm<ConversionDefinition>::load_(
std::istream&, const otl::ip::detail::file::pnm_detail::header&,  otl::ip::image<T, DataType, Container>&) [with  DestinationDataType =
otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<otl::ip::detail::image::data_type::block<3u,  1u, 3u, 3u,
otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>,  otl::ip::detail::image::data_type::configuration_category::interleaved>  >,
T = unsigned char, DataType =  otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<otl::ip::detail::image::data_type::block<
3u, 1u, 3u, 3u, otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>,
otl::ip::detail::image::data_type::configuration_category::interleaved>  >, Container = otl::buffer<unsigned char>,  ConversionDefinition = otl::ip::cpu_colour_conversion,
std::istream = std::basic_istream<char>]’
/home/andrew/projects/OpenTemplateLibrary/otl/ip/detail/file/pnm.hpp:106:9:    instantiated from ‘static void  otl::ip::detail::file::pnm<ConversionDefinition>::load(
const std::string&, otl::ip::image<T, DataType,  Container>&) [with T = unsigned char, DataType =  otl::ip::detail::image::data_type::rgb_type<
otl::ip::detail::image::data_type::data_layout<otl::ip::detail::image::data_type::block<3u, 1u, 3u, 3u,
otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>,  otl::ip::detail::image::data_type::configuration_category::interleaved>  >,
Container = otl::buffer<unsigned char>, ConversionDefinition =  otl::ip::cpu_colour_conversion, std::string =  std::basic_string<char>]’
/home/andrew/projects/OpenTemplateLibrary/otl/ip/file.hpp:63:7:    instantiated from ‘static void  otl::ip::file<ConversionDefinition>::load_pnm(const  std::string&,
otl::ip::image<T, DataType, Container>&) [with T = unsigned  char, DataType =  otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<
otl::ip::detail::image::data_type::block<3u, 1u, 3u, 3u,  otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>, 
otl::ip::detail::image::data_type::configuration_category::interleaved>  >, Container = otl::buffer<unsigned char>,  ConversionDefinition = otl::ip::cpu_colour_conversion,
std::string = std::basic_string<char>]’
/home/andrew/projects/OpenTemplateLibrary/otl/ip/file.hpp:36:33:    instantiated from ‘static void  otl::ip::file<ConversionDefinition>::load(const std::string&,
otl::ip::image<T, DataType, Container>&) [with T = unsigned  char, DataType =  otl::ip::detail::image::data_type::rgb_type<otl::ip::detail::image::data_type::data_layout<
otl::ip::detail::image::data_type::block<3u, 1u, 3u, 3u,  otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>, 
otl::ip::detail::image::data_type::configuration_category::interleaved>  >, Container = otl::buffer<unsigned char>,  ConversionDefinition = otl::ip::cpu_colour_conversion,
std::string = std::basic_string<char>]’
/home/andrew/.codelite/workspace/main.cpp:11:97:  instantiated from here
/home/andrew/projects/OpenTemplateLibrary/otl/ip/detail/image/assignable_pixel.hpp:149:5:  error: no match for ‘operator+’ in ‘position + 1’

---

I guess it'll probably take me a while to sift through the error to figure out what's wrong with the code, but that's life. However, there is a point that I would like to make, and that is, that although an error like the above looks crazy; by the time you remove all of the namespace information and format it into a more manageable form, it's generally pretty easy to follow to figure out what the compiler is complaining about. Therefore, the point that I would like to make, is that if you get into template programming and see an error like the above, don't be put off - it's probably not all that bad.

What I really don't understand is why such error messages always seem to come in the form 'error - instantiated from - ... - instantiated from - my code'. At least 99% of the time I (as a programmer) am interested only in the last part or last few parts. If the order of the parts was simply reversed in the compiler output, figuring out what such an error means would be so much easier.

I agree, a reversed template "call stack" would be helpful; anyway, I think it's more an IDE related issue; the IDE should be responsible of processing the compiler output graphically in a way similar to how the debugger shows the runtime state of variables.
In this way, the compiler would be free of outputting all the information it has about a failing template instantiation ( as now stands, often is too much, sometime is too little ) and the IDE would present it in a nice graphical way, with full on demand info on the whole instantiation tree.

Another issue is at the language support level, it's just too easy to invoke compiler bugs when working with templates ... ( at least in vc++ )

Quote:

---

Anyway, it's always good to have more than one compiler at hand when something like this happens, since sometimes one tracks the error down in a more concise manner than the other

---

I find out that the error messages of gcc4.6.2 is much more easy to understand than the error
messages generated by vc2010.

Quote:

---

by the time you remove all of the namespace information and format it into a more manageable form, it's generally pretty easy to follow to figure out what the compiler is complaining about.

---

I hope so, this technique is mentioned by item49 of "effective stl", looks like I have to take a look
at it since I always play with template

The thing that I would like to see is for the compiler output not to simply be displayed as plain text. For example it would be nice if:

Code:

---

In function ‘void otl::ip::detail::image::assign_iterators(Iterator,
otl::ip::detail::image::data_type::configuration_category::interleaved,  const otl::ip::detail::dimensions&,  otl::ip::detail::image::data_type::triplet_block,
Iterator2&, Iterator2&, Iterator2&) [with Iterator =  otl::detail::random_access_iterator<const unsigned char>,  Iterator2 = otl::iterator::pattern_iterator<
otl::detail::random_access_iterator<const unsigned char>, 1u,  3>, otl::ip::detail::image::data_type::triplet_block =  otl::ip::detail::image::data_type::block<
3u, 1u, 3u, 3u, otl::ip::detail::image::data_type::data_configuration_description::three_plane_data>]’:

---

was displayed like:

Code:

---

In function

‘void assign_iterators(Iterator, interleaved,  const dimensions&,  triplet_block, Iterator2&, Iterator2&, Iterator2&)

[with
  Iterator =  random_access_iterator<const unsigned char>,   
  Iterator2 = pattern_iterator<random_access_iterator<const unsigned char>, 1u,  3>,
  triplet_block =  block<3u, 1u, 3u, 3u, three_plane_data>
]’:

---

where you could hover the mouse pointer over each item and it would tell you the namespace information about it.

I also agree that a reverse stack for each error might be helpful.

Quote:

---

Originally Posted by PredicateNormative

The thing that I would like to see is for the compiler output not to simply be displayed as plain text. For example it would be nice if:

---

I believe there was a program that simplified the compiler output for template errors. Don't remember the name now, but I definitely know it existed.

Don't hold me to it, but I believe it was called C++ Filt or something like that.

Regards,

Paul McKenzie

Quote:

---

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.

---

Very true! I've found that of those that don't understand, some will pick it up very quickly, while others never quite seem to grasp it.

I've used a lot of template programming in the last few years, but almost all of it was in the implementation of an internal common library. For the users of the library (the other coders in the team), there was very little template knowledge required to use it, except for the very occasional template parameter to help the compiler resolve an abiguity. It was only if someone were to want to modify or add to the library would an in-depth knowledge of templates be required.

Quote:

---

Very true! I've found that of those that don't understand, some will pick it up very quickly, while others never quite seem to grasp it.

---

Maybe that is why so many programmers don't believe template could give a hand on balancing
between performance, robustness and abstraction.

Looks like C++ has to find a better way to make template become more instinct
Atleast it should make the users have a better feeling about "compile time cost" and "run time cost"

Quote:

---

Originally Posted by Paul McKenzie

I believe there was a program that simplified the compiler output for template errors. Don't remember the name now, but I definitely know it existed.

Don't hold me to it, but I believe it was called C++ Filt or something like that.

Regards,

Paul McKenzie

---

You may be thinking of stlfilt (http://www.bdsoft.com/tools/stlfilt.html). I've never used it but it looks quite useful.

Quote:

---

Originally Posted by Paul McKenzie

I believe there was a program that simplified the compiler output for template errors. Don't remember the name now, but I definitely know it existed.

Don't hold me to it, but I believe it was called C++ Filt or something like that.

Regards,

Paul McKenzie

---

I have heard that such things exist, but I've never tried one... given the amount of template code I write I'm beginning to think that it would be a good thing. Thanks for the advice.

Quote:

---

Originally Posted by Peter_B

You may be thinking of stlfilt (http://www.bdsoft.com/tools/stlfilt.html). I've never used it but it looks quite useful.

---

Thanks for the link, I'll take a look.